El término "Lisp" (o "similar a Lisp") es un paraguas para muchos idiomas diferentes, como Common Lisp, Scheme y Arc. Existe una fragmentación similar en otras comunidades lingüísticas, como en ML.
Sin embargo, Ruby y Python lograron evitar este destino, donde la innovación se produjo más en la implementación (como PyPy o YARV) en lugar de realizar cambios en el lenguaje en sí.
¿Las comunidades Ruby y Python hicieron algo especial para evitar la fragmentación del idioma?
Ruby y Python ambos tienen dictadores benévolos a su mando. Son lenguajes profundamente arraigados en preocupaciones pragmáticas. Esos son probablemente los factores más significativos que inhiben la fragmentación. Lisp y ML, por otro lado, son más como lenguajes de "diseño por comité", concebidos en la academia, para propósitos teóricos.
Lisp fue diseñado originalmente por John McCarthy como una notación matemática práctica para programas de computadora. Nunca lo implementó como un lenguaje de programación real; La primera implementación fue desarrollada por Steve Russell , pero no fue un dictador benévolo. Con el tiempo, aparecieron muchas implementaciones diferentes de Lisp; Common Lisp fue un intento de estandarizarlos.
Lisp es más de una "familia" de idiomas. Así es ML, que siguió un camino evolutivo similar a Lisp.
Un factor probable es simplemente la edad. Lisp y ML son mucho más antiguos que Python y Ruby:
Lisp: 1958
ML: 1973
Python: 1991
Ruby: 1995
Obviamente, Lisp y ML han visto un cambio mucho mayor en las capacidades de hardware, más tendencias en ciencias de la computación y muchos más estudiantes de doctorado que buscan algo en lo que trabajar.
Son esencialmente todos los lenguajes definidos para la implementación
Cuando es fácil crear una nueva implementación de un lenguaje que sea en gran parte compatible con el código existente, los hackers son piratas informáticos, siguen adelante y lo hacen. Todos escriben una implementación de Lisp en algún momento. Los compiladores de ML son casi obligatorios para los estudiantes graduados en diseño de idiomas; el lenguaje es, después de todo, famoso bien documentado .
Por otro lado, tenemos los lenguajes ad hoc y definidos por la implementación. O lenguajes que son tan complejos que es una barrera significativa para producir una implementación alternativa viable:
Este aspecto negativo - los lenguajes que son demasiado difíciles de producir alternativas viables a, tienen el lado positivo masivo : los escasos recursos para desarrolladores se concentran en la única implementación verdadera.
Como nota histórica, varios miembros de la comunidad de Haskell buscaron activamente las fusiones y la concentración del esfuerzo de desarrollo, reconociendo que cualquier fragmentación de la comunidad de desarrollo significaría que no tendríamos éxito. GHC fue elegido y defendido.
Yo diría que un factor es una plataforma de definición . Para Haskell, la plataforma es el estándar de Haskell y el GHC (me imagino). Para Ruby fue Ruby on Rails el que "definió" la plataforma de desarrollo de Ruby. Para C era Unix.
Compare eso con Lisp, donde no había una plataforma original que definiera cómo era el idioma. Si recuerdo correctamente, cada máquina Lisp tenía pequeñas diferencias según el modelo y el fabricante. Common Lisp fue por alguna razón no definitoria. Posiblemente debido a demasiada competencia y reticencia a moverse a otra plataforma.
Esto es, por supuesto, totalmente especulación de mi parte. El pensamiento vino de las respuestas del comentario sobre la respuesta de Harvey. Sin embargo, parece que la plataforma de definición viene en muchas formas, pero la propiedad común parece ser que es de lo que gana popularidad.
No olvides sopesar la cultura que impulsa el desarrollo de un idioma
También valoraría el hecho de que el desarrollo en python / php se realiza activamente en público. Usted tiene un grupo de personas que especifican una especificación estándar que está disponible gratuitamente para cualquiera.
Al igual que el W3C lo hace con el estándar HTML / CSS. Usted tiene un pequeño grupo de personas motivadas que controlan los detalles más finos de lo que el lenguaje está diseñado para lograr. Todo entra en una especificación claramente definida antes de que se publique al público.
OTOH, idiomas como LISP están ocultos a puerta cerrada por profesores u otras personas que realmente creen que su punto de vista sobre el "mejor uso" del idioma es correcto. Pueden ser simultáneamente correctos e incorrectos al mismo tiempo porque algunas implementaciones son buenas en ciertas cosas; mientras que ninguno es el mejor en todo.
Eso no es necesariamente algo malo porque la diversidad engendra innovación. Los lenguajes como LISP son, y seguirán siendo excelentes lenguajes para el aprendizaje y la investigación, ya que superan los límites de la comprensión.
Pero las cualidades que hacen que un entorno sea bueno para la innovación no son necesariamente beneficiosas para la estabilidad; a la inversa, las cualidades que hacen que un entorno sea bueno para la estabilidad no son necesariamente buenas para la creatividad.
Cuando el desarrollo se basa en la colaboración activa, a veces los individuos se ven obligados a ceder para el beneficio del todo. Malo para la investigación / bueno para la consistencia.
El hecho es que aún vivimos en el extremo oeste del desarrollo del lenguaje de programación. El problema de diseñar el "lenguaje ideal" es tan grande que, a pesar de los esfuerzos monumentales, nadie se ha acercado a resolverlo.
En el sector de investigación / academia, todavía hay mucho espacio para mejorar e innovar. En el sector comercial, donde hay un crecimiento exponencial de software que se utiliza en aplicaciones prácticas y la fuerza motriz es la simplicidad y la consistencia.
Algunos idiomas se especializan en el primero, algunos se especializan en el segundo. Aquellos que tratan de especializarse en ambos, generalmente tampoco lo hacen muy bien y mueren.
Por ambos, me refiero a lenguajes monolíticos como VB / C # / Java. Es muy temprano para decirlo, pero me gustaría ver qué aspecto tienen C # y Python en 10 años. Al ritmo actual, C # está aumentando la funcionalidad y la inconsistencia a un ritmo que lo hace ver bastante sombrío. Incluso con una gran documentación, es demasiado difícil recordar todos los detalles sutiles y las peculiaridades incluidas en el idioma. Es genial para un solo desarrollador, pero tan pronto como incorporas más desarrolladores con estilos únicos, la inconsistencia en el código base crece, la calidad se resiente y nadie gana. Creo que hay mucho que aprender de las dificultades que presenta Perl en un entorno de producción.
No creo que sea correcto decir que lenguajes como Python y Ruby no están fragmentados. Ya estamos empezando a ver algunos efectos de fragmentación. Por ejemplo, Python 3 no es totalmente compatible con Python 2, por lo que es necesario mantener ambas versiones y muchos de los códigos existentes solo funcionan con Python 2. También hay algunos derivados de Python, incluido PyPy.
Otro factor es la edad de las lenguas. Los más sometidos a la fragmentación son los idiomas más antiguos y, por lo tanto, están sujetos a presiones de evolución y revisión. Lisp se inventó hace varias décadas, por lo que ha habido tiempo suficiente para tomar algunas de sus ideas e incorporarlas a nuevos idiomas. C es otro ejemplo de un lenguaje fragmentado. Si bien C solo tuvo una revisión realmente importante del lenguaje en sí (K & R a ANSI), ha habido numerosas derivaciones que incluyen C ++, Not Quite C, y todas las demás que comparten una sintaxis similar a C.
Ruby en sí mismo es una "fragmentación" (si lo desea) de idiomas anteriores. Dado que incorpora ideas de C, Smalltalk y Perl (entre otras), actualmente es el lenguaje haciendo la fragmentación. No veo por qué es posible que no veamos más convolución de Ruby con otros idiomas en el futuro.
Lisp está fragmentado porque es un modelo tan poderoso, el lenguaje más sorprendente jamás concebido. La mayoría de los idiomas de hoy toman prestadas cosas que se implementaron por primera vez en Lisp, por lo que de alguna manera puede decir que cada idioma es parte de esta fragmentación en particular. Smalltalk, por ejemplo, fue fuertemente inspirado por Lisp, y Ruby está fuertemente inspirado por Smalltalk. JavaScript es Lisp en un disfraz de Java, y así sucesivamente. Está todo conectado, y cada inventor de idiomas selecciona sus piezas favoritas de otros idiomas.
Otro factor es que Lisp es probablemente el concepto de programación más fácil de implementar, razón por la cual se realiza una y otra vez.
Los lenguajes similares a Lisp son demasiado básicos y teóricos para cambiarlos dramáticamente. Los cambios gramaticales (no solo quiero cambiar los nombres de los comandos) simplemente no encajarían en la teoría de la programación funcional detrás de ellos.
Pero el hecho de que haya lenguajes como lisp muestra que los "cambios" ya se hicieron para lisp de todos modos. En otras palabras, hay lenguajes creados por personas que se inspiraron en lisp o es la teoría subyacente y crearon un nuevo lenguaje similar similar.
También hay muchos lenguajes inspirados en Python. P.ej. Julia, CoffeeScript, etc., que formarían su propia familia de lenguajes orientados a objetos sensibles al espacio en blanco.
Creo que los conceptos básicos de un lenguaje como Python nunca cambiarán realmente. Python está orientado a objetos y, por lo tanto, tiene similitudes con C ++ y Java, pero es dinámico y, por lo tanto, también similar a muchos lenguajes de script.
Bueno, ¿a quién le importan los idiomas? Lo que cuenta es el propósito: el francés es similar al latín, pero las chicas que entienden el francés son mucho más atractivas;)
Lea otras preguntas en las etiquetas programming-languages language-design