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.
I’ve argued before that above a certain mimimal level of clarity, expressiveness, and consistency, the choice of identifiers within a system has a greater effect on maintainability than does the syntax of a language. Of course, that presumes that the people responsible for developing that system are proficient in that language. (If not, you have a bigger maintenance problem than your choice of language or coding standards.)
A large part of choosing good identifiers is having a good understanding of the problem domain. What does the system do? What should it do? I’m a decent programmer, but if you plop me in the middle of a large insurance system written in COBOL, I’m in trouble for two very good reasons. First, I don’t know COBOL. Second, I don’t know anything about insurance!
Even so, people still believe that language syntax matters, and so they bring out the tired old “intuitive to novices” argument. No matter how often people repeat it, it’s still bunk.
Why?
Syntax doesn’t matter as much as semantics.
A programming language, its libraries, and its platforms and tools are just tools for expressing a solution. That solution depends on the problem! Any correct solution must express at least some of the semantics of the problem domain. How likely is a novice to understand those, and if the novice doesn’t understand those semantics, what does his or her opinion on what the program does matter?
Even further, no language is purely syntax. Every programming language also has underlying semantics–and those are rarely obvious when reading only the language’s syntax. Filling in the gaps is a matter of extrapolation and pattern matching through a series of hopefully-educated guesses–that is, intuition.
The same thing happens in natural languages. We call some of those guesses false cognates, because certain words or constructs or parts of speech look superficially similar between languages, but they’re often very different.
Fortunately, human languages often have sufficient redundency and fuzziness that it’s still possible to communicate without too much difficulty in the face of false cognates and other errors (there’s that intuition again). Unfortunately, programming languages don’t.
Unless you know of a programming language that encodes all of its semantics completely in its syntax such that an interested but otherwise ignorant observer can explain the full behavior of a useful system within its problem domain, this is a lousy metric for judging the maintainability of a programming language.
Hey, dude. I wrote a short followup, posted here:
http://blog.plover.com/prog/intuitive-to-beginners.html
See you next week.
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.
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:
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.
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
@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.
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.
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.
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. :-)
@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.
"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.
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):
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:
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.
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.