Linked by snydeq on Sun 11th Dec 2011 01:35 UTC
Fatal Exception's Neil McAllister writes in favor of new programming languages given the difficulty of upgrading existing, popular languages. 'Whenever a new programming language is announced, a certain segment of the developer population always rolls its eyes and groans that we have quite enough to choose from already,' McAllister writes. 'But once a language reaches a certain tipping point of popularity, overhauling it to include support for new features, paradigms, and patterns is easier said than done.' PHP 6, Perl 6, Python 3, ECMAScript 4 -- 'the lesson from all of these examples is clear: Programming languages move slowly, and the more popular a language is, the slower it moves. It is far, far easier to create a new language from whole cloth than it is to convince the existing user base of a popular language to accept radical changes.'
Thread beginning with comment 499934
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: "Better" vs. Better
by lucas_maximus on Mon 12th Dec 2011 19:12
in reply to "RE[4]: "Better" vs. Better"
Member since:2009-08-18
The only thing that proves is that the rewrite was poorly handled. For every case where a rewrite was a disaster, you have a case where it was a great success and the old version was treated with good riddance.
If you have something working, it is ridiculous to do a full rewrite. The only time I can see it making sense if the current platform is going to be depreciated, or fundamental core changes need to be made.
Re-factoring and rewriting modules is fine. Slowly changing the architecture is okay as well. It is pretty easy to do this after a few iterations.
If you create a new piece of crap, all you have is a new piece of crap. The problem isn't that you made something new, it's that you made it a piece of crap.
Agreed, but that doesn't mean that rewriting a working application is a good idea because it might be better in the future.
Many of the weird logic the applications have are there for very good reasons.
RE[6]: "Better" vs. Better
by ilovebeer on Tue 13th Dec 2011 10:30
in reply to "RE[5]: "Better" vs. Better"
Member since:2011-08-08
If you have something working, it is ridiculous to do a full rewrite. The only time I can see it making sense if the current platform is going to be depreciated, or fundamental core changes need to be made.
I'm not talking about doing rewrites when there's no need for it. When you have poorly designed software that's in a constant state of maintenance, you can reach a point where maintaining it and dealing with the poor design is no longer the best option -- when too much time and too many resources are being committed just to keep it working. In these cases a proper rewrite can easily be the best solution if the end result is relieving the time & resources being spent.
The people who are saying that a rewrite is never a good choice and believe that there are never any circumstances which call for it, are completely nuts. They're either not coders, not good coders, never had to deal with resource management, or aren't good at it.
Member since:
2011-08-08
The old product is still going and has been bought by new customers and is still paying the bills. If the amount of effort for the rewrite had been spent refactoring the product ... It would probably would have none of the performance problems it currently has.
The only thing that proves is that the rewrite was poorly handled. For every case where a rewrite was a disaster, you have a case where it was a great success and the old version was treated with good riddance.
If you create a new piece of crap, all you have is a new piece of crap. The problem isn't that you made something new, it's that you made it a piece of crap.