NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
2004, huh? (Score:5, Interesting)
Well, back in the Day, when DEC was strong and I was using VMS at government labs, I saw accounting numbers for how many cycles I used and how much that would cost our group.
This is just another example of my notion, which I hope to turn into an idea, that so-called utility computi
Re:2004, huh? (Score:2)
Great reply. I only have one teeny side comment:
I think the example of COBOL weakens your argument. Consider the era in which it was created. New language technologies weren't coming around the way that they are now and COBOL had no serious competition. As a result, we have many billions of dollars worth of COBOL code strewn around the world and when a company is looking at their multi-million dollar COBOL code base and thinking about migration, they think "large projects fail" (and they're right). Further, the business rules embedded in decades of COBOL code are mostly known by older programmers, many of whom aren't going to look at Java or Perl and really understand what's going on. It's like being used to working on a Ford Model T and being handed a Ford Taurus: you'll likely recognize what's under the hood, but you can't even do a tune-up.
In other words, COBOL hangs on because regardless of whatever business cycles were taking place in the sixties and seventies, choosing anything but COBOL was not part of that cycle and now it's often deemed too expensive to replace. Today, the choice of COBOL is not subject to cycles the way that the choice of ColdFusion and PHP are, but the article was speculating about evolutionary trends (a model COBOL fits) rather than cyclical ones (which ColdFusion and PHP fit).
Reply to This
Parent
Re:2004, huh? (Score:2)