4 ms·
C and C descendants happen to be the primary reason we have not really moved forward any further than where we are right now. To build a mildly succesful C appl
by jlouis 15y ago
C and C descendants happen to be the primary reason we have not really moved forward any further than where we are right now. To build a mildly succesful C application, you needs lots and lots of code. The question is: Does it necessarily have to be so?
Haskell as a language is far more advanced and your "feel" might actually be right: You are now programming in the 80'es rather than the 70'es which most C-descendants really are programming in :)
- debacle 15y agoTo build a mildly successful C#, JavaScript, Java, Perl, or PHP application, you need very little code, and all of these languages are vastly more popular than Haskell because it is orders of magnitude easier to get things done in those languages compared to Haskell.
- Amadiro 15y agoYou need to write lots and lots of code to write a successful application in any language, really...
- batista 15y ago>C and C descendants happen to be the primary reason we have not really moved forward any further than where we are right now. Really? This implies you have some knowledge of what would have happen if C/C-descendants did not exist. It also implies that C/C-desc adoption was a historical accident, or an idiotic move, instead of something based on very pragmatic decisions. To write a performant program until at least 1990, from a word processor to a game, you needed not only C-level speed but also lots of tricks and twists to your code (ingenuity), most of which were only possible because of the low-level access C provides and the programmer's knowledge of the program's state (so a higher level compiler couldn't easily derive and do the same optimizations for generic programs). And sometimes you even have to drop in assembly. Remember all those 80's games (like Prince of Persia) written in assembly? So, even if C didn't exist, it would have to be invented (or something much like it). Worse case scenario, we would be using assembly. After the 90's, with 486's etc, the situation got better, in the sense that we could even afford garbage collection. Still, our expectations got bigger too. Whereas 256 graphics and SID sound on a largely uni-tasking system was good for the eighties (at best you have some expensive Unix workstation and you run X with 4-5 programs loaded, X-eyes included), we now want millions of color, multiple CD-quality sound streams playing, 10-20 heavy programs loaded at once, GPU compositors, streaming audio and video, anti-aliased fonts, etc etc. So, still, a high level solution feels slow compared to C/C++ when it does today's state of the art (for 10-years ago or yesterday's state of the art, even Python or Javascript is sufficient). Same for UIs (where waiting for the user's actions is the largest slowdown). As long as you get into the "cpu intensive" or "memory bound" issue, anything but C/C++ seems slow. (C descendant's like Java/C#/Go etc are also slow --not arguing that. Any multimedia app done in Java, for example, is like a relic from the 90's).