Criteria for a programming language to be considered "mature"

Question

I was recently reading an answer to this question, and I was struck by the statement "The language is mature".

So I was wondering what we actually mean when we say that "A programming language is mature"? Normally, a programming language is initially developed out of a need, e.g.

• Try out / implement a new programming paradigm or a new combination of features that cannot be found in existing languages.
• Try to solve a problem or overcome a limitation of an existing language.
• Create a language for teaching programming.
• Create a language that solves a particular class of problems (e.g. concurrency).
• Create a language and an API for a special application field, e.g. the web (in this case the language might reuse a well-known paradigm, but the whole API must be new).
• Create a language to push your competitor out of the market (in this case the creator might want the new language to be very similar to an existing one, in order to attract developers to the new programming language and platform).

Regardless of what the original motivation and scenario in which a language has been created, eventually some languages are considered mature. In my intuition, this means that the language has achieved (at least one of) its goals, e.g. "We can now use language X as a reliable tool for writing web applications."

This is however a bit vague, so I wanted to ask what you consider the most important criteria (if any) that are applied when saying that a language is mature.

IMPORTANT NOTE

This question is (on purpose) language-agnostic because I am only interested in general criteria. Please write only language-agnostic answers and comments! I am not asking whether any specific "language X is mature" or "which programming languages can be considered mature", or whether "language X is more mature than language Y": please avoid posting any opinions or reference about any specific languages because these are out of the scope of this question.

EDIT

To make the question more precise, by criteria I mean such things as "tool support", "adoption by the industry", "stability", "rich API", "large user community", "successful application record", "standardization", "clean and uniform semantics", and so on.

Answer 1

Acceptance Factors

I'd say a combination of various things, but I don't think they are all required. Some languages considered mature nowadays clearly do not satisfy some of these.

I'd say a combination of:

• Tooling:
  • mainline: At least one stable "official" or widely-accepted (de-facto or vendor-recommended/supported) tool suite (compiler, interpreter, vm, editor).
  • alternative: Some stable and not-so-stable alternatives of the above tooling (closed or open source variants, free or commercial variants, extensions, etc...).
• Community: An active , but not necessarily large group of followers and contributors.
• Recognition:
  • Some degree of recognition and use by some industrial actors (even if in a niche).
  • Some degree of recognition in popular culture (even if in a niche).

On Fame, Recognition and Maturity

Note that the differentiator here is on having strong and active criteria validators, not large or numerous ones. To clarify, consider these vastly different examples:

• Ruby was for a long-time a language with a large community-backing, an official reference implementation and so forth but could hardly be considered mature until it ironed out some of its rough edges. It was famous before being mature.

• On the other hand of the spectrum, some once very-widely used languages (COBOL, FORTRAN...) are now less visible but are still mature in every possible sense. They were once famous and mature.

• Also, some niche-languages are in my view definitely mature, inspite of their small (but established) market penetration. Consider Oberon or Limbo. They are mature but never got famous. Others, like R, are relatively famous in that their "niches" aren't really niches (bugs me when people call things like Scala or Clojure "niche languages", which they definitely aren't), though their field of applications are not exactly what you'd call mainstream.

On Stability

What's stable anyways? It's quite relative...

• Compliance?
  • To the standard (if there's one)?
  • To a reference implementation (if there's one)?
• Number of bugs? (hardly a good measure)
• Use in critical environments?

In general, stability simply means I don't get surprised on a daily basis when going about my average job using the language's toolkit, and I can get definitive answers on what should or should not happen when I attempt to do something with the language and its toolkit, whether it's at the build-time or runtime of my programs.

But stability for someone writing smartphone apps and stability for someone writing medical or avionics systems is a different kind of bird.

Answer 2

I've actually had the same wondering a few years back. Back then, I decided that a language is mature (i.e. good for solving problems of type x) if it has most of the necessary features needed to solve that problem. In other words, how much of the specific problem solving tools I have to create myself vs. how many already come with the language. As per your comment I'm removing the language-speific example and replacing it with a language agnostic one:

I basically thought that a language having a lot of built in "helper" and "utility" libraries is more mature than one in which some of those didn't exist (and in which I'd have to write them - or something similar to them - myself)

I'm talking about all this in the past because these days I've pretty much ditched that way of thinking, and think of a language's maturity more like this:

• how strong the community is for that language. How many docs, books, pertinent examples are there. This is important, because you can have languages which are very nice, and may be better suited for some specific task than others, but which are poorly documented, so that you never get to see their advantages.

• performance. For a given task, and a given x implementation, the language in which that implementation will run faster is more mature. Yes, this is a very gray area, and for most languages and platforms it's hard to make the comparison. However for certain languages and platforms it's quite straight forward to see which one out-performs which. For certain kind of problems this is very important.

• bugs. Oh yes. I never would have thought of this until I've seen it with my own eyes. I'm not gonna give any examples because I don't want to seem like I'm bashing one language or another, but there are languages out there (well, more precisely, compile and run-time environments for certain languages) which are very buggy, to the point where you can no longer trust and estimate how something will work. To me the maturity of a language falls heavily when this is the case.

The reasons why I switched the way I think of a language as more mature are :

• first off, the fact that a language has a ton of helper libraries and utilities might not always mean that they're actually useful. Those libraries are still generic, and they may be a long way away from some specific need you have, such that in the end I tend to rewrite myself part of them to have a more efficient, problem-specific solution.

• furthermore, things such as language & platform performance and documentation are things for which it's harder to compensate than it is with lack of libraries. If the code you wrote in language x and platform y is slow, optimizing it by yourself will never be as good as replacing it with language x2 and platform y2 for which a cohort of (probably smarter) people than myself have done optimizations. Same goes for documentation, the lack of it translates in more time spend on doing proof of concepts, trials and error, source and unit test code exploring in order to see how something must be done. And even if you go through all this, you still don't know if the solution you've chosen is the most suited, as the language creators intended for it to work.