Syntax Matters...?

<i>It is important, however, to distinguish between syntax and expressiveness. I don’t care (too much) whether you write function(x) { ... }, \x -&#62; ... or { |x| ... } to denote a closure, but there had better be a way to write a closure somehow! (Java, I’m looking at you here)</i><p>Java is the refutation, IMO: it <i>does</i> have a way to express a closure, it's just that the syntax (anonymous class) is laborious. You need to wrap up any mutable variables to be captured in final single-element arrays, and your closure type will be a single-method interface, but the expressiveness is there. The syntax just sucks.<p>The laborious syntax is what stops you from writing what may be expressed in C# as 'foo.Where(x =&#62; x.Name.Length &#62; 10).OrderBy(x =&#62; x.Name)' in Java. The equivalent, even using the smaller Javascript syntax of 'function(x) { return x.name.length &#62; 10; }', is tedious. The (current) Java syntax is just silly.<p>The syntax "weight" of a feature matters. Syntax that's light and unobtrusive invites use. Syntax that's large and clumsy dissuades use, to the point that whole libraries may not come into existence, not because of a lack of expressiveness in the language, but because of aesthetic ugliness.<p>Lisp has an out here because of macros; almost everything is equally ugly. Many people appear to consider this base level of ugliness unacceptable; others may see it as a flaw of Lisp, because the very malleability of the syntax makes it harder to encode implementation costs in the <i>form</i> of the program.

I don't agree that surface syntax doesn't matter unless it affects language functionality. Syntax is UI for programming languages, and UI for programming languages matters as surely as UI for other software matters. Fortunes have been won and lost on UI.<p>To me, the problem is that there is no answer to programming language syntax that pleases everybody. There are general aesthetic principles to follow, but the fundamental questions - semicolons vs. newlines, indentation vs. braces, short vs. long keywords - generate a lot more heat than light. We have to pick one and disappoint somebody.<p>Note that even in this thread, there is disagreement about whether JavaScript is too terse or too verbose!

Frankly, I've stopped using languages, or lost interest in learning languages, entire over "small" syntax issues. Syntax is a bigger potential deal-breaker to me than functionality in many cases - I spent many times more time reading code than molding my mental model of what I want to do into something I can write down as code in a particular language. If I can't read and scan code quickly, the language is dead to me.

Syntax matters. Take Erlang, great language that nobody learns because it looks and feels alien. Damien Katz, creator of CouchDB &#38; now Couchbase, is pretty convinced this is its main reason for lack of adoption: <a href="http://qconlondon.com/dl/qcon-london-2012/slides/DamienKatz_ErlangInTheRealWorldCouchDB.pdf" rel="nofollow">http://qconlondon.com/dl/qcon-london-2012/slides/DamienKatz_...</a> (~8 MB)

Well, there are two things here: syntax, and lexical form or lexical syntax -- the underlying structure and the textual representation. The term 'lexical form/syntax' ought to be more popularly used, and hence make it clearer to talk about exactly what we like or do not.

This touches on some really important relationships between programming languages and cognition.<p>Alan Kay has been studying how children take to programming and many of the ideas from Smalltalk come from these studies.<p>When designing for children, every part of the user interface, including the syntax of the programming language, matters a lot. For example, he writes, "If we take functional relationships as an example, it has been shown that children readily understand them but have considerable difficulty with variables, and much more difficulty with parameters. The standard math syntax for functions with parameters requires some extra trained chunks to associated dummy names with actual parameters. Some computer languages allow conventions for prefixing the actual parameters with the dummy names. This is good. For younger children, it's likely that making these into complete assignment statements is an even better idea. An object oriented language can use instance variables for a long time before introducing the idea of passing parameters in a method, etc. Having really good trace and single-step visualizations is critical." <a href="http://www.donhopkins.com/drupal/node/140" rel="nofollow">http://www.donhopkins.com/drupal/node/140</a><p>Children have different cognitive needs than adult programmers (and different needs from each other depending on age). But cognitive needs matter in designing programming languages for adults too. I personally take the optimistic (or cynical?) view that we have a lot of room to improve our programming interfaces (not just languages, but the entire programming experience viewed holistically).

Syntax matters for people who are just learning a new language. When I was learning to program I thought about code in terms of the pascal statements I had to write. Now I think about more abstract ideas, about data flow and control flow. I can map those ideas to the language I am using at any given moment but that only came after many years of experience.<p>On a different note, I have abstained from commenting on Rust's attitude toward keyword names but aside #2 just bothers me. Naming conventions matter and since Rust may possibly become used in the future it may inspire some new generation of users to learn to program. 20 years later they will start writing their own languages and think "Hey, I used 'ret' in Rust and that brings back good memories so I'll just keep using it!". Truly an embarrassing part of hacker culture.

The smalltalk difference is not just syntax. Smalltalk uses messages instead of function calls. It's a different concept because smalltalk object can handle messages that are not declared on the class body. If you changed the parameters order it would be a different message, and you would not have a compile error, because it would still be possible to an instance to answer that message.

I think good syntax won't make a language better but bad syntax can make a language worst<p>Its like you will not work for a company because it have clean toilets, but if they have dirty toilets you wont work for them<p>If you find this logic familiar, its because i am basing it on motivation theory

I have real problems reading a large volume of code in certain programming languages. With a lot of code, even if I'm not familiar with the language, I can scan it and understand the broad strokes and what it's doing very quickly.<p>There are two languages I can't do that with. Javascript and Lisp. For me, Lisp and Javascript's syntax is too sparse. I've even used Javascript for a few days every week for the last 10 years and I still can't 'scan' a large code file. I know how it works, I know how to use it, I know the good parts and all the tricks. But I still dread cracking open a misbehaving Jquery plugin or any home grown, even self-written, non-trivial code base in it.<p>With both of them it's a laborious process of actually having to load the whole code into my head, to remember what other functions are doing, how things are initialized. Perhaps you can call it laziness, but personally I only 'load' a whole code base into my memory when I'm doing significant work with it. It takes time and effort I don't want to have to put in just to make a tweak.<p>So not being able to just skim read code is intensely annoying.<p>And that's down to syntax. So to me syntax does matter and it's why I'll keep railing against javascript being the only available language in the browser. It's not just a matter of preference, it's also a matter of productivity. I at least, and I suspect many others, are not very productive with sparse syntactical languages because they're so hard to skim read.<p>EDIT: Some people have the gift/skill of memorizing things very quickly. I don't, I have the gift/skill of understanding things very quickly, which generally means I can get away with a weak memory. I think a lot of programmers have one of those two skills, but rarely both. Sparse syntax is a bane for the latter.

Brilliant