27 ms·

What i am getting at is that, no matter how hard you try, the result won't ever be the same. The fact that the melody is the same isn't good enough, it simply w

What i am getting at is that, no matter how hard you try, the result won't ever be the same. The fact that the melody is the same isn't good enough, it simply won't sound the same. The instrument has a definitive palpable impact on the end user (the listener in this case). That's simply not true of programming languages. The programmer may take longer to get the same result in Java than in Haskell, but he can reach the exact same result. It may be true about programming languages ecosystems (libraries and such) and this may have a much more profound effect on the user experience, but interestingly enough, the ecosystems of Java / C++ are amongst the biggest and most fertile, so that's definitely not a point against them. EDIT: One point you might be making is that the programmer's pleasure and frustration will have an impact on the end result. While already very far from the musical instrument analogy, for the reasons i have explained above, this really remains to be proved. The fact that haskell and other 'state of the art' languages are more pleasurable when you program for yourself doesn't necessarily map to the fact that it would make programming in an enterprise context more efficient. It could, but i would like to see cold hard data of this before making statements such as "the end result won't be as good".

lars512 16y ago
This is only true if you think of the result narrowly as a well known final running state. In reality, what you work with is more like a wavefront which is updated as bugs are found and requirements are better understood. If you work in a terrible language, your ability to adapt to conditions which change daily is not the same as with a good language. To update the analogy: you're playing an old saxophone, with so many extra keys that you'll never memorize all the conbinations, and the music is being slightly changed at every practice. A new instrument, with less keys to achieve the same thing, allows you to memorize them well, adapt to today's song, and play it with flair and improvisation.
- Raphael_Amiard 16y ago
  > you're playing an old saxophone, with so many extra keys that you'll never memorize all the conbinations, and the music is being slightly changed at every practice. A new instrument, with less keys to achieve the same thing, allows you to memorize them well, adapt to today's song, and play it with flair and improvisation. Well have you ever played saxophone ? Old saxophones don't have "extra keys", and better instruments don't have less keys to achieve the same thing, because you don't achieve the same thing with less keys. You're talking about different instruments then, and as musicians are generally not stuck on the notion of productivity, they don't even try to quantify such things. This is maybe the most upsetting analogy i have ever saw. You're literally talking about things you don't have a clue about (i'm speaking about the musical analogy here). Your observations on good and bad languages is very vague, and you're only moving the problem to changing requirements, but then you have the same sets of things to prove : Show me hard proof that productivity will be superior with language x than with language y. I'm totally open to the idea that it can be superior. I'm precisely saying, you have no real clue as if it is or not, and it's a thousand times harder to define than to define if a saxophone is superior or inferior to another saxophone. I have trouble seeing why the idea that improvements in productivity relative to the "quality" of a language is something that is very hard to quantify, has so much trouble getting through this argument. Maybe it is because, as hackers, we have trouble accepting that our pet language of the day isn't necessarily better, in a production environment, than one of the heavy weights.

lars512 16y ago

This is only true if you think of the result narrowly as a well known final running state. In reality, what you work with is more like a wavefront which is updated as bugs are found and requirements are better understood. If you work in a terrible language, your ability to adapt to conditions which change daily is not the same as with a good language. To update the analogy: you're playing an old saxophone, with so many extra keys that you'll never memorize all the conbinations, and the music is being slightly changed at every practice. A new instrument, with less keys to achieve the same thing, allows you to memorize them well, adapt to today's song, and play it with flair and improvisation.

Raphael_Amiard 16y ago
> you're playing an old saxophone, with so many extra keys that you'll never memorize all the conbinations, and the music is being slightly changed at every practice. A new instrument, with less keys to achieve the same thing, allows you to memorize them well, adapt to today's song, and play it with flair and improvisation. Well have you ever played saxophone ? Old saxophones don't have "extra keys", and better instruments don't have less keys to achieve the same thing, because you don't achieve the same thing with less keys. You're talking about different instruments then, and as musicians are generally not stuck on the notion of productivity, they don't even try to quantify such things. This is maybe the most upsetting analogy i have ever saw. You're literally talking about things you don't have a clue about (i'm speaking about the musical analogy here). Your observations on good and bad languages is very vague, and you're only moving the problem to changing requirements, but then you have the same sets of things to prove : Show me hard proof that productivity will be superior with language x than with language y. I'm totally open to the idea that it can be superior. I'm precisely saying, you have no real clue as if it is or not, and it's a thousand times harder to define than to define if a saxophone is superior or inferior to another saxophone. I have trouble seeing why the idea that improvements in productivity relative to the "quality" of a language is something that is very hard to quantify, has so much trouble getting through this argument. Maybe it is because, as hackers, we have trouble accepting that our pet language of the day isn't necessarily better, in a production environment, than one of the heavy weights.