Fetishizing Programming Languages
pathdependent.com
pathdependent.com
Technically, of course, these languages are all equivalent because you can write an interpreter for one in another. But that also implies they're not equivalent conceptually; that's what "interpret" means.
The influence of the medium on the program is so acutely obvious to me that I wonder how anyone could miss it. Here's one thing I think obscures it: when we compare programming languages, it's almost always by juxtaposing implementations of a program (or code snippet) that we already know how to write: something clearly defined and well-understood. But this is precisely when you're least likely to be influenced by the medium. (Someone porting, say, the Mona Lisa to watercolor, or fingerpaint for that matter, doesn't have to make big decisions about what to paint: it's clear what the picture should look like because it already exists.) It's when you don't yet know what the program should do, or what direction it should evolve in, that your ideas are going to be deeply conditioned by the medium in which it has evolved so far.
In other words, the way we compare programming languages is designed to overlook all the most interesting and subtle differences between them. Maybe that's why people come to the conclusion that language doesn't matter. Every time I hear that I wonder how deep that person has really gone. One wouldn't think much of an artist who said that medium doesn't matter.
Awful analogy. Software is like capentry (in the small) and architecture (in the large). In both cases materials matter. A language is the material for building a particular kind of structure, not only a tool for building that structure.
Consider the fact that many programming languages fail miserably at concurrency. Is that because you don't know how to use the hammer, or because you picked a really bad material for building that particular kind of structure?
EDIT: Thought about this some more, changed my negative slant on carpentry. Furniture is a delicate and beautiful sculptural practice. In carpentry materials matter just as much.
EDIT: Taking your analogy further, I have occasionally seen the exact same sculpture made out of several different materials, because the sculptor was experimenting. I've also seen such studies where the piece was executed very differently to take advantage of the different potentials of the materials.
I suppose that the blacksmith market's a bit saturated though, and anvils tend to last a rather long time.
For example, I wasn't saying that you shouldn't use a language with good intrinsic support for concurrency on projects that are heavily concurrent. However learning many languages that adhere to a CSP-style concurrency is not going to be as beneficial as learning things such as algorithm design.
If you know Python and Perl and you teach yourself Ruby, you probably won't learn very much. If you then teach yourself Lua, Javascript and PHP, you'll learn progressively less each time.
I was surprised to see this particular brand of negativity in the comments. I thought the post was trivial, not controversial.
Example: When you come from a C background and you discover declarative or more specifically functional programming, how is this not a new way to solve problems?
By paradigms, I mean programming language paradigms (e.g. functional programming, class-based object-oriented programming, generic programming, etc.) The danger comes from learning many languages of the same class for the sake of learning them. There are other areas of programming that would be more beneficial to learn, given limited time.
This might be true if you completely diminish the importance of syntax. Likewise, there is a lot to learn from those little gaps between where any two similar languages diverge.