Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
    
Regarding the vote to close (not a real question): The main point of the question is: "What you consider the most important criteria (if any) that are applied when saying that a language is mature." Possible criteria that come to my mind are: large user community, rich API, language stability, tool support. But I am really not sure which criteria are normally applied and which ones are considered less important for the definition of language maturity. Any suggestions on how to better formulate my question are welcome. –  Giorgio Nov 10 '12 at 13:32

2 Answers 2

up vote 7 down vote accepted

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.

share|improve this answer
    
+1 (not only but also) because you're touching on the open-source factor. There are a TON of examples in which closed source (and usually commercial) solutions are better than open source alternatives. Having open source tools, libraries, etc for a language counts however to its maturity, as (to me, at least) it means more than just the people who have a financial interest in the language have adopted that language hence they did it for more practical reasons. –  Shivan Dragon Nov 10 '12 at 23:11
    
@haylem: I agree with you that famous and mature are not the same. Good point. Regarding stability, I think it is a good idea to relate it to the level of "surprise" when using the language. –  Giorgio Nov 11 '12 at 10:01
    
@haylem: There are already two votes to close the question (I wish such votes were accompanied by some explanation, because that would help me improve my question). One reason could be that language comparisons are a delicate topic that can start debate (even though I do not see much debate up to now). Do you think it would be possible to formulate your answer without reference to specific languages? I think everybody would understand your point regarding being mature and being wide spread without mentioning specific examples. –  Giorgio Nov 11 '12 at 10:37
    
@Giorgio: my answer is already language-agnostic, the second section is just clarifying with examples. I'll try to re-write / expand it a bit tomorrow if I have time. –  haylem Nov 11 '12 at 19:08

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.

share|improve this answer
    
Thanks for the answer but please avoid mentioning specific languages, since this can lead to debate that is out of the scope of the question. –  Giorgio Nov 10 '12 at 12:22
    
I liked it better with a concrete, real-world example. –  Blrfl Nov 10 '12 at 12:29
    
@Blrfl: It might be easier to read but then people may start to debate about different programming languages and the question gets closed as "non constructive". –  Giorgio Nov 10 '12 at 12:33
1  
@Shivan Dragon: Thanks for removing the specific references, and thanks for the interesting answer. +1. –  Giorgio Nov 10 '12 at 12:35
2  
@Blrfl: I tend to agree more with Giorgio here, each time specific comparisons are done between languages they're usually followed by unending debates and, as Godwin's law states, it might even get down to Hitler references :). Better to leave it agnostic. –  Shivan Dragon Nov 10 '12 at 12:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.