Hace poco leí una respuesta a esta pregunta y me llamó la atención la frase "El lenguaje es maduro".

Entonces, me preguntaba a qué nos referimos cuando decimos que "un lenguaje de programación está maduro". Normalmente, un lenguaje de programación se desarrolla inicialmente a partir de una necesidad, p. Ej.

• Pruebe / implemente un nuevo paradigma de programación o una nueva combinación de características que no se pueden encontrar en los lenguajes existentes.
• Intenta resolver un problema o supera una limitación de un idioma existente.
• Crea un lenguaje para enseñar programación.
• Cree un lenguaje que resuelva una clase particular de problemas (por ejemplo, concurrencia).
• Cree un lenguaje y una API para un campo de aplicación especial, por ejemplo, la web (en este caso, el lenguaje podría reutilizar un paradigma bien conocido, pero toda la API debe ser nueva).
• Cree un lenguaje para sacar a su competidor del mercado (en este caso, el creador puede querer que el nuevo lenguaje sea muy similar al existente, para atraer a los desarrolladores al nuevo lenguaje y plataforma de programación).

Independientemente de cuál sea la motivación original y el escenario en el que se ha creado un idioma, eventualmente algunos idiomas se consideran maduros . En mi intuición, esto significa que el lenguaje ha logrado (al menos uno de) sus objetivos, por ejemplo, "Ahora podemos usar el lenguaje X como una herramienta confiable para escribir aplicaciones web".

Sin embargo, esto es un poco vago, por lo que quería preguntarle cuáles considera que son los criterios más importantes (si los hay) que se aplican al decir que un idioma es maduro.

NOTA IMPORTANTE

Esta pregunta es (a propósito) independiente del lenguaje porque solo me interesan los criterios generales. ¡Por favor escriba solo respuestas y comentarios independientes del idioma! No estoy preguntando si algún "lenguaje X es maduro" específico o "qué lenguajes de programación se pueden considerar maduros", o si "el lenguaje X es más maduro que el lenguaje Y": evite publicar opiniones o referencias sobre idiomas específicos porque están fuera del alcance de esta pregunta.

EDITAR

Para hacer la pregunta más precisa, por criterios quiero decir cosas como "soporte de herramientas", "adopción por parte de la industria", "estabilidad", "API enriquecida", "gran comunidad de usuarios", "registro de aplicaciones exitosas", "estandarización" , "semántica limpia y uniforme", y así sucesivamente.

Factores de aceptación

Diría una combinación de varias cosas, pero no creo que todas sean necesarias. Algunos idiomas considerados maduros hoy en día claramente no satisfacen algunos de estos.

Yo diría una combinación de:

• Estampación:
  • línea principal: Al menos un conjunto de herramientas "oficial" estable o ampliamente aceptado (de facto o recomendado / respaldado por el proveedor) (compilador, intérprete, vm, editor).
  • Alternativa : algunas alternativas estables y no tan estables de las herramientas anteriores (variantes de código abierto o cerrado, variantes gratuitas o comerciales, extensiones, etc.).
• Comunidad: un grupo activo , pero no necesariamente grande de seguidores y contribuyentes.
• Reconocimiento:
  • Algún grado de reconocimiento y uso por parte de algunos actores industriales (incluso si están en un nicho).
  • Algún grado de reconocimiento en la cultura popular (incluso si está en un nicho).

Sobre fama, reconocimiento y madurez

Tenga en cuenta que el diferenciador aquí es tener validadores de criterios fuertes y activos, no grandes o numerosos. Para aclarar, considere estos ejemplos muy diferentes:

• Ruby fue durante mucho tiempo un idioma con un gran respaldo de la comunidad, una implementación de referencia oficial, etc. Era famoso antes de ser maduro.

• Por otro lado del espectro, algunos idiomas que alguna vez fueron muy utilizados (COBOL, FORTRAN ...) ahora son menos visibles pero aún maduros en todos los sentidos posibles. Alguna vez fueron famosos y maduros.

• Además, en mi opinión, algunos lenguajes de nicho son definitivamente maduros, a pesar de su pequeña (pero establecida) penetración en el mercado. Considere Oberon o Limbo. Son maduros pero nunca se hicieron famosos. Otros, como R, son relativamente famosos porque sus "nichos" no son realmente nichos (me molesta cuando las personas llaman a Scala o Clojure "lenguajes de nicho", que definitivamente no lo son), aunque su campo de aplicaciones no lo es. exactamente lo que llamarías mainstream.

Sobre la estabilidad

¿Qué es estable de todos modos? Es bastante relativo ...

• ¿Conformidad?
  • ¿Al estándar (si hay uno)?
  • ¿A una implementación de referencia (si hay una)?
• Número de errores? (apenas una buena medida)
• Uso en entornos críticos?

En general, la estabilidad simplemente significa que no me sorprende a diario cuando realizo mi trabajo promedio usando el juego de herramientas del idioma, y ​​puedo obtener respuestas definitivas sobre lo que debería o no debería suceder cuando intento hacer algo con el idioma y su kit de herramientas, ya sea en tiempo de compilación o tiempo de ejecución de mis programas.

Pero la estabilidad para alguien que escribe aplicaciones para teléfonos inteligentes y la estabilidad para alguien que escribe sistemas médicos o de aviónica es un tipo diferente de ave.

De hecho, me he preguntado lo mismo hace unos años. En aquel entonces, decidí que un lenguaje es maduro (es decir, bueno para resolver problemas de tipo x) si tiene la mayoría de las características necesarias para resolver ese problema. En otras palabras, qué cantidad de herramientas de resolución de problemas específicos tengo para crearme frente a cuántas ya vienen con el lenguaje. Según su comentario, eliminaré el ejemplo específico del idioma y lo reemplazaré con un lenguaje independiente del idioma:

Básicamente pensé que un lenguaje que tiene muchas bibliotecas "auxiliares" y "útiles" integradas es más maduro que uno en el que algunos de ellos no existían (y en el que tendría que escribirlos, o algo similar a ellos mismos)

Estoy hablando de todo esto en el pasado porque en estos días he abandonado esa forma de pensar, y pienso en la madurez de un idioma más como esto:

• qué tan fuerte es la comunidad para ese idioma. Cuántos documentos, libros, ejemplos pertinentes hay. Esto es importante, porque puede tener idiomas que son muy agradables y que pueden ser más adecuados para una tarea específica que otras, pero que están mal documentados, de modo que nunca pueda ver sus ventajas.

• actuación. Para una tarea determinada y una implementación x dada, el lenguaje en el que esa implementación se ejecutará más rápido es más maduro. Sí, esta es un área muy gris, y para la mayoría de los idiomas y plataformas es difícil hacer la comparación. Sin embargo, para ciertos lenguajes y plataformas es bastante sencillo ver cuál supera a cuál. Para cierto tipo de problemas esto es muy importante.

• loco. Oh si. Nunca hubiera pensado en esto hasta que lo haya visto con mis propios ojos. No voy a dar ningún ejemplo porque no quiero parecer que estoy criticando un idioma u otro, pero hay idiomas por ahí (bueno, más precisamente, entornos de compilación y tiempo de ejecución para ciertos idiomas) que son muy defectuoso, hasta el punto en que ya no puedes confiar y estimar cómo funcionará algo. Para mí, la madurez de un idioma cae mucho cuando este es el caso.

Las razones por las que cambié la forma en que pienso que un idioma es más maduro son:

• En primer lugar, el hecho de que un lenguaje tenga un montón de bibliotecas y utilidades auxiliares puede no siempre significar que sean realmente útiles. Esas bibliotecas siguen siendo genéricas, y pueden estar muy lejos de alguna necesidad específica que tenga, de modo que al final tiendo a reescribirme parte de ellas para tener una solución más eficiente y específica del problema.

• además, cosas como el rendimiento del lenguaje y la plataforma y la documentación son cosas por las que es más difícil de compensar que la falta de bibliotecas. Si el código que escribió en el lenguaje xy en la plataforma y es lento, optimizarlo usted mismo nunca será tan bueno como reemplazarlo con el lenguaje x2 y la plataforma y2 para el cual una cohorte de personas (probablemente más inteligentes) que yo ha realizado optimizaciones. Lo mismo ocurre con la documentación, la falta de ella se traduce en más tiempo dedicado a hacer pruebas de conceptos, pruebas y errores, exploración de código fuente y prueba de unidad para ver cómo se debe hacer algo. E incluso si pasa por todo esto, todavía no sabe si la solución que ha elegido es la más adecuada, ya que los creadores del lenguaje pretendían que funcionara.