Why It’s Pointless to Debate Which Language is the best
lostintangent.com
lostintangent.com
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.
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.
Every language, your favorite too, has its pros and cons.
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.
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.
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.
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).
As long as it performs well for you everything else is premature optimization ;)
Incidentally, I put out a little challenge on this exact subject:
What do you use a lead-shot-filled hammer for?
This opens up a second front: In addition to "is it the best choice for this task", it allows you to discuss whether the language is actually Pareto optimal for this task. Even "the best language for the task" may be able to use some improvement.
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.
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 completely do this yet, but perhaps in the near future.
But more than that, I think it really doesn't have anything to do with labeling yourself a 'java developer' or 'rails developer'.
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.
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.
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.
Without context (application, and all the other requirements) it is just so much hot air.
People in the tech, and geek community, are stubborn mother fuckers. You have to have a badass debate skill to get even the most obvious ideas into people's heads. Simply being right doesn't mean a damn thing.
Programming Arguments are one of the best places to get these sort of skills. Not only are you trying to convince the unconvincable, you're trying to appeal to the crowd.
The people loving language wars are generally trolls, which carefully craft "arguments" that infuriate people while being wrong in a way that needs long expositions to answer.
I do expect better than that type of garbage from HN.
Edit: I do buy jacquesm's argument about pro and cons for languages; the fit with different problem spaces are different for different paradigms, etc.
For example, I'm personally going back to functional programming now, hoping for a new dawn in the coming mass-multicore world. But I'm not going to do any lisp language wars, since that is as useful as Emacs/Vi "debates".
Edit 2: If someone really think to learn something from language wars, why not just Google for a few? There are lots of them to review, on lots of web sites.
>>You look at me and say "troll", I look at you and say "delusional."
But that comment was quite trollish in just dismissing an argument with a one word insult. Good bye.
post script It's 'goodbye'
post post script My net out of this conversation was +11
If you self identify with 'people that love language wars' then that's something you can't blame him for.
Loving language wars and debating the finer points of the pros and cons of various languages are two different things.
Language wars are almost without exception based in the people having them, not in the relative merits of the languages.
Think of it as religion: If you were born in Iran you probably are a muslim, if you were born in Italy chances are you're catholic and if you were born in India chances are you are a hindu.
You could have debates all day long about 'whose' religion is the better one (or the true one), but it would be an argument mostly rooted in to your familiarity with a certain religion because of your heritage.
An objective argument would essentially require parties to give some ground based on real arguments, in a language war that rarely if ever happens.
Debate is to advance a common viewpoint, not to get your way. Then a gun will suffice. And plenty of religious wars indeed devolve in to violence.
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.
Time will tell I guess.