Dead languages

Question

At which point should you (or your company) ditch the language used for many years, for which you have the workforce, simply because it became irrelevant or much better alternatives came into the marketplace?

Edit:It is a tough proposition because for example, I know of companies that are stuck with PowerBuilder. They have so much invested in logic and UI that it is hard to justify moving to C# for example just for the sake of it, so they continue on, adding features, fixing bugs. What is sad is that it becomes more and more likely that clients will be fed up with the "moldy smell" and go for something "more modern", as well as there will be a point where the language won't be supported or won't run properly in a new environment (such as 64bit)

Answer 1

If you cannot achieve your goals with the language you are using, you should switch. The tough part is identifying those goals, and performing an accurate analysis of whether the language can achieve them. Switching languages can be costly and certainly is not a goal in itself.

Answer 2

More than "dead languages", I'd speak of "dead technologies".

A language like C++ or Python is likely going to last for some more decades. The client/server technology or the "native client" (opposite to the "web client") technologies are "dead", or they are fastly going to extinguish.

Answer 3

As time goes by, you will find that the cost of your work force will increase, the ability to keep your work force up to professional standards will decrease, and eventually, attrition will take place, as your developers learn modern languages on their own.

You're better off moving to a modern language sooner, rather than later. The breadth of the employment pool will widen, and your existing employees, expert in your business rules, will get less antsy watching the world leave them behind.

Answer 4

Mine jumped from Smalltalk to Java back in 1998.

Answer 5

I'm not terribly impressed when the fickle blogsphere declares some technology "dead" simply because it's not the latest shiny fad. I'd look at questions such as these:

• Does the language/implementation still meet the needs of the stakeholders?

• Is the language still supported (by vendor(s) and/or community as before)?

• Is there an implementation for the language for your current development and production environments?

• Can your staff still use the language?

• Can you still hire and/or train new programmers in the language?

• Does the language still provide competitive ROI (in terms of business functions implemented per development and maintenance effort, including the cost of learning new languages and/or techniques)?

If the answers are all "yes", then the language is still viable for your use, regardless of what's getting the most blog posts and tweets this week.

As more of the questions above are answered "no", you have more reasons to consider alternatives.

Answer 6

Who says you have to either ditch something that is working or ignore the better alternatives?

Unless you are extremely small, you can do both: keep enough expertise in the old technology around to keep profiting from the investment in it, while at the same time building expertise and investment in the new technology to replace the old one gradually.

Answer 7

I agree with Argalatyr, but the investment in the older language can be pretty large. There are lots of COBOL programs still around, and they won't go away soon.

Answer 8

I think it depends. If its a custom solution that is stable, won't be extended, still compilable, and able to run on modern hardware and OS's, then it makes sense to keep it. It you will continue to add features and actively develop it, then it makes sense to begin to move it. Otherwise the quality of your developer will steadily decrease as time marches on. The devs you would want will learn to work with modern languages and leave the old technology behind unless you pay them a lot of money.

Answer 9

I would say that you should make your decision based on business objectives, and cost-benefit analysis.

What are the risks of you abandoning your existing code base and re-writing everything in some new language?

What are the benefits?

You should try and quantify both.

For example, rewriting the app in a new language may require you to either:

1. Double the number of developers, testers, and product managers you have on staff or
2. Risk spending an extended period of time not delivering any new value to your product while you re-implement it's existing features.

Both of those come with risks. The first one costs a lot. Also, chances are that your best developers are going to want to work on the rewrite, and may up and quit on you if they have to maintain the legacy stuff while the new folks work on the "cool" project. But, if you put all your best people on the rewrite, it means that the new, less experienced folks working on the old stuff are going to be not as good. So, your customer service and bug fix rates, and general quality of the old stuff will drop considerably once the re-write starts. This may cause you to loose customers.

The second one could give your competitiors an opportunity to start stealing business from you. While you are not delivering any new value, they go in, add a bunch of value that is attractive to your customers, and steal a bunch of them from you. At the end of the process, your competition has a super cool app and you have the same thing, just written in a different language.

You should then look at the flip side and ask "what new value, in terms my customers care about, can I deliver to them by doing the rewrite". If that value is something you can deliver without rewriting the software, then you shouldn't include it in that. It doesn't count. Once you figure out the "unique" benefits delivered by the rewrite you should then convert that into dollars.

If that dollar figure is higher than the cost of doubling your payroll, and/or your loss in sales, then go for it.

If it isn't, then I would suggest looking at cheaper ways of delivering that value. Can you keep the old system in place, and just write new components in the new super programing language? Or you can you get away with rewriting just a small part of it?

Answer 10

Well, there is a difference between what I would call true languages and proprietary code builders. I've always considered Powerbuilder a "code builder" rather than a pure language - so your question takes on a different flavor to me.

Pure languages can go "out of style", but unless you simply cannot find a compiler for your hardware, the language is not really dead. You may discover that finding programmers for some languages gets harder and harder as time goes on - effectively rendering a fully operational language "dead". This is probably the best litmus test for when to move to a new language - when your costs to maintain exceed any possible value from the code.

Cobol is a good case study - it was tending this way until the Y2K "crisis" suddenly made being a Cobol programmer quite lucrative. However, it also reinforced the desire in many companies to replace Cobol apps ASAP once the "disaster" was averted.

So maybe somthing like APL has seen it's day go by, or perhaps PL/1 - I haven't seen much new interest in either as "working" languages. Cobol's time may (or may not) be nearing an end. FORTRAN has been deemed "dead" for years, but there are still loads of scientific programs based on it. So it ends up depending on your industry and what the code base is. Plus loads and loads of opinion. ;-)

As for "code generator" languages, I always considered them dead from the beginning. Most are totally proprietary, and thus defendant on the revenue stream of the vendor keeping it alive and (hopefully) up-to-date. However, this same business pressure can lead to new versions being totally incompatible with older code- and as it's a one-vendor product, now you're stuck - upgrade and rewrite all your code base, or stick with the old version and hope they don't abandon you. Powerbuilder, Crystal Reports and any proprietary product's macro language fall into these categories, IMO.

Conclusion

I think the code builders were dead languages from the get-go in my opinion, because their lifetime and upgrade path was controlled by a single entity and defendant totally on market forces.

Pure languages, on the other hand, are never really dead as long as a compiler (or interpreter) exists for your hardware platform, and there are programmers for the language.

Cheers,

-Richard

Answer 11

Besides the benefits of a getting a better supported language. You get other benefits from moving to a new language. Porting an application is frequently an opportunity to redisign and fix deficiencies in the application. The key is identifying when you can afford to invest in a new technology and making sure you have everything you need to duplicate the functionality. A full suite of Acceptance tests would be invaluable to have.

Switching just to use a different more "cool" language would I think be a bad idea. But switching because you need something the new language offers and it's come time to refactor a large portion of the app anyway would be a wise.

Answer 12

I think Huntrods makes good points about languages vs code builders. I have used PowerBuilder on-and-off for a dozen years now, and it's "dead" value has always depended on the cost of making a change - the higher the cost, the more "alive" the company considers it.

My current company has a product on the market that will eventually cost several man-years to replace in C#. We're moving that way anyway, but new feature development is still happening in PowerBuilder because that product pays the bills. Working, saleable product in a 'dead' language beats the hell out of incomplete or unsellable whiz-bang newness.

Answer 13

I still comment my code in Latin. Tricky at times as they didn't really have a translation for lots of common programming terms in Roman times, but I make do.