Language Maturity Lifecycle

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)?

From stackoverflow Michael Damatov

• 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.

  mas : '... never truly alive' ... Would you include languages that have died because the hardware or company they were specific to has died? I would agree more readily that a language family or paradigm that has died was not fully (or at least usefully) alive. e.g. assembler language for current processor architectures (and a few via emulators) is still current but not, for example, PLAN (the assembler language for ICL 1900 series mainframes): yet PLAN was alive for several decades: individual assemblers rarely survive their hardware whereas evolution of assembler is slow (e.g. MIX --> MMIX).

  Jeffrey L Whitledge : In my opinion, since the differences from one assembly language to the next are a direct response to differences in the targeted hardware, the evolution of assembler is more indicative of hardware evolution rather than software evolution. Assembly Language itself—if such a thing can be considered apart from a particular set of opcodes—hasn't changed much over the years. At least in my opinion. Perhaps an expert on Assembly Language would think differently.
  From Jeffrey L Whitledge

• 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.

  From benjismith

• 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.

  From VonC