The Broken Metric of Intuitive to the Uneducated Language Syntax

by chromatic

I'm pretty good at Perl, so I hear a lot of comments about programming language syntax. Many of them are fluff around the old argument that "I don't like to read punctuation." Many of them bring up the silly idea that an ideal programming language syntax should be so intuitive that people who've never used the language before should be able to understand programs written in the language.

That's a ridiculous argument.


12 Comments

Mark Dominus
2007-07-20 10:07:53

Hey, dude. I wrote a short followup, posted here:
http://blog.plover.com/prog/intuitive-to-beginners.html


See you next week.


chromatic
2007-07-20 10:19:19
Thanks, MJD... you're right. I've never seen a beginner confused solely by syntax. Perhaps the best example is the dereferencing syntax in Perl 5, where the syntax *is* confusing, but mostly due to semantic problems with variadic sigils.


I suppose I've never cared if novices found syntax confusing (which you point out is important to prove, if the argument is to hold weight) because I never thought the resulting argument held weight.

Mark Dominus
2007-07-20 10:56:58
I see your point. Really, it's such a bankrupt argument, it's hard to know what part to refute first. :)


I also addressed something like this seven years ago:



The RFC author's counterpart of this tactic was to describe their own proposal as 'more intuitive' and 'elegant' and everything else as 'counter-intuitive' and 'ugly'. 'Elegant' appears to be RFCese for 'I don't have any concrete reason for believing that this would be better, but I like it anyway.'


http://www.perl.com/pub/a/2000/11/perl6rfc.html


Last week I was reading a nice paper about the failure of just about everyone to figure out just what was intuitive to beginning programmers, and i wanted to cite it in my blog post, but I cannot find it. I even scoured my office for the hardcopy and my /tmp directory for wandering PDF files.


But just as I finished that sentence, I remembered a search term and found it again! Check this out.


Daniel Billotte
2007-07-20 11:58:28
I agree that such an argument is bunk. Learning to program is hard and some very smart people just can't do it. I have a couple of friends who are finance or business wizards but were complete failures when it came to learning how to program.


That said, why would we want to design professional programming languages around the metric of "easy to understand by beginners"? When was the last time that you saw a beginner successfully writing software for an aerospace guidance system, a complicated high traffic web application, or a complex numerical analysis system? Short of the random genius, you don't.


If somebody wants to design a language whose main goal is to facilitate learning, then go right ahead. Maybe it will even find use in real-world systems. However, to design a language that is intended for production in an industrial application around the idea of "easy for beginners to learn" is like trying to design a competitive top-fuel dragster that is safe to drive for a 16 year old who is just learning how to drive.


I am not saying that an industrial quality language must be overly complex and hard to grok, but they should be designed for people who know how to program and with an emphasis on being good at solving real world problems. Leave the training wheels at school.


Reminds me of a funny picture. (no offense intended to PHP lovers and gurus. Each professional should use the language which they feel is most productive for their problem domain)


http://tnx.nl/php

chromatic
2007-07-20 12:06:59
@Daniel, I mostly agree... but one of the main goals for Python is learnability. I may not agree with all of its design choices, but the resulting language is both capable and powerful, and it's appropriate for plenty of industrial-strength problems.


Learnability and consistency are important, but sacrificing to the cult of the perpetual novice doesn't often get a technology very far.

Juliette
2007-07-21 04:08:46
It's the difference between learnability and usability. For programming languages, usability for people who have got over the learning curve is more important that learnability. Usability and learnability are often related however and usability is a good thing to strive for when designing a programming language (assuming you're not sacrificing utility of course).


Where learnability does matter is if you want a critical mass of people to use your programming language. But here, you're not aiming so much at novice programmers but programmers with experience in other languages and I suspect a programming language with high learnability for other programmers would look quite different from one with high learnability for novices.

Kurt Cagle
2007-07-22 17:17:14
I'd tend to agree with this point, and reflect upon it in my experiences in the declarative side of things. If you look at XML, you have a common syntax, but often wildly different semantics. Working with a complex RDF resource is far more difficult than working with XHTML, despite the fact that RDF has only a handful of tags, because the concepts involved, and the expressions of those concepts, can become esoteric quite rapidly. Similarly, while C++ and JavaScript have remarkably similar syntaxes, JavaScript is generally a far easier language to work with for most base cases precisely because the semantics and underlying concepts that JavaScript works with tends to be considerably more limited.
Ralph Corderoy
2007-07-23 15:31:21
It's a sticky wicket. Perl gain favour because it was a scripting language with Unix heritage that was more powerful than shell + awk + etc. That advantage has gone with languages like Python gaining popularity. Python has shown that it doesn't have to read like Perl to get the same job done in a nicer fashion.


Perl hasn't helped by going into self-imposed stasis due to Perl 6. Whoever threw mugs against a wall insisting something bigger be done must have been funded by the PSF. :-)

chromatic
2007-07-23 20:55:42
@Ralph, I think you may be disregarding CPAN for both points. Python has some good features (and a couple of libraries I wish Perl had), but it really doesn't have the CPAN. Also, the CPAN has grown tremendously in both breadth and quality since the initial Perl 6 announcement.
Robert
2007-07-24 10:24:09
"Perl hasn't helped by going into self-imposed stasis due to Perl 6."


I think he simply means that people ARE waiting to see on Perl 6. There *is* a lot going on in Perl 5 as Perl 5.10 shows.

Ovid
2007-07-29 09:45:40

As an former COBOL programmer, I can assure you that the idea that a language "should be intuitive for a non-programmer to read" is absolute bunk. It was believed that COBOL should be so easy that non-technical people should be able to at least read it. After all, don't you want your boss to read your code and tell you where you made logic errors? That led to monstrosities like this (borrowed from the Wikipedia COBOL article):


MULTIPLY B BY B GIVING B-SQUARED.  
MULTIPLY 4 BY A GIVING FOUR-A.
MULTIPLY FOUR-A BY C GIVING FOUR-A-C.
SUBTRACT FOUR-A-C FROM B-SQUARED GIVING RESULT-1.
COMPUTE RESULT-2 = RESULT-1 ** .5.
SUBTRACT B FROM RESULT-2 GIVING NUMERATOR.
MULTIPLY 2 BY A GIVING DENOMINATOR.
DIVIDE NUMERATOR BY DENOMINATOR GIVING X.


In fact, in the original version of COBOL, that is pretty close to how you would have to write that. Later versions of COBOL introduced operators and that allowed you to turn the above into this:


COMPUTE X = (-B + (B ** 2 - (4 * A * C)) **.5) / (2 * A).


Sure, that's still pretty tough to read, but hey, it's a complex formula.


Another interesting side effect of going too far to make things easier to read is the necessity of adding in all of those extra reserved words, making programming more difficult. I've seen plenty of times when programmers stumble on reserved words for column names in SQL since they tend to know SQL less than other languages.


As a counter-example, look at how simple Lisp is. Here's a simplified grammar (PDF):


<defn>       ::= <fn-defn> | <const-defn>
<const-defn> ::= [<comment>] <identifier> = <expr>
<comment> ::= ;;;<any string of characters>
<var> ::= <symbolic-atom>
<expr> ::= <value> | <identifier> | <fn-call> | <cond-expr> |<let-expr>
<value> ::= <numeric-atom> | " <symbolic-atom> " | <list>
<identifier> ::= <letter>{[-]<digit> | [-]<letter>}
<fn-call> ::= <identifier> [ <expr> {; <expr>} ]
<cond-expr> ::= [ <clause> { ;<clause>}]
<clause> ::= <expr> --> <expr>
<let-expr> ::= {<local-defn> { ; <local-defn>} : <expr> }
<local-defn> ::= <identifier> = <expr>
<fn-defn> ::= <identifier> [ <identifier> { ; <identifier>} ] = <expr>


See how simple that is? Regardless of how well you like Lisp, it's a powerful, expressive language that almost seems to go to extremes to not be human readable -- until you know Lisp.

GIlbert Healton
2007-07-31 18:17:29
Yes, the syntax alone does not make effective languages.


What I look at is how much effort does it take a competent developer to solve a problem, as compared with other languages, set up against the very weighty question of how much effort does it take to maintain the original code.


Some languages I've used have been sane, others insane, and others very strange. After I put the effort into learning new languages, I want them to be a useful tools rather than obstacles to overcome.


Make a language so simple that even a fool can use it,
and only fools will want to use it.


Choose whatever language you like,
Adopting all Computer Science advances,
It never has been, and never will be,
The least bit difficult to write
Bad programs.