Language Maturity Lifecycle

Question

Wikipedia describes five stages of technology lifecycle:

1. Bleeding edge - any technology that shows high potential but hasn't demonstrated its value or settled down into any kind of consensus. Early adopters may win big, or may be stuck with a white elephant.
2. Leading edge - a technology that has proven itself in the marketplace but is still new enough that it may be difficult to find knowledgeable personnel to implement or support it.
3. State of the art - when everyone agrees that a particular technology is the right solution.
4. Dated - still useful, still sometimes implemented, but a replacement leading edge technology is readily available.
5. Obsolete - has been superseded by state-of-the-art technology, maintained but no longer implemented.

How would you position modern programming languages withing the stages, eps. C++, Java, C#? Older (Pascal, Fortran) and newer languages (F#, Ruby)?

Answer 1

The category Obsolete as defined does not exist in the world of programming languages.

COBOL, FORTRAN, BASIC: relics from a primitive era, and still being implemented.

If a programming language has truly died, then it was never truly alive.

Answer 2

Here's how I'd organize them:

Dated:

• C++

Obsolete:

• Pascal
• Fortran

State of the Art:

• Java
• C#?

Bleeding Edge:

• F#

Leading Edge:

• Ruby

But having said all that, who cares?

Personally, all of my professional work is in Java. My personal projects and consulting gigs have used C#, Python, PHP, and D.

I've been following the D newsgroup (where the compiler developer and all of the stdlib contributors hang out) for the last five years. I've been eyeballing Nemerle for a while. And I think "Nice" looks...well...nice.

Programming languages are interesting because they sometimes propose a few new ideas about techniques to solve problems (predicates & delegates beat the pants off of anonymous inner classes), and sometimes a language is particularly well-suited for a particular deployment platform.

I think it's easy for developers to get wrapped up in tool envy, especially when their jobs sometimes require them to focus on mundane problems day in and day out.

And don't get me wrong, I totally get the appeal of admiring new toys. I like roaming aimlessly around at Home Depot drooling over new circular saws as much as the next guy...

But when push comes to shove, I try to remember that solving problems is a lot more rewarding than just throwing away the old tools to make room for the new. Whenever possible, if I can keep my work pipeline filled with interesting projects, I don't care so much about tools and languages.

Answer 3

Programming languages are more linked to the maturity of the systems they support than to some "maturity" of themselves.

Some old _**legacy**_ system with FORTRAN batches processing thousands of tasks every hour during the night will not be replaced anytime soon by the latest J2EE or C# framework just because it is nicer.

The "right" technology in programming is the one doing the job.