Why It’s Pointless to Debate Which Language is the best

Yes, it is pointless, because there is no 'best'.<p>Just like I have 5 different hammers in my toolbox (Estwing, benchhammer, rubber hammer, plastic head and lead shot filled) I have a whole bunch of languages in my toolbox too.<p>Picking one is based on what I intend to do with the resulting product, familiarity and the speed with which I wish to get my result. If it is code that will run in production for many years I will pick another language than if it is a quick-and-dirty I need the answer now type thing.<p><i>Every</i> language, your favorite too, has its pros and cons.<p>If there were a single, perfect language I do not doubt that it would overrun the world of programming in the time it would take to spread the news.<p>But languages are trade-offs. Space, speed, readability, maintainability, expressiveness. All of those (and probably more) can be changed enough to give a spectrum of possibilities, and with enough spacing between those in the various dimensions you end up with a large number of viable languages.<p>And that's good. A lisp programmer will solve something in a completely different way from a C programmer or a prolog programmer. There is absolutely nothing wrong with that.<p>In the end all that matters is that your solution produces correct results (and not just in the logical sense of 'correct', also correct for all the other parameters).<p>As long as it performs well for you everything else is premature optimization ;)<p>Incidentally, I put out a little challenge on this exact subject:<p><a href="http://news.ycombinator.com/item?id=1073333" rel="nofollow">http://news.ycombinator.com/item?id=1073333</a>

But its not pointless to debate which are <i>better</i> (for a given task).<p>I personally have five or six languages which I use often, depending on what I'm doing. Ok, some of these I use only because I have to, but others I use purely because they suit a certain class of task.<p>The great thing about platforms like JVM and .NET is that I can use these different languages together in a single project :-) so each module can be written in the language that suits its task best. I don't <i>completely</i> do this yet, but perhaps in the near future.

I don't think its pointless to debate which language is best, or that it is not interesting anymore. I still find it interesting.<p>But more than that, I think it really doesn't have anything to do with labeling yourself a 'java developer' or 'rails developer'.<p>When programmers add titles like that, it usually means (or should mean) they have a lot of specific expertise on a particular language/framework. And of course this knowledge is not easily transferable from one technology to the other as one might think.<p>If you have a shop with ASP MVC product and are looking for a hire, you could hire a 'rails dev' or even a 'struts dev', but that won't be the same as hiring an 'ASP MVC dev' or even any programmer 'like a systems programmer' or 'firmware programmer' to fit the bill.<p>Of course they can all program, but those are very different beasts and the title makes a difference. The title helps you get a programmer with an experience and knowledge set which is more closely aligned with what you need.

Debating which language was best is how I learned to program better, notice flaws easier, and simply argue my case more efficiently.

It seems to me that the author is ignoring the relationship between experience and expertise in a language. Programmers call themselves <i>[language/framework] developers</i> because they've invested a lot of time becoming proficient in that language/framework. Of course there's some skills transference when you pick up another language, but they're not commodities and they're certainly not entirely fungible.

I think the Zen Buddhists have it. Most of the thoughts we have are centred around avoiding having to deal with what is right in front of us. In otherwords we are constantly shirking things. The good news is that everythig one is inclined to shirk is an opportunity to develop character by simply doing it and sticking at it until it is done. The Zen Buddhists also repeatedly refer to judging things as good or bad or "picking and choosing this vs that" as the primary shirk mechanism. In my case this is definitely true. Lets face it. Conceptually CS or programming is a very limited domain (compared to something like, say physics, or even electrical engineering). I used to program in C++ all the time. What have I picked up since then in working with/reading about other languanges? I mean what have I picked up that fundamentally/conceptually new? Nothing. (The functional stuff certainly does not introduce any new concept. Objects/interfaces are first class collections of functions) So bottom line is that if I am honest, experimenting with/reading about other languages has been a net loss for me. The only reason I do it is literally because its a form of shopping as in "Modelling real world problems is hard, let's go shopping"

I've been working for about 5 years now. I've been teaching myself programming for the last 10 years. Since that time, I've always assumed a position of lacking knowledge, always assuming that others knew more than me. In the last year or so, I've realized that that last assumption is often false. I still assume I don't know enough, because nobody ever could, but I realize that, because nobody else does either, what they have to say that does not jibe with my own experiences doesn't hold a lot of water.

I'm not so sure that simply having a grasp of the core underlying paradigms in a given polyglot scenario is really enough to say that you can therefore take your well undestood abstractions and apply them to any other language.<p>For example; I just spent the afternoon trying to pick up Scala / Lift by way of checking out the open source code to Apache Esme project, I must admit that I'm a little baffled at this stage, I can see tantalising glimpses of familiarity here and there within the framework, but compared to my prior experience in PHP / Django / Ruby on Rails / Grails I can tell this is going to be quite a paradigm shift. Wondering if maybe I should've started on something small and less complex first rather than diving in on Esme.<p>Time will tell I guess.