4 ms·

Perhaps if you'd read more criticism of existing languages you'd be able to more clearly see the needs for new languages to address certain issues and new techn

Perhaps if you'd read more criticism of existing languages you'd be able to more clearly see the needs for new languages to address certain issues and new technology challenges. I think many programmers would have told you they didn't feel unreasonably restricted by COBOL, ALGOL, ADA or FORTRAN as well, but I sure am glad different people felt annoyed enough with those languages to write some new ones.

axod 17y ago
Point is, if they hadn't created new languages, we'd still have all we have today. It'd just be in those languages. Some people will always whine and moan about any language, but in every case there's a work around for any dislike they have. If they're a good programmer they'll be able to work out a solution. It's like a builder moaning that he can't always build on perfectly flat stable ground. What 'new technology challenges' do you mean? The fact that suddenly in the last few months we've been able to switch to 'realtime' web! Which is a marvelous technological achievement never before seen in computing? It's all buzz words and bs.
- djcapelis 17y ago
  You really don't think there's been any progress in programming languages in the last 30 years? I think there has, and I think there will continue to be progress. The area that seems most likely and is getting the most attention right now is concurrency, an area that many existing mainstays handle fairly poorly. We may not need a whole new language to address these deficiencies, but certainly different language design concepts, principles and frameworks may need to be incorporated into future versions of languages to provide their continued usage in the new manycore environment we seem to be kicking and screaming our way into. Certainly I can and have written multithreaded code in C, C++ and many existing languages, yet I can see the value in exploring ways to make that easier. Can't you?
  - axod 17y ago
    I don't think there's been much to speak of no. Probably the most useful work has gone into runtime optimizations, JIT etc I heartily strongly disagree about concurrency. Concurrency is handled badly by most languages because it's a horrible thing to run more than 1 thread per CPU. But I won't start another rant on that. >> " the new manycore environment we seem to be kicking and screaming our way into." Again, I don't buy the koolaid. We were using multi cores 10 years ago and warning that we'd all have hundred core CPUs. I too have written multithreaded code, and decided the solution was to stop writing multithreaded code.
    - jacquesm 17y ago
      > I too have written multithreaded code, and decided the solution was to stop writing multithreaded code. Not too long ago on some thread here I said I thought that writing solid multi threaded code was hard and I got reamed for it. I think I have above average experience in C and writing an operating system kernel has given me a good amount of insight in to how difficult it really is. Anybody that thinks writing a multi-threaded program is a walk in the park hasn't done enough of it yet (or at least, not enough debugging, especially under high load you can have the weirdest problems if you aren't very very careful).
      - axod 17y ago
        Sure, but it's an avoidable problem. Writing multithreaded code on a single core is like saying to the OS: "I don't know what order I want my code to execute, here! You decide some random pattern, and I'll write a ton of code to deal with your random execution of my code."
        djcapelis 17y ago
        Multithreaded code can be useful on a single core when you have blocking syscalls. Non-blocking I/O can help but doesn't eliminate this. Further, non-blocking I/O carries its own complexities. Though I have to say, your characterization of the issues with multi-threading is nothing short of hilarious.
        17y ago

axod 17y ago

Point is, if they hadn't created new languages, we'd still have all we have today. It'd just be in those languages. Some people will always whine and moan about any language, but in every case there's a work around for any dislike they have. If they're a good programmer they'll be able to work out a solution. It's like a builder moaning that he can't always build on perfectly flat stable ground. What 'new technology challenges' do you mean? The fact that suddenly in the last few months we've been able to switch to 'realtime' web! Which is a marvelous technological achievement never before seen in computing? It's all buzz words and bs.

djcapelis 17y ago
You really don't think there's been any progress in programming languages in the last 30 years? I think there has, and I think there will continue to be progress. The area that seems most likely and is getting the most attention right now is concurrency, an area that many existing mainstays handle fairly poorly. We may not need a whole new language to address these deficiencies, but certainly different language design concepts, principles and frameworks may need to be incorporated into future versions of languages to provide their continued usage in the new manycore environment we seem to be kicking and screaming our way into. Certainly I can and have written multithreaded code in C, C++ and many existing languages, yet I can see the value in exploring ways to make that easier. Can't you?
- axod 17y ago
  I don't think there's been much to speak of no. Probably the most useful work has gone into runtime optimizations, JIT etc I heartily strongly disagree about concurrency. Concurrency is handled badly by most languages because it's a horrible thing to run more than 1 thread per CPU. But I won't start another rant on that. >> " the new manycore environment we seem to be kicking and screaming our way into." Again, I don't buy the koolaid. We were using multi cores 10 years ago and warning that we'd all have hundred core CPUs. I too have written multithreaded code, and decided the solution was to stop writing multithreaded code.
  - jacquesm 17y ago
    > I too have written multithreaded code, and decided the solution was to stop writing multithreaded code. Not too long ago on some thread here I said I thought that writing solid multi threaded code was hard and I got reamed for it. I think I have above average experience in C and writing an operating system kernel has given me a good amount of insight in to how difficult it really is. Anybody that thinks writing a multi-threaded program is a walk in the park hasn't done enough of it yet (or at least, not enough debugging, especially under high load you can have the weirdest problems if you aren't very very careful).
    - axod 17y ago
      Sure, but it's an avoidable problem. Writing multithreaded code on a single core is like saying to the OS: "I don't know what order I want my code to execute, here! You decide some random pattern, and I'll write a ton of code to deal with your random execution of my code."
      - djcapelis 17y ago
        Multithreaded code can be useful on a single core when you have blocking syscalls. Non-blocking I/O can help but doesn't eliminate this. Further, non-blocking I/O carries its own complexities. Though I have to say, your characterization of the issues with multi-threading is nothing short of hilarious.
      - 17y ago