Carpenters don’t seem to suffer from the same error of judgement. There might be several brands of hammers offering slightly different features, but they all pound nails into wood.
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.
An adobe/earthcrete Earthship might be a great idea in a southwest desert setting. It would be stupid to build one in a much of Houston.
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.
The software and CS fields are also relatively nascent. Programming languages today are arguably better than the ones we had available to use 20 years ago, whereas a hammer you buy today is pretty much as good as one you could buy 200 years ago.
In a lot of cases old hammers are better, especially when working metal. Most are cast now, rather than forged. The situation with anvils is even worse, with only one company that I'm aware of still making forged anvils.
I suppose that the blacksmith market's a bit saturated though, and anvils tend to last a rather long time.
Perhaps it was an "awful" analogy. I was not saying one language fits all.
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.
I've always hated the "programming languages are just tools" argument too, when it's used in a minimizing fashion. Programming languages, if they are tools, are at least extremely sophisticated tools that differ widely. It's like choosing between shovels, bulldozers, explosives, and backhoes--yes, they're all ways of moving dirt and you can get the job done with just one of them, but it makes all the difference which tool you use.
> there exists a danger of conflating learning new languages with learning new ways to solve problems
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?
However, once you are familiar with the broad paradigms, there exists a danger of conflating learning new languages with learning new ways 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.
Wow, I disagree with this so much that it makes me realize I don't accept that a programming language is a tool. A compiler is a tool. A language is a medium for thinking. Different ideas arise when working in different media. This leads to a thousand different little decisions about how to move forward, resulting in different programs - potentially vastly different.
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.
I think what the author is driving at is: when multiple programming languages exist in the same space, it's not a very effective use of your time to learn all of them.
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.
"Learning a set of very similar languages is of limited utility because your not actually gaining anything new."
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.
16 comments
[ 3.4 ms ] story [ 45.3 ms ] threadAwful 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.
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.
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.
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.
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.