Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: