¿Cómo pudieron algunas comunidades lingüísticas (por ejemplo, Ruby y Python) evitar la fragmentación mientras que otras (por ejemplo, Lisp o ML) no pudieron?

67

El término "Lisp" (o "Lisp-like") es un paraguas para muchos idiomas diferentes, como Common Lisp, Scheme y Arc. Hay una fragmentación similar en otras comunidades lingüísticas, como en ML.

Sin embargo, Ruby y Python han logrado 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 prevenir la fragmentación del lenguaje?

programming-languages language-design chrisaycock
fuente
10
Dices fragmentación como si fuera algo malo.
Sonia
21
@Sonia Desde una perspectiva de cuota de mercado, la fragmentación suele ser un desastre.
chrisaycock
55
¿Los idiomas compiten entre ellos?
Barry Brown el
32
@Sonia Puede ser algo malo. Por ejemplo, una biblioteca escrita para Python casi ciertamente no depende de la implementación, mientras que una biblioteca escrita para Lisp puede no funcionar en Scheme.
Kris Harper
2
@Barry Brown: ¡Gran punto! Los idiomas no deben competir entre sí en el mercado. Pero los vendedores de idiomas lo son y esto a menudo influye en el diseño del lenguaje (aunque no creo que este sea el caso de Ruby, Python, Lisp, ML).
Giorgio

Respuestas:

77

Ruby y Python tienen dictadores benevolentes al frente. Son idiomas profundamente arraigados en preocupaciones pragmáticas. Esos son probablemente los factores más importantes 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, con fines 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; Steve Russell desarrolló la primera implementación , pero no fue un dictador benevolente. Con el tiempo, aparecieron muchas implementaciones diferentes de Lisp; Common Lisp fue un intento de estandarizarlos.

Lisp es más una "familia" de idiomas. También lo es ML, que siguió un camino evolutivo similar a Lisp.

Robert Harvey
fuente
44
Hmm, definitivamente veo el estado del dictador entre comunidades de lenguaje homogéneas como Objective-C (para aplicaciones iOS) y Ada (para contratos del Departamento de Defensa). En estos casos, un poder superior exigía adherencia, que los desarrolladores siguieron solo para poder vender sus warez. Pero nunca se me ha requerido codificar en Python (proyecto de aficionado) en el mismo sentido en que podría estar obligado a codificar en C # (componente .Net). Es decir, podría huir más fácilmente de Python que, por ejemplo, C. Sin esta amenaza de usarlo o no harás ventas , ¿cómo puede un dictador aferrarse al rebaño? Sin embargo, esa podría ser una pregunta separada.
chrisaycock
1
Por "dictador benevolente", quiero decir que todos los cambios de idioma deben pasar por una persona que tenga la visión de mantener el idioma puro. La gente se queda con Python por razones pragmáticas; les gusta el idioma y son productivos en él. Pero no todos y sus hermanos pueden bifurcarlo, y aún así llamarlo Python.
Robert Harvey
44
@HenrikHansen Haskell es un estándar, como Robert menciona. Por lo tanto, el compilador HUGS debe ser compatible con GHC ya que ambos se llaman a sí mismos "Haskell". La misma protección basada en estándares se extiende a C y C ++, por lo que GCC y Visual Studio deben ser compatibles (suponiendo que no se utilicen extensiones propietarias). La curiosidad es lo que le sucedió a Lisp, donde ya existe un estándar (Common Lisp) y, sin embargo, hay muchos otros Lisps. ML tiene el mismo problema cuando hay ML estándar y otros ML.
chrisaycock
44
"Common Lisp fue desarrollado para estandarizar las variantes divergentes de Lisp que lo precedieron" - en.wikipedia.org/wiki/Common_Lisp . En otras palabras, ya había fragmentación antes de que se desarrollara el estándar.
Robert Harvey
3
Incluso diría que ML y Lisp no son lenguajes como Python y Ruby. Lisp y ML son más como "conceptos", implementados por varios idiomas diferentes.
BenjaminB
29

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

  • Rubí: 1995

Lisp y ML obviamente han visto un cambio mucho mayor en las capacidades de hardware, más tendencias en informática y muchos más estudiantes de doctorado que buscan algo en qué trabajar.

Caleb
fuente
77
Posiblemente, pero no recuerdo que Fortran tenga este grado de bifurcación. (Hubo cosas como Fortran D, pero la mayoría de los Fortrans han pasado por la estandarización). Supongo que tal vez la edad de fusión podría ser un factor.
chrisaycock
2
AFAIK, Fortran tenía mucha incompatibilidad y extensiones no estándar y diferentes implementaciones hasta que los comités de estándares lo resolvieron gradualmente, probablemente porque estaba más extendido que Lisp y ML.
erjiang
@erjian: FORTRAN tuvo sus incompatibilidades resueltas porque había un incentivo serio para: el uso comercial. LISP, utilizado principalmente en el mundo académico, nunca tuvo ese lujo. Es decir, no es qué tan extendido fue su uso, sino qué tan ricos eran sus usuarios.
MSalters
2
O, alternativamente, las variantes no se llamaban FORTRAN. BÁSICO, cuando salió, seguro parecía un FORTRAN simplificado.
David Thornley,
1
@MSalters Common Lisp fue en realidad un esfuerzo (bastante exitoso de la OMI) para resolver las incompatibilidades en los diversos dialectos maclisp dictados, entre otras cosas, por el uso comercial (y también DARPA quería que todos los laboratorios de investigación que financiaba pudieran compartir código más fácilmente) . Hoy en día, aparte del esquema, clojure y lisp común, no hay lisps prácticos de propósito general, y estos tres son lo suficientemente diferentes, tienen comunidades muy separadas con culturas e historia separadas para no contarlos como dialectos del mismo idioma más que java y C ++. .
Pavel Penev
24

Son esencialmente todos los lenguajes definidos de implementación

Cuando es fácil crear una nueva implementación de un lenguaje que sea ampliamente compatible con el código existente, los piratas informáticos son piratas informáticos, continúan y lo hacen. Todos escriben una implementación de Lisp en algún momento. Los compiladores de ML son casi obligatorios para los estudiantes de posgrado en diseño de idiomas: después de todo, el idioma está muy 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 importante para producir una implementación alternativa viable:

  • rubí; perl Python: todo demasiado definido en la implementación para producir alternativas viables
  • ghc haskell y erlang: bien definidos, pero tan difíciles de hacer algo que compita con ghc (o erlang) que las personas no suelen molestarse

Este aparente inconveniente: los lenguajes que son demasiado difíciles de producir alternativas viables, tienen la ventaja masiva : los escasos recursos para desarrolladores se concentran en la única implementación real.

Como nota histórica, varios miembros de la comunidad de Haskell buscaron activamente fusiones y 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.

Don Stewart
fuente
2
Me encantaría saber más acerca de las "fusiones y concentración perseguidas activamente".
Sam Tobin-Hochstadt,
La fragmentación es natural. Los lenguajes como Python y Ruby son anomolias que no se fragmentaron en el principal, si no cuenta las variantes no utilizadas, por ejemplo, ChinesePython, y las variantes estancadas en una versión anterior, por ejemplo, Jython. También hay un sesgo de supervivencia aquí, porque la mayoría de los idiomas con un dictador no se vuelven muy populares, por ejemplo, Nermerle, Groovy, Beanshell, Boo, de hecho, probablemente hay miles de ellos.
Vorg van Geir
1
Incluso entonces, Haskell podría ser más práctico para alcanzar el estado de madurez de Python / Ruby. Haskell's cabalno es una herramienta divertida de usar y bastante fácil de romper: Incluso Yesod lo reconoce: yesodweb.com/blog/2012/04/cabal-meta Python y Ruby son mucho mejores en lo que respecta a la gestión de paquetes.
Ehtesh Choudhury
1
@Shurane Python y Ruby no escriben chequean sus paquetes antes de la integración ...
Don Stewart
2
-1: para "ruby; perl; python - todo demasiado definido en la implementación para producir alternativas viables" Jython, IronPython, JRuby, IronRuby, PyPy, Stackless demuestran que estás equivocado en cuanto a implementaciones (y estas son solo las principales). Además, CPython es una implementación de referencia, pero no la definición del lenguaje, esto es
vartec
12

Yo diría que un factor es una plataforma definitoria . Para Haskell, la plataforma es el estándar de Haskell y el GHC (me imagino). Para Ruby, fue Ruby on Rails quien "definió" la plataforma de desarrollo Ruby. Para C fue Unix.

Compare eso con Lisp, donde no había una plataforma original que definiera cómo era el lenguaje. Si recuerdo correctamente, cada máquina Lisp tenía ligeras diferencias según el modelo y el fabricante. Common Lisp fue por alguna razón no definitoria. Posiblemente debido a demasiada competencia y renuencia a mudarse a otra plataforma.

Esto es, por supuesto, completamente especulativo de mi parte. El pensamiento surgió de las respuestas al comentario sobre la respuesta de Harvey. Sin embargo, parece que la plataforma de definición tiene muchas formas, pero la propiedad común parece ser que es lo que gana popularidad.

Henrik Hansen
fuente
En realidad me gusta esta idea. Puedo usar muchas formas de Lisp porque ninguna de ellas tiene un "marco asesino", pero si quiero usar Rails, debo seguir con el canónico Ruby. Ciertamente, no es la única respuesta, pero me gusta su hipótesis.
chrisaycock
Estoy de acuerdo con la parte de la plataforma . Si tiene un solo traductor capaz de ejecutar el idioma, no habría mucha fragmentación.
c69
El ceceo común no se estableció en una sola definición temprana porque las personas tenían opiniones firmes sobre ciertas cosas, por ejemplo, macros higiénicos.
Robert Harvey
Estoy de acuerdo y en desacuerdo con esto. Estoy de acuerdo porque un 'marco asesino' parchea el lenguaje central con una funcionalidad valiosa, fomenta el crecimiento y permite una rápida innovación fuera de las especificaciones estándar. No estoy de acuerdo porque, si los mantenedores del marco no son muy cuidadosos, ese rápido aumento en la innovación podría generar mucha hinchazón y / o abstracciones con fugas que podrían volverlo inestable.
Evan Plaice el
1
(cont) Los marcos como jQuery que extienden la funcionalidad central de un lenguaje idealmente morirán en el futuro ya que las contribuciones más valiosas dadas por esos marcos se estandarizan e incorporan al núcleo. En mi humilde opinión, los marcos tienden a morir más rápido porque los desarrolladores generalmente prefieren reducir / eliminar dependencias a medida que se estabiliza una base de código. Si los desarrolladores de lenguaje quieren seguir siendo relevantes, facilitarán ese proceso adaptando y adoptando la funcionalidad del marco, y alentando a sus usuarios a reducir las dependencias de los marcos de terceros.
Evan Plaice el
7

No olvides sopesar la cultura que impulsa el desarrollo de un idioma.

También consideraría el hecho de que el desarrollo en python / php se realiza activamente en público. Tiene un grupo de personas que establecen una especificación estándar que está disponible gratuitamente para cualquiera / todos.

Al igual que el W3C hace con el estándar HTML / CSS. Tienes 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 ser lanzado al público.

OTOH, idiomas como LISP son bifurcados a puertas cerradas por profesores u otras personas que realmente creen que su perspectiva sobre el "mejor uso" del lenguaje es correcta. Pueden ser simultáneamente correctos e incorrectos al mismo tiempo porque algunas implementaciones son excelentes en ciertas cosas; mientras que ninguno es el mejor en todo.

Eso no es necesariamente algo malo porque la diversidad genera innovación. Los idiomas como LISP son y seguirán siendo excelentes idiomas 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; Por el contrario, 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 una colaboración activa, a veces las personas se ven obligadas a conceder en beneficio del todo mayor. Malo para la investigación / bueno para la consistencia.

El hecho es que todavía estamos viviendo en el salvaje 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 margen de mejora e innovación. En el sector comercial, donde hay un crecimiento exponencial del software que se utiliza en aplicaciones prácticas y la fuerza impulsora es la simplicidad y la coherencia.

Algunos idiomas se especializan en el primero, algunos se especializan en el segundo. Aquellos que intentan especializarse en ambos generalmente no lo hacen muy bien y mueren.

Por ambos, me refiero a lenguajes monolíticos como VB / C # / Java. Es demasiado pronto para decirlo, pero me gustaría ver cómo se ven C # y Python en 10 años. Al ritmo actual, C # está aumentando la funcionalidad y la inconsistencia a un ritmo que lo hace parecer bastante sombrío. Incluso con una excelente documentación, es demasiado doloroso recordar todos los detalles sutiles y las peculiaridades incluidas en el lenguaje. Es genial para un solo desarrollador, pero tan pronto como agregue más desarrolladores con estilos únicos, la inconsistencia en la base de código aumenta, la calidad sufre y nadie gana. Creo que hay mucho que aprender de las dificultades que presenta Perl en un entorno de producción.

Evan Plaice
fuente
¿Escalera? ¿Te refieres a esto último?
Giorgio
@ Jorge Sí, odio cuando escribo mal eso.
Evan Plaice
2

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 ambas versiones deben mantenerse y muchos de los códigos existentes solo funcionan con Python 2. También hay algunas derivaciones de Python, incluido PyPy.

Otro factor es la edad de los idiomas. Los más sujetos 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 lenguaje fragmentado. Si bien C solo tuvo una revisión realmente importante del lenguaje en sí (K&R a ANSI), ha habido numerosos spin-offs que incluyen C ++, Not Quite C y todos los demás que comparten una sintaxis similar a C.

Ruby en sí es una "fragmentación" (si lo desea) de los idiomas anteriores. Ya que incorpora las ideas de C, Smalltalk, y Perl (entre otros), que es actualmente el idioma haciendo la fragmentación. No veo por qué podríamos no ver una mayor convolución de Ruby con otros idiomas en el futuro.

Barry Brown
fuente
66
-1 porque: (1) Python 3.x no es fragmentación. Es solo el siguiente paso en la evolución del lenguaje; Python 2.x se eliminará por completo en unos pocos años. (2) Otras implementaciones de lenguaje que son 99% compatibles (el 1% son detalles de implementación y en su mayoría bastante oscuros) y se niegan activamente a participar en la definición del lenguaje no son fragmentación. (3) Un lenguaje muy diferente que comparte algo en común y es algo compatible (C ++ a C) es apenas fragmentación. (4) Aceptar ideas de idiomas existentes no es fragmentación, es la única forma en que se diseña un idioma.
2
@delnan: ¿Python 2.x se eliminará por completo en unos años? ¡Eso es algo tonto de decir, cuando COBOL y Fortran todavía están cerca!
Mason Wheeler
3
@MasonWheeler Estoy hablando del desarrollo. El VCS todavía tendrá un código antiguo archivado, las descargas binarias no oficiales pueden permanecer durante décadas, y algunas tiendas pueden evitar la transferencia. Pero espero que algún día no muy lejano, la gran mayoría de la programación de Python ocurra en Python 3. Después de todo, el desarrollo de características 2.x cesó hace un tiempo (y no se reanudará a menos que se lave el cerebro a python-dev) , no se supone que las actualizaciones de seguridad / corrección de errores continúen para siempre, y una parte importante de las bibliotecas se transfiere a Python 3 con la mayoría de las otras que esperan (por ejemplo, Djano) o no se mantienen.
1
@MasonWheeler Oh, y en cuanto a Fortran y COBOL: Fortran recibió una nueva revisión estándar en 2008, y COBOL recibió una en 2002 con un puñado de informes técnicos desde entonces.
@MasonWheeler ¿Sabía que COBOL moderno permite la programación orientada a objetos?
2

Lisp está fragmentado porque es un modelo tan poderoso, el lenguaje más sorprendente jamás concebido. La mayoría de los idiomas actuales toman prestados elementos que se implementaron por primera vez en Lisp, por lo que, de alguna manera, se puede decir que cada idioma es parte de esta fragmentación particular. Smalltalk, por ejemplo, estuvo fuertemente inspirado por Lisp, y Ruby está fuertemente inspirado por Smalltalk. JavaScript es Lisp con un disfraz de Java, etc. Todo está 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 hace una y otra vez.

Torbjørn
fuente
1

Los lenguajes similares a Lisp son demasiado básicos y teóricos para cambiarlos dramáticamente. Los cambios gramaticales (no me refiero a solo 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 idiomas como lisp muestra que los "cambios" ya se hicieron para lisp de todos modos. En otras palabras, hay idiomas creados por personas que se inspiraron en el lisp o su teoría y crearon un lenguaje nuevo similar.

También hay muchos lenguajes inspirados en Python. Por ejemplo, Julia, CoffeeScript, etc., que formarían su propia familia de lenguajes orientados a objetos sensibles al espacio en blanco.

Creo que los fundamentos 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 es 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 populares;)

PSchwede
fuente