The problem with using this kind of rhetoric is that it is also "utter crap" to require everyone to stop making progress on applications and high-level systems because some "whiners" are "unwilling" to put up with a couple warts in the languages they are using so that we can all instead go through tons of working code to update it to some new syntax or language standard; one might even, then, claim that it is this other set of whiners that "are to blame" for why a lot of libraries in some languages (I'm looking at you, Python) have never been able to get past puberty where they can start to crystalize into high-level perfection, and are instead trapped in a perpetual quagmire of "suck" while they scramble and fight to catch up to a shifting platform (and often just get thrown out and rewritten over and over and over again by new generations of whiners that insist that the old syntax is so unusable that they refuse to touch it anymore and would rather just start fresh).

(edit: The author of the comment I responded to added another two paragraphs.) C# beating Java is not something I think is as clear-cut as you seem to believe (from my vantage, C# is used by Windows developers, and Java is used by everyone else: the dividing line has little to do with syntax preferences and much more to do with the quality of the IDEs and the integration of the runtimes; before MS was legally required to stop distributing it, J++ was gaining ground), but to the extent to which it is true you have to remember that C# also is not making breaking language changes, and in fact didn't even make drastic changes to Java (which one might argue is the legacy that C# continued). In fact, C# was so compelling to a lot of us who adopted it early because it had such amazing backwards-compatibility in the form of interop with native C and C++ code with the ability to nearly natively interact with our existing COM objects.

If I have a wart, I go to the GP to have it iced, perhaps it hurts for a little while, but my skin is better off.

If a compiler removes a wart, why wouldn't you s/wart/scar/? Perhaps it's a bit of a pain every compiler release, but in the end isn't your software a bit more future-proof?

There is no need to stop making progress, this is why good software is open source and on github.

New generations of whiners are better judges of what is and what is not useable than old farts. The new generation has a glimpse of the future.

edit: I don't think native code interop is backwards compatibility, that would imply C/C++ is somehow a thing of the past. My point was that as long as C/C++ are being adapted to the future, they will never be legacy and retain relevance where their use is warranted. C# perhaps is not a winner in adoption, but it is gaining ground on linux and osx. My observation that C# beats Java is more in the syntax area.

This is a circular definition of "future-proof": if the compiler never changed, then the software would have been future-proof the day it was written, and the only reason it is not future-proof with the shifting compiler is due to the threat that the compiler will eventually stop supporting the feature. However, the assumption is generally and honestly should be (having been proved in the field after decades of engineering) that there will be many orders of magnitude more lines of code that exist outside of the compiler (which is but one program often maintained by a single team of people) than there ever will be in the compiler to maintain the old feature.

As for your comment about open-source... that doesn't help the problem of "all the developers are spending their time updating and re-testing working code rather than writing new code that relies on it", and specifically looking at GitHub makes no sense. Finally, the "old farts" you are now denigrating have more knowledge and experience of the kinds of failures you will run into, and so far in my experience the people rebuilding systems end up learning, the hard way, the same lessons that they could have just inherited (a rather visceral lesson as I've watched my friend Yehuda work on Bundler over the years, as he got to rediscover all of the things that APT solved over a decade ago).

I don't think it is circular, if the compiler never changes, a new compiler (for a new language) will come out. New generations might find the unchanged compiler to be obsolete (as many think of C). Thus its future might be mitigated. I don't believe introducing backwards incompatible changes is such a big thing that developers have significantly less time to develop new features. Look at Ruby 1.8->1.9 and Rails 2->3, yes it was a pain to upgrade, for a little while. But the advantages are obvious, and it was not _that_ much work. I was looking at github specifically because of their 'fork me' attitude, which I admire. I don't advocate at all we should develop software without looking at the past, if Yehuda didn't look at APT closely when he was working on bundler, then that was a missed opportunity I agree. Do you think Bundler should have somehow been an (compatible) improvement on APT instead of a separate software? I myself have never used APT the way I use bundler, and I have no idea if that would be possible.