Language wars
By Didier Verna on Thursday, July 12 2012, 11:42 - Lisp - Permalink
Programming languages are tools. Just like hammers. There's nothing personal about them. They just help you build stuff. Yet, there are many religious wars about programming languages out there. Wars which despite being all about science, are much more related to emotions, beliefs and personal aggressions than about objective arguments.
This is funny because do you know of any religious wars about hammers? So what's the difference?
Here's a recent personal example. A guy explaining how the static typing of Common Lisp works (type declarations) and what kind of performance-oriented optimization can be achieved with it (C-like, static but weak typing in SBCL for instance). And then, there's inevitably the troll (whom I know knows better) in the audience who goes:
So, yeah, what you're doing is just C code, and you have to type manually, and it's ugly. So if it's just for writing C code, I don't see the point in using another language.
Hmmm. Let's see. So, yes indeed, static typing in Common Lisp is ugly. And yes, it's not even strong typing. And yes, it would be nicer to have run-time hotspot detection and automatic type-dependant optimization like what's found in some other languages or virtual machines, rather than having to do it by hand (BTW, that would make for a nice Ph.D. I think). But what does that really tell you? That no language is perfect? Wow, thank you very much, that's new. For as much as I think that Lisp The Idea™ is perfect, I don't think anyone ever pretended that Common Lisp (or any Lisp for that matter) was. But is that a reason for not using it at all and sticking to C? Any sane computer scientist knows that the choice of a language doesn't boil down to only one parameter. Any computer scientist who tells otherwise is a troll.
In spite of all its defects, I still have a gazillon reasons to prefer Common Lisp over C, C++, or any language that I know of currently (and this may very well change in the future). The flexibility of lambda lists, the macros, the MOP or more generally its structural and behavioral reflexivity. Its run-time compilation, debugging, introspection and intersession capabilities. These are just a few examples. Still, I don't deny anyone the right to prefer another language for whatever purpose and whatever reasons they may feel legitimate.
So, I normally just ignore those purposedly trollesque and completely idiotic remarks. Yet, sometimes like yesterday, I snap. It gets on my nerves and I become all upset and angry. Why? I never get angry when someone tells me that my hammer is a piece of crap (it's not). I do enough Aikido to know how to control my temper, but for some reason, it doesn't always work when it comes to programming languages. So what is it about them that in spite of all your efforts, you can't help from getting personally and emotionally involved once in a while?
I think the answer becomes apparent when you consider the artistic aspect in programming. When an artist creates a piece (music, theater, dance, painting, architecture, whatever you like), (s)he exposes a very intimate part of himself through his creation. The art "is" the artist, and the artist "is" his art. In doing so, he puts himself in danger. It's like yelling out to the whole world Hey, look, I'm vulnerable right here!!
. It's a well know fact that many artists are very fragile, in the sense that they suffer from their creation not being liked. Because a piece of art is intrinsically a piece of the artist himself, when you say I don't like this piece of art
, you're actually saying I don't like the artist
. Then, it's up to artist to handle the fact of not being liked.
And that's the whole problem, which, as a musician, I know all too well. Where does the artistic fiber come from? It's an urge to express yourself. To express something that you can't express in any other way. A very deep and perpetual wound of some sort, a feeling of not really belonging. More importantly, it's a calling. Sometimes, the simple fact of creating is enough to heal you a bit, but more often, you create in order for your creation to be seen or heard. So yes, it's a calling to the Others. You expect them to answer your call by telling you that they like you (your art, but that is the same). Artists often have this urge to be liked by the Others. So when you dislike some artwork, you're also not liking the artist himself (the part of him that lives in his creation) and you're actually giving him the exact opposite of what he was looking for. And that hurts.
Back to programming languages. Why do we get all emotional about them, and not about hammers? The answer is in fact quite simple. Look at an architectural masterpiece. Do you see the hammer that was used to build it? Now look at a software masterpiece. Do you see the language that was used to write it? That's the crucial difference. You cannot decouple the language from the software, even once it has been written (the art is not in the executable; it's in the source code). The language itself will always be here for you to contemplate.
All in all, I think that's why there will always be language wars. Languages are not just tools, actually. They're not just like hammers. As soon as you care about the code you write, your software becomes artwork, you become an artist, and you start to be personally and emotionally involved. Your software becomes part of you. And contrary to the hammer, your sticky programming language, being intrinsically bound to the artwork, also becomes part of you. That's when the battle for objectivity is lost. By criticizing the language, the troll also criticizes your artwork, and in doing so, he tells you that he doesn't like you. That may hurt.
It's good to consider programming as art. Unfortunately, this also means that there will always be language wars.
Comments
Just one nit: I think you're wrong about the hammers. Give me a minute to go through a carpenter's toolkit and I can tell whether I would want to work with them. And you'll sometimes hear people argue one brand or style against another.
Of course the other side of that is that criteria for handbuilding of physical structures are fairly straightforward and easily verifiable. If the hammer puts the nails in solidly and in the right places, that's the end of the story in a way that's not so true for software.
So it might also be that we have religious wars about languages because we don't actually have hammers, but rather a bunch of different-size, different-shaped rocks, none of which hammers nails very well.
I was going to remark on the opening string of analogies, too. What's more personal than something you hold in your hand?
You might as well say that programming languages are musical instruments, just like a guitar, and there's nothing personal about them -- they just help you play stuff.
Well, that's why I took hammers as an example and not guitars. If you care about your specific instrument (not every musician does), then it will stick in the final music, proportionally to the care you give to it. Now, the guy in the audience telling you that he doesn't like your sound may hurt you or not, depending on whether you care about your sound (hence your instrument and the way you play it) or only about the notes you play. But in both cases, the instruments are still here, in the final music.
Nobody, on the other hand, can criticize your hammer by looking at your house, or your color brand, by looking at your painting. Although I do understand how one can care about his own hammers (I care about my guitars).
I have met musicians that could play with any instrument, with any sound, and still be happy. For them, the instrument truly was only a tool, not personal at all. But this has always puzzled me.
I think, languages are more, than just tools. They shape how you think. That is important and can easily get personal, because you start to defend *your* point of view and perspective.
A programming language is a language, one that you think in.
Nobody likes to hear that the way they think is dumb, or that there is a more efficient way of thinking.
That's also a reason why people can get a bit emotional when it comes to programming, it's way more personal.
I definitely agree with your point, but I think you misunderstood (and misquoted IMHO) the guy you categorize as a "troll" from the audience.
What he was arguing is that the work that has been done by adding static typing manually in the Lisp code could have been implemented in a more generic way by improving the implementation instead of optimizing a specific library. He gave several examples of languages with very good implementations that can achieve good performance without static typing (Javascript for example), and I think he has a good point here: the work that has been done to optimize Climb will most likely not help any other Lisp code to run faster.
Is there any reason CL implementations are lagging behind implementations of other dynamic languages? Is that because of some attributes of the language that don't allow the "common" VM optimizations (that "the guy in the audience" talked about: partial specialization, hidden classes, hotspot profiling, etc.) to be applied, or is it because people lack the time and/or motivation to implement a performant CL VM?
All of which is why we have "egoless programming", which sadly seems to have fallen out of fashion over the past decades:
http://articles.techrepublic.com.co...
Also, I've found this useful across various creative disciplines:
http://www.amazon.com/dp/0961454733...
The analogy about the connection of an artist to their work and the coder to their language is demonstrated by the fact that in a lot of cases, when talking about code from one developer to another, a possessive adjective (or pronoun) is used. For example, "Your code doesn't work" or "His code is wrong". I do my best to decouple the code from the person ("The code is doing the wrong thing") but even when I do, it feels like I'm making a personal attack.
As to language wars, I've never found them productive, yet we as a community continuously supply weapons for it. Projects often draw attention to their implementation language. By saying "Foo was written in C" you leave the reader to fill in the unwritten part: "so it must be fast and lean!".
Paul: yes, you're correct. There can be wars about tools as well, as soon as you start to care (i.e. you put some personal involvement in them). Not to mention the fact that tools, because they are created as well, can very well be artwork themselves. You are also very correct about the fitness (or lack thereof) of a tool for a particular task. That's exactly why I have come to love Lisp. Because no language is perfect, I prefer to have many options. Lisp is not a tool, but a large toolbox in which you can pick the tools you need or prefer when you need them. It's even more than that: Lisp is also a factory for creating the tools you need if they don't come built-in. For me, it's much better to have this freedom, rather than being forced to, say, use objects all the time, or be statically typed all the time, or purely functional all the time etc.
Vsevolod, Sander: I totally agree about the importance of the "language" part in programming languages, and the relation to your way of thinking.
David: interesting, thanks for the links!
Delroth: the trollness not only lies in what you say but how you say it. I don't think I have misquoted him, but in the heat of the moment, you never know :-). Of course the "other" points (the ones following the initial remark) are all valid, notably regarding hotspots etc. and I didn't argue about those.
But he also knows better, and in particular, that sometimes, you cannot just fix the problem at its origin and need to work around it (otherwise, 80% of the autotools for instance, would simply not exist). Consider this: in Climb we wanted to figure out where exactly the code was statically typed vs. where it truely depended on some level of genericity, and how much performance we could get from optimizing for the static types, in the current implementation. I have one 1st year student to do that. Now what do you think was the reasonable plan: go and ask him to fix one (or seven) CL implementations by doing run-time hotspot detection (hint: that would require at least a Ph.D.), or work around the real problem and do it by hand ? ;-) No, there are times where you just need to be practical and reasonable.
Of course, I would like to have all those neafty features in CL. However, and that also answers your final question: it really is a question of money and manpower, so this is not going to happen just today...
"If you care about your specific instrument (not every musician does)" ... "I have met musicians that could play with any instrument, with any sound, and still be happy."
Curious. I've never met a musician who did not care about their instrument. That doesn't mean they're unable to also have fun playing a plastic toy, if it's what's at hand.
"Nobody, on the other hand, can criticize your hammer by looking at your house"
This is a good point, in the case of hammers and houses, but I think this is more evidence that a programming language is not simply a "tool", in any sense listed here. The programming language usually does shine through in the final product. Does your URL have "index.php" in it? Does your error page have a yellow background? Does your native app use a different font, or does drag-n-drop not work right, or do the standard controls not animate in the standard way? (These are all actual things I've seen this week that announce the programming language.)
Granted, if you took the time to polish every corner, then the language shouldn't be visible in the final product. But almost nobody does, or can. In software, there's just too many corners. For modern software with a reasonable feature set, there will always exist some user input that causes default behavior of your language/framework/libraries to show through. So usually, people can tell pretty easily what you used to build it.
It'd be like having a house with little round indentations in a few places with "CRAFTSMAN" logos in them (if Craftsman was silly enough to put their name on the striking head of the hammer, like PHP does with their name in URLs). Your house will still be just as strong, but everybody who's spent at least 5 minutes in your house knows what kind of hammer was used.
As one extreme case, look at Java apps, and look at how many people on the internet have asked for (back when Java was popular for writing desktop software) "a program to do XYZ, but native and not Java".
delroth:
"Is there any reason CL implementations are lagging behind implementations of other dynamic languages?"
Very few dynamic languages are ahead of modern Lisp compilers. In raw performance, perhaps the only runtime that is consistently ahead of it today is the Java VM.
"Is that because of some attributes of the language that don't allow the "common" VM optimizations (that "the guy in the audience" talked about: partial specialization, hidden classes, hotspot profiling, etc.) to be applied,"
Do you know what these even mean? For example, why would you need "hidden classes" unless you were implementing a language like Javascript which didn't have proper classes to begin with? CL already has real classes. In what context could "hidden classes" be helpful?
"or is it because people lack the time and/or motivation to implement a performant CL VM?"
I'm gonna have to call "citation needed" on this one. But as long as we're trolling, I'll ask the opposite question. I wonder why in 2012, only one dynamic runtime is consistently faster than a free CL compiler, and most of the popular ones are much slower, in addition to being for less powerful languages -- is it because the languages were so poorly designed?
Alex: that was exactly my point. Languages, after all, are not just tools.