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.
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.