

Fetishizing Programming Languages - chasingsparks
http://pathdependent.com/2010/05/01/fetishizing-programming-languages/

======
gruseom
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.

~~~
silentbicycle
Well said. I like Ken Iverson's phrase for this (and lecture), " _notation as
a tool of thought_ ".

------
swannodette
_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.

~~~
baguasquirrel
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.

~~~
jackfoxy
Yeah,the wooden shaft of 200 years ago is hard to beat. There have been some
ergonomic improvements in high-end hammers
[http://www.stanleytools.com/xhtml/literature/StanleyHandTool...](http://www.stanleytools.com/xhtml/literature/StanleyHandToolsCatalogHammers.pdf),
but simple metal shafts are actually a step backwards.

------
philh
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.

------
makmanalp
> 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?

~~~
chasingsparks
_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.

------
fogus
"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.

