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:
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.
But its not pointless to debate which are better (for a given task).
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.
I don't think its pointless to debate which language is best, or that it is not interesting anymore. I still find it interesting.
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.
You don't think that's a learning experience either?
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.
Oh please, I don't buy that argument because I have seen too many language arguments devolve into Emacs/Vi pro/anti wars.
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.
He did not call you a troll, he called people that love language wars trolls.
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.
It seems to me that the author is ignoring the relationship between experience and expertise in a language. Programmers call themselves [language/framework] developers 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.
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.
Comments
Yes, it is pointless, because there is no 'best'.
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:
http://news.ycombinator.com/item?id=1073333
I find the concept of "Pareto optimal" a useful one here: http://en.wikipedia.org/wiki/Pareto_efficiency
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.
Sorry to derail, but it's going to bug me all day if I don't ask.
What do you use a lead-shot-filled hammer for?
It's a recoil free hammer.
http://en.wikipedia.org/wiki/Dead_blow_hammer
Thank you :-)
But its not pointless to debate which are better (for a given task).
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.
I don't think its pointless to debate which language is best, or that it is not interesting anymore. I still find it interesting.
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.
Debating which language was best is how I learned to program better, notice flaws easier, and simply argue my case more efficiently.
But for such a debate to be meaningful you need context.
Without context (application, and all the other requirements) it is just so much hot air.
You don't think that's a learning experience either?
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.
Oh please, I don't buy that argument because I have seen too many language arguments devolve into Emacs/Vi pro/anti wars.
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."
He did not call you a troll, he called people that love language wars trolls.
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.
I didn't call you troll, just that trolls argue similar positions.
>>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.
I know you didn't call me troll. If you read very carefully (And it's clear you didn't) I never suggested you called me troll.
post script It's 'goodbye'
post post script My net out of this conversation was +11
It seems to me that the author is ignoring the relationship between experience and expertise in a language. Programmers call themselves [language/framework] developers 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.
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.