Hacker News Reader

Comment by Animats | Hacker News Reader

On the other hand, they're getting decades out of the software. Use the bleeding-edge stuff, and it's obsolete in two or three years now. Use a "cloud" service, and the service probably goes away within five years. The new stuff has too much churn. Where will Rails be in ten years? Python? Java will still be around; it's the successor to COBOL.

View on HN

Python's been around for like 27 years, so 10 more doesn't seem that tough.

2.x or 3.x?

I understand a lot of people whinge about this, but converting most of my 2.x code to 3.x code involved nothing more than adding brackets to my print statements.

Not meaning to trivialize your experience, and I'm sure that's true for a lot of projects. But on the other hand, big enterprise and government tend to accumulate projects that were written over decades of change cycles.

Porting something like that across a non-backwards-compatible version bump while preserving identical behavior which is sparsely documented and uncovered by unit tests? Starts to be a serious amount of effort quickly.

> The new stuff has too much churn.

<3 <3 <3

Indeed. Basically anything in the JS world, except maybe nodejs, will vanish in 5 years. (I'm looking at you, bower, gulp, EmberJS, even the giant dinosaurus jQuery is on the decline, given everyone and their dogs shift to Angular)

Seriously, if one is after long-lived software, choose a solid PHP framework (Drupal 7, for example, is around for 5 years now and probably will be supported for two or three years) or a Java framework, together with a rock-solid database (i.e. no NoSQL crap)...

Hate PHP and Java all you want, but these two languages put backwards compatibility as priority.

Ember is going to be 5 years old this year and has a team dedicated to backwards compatibility. It's the least "churn" of the frameworks.

And the government could just choose not to use any third party framework.

But to prove your point, people are moving to React, not Angular :-) jQuery is used in almost all Angular apps anyway.

Nassim Taleb talks about this a tautology that is reflective of this concept in Antifragile -- basically says that technologies that have been around for "x" years are likely to remain in use for another "x" years. Think about the wheel. Or paper. Or (as cited above) COBOL. Interesting food for thought. I use this when talking to folks who insist that client-side file storage is going away (e.g. "but everything is going to move to the cloud!"). Explicit filenames on the desktop have been around for decades -- and are likely to remain a fundamental part of our system structures for a long time to come (though are likely to be joined by documents stored in the cloud).

They're getting decades out of the software, but "about three-fourths of the $80 billion budget goes to keep aging technology running". Is that worth it to you?

Depends. Where would that 3/4 be going if they invested in new technology? Training? Support?

Nothing if they keep the interfaces the same. The real cost, immediate and over time, is the port of the applications or systems to new HW and toolchains. I can't overstate enough how many problems this can cause. Especially if they don't have source for these apps or it's barely commented.

Debugging, constant break-fix, and given the typical quality of modern software bribing the international community into ignoring the occasional unintended ICBM launch. :P

That isn't a useful metric without details, as it probably includes such sundries as licensing, maintenance agreements, and salaries. A brand-new suite of Oracle enterprise systems would probably be as unfavorable a cost profile.

"75% of the budget to maintenance, and 25% to new system acquisitions", which is what I suspect that statistic really means, isn't that bad.

Honestly it might be heavy on new system acquisitions. I tend to think that enterprise lifecycles are too fast, most of the time, but that's because they're frequently driven by vendor licensing policies that make old-but-working systems prohibitively expensive on purpose. (IBM is notorious for this.)

I don't know if there's a name for this already, but I think there's a common fallacy in which people think that a "chuck it and redo it from the ground up" effort will be easier than fixing their existing system's bugs and/or will result in a less-buggy system. But there's a danger in that you're just moving from a situation where you know where all the bugs are, to a situation where you haven't found them yet. I've seen companies that seem to be stuck endlessly in this cycle.

Yeah, like all the Python code I've written is just going to expire in 10 years. Popular languages rarely ever die, there is clearly an extraordinarily long tail

Does your code all work in python 3? I know none of my old ruby 1.8.3 code still works.

I don't think your Ruby 1.8.3 code is supposed to work with Python 3.

Seriously, though, as far as I can tell, the transition to Python 3 is extremely low on pain. My Perl 5 to Perl 6 transition will be much more interesting, however.

I thought this too back when I coded perl for a living. Still scratching my head over how PHP basically won that fight.

Perl 5 has maintained almost perfect backward compatibility for decades (going back to Perl 4 in some cases...some of our code has some Perl 4-isms, like use of "local", that still work fine). I guess they wanted to wait until they really figured out how to completely break backward compatibility to break it (and they did, of course...nobody's gonna be able to transition to Perl 6 without a rewrite, though it'll be possible to do a transition process with some Perl 5 and some Perl 6, which is cool, I guess).

I'm amazed at that. I have a Perl program running on a server that's been running since 1999, quietly updating a MySQL database of SEC filings. It's been moved to a new hosting company twice, as old ones went out of business, but it's still doing its job.

I hate Perl as a programming language, but it does provide stability.

New stuff only churns as fast as you churn it. Why wouldn't Rails from today, or your other examples, still run in 10 years?

Reply on news.ycombinator.com