Criteria for a Mature Programming Language

programming-languages

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.

Best Answer

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.

Related Solutions

Is Language-Oriented Programming practical

I've been advocating DSLs for a long time, but I worry about what happens to Good Ideas when they become bandwagons. Products get built that advertise The Good Idea, promising all you have to do is get one, and you'll be in the in-group, without having to think very carefully about what it means.

What is a language? It's a vocabulary and syntax in which meanings can be communicated, right? Every time you declare a variable, write a function, define a class, you are building a new language, by adding nouns and verbs to an existing language. Now you can say things in it that you couldn't before.

I think what makes a language Domain Specific is the extent to which it naturally expresses the mental concepts that are being communicated, and I think there's a simple measure of that. Basically, if there is a simple independent stand-alone requirement X, that could be included in the program or not, its correct implementation requires some set of code insertions, deletions, and replacements Y. A simple before-and-after diff can display Y. The number N of such changes is a measure of how domain-specific the language is. The smaller N is, for typical requirements, the better.

It doesn't necessarily depend on fancy syntax, control structures, message-passing, or what have you. What it depends on is how concisely it implements the requirement. Many tools will claim to do this, but claims are not actuality. It has to be real.

Sometimes an unusual technology is necessary. Here's my favorite example. When it is, it illustrates the point that it may require effort on the part of programmers to understand it. So domain-specificity (and maintainability) is not at all the same thing as readability.

So I agree with the second approach, that a good language is one that easily lets one build the necessary languages on top of it. (That's what I liked about Lisp.) But even more important is programmers need to know how to build languages to match the domains they are working in, and be willing to climb the learning curves of such languages.

I don't really see that happening. Instead they are stuck in the "programs = algorithms + data structure", or "nouns become classes and verbs become methods" turn-the-crank modes of thinking. They are not working in terms of how to take thought domains and linguify them for maximum concision.

Functional Programming – Is It on the Rise?

In which scenarios should I consider a functional programming languages better suited to do a given task? Besides the so recently popular multicore problem of parallel programming.

Anything that involves creating sequence of derived data elements using a number of transformation steps.

Essentially, the "spreadsheet problem". You have some initial data and set of row-by-row calculations to apply to that data.

Our production applications do a number of statistical summaries of data; this is all best approached functionally.

One common thing we do is a match-merge between three monstrous data sets. Similar to a SQL join, but not as generalized. This is followed by a number of calculations of derived data. This is all just functional transformations.

The application is written in Python, but is written in a functional style using generator functions and immutable named tuples. It's a composition of lower-level functions.

Here's a concrete example of a functional composition.

for line in ( l.split(":") for l in ( l.strip() for l in someFile ) ):
    print line[0], line[3]

This is one way that functional programming influences languages like Python.

Sometimes this kind of thing gets written as:

cleaned = ( l.strip() for l in someFile )
split = ( l.split(":") for l in cleaned )
for line in split:
     print line[0], line[3]

If I decided to switch to a functional programming language which do you consider are the biggest pitfalls that I will face? (Besides the paradigm change and the difficulty to evaluate performance due to lazy evaluation).

Immutable objects is the toughest hurdle.

Often you'll wind up calculating values that create new objects instead of updating existing objects. The idea that it's a mutable attribute of an object is a hard mental habit to break.

A derived property or method function is a better approach. Stateful objects are a hard habit to break.

With so many functional programming languages out there, how would you choose the one the better suit your needs?

It doesn't matter at first. Pick any language to learn. Once you know something, you're in a position consider picking another to better suit your needs.

I've read up on Haskell just to understand the things Python lacks.