3 ms·

No it's not, because you wont get the same sound from the beat-up trombone, whereas you can reach the exact same result programming in C# or java

stcredzero 16y ago
You can play the same melody, but technique might suffer, and the result won't be as pretty. That can be frustrating.
- Raphael_Amiard 16y ago
  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.
- Natsu 16y ago
  It's weird, and it's not quite the same situation as you're talking about, but I've found that working with overly limited languages and systems can be rewarding, too. Especially when they're so limited that you have to be creative just to find any solution. One of my earliest programming experiences was for a very primitive language. You had something like 26 variables total, all globals, and no flow control except GOTO. I ended up reinventing quite a lot of things to get even trivial programs working. I remember teaching myself loops, bitmasks and more, before I even knew what those things were. Or that time I remember having to use VBScript. Someone had made an OCX marked 'safe for scripting' that would write out some assembly and execute it, allowing one to call any C functions that left the stack clean (e.g. Windows APIs). I remember finding some crazy ways to abuse that. I also remember turning a testing tool into a music player when I was bored. That said, I understand not wanting to program like that 40-hours a week. I know it can be grating after a while. But sometimes, you can have a bit of fun by finding clever ways to expand the capabilities of very limited systems.
  - sprout 16y ago
    The problem is when your job is to get stuff out the door as quickly as possible. I just quit a job where I was writing primarily in a proprietary extension to a proprietary dialect of BASIC that has all manner of weird compiler quirks and just plain poor architecture. I knew there were ways I could do some better stuff long-term, but implementing them was completely outside the scope of the limited projects I was undertaking.
deleted 16y ago
[deleted]

stcredzero 16y ago

You can play the same melody, but technique might suffer, and the result won't be as pretty. That can be frustrating.

Raphael_Amiard 16y ago
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.
Natsu 16y ago
It's weird, and it's not quite the same situation as you're talking about, but I've found that working with overly limited languages and systems can be rewarding, too. Especially when they're so limited that you have to be creative just to find any solution. One of my earliest programming experiences was for a very primitive language. You had something like 26 variables total, all globals, and no flow control except GOTO. I ended up reinventing quite a lot of things to get even trivial programs working. I remember teaching myself loops, bitmasks and more, before I even knew what those things were. Or that time I remember having to use VBScript. Someone had made an OCX marked 'safe for scripting' that would write out some assembly and execute it, allowing one to call any C functions that left the stack clean (e.g. Windows APIs). I remember finding some crazy ways to abuse that. I also remember turning a testing tool into a music player when I was bored. That said, I understand not wanting to program like that 40-hours a week. I know it can be grating after a while. But sometimes, you can have a bit of fun by finding clever ways to expand the capabilities of very limited systems.
- sprout 16y ago
  The problem is when your job is to get stuff out the door as quickly as possible. I just quit a job where I was writing primarily in a proprietary extension to a proprietary dialect of BASIC that has all manner of weird compiler quirks and just plain poor architecture. I knew there were ways I could do some better stuff long-term, but implementing them was completely outside the scope of the limited projects I was undertaking.

deleted 16y ago

[deleted]