>I think it is if you consider wasted effort a problem. But apparently not everyone doe
You haven't considered 2 things: marginal returns and opportunity cost.
Your solution to this "wasted effort" is to build a better C (or a better language). But this overlooks the millions of hours spent in C systems, C code, C compilers, learning, and all that would have to be done once again...
If the better language already existed, and was a drop in replacement (meaning everything just works) then your argument would indeed mean an end to wasted effort if adopted.
But as it is, it means tons of EXTRA effort, which is not clear is if better than the current wasted effort because of C deficiencies.
> You haven't considered 2 things: marginal returns and opportunity cost.
Yes, I have.
> this overlooks the millions of hours spent in C systems
No, it doesn't. You are assuming that I am advocating re-writing existing C code in this hypothetical new language. I'm not. The hypothetical new language should be backwards-compatible with C, either a superset of C (like C++) or with a C (and C++) FFI (just about every other language out there today).
But even that is not strictly necessary. It is already common practice for programs written in different languages to interact with each other via language-independent mechanisms like pipes and sockets.
> If the better language already existed, and was a drop in replacement (meaning everything just works) then your argument would indeed mean an end to wasted effort if adopted.
Many such languages exist. The one I like to use, Common Lisp (and specifically Clozure Common Lisp) not only has a C FFI, it has an Objective-C FFI, which allows me to easily write Cocoa applications and leverage all of the power of both C and ObjC libraries on OS X with all of the efficiency of C. No wheel-reinventing required. And yes, everything Just Works. (With QuickLisp it really Just Works!)
> But as it is, it means tons of EXTRA effort
No, it doesn't. If you think it does, then you're doing it wrong.
> Many such languages exist. The one I like to use, Common Lisp (and specifically Clozure Common Lisp) not only has a C FFI, it has an Objective-C FFI, which allows me to easily write Cocoa applications and leverage all of the power of both C and ObjC libraries on OS X with all of the efficiency of C. No wheel-reinventing required. And yes, everything Just Works. (With QuickLisp it really Just Works!)
Not sure in what parallel universe starting to write software in CL, and getting hundreds of thousands of C programmers to adopt it doesn't mean "tons of EXTRA effort".
Heck, even the re-training required is millions of man-hours.
Even worse for the other proposed solution, to have legacy programs (that is: 99.9999% of available software that's not in the "NEW LANGUAGE") written in different languages to interact with each other via language-independent mechanisms like pipes and sockets.
And all that to gain what?
Supposedly it was to have a language where compilers could take advantage of the superior design to be even faster and more optimized than C, and you propose CL, which, after 30+ years, is slower or at best equal-ish to C.
I was not suggesting that all C programmers switch to Common Lisp (though I don't think that would be a bad thing). I was just citing that as an existence proof that it is possible to introduce a new language into the software development mix without abandoning all of the legacy code written in C.
> And all that to gain what?
The ability to write future software with less effort (and that is more reliable and secure) than past software.
> equal-ish to C.
Equal-ish is good enough given the big win in security, reliability and development effort.
>I was just citing that as an existence proof that it is possible to introduce a new language into the software development mix without abandoning all of the legacy code written in C.
I don't think anybody doubted that. At least not anybody who ever heard of the C calling conventions and FFIs.
But you started this thread advocating for something much stronger, which I read (correct me if I'm wrong) as: working around C is wasting so much effort, people should adopt a better language design for better compiler optimizations, etc.
Unless this adoption is actually a mass phenomenon (even a replacement), then instead of improving things, it only split all the effort and worsened things.
>The ability to write future software with less effort (and that is more reliable and secure) than past software (...) Equal-ish is good enough given the big win in security, reliability and development effort.
At the start of this thread you were all about compiler optimizations for speed -- not about more reliability and security. Now "equal-ish" to C is good enough?
> this overlooks the millions of hours spent in C systems, C code, C compilers, learning, and all that would have to be done once again...
and you are wrong -- on two counts. I didn't overlook these things, and they would not have to be done again. It's a little unclear to me how you could possibly think that they would have to be done again if you didn't doubt that this problem could be solved with an FFI.
> But you started this thread advocating for something much stronger, which I read (correct me if I'm wrong) as: working around C is wasting so much effort, people should adopt a better language design for better compiler optimizations, etc.
Yes, that's right.
> Unless this adoption is actually a mass phenomenon (even a replacement), then instead of improving things, it only split all the effort and worsened things.
No, that's not right. Different tools are good for different tasks. There's nothing wrong with split efforts.
Furthermore, even if you're right and there should be only the One True Language, don't you think it would be better if it were actually a well designed one?
> At the start of this thread you were all about compiler optimizations for speed
Not quite. I was lamenting the way in which compilers are evolving: people write clever algorithms in C, and compiler writers then write compilers to try to reverse-engineer those clever algorithms, and neither of those efforts would be necessary if we had a language that could directly express the things that people want to run fast and compiler writers could just directly compile those things to run fast. Life would be better for everyone.
The problem with C is that it's a low-level language masquerading as a high-level one. It's a macro assembler for a machine that was common in the 1970s but is no longer common today. The general idea of having a high-level assembler is a good one, but it needs to be an assembler for the actual target machine, otherwise you waste a lot of effort dealing with the impedance mismatch.
You haven't considered 2 things: marginal returns and opportunity cost.
Your solution to this "wasted effort" is to build a better C (or a better language). But this overlooks the millions of hours spent in C systems, C code, C compilers, learning, and all that would have to be done once again...
If the better language already existed, and was a drop in replacement (meaning everything just works) then your argument would indeed mean an end to wasted effort if adopted.
But as it is, it means tons of EXTRA effort, which is not clear is if better than the current wasted effort because of C deficiencies.