Programming languages are not like hand tools
Posted by David N. Welton Wed, 12 Dec 2007 23:52:00 GMT
I have seen the "right tool for the job" comment one too many times, and felt like writing something about it.
Real tools are pretty simple, really. Things like saws and hammers have been around for thousands of years, and don't require a great deal of thinking to understand. Some people are masters with hand tools and create wonderful works of art with them, but the tools themselves are not complex.
My programming language, Hecl, is a pretty simple one in a lot of ways (it has to be, to fit on cell phones), and at last count, the core has 7670 lines in a rough count that includes comments. That entails quite a few "moving parts" compared to even something like an electric drill. Programming languages are complex. Certainly to create, but even to use well; to understand the nooks and crannies and ramifications of the language's design is not something that is accomplished in a few days for most people.
Your average programmer really doesn't know all that many languages, and even those who know many probably don't use most of them on a day to day basis. I like learning new languages, yet still wouldn't relish the idea of going through the mental task-switch required to move between too many in one day.
What this means, is that when there is a job to be done, most programmers will reach for what they already know, rather than the best possible system, and that makes sense. If you know Python, why not write web software in Python, if you get asked to create something for the web? Or if you know Tcl because you create gui's with Tk, you're still likely to pick it when you need to create a little server. There are reasons why something like Erlang might make for a better server platform than Tcl, but is it that much better to justify dropping everything, learning a new language, committing to a new set of infrastructure requirements, and adding another thing to ask of people joining your organization? Most likely, it is not, unless the server you're writing is for a telephony switch that has to be on all the time, in which case, yes, maybe you do need Erlang. If, as is often the case, it wasn't something that had to be the best in the world, all that extra time to learn a new language would have been mostly "wasted" (ignoring, of course, the fact that for individuals, learning new things is almost always good, but that's not what we're talking about). Even the smart folks who hack away in languages like Haskell are fond of using what it has to offer, rather than jumping ship to something else at the first hint of the "something else" being better at their language of choice for a given task.
So both Tcl and Erlang were up to the task of creating a little server. You could have used Ruby or Python as well. Java might prove a bit more verbose, but it's certainly up to the task. Any number of languages would be, of course. So it's not like there is a "right tool" and a "wrong tool".
Maybe a better analogy is languages are like toolboxes, or even whole workshops, full of tools. Most of them have most of the common tools like hammers and saws, some sort of web libraries or the means to create tcp/ip servers. Where they differ is in things like the amount of tools available, the specialized tools that you get for free, the craftsmanship and ease of use of the tools in the hands of both experts and beginners... or in some cases (lisp, say), some fancy tools and supplies that make it possible to build yourself some new tools if you need to (that only you know how to use, but that's another topic). Some sets of tools really aren't very good for some jobs - you don't want to build blazing fast 3-d shooter games in PHP, just as you wouldn't want to use a regular set of screwdrivers on a delicate watch. However, even though you'd want to use a toolset that also has some specialized tools for working on the watch, you'd rather own a toolbox that came with the watch tools as well as the regular Phillips screwdrivers, because those are pretty handy around the house, and it wouldn't do to have only the watch tools for fixing common household items.
The point being, languages are big investments, so those that do more, even if they're not the absolute greatest or first choice for a given task, are generally going to be more useful to more people, especially those just starting out who want a "safe" choice, a language they know will let them do a variety of things, rather than only one or two things (pound nails, say) really well.
Good piece!
I would contend that the place where the analogy breaks down is the general acceptance and standardization of what one may call "tools" in the real world and the equivalents thereof in the "language world".
The issue seems to be that we all seem to have agreed on how a hammer looks like and works, but not all people concerned seem to agree on how simple constructs should be standardized in the computer language world.
It would be like picking up a hammer and finding there is a hinge on it really close to the head which becomes activated only if you raise the hammer higher than your head (or something like that).
Programming languages may be 'tool sets' or workshops, but the tools contained within are not necessarily standardized to the point where they can be used without having to think too much about the low level implementation or the language designer's "philosophy" etc.
Hammers are not as simple as you seem to think. Putting up 2x4 framing? Use a 16 oz framing hammer. Hanging the door and window trim? use a smaller 12 oz. hammer. For driving a chisel, use a mallet. And so on...
But you're right -- a toolbox is probably a better analogy for a programming language. If you pick the right toolbox for a job, you'll have the right tools for each part of the job. If you pick the wrong toolbox you'll be banging on railroad spikes, spikes, framing nails, finishing nails, and chisels alike with the backside of your lineman's pliers (also known as the "electrician's hammer").
I think I do like your analogy better than the tool one but it sounds like you are defending the status quo mentality of most programmers. Yes, writing a massively complex set of enterprise servers (for a MAJOR, global semiconductor mfg. to control their FABs) in VBv5 is probably possible (it was actually suggested by one of the companies lead programmers because he said that OO was too difficult & he had never seen anyone successfully implement it anywhere) it wouldn't be in my top three...
I think the old adage is: Give a child a hammer and all the world is a nail.
Spanky, exploring new languages is good, and is something more programmers should do. Jumping on a new language for each new task is probably not a good idea, on the other hand. One need look no further than Google, which allows the use of a grand total of 5 programming languages: C, C++, Java, Javascript and Python.
"If, as is often the case, it wasn't something that had to be the best in the world, all that extra time to learn a new language would have been mostly "wasted" (ignoring, of course, the fact that for individuals, learning new things is almost always good, but that's not what we're talking about)."
Oh, but it is what we are talking about. The reason why the hammer -> nail analogy exists is because languages encourage you to do things in certain ways. That way may be fine for the app, or it may be brain dead. If you only know one language, you most likely know the most mainstream way to do things.
Different languages allow to think differently. In essence, learning a new language allows you to kitbash your toolbox, creating tools that never existed in that form before. This is regardless of the toolbox. This is why Eric Raymond encourages people to learn Lisp, not to program it, but to learn to program in a Lisp manner.
So the toolbox is a fine metaphor, but learning more languages is never wasted, regardless of if you use it or not.
jpcardier: in terms of your own growth as a programmer, I could not agree more with the idea that learning a new language is never a waste.
However, if you're being paid to accomplish something, you also have to consider the needs of whoever is giving you money, and stopping work to learn a new language may not be what they had in mind!