"Syntactic Sugar"
It frustrates me when I hear people dismiss the differences between computer languages. There really isn’t any difference between languages, the argument goes, because “all Turing complete language differ solely on syntactic sugar.”
That’s a direct quote from part twelve of Michele Simionato’s excellent The Adventures of a Pythonista in Schemeland, but I’ve got no beef with his articles. Like I say, they’ve been an excellent introduction to Scheme for me. However, I’ve seen this particular assertion – “all programming languages are the same because they’re all Turing complete” – used repeatedly as long as I’ve been a programmer. It drives me nuts.
Sure, it’s true on a technical level. Any computer language we write
gets interpreted and compiled down to machine code, so at a practical
level a C program with a for(;;)
loop and a Python list comprehension
might end up with the same values flowing over my registers and the same
instructions dropping into the CPU. But this reductionist view of
programming completely ignores the incredibly important role that
language plays in thought.
The traditional view of languages – human or computer – is that they’re a tool we use to express thought. But modern literary and linguistic theory holds that it’s a two way street: our thought drives our language, but the language we use leaves an indelible imprint on our thought processes. I’m not a linguist, but from what I can tell the Sapir-Whorf hypothesis is the main designator for this idea of language influencing thought.
There’s no question in my mind that this applies full-force to software development: different languages make it easier or harder to conceive of certain types and classes of algorithms. So-called “syntactic sugar” can make a big difference in efficiency: one language might naturally lend itself to writing a something close to the theoretically optimal case, while another might lead you towards a different, less efficient, solution.
Most importantly, though, is the way that computer languages intersect with our own thoughts. You’ll often a developer talk about how his favorite language “fits my brain” or “matches the way I think.” As a group of analytical types, we often dismiss these types of assertions in favor of more quantitative measurements of performance or memory consumption. But that’s a huge mistake: we’ll always be more productive in a language that promotes a type of thought with which we’re already familiar.