Perhaps this isn’t true of the development community in general, but my experience with the Java community is that people don’t appreciate that syntax makes a difference: I’ve had numerous debates on various forums about why Java should have closures, for example, and the pushback always takes the form of “you can already do that in Java, so we don’t need closures.”

To what extent do the people offering pushback actually know more than one language? And “I programmed in X for two weeks back in college” doesn’t count it. Nor does “I know both Java and C#!” (which reminds me of the joke from the Blues Brothers- “We play both kinds of music here- country and western!”).

Java and C++ are especially bad with this- with the rise of schools that taught Java or C++ as first programming languages, it’s now possible for someone to have gotten a degree in CS, and have 5-10 years of professional development experience, and never learned a second language.

At which point, Robert’s comment really doesn’t hold. If you only have one point of view, you have no depth perception- and if you only know one language, you have no ability to judge the advantage or disadvantage of adding a given feature to the lanuage (or the advantage or disadvantage of other languages).

Perhaps this isn’t true of the development community in general, but my experience with the Java community is that people don’t appreciate that syntax makes a difference: I’ve had numerous debates on various forums about why Java should have closures, for example, and the pushback always takes the form of “you can already do that in Java, so we don’t need closures.” So I was just trying to emphasize that saying “we can already do X” is not in itself a good reason for rejecting better ways to do X. Developers in general are often far too defensive about their tools, languages, and techniques, and there’s a large lost opportunity for improvement as a result.

It is interesting that the arguments start to sound the same; everyone’s trying to get to the same place as far as more expressive, less-verbose, harder to screw up, more maintainable code, people just disagree on how exactly to get there. And inevitably people gravitate towards the tools they’re most familiar with (including me), which makes it difficult to truly be objective about what tradeoffs we’re really making when we choose static or dynamic typing. GScript’s type system pushes it much closer to the Java camp than to the Ocaml camp, which at least is an improvement thanks to type inference and lets us do certain kinds of metaprogramming, but the Ocaml type system really seems like more of the “right thing.” I appreciate the effort to point out to people that static typing doesn’t have to suck, though; far too often people assume “static typing” implies something in the C/Java mold along with all their limitations.

I’m kinda with Thomas: yeah, syntax is a big deal, and I’m not sure there are people out there who deny that. Maybe there are people out there who deny the importance of syntax and other language design considerations, but I don’t really see them. Basically, if you know more than one language, it’s hard to not recognize the differences between them: there’s a practical impact that’s pretty obvious pretty fast. As my co-blogger, Brian Hurt, puts it: “It’s not what a programming language make possible, it’s what a programming language make easy which determines what patterns are common and what patterns aren’t.”[1]

One really interesting thing did jump out with me from this post, though, and it apparently piqued Raganwald, too:
“Less code takes longer to write, but the real benefits are around maintenance: less code means less of a chance of bugs, less to keep in your head, less for someone else (or yourself 6 months later) to read through and learn, less to test, and less to modify when you change the rest of the system.”

Just s/less code/type checked code/g and this sounds exactly like my argumentation for static typing, particularly given the more compact syntax of implied static typing languages like Ocaml [2]. It’s really funny.

[1] http://enfranchisedmind.com/blog/2007/07/10/the-hole-in-the-middle-pattern
[2] http://enfranchisedmind.com/blog/2008/04/14/useful-things-about-static-typing/

I think that’s a great analogy, and I think you put it much more succinctly than I did in distinguishing between syntax mattering and syntax being imperative.

@Daniel:

That’s a great point about expressiveness. I was trying to make a point like that with the “map” example: in GScript, Ruby, or Python there’s one canonical way to do it, whereas a language like Java has too many options that, as you say, give you the ability to either screw it up or at least make it confusing to the reader. Likewise, I’m sure there are even more ways to code that in x86 assembler.

I also like the analyze this using the concept of “chunking” of short-term memory, whereby most can keep (I believe) 7 +/- 2 “chunks” in their head at one time, so the key to keeping more in your head is to have those chunks contain more information (whole words instead of individual letters, for example). Something like “map” is a pre-made chunk, whereas the Java for loop is about 3 or 4 different chunks, so it becomes harder to keep the whole program in your head. That’s naturally also an argument for decomposition, which is also key, but languages that encourage you to write in higher-level chunks will naturally lead to programs that are easier to get your head around.

You can also think of chunks in terms of things like chess openings; becoming a grand-master chess player is very much about having pre-built chunks to draw from stored in long-term memory. Higher-level languages give you those pre-built chunks that you can store in your mental backpack and pull out more easily when necessary (either when reading or writing), while less-expressive languages make that harder to do.

Here’s the really nasty bit about this: if I write in 500 lines of Blub what you write in (say) 50 lines of Lisp, it’s

When we say things like “these 500 lines of java would be 50 lines of ruby, or 20 of lisp,” it sounds like it’s trivial to translate the other way, to turn 50 ruby lines into 500 java lines, like they’re equivalent. But of course, it’s not: explain a 50-line ruby snip to 10 blub programmers, and you’ll get 10 very different 500-line blub programs.

Each line of code, each token, is a decision point, something to consider, and that’s where less-expressive languages hurt us: they put more decisions in our way, they give us more chances to screw up.