¿Por qué la comunidad Lisp está tan fragmentada?
scheme common-lisp (9)
Creo que es porque "Lisp" es una descripción tan amplia de un idioma. La única cosa común entre todos los ceceos que sé es que la mayoría de las cosas están entre paréntesis, y usa la notación de función de prefijo. P.ej
(fun (+ 3 4))
Sin embargo, casi todo lo demás puede variar entre implementaciones. Scheme y CL son idiomas completamente diferentes, y deberían considerarse así.
Creo que llamar a la comunidad de lisp fragmentada es como llamar a la comunidad "C like" fragmentada. Tiene c, c ++, d, java, c #, go, javascript, python y muchos otros lenguajes que no se me ocurren.
En resumen: Lisp es más una propiedad de lenguaje (como recolección de basura, escritura estática) que una implementación de idioma real, por lo que es completamente normal que haya muchos idiomas que tengan la propiedad Lisp like, al igual que muchos idiomas tienen recolección de basura.
Para empezar, no solo existen dos dialectos principales del lenguaje (Common Lisp y Scheme), sino que cada uno de los dialectos tiene muchas implementaciones individuales. Por ejemplo, Chicken Scheme, Bigloo, etc ... cada uno con ligeras diferencias.
Desde un punto de vista moderno, esto es extraño, ya que los idiomas en estos días tienden a tener implementaciones / especificaciones definitivas. Piense en Java, C #, Python, Ruby, etc., donde cada uno tiene un único sitio definitivo al que puede acceder para obtener documentos, descargas y demás de la API. Por supuesto, Lisp es anterior a todos estos idiomas. Pero, de nuevo, incluso C / C ++ están estandarizados (más o menos).
¿La fragmentación de esta comunidad se debe a la edad de Lisp? ¿O tal vez diferentes implementaciones / dialectos están destinados a resolver diferentes problemas? Entiendo que hay buenas razones por las que Lisp nunca estará tan unido como los idiomas que han crecido en torno a una única implementación definitiva, pero en este punto ¿hay alguna buena razón por la cual la comunidad Lisp no debería moverse en esta dirección?
Creo que es porque Lisp nació y mantiene el espíritu de la cultura hacker. La cultura de los hackers es tomar algo y hacerlo "mejor" según su creencia en "mejor".
Entonces, cuando tienes un grupo de hackers dubitativos y una cultura de modificación, ocurre la fragmentación. Obtiene Scheme , Common Lisp , ELISP , Arc . Todos estos son idiomas bastante diferentes, pero todos son "Lisp" al mismo tiempo.
Ahora, ¿por qué la comunidad está fragmentada? Bueno, culparé al tiempo y a la madurez por eso. ¡El lenguaje tiene 50 años! :-)
Dos posibles factores contribuyentes:
Los lenguajes Lisp no son muy populares en comparación con otros lenguajes como C / C ++ / Ruby y demás, eso solo puede dar la ilusión de una comunidad fragmentada. Puede haber una fragmentación igual en las otras comunidades lingüísticas, pero una comunidad más grande tendrá fragmentos más grandes.
Los lenguajes Lisp son más fáciles de implementar que la mayoría. He visto muchas, muchas implementaciones de Lisp "de juguete" que las personas han hecho para divertirse, muchas implementaciones de Lisp "adecuadas" para resolver tareas específicas. Hay muchas más implementaciones de Lisp que, por ejemplo, los intérpretes de Python (conozco aproximadamente 5, la mayoría de las cuales son generalmente intercambiables)
Hay proyectos prometedores como Clojure, que es un lenguaje nuevo, con un objetivo claro (concurrencia), sin mucho "bagaje histórico", fácil de instalar / configurar, puede aprovecharse del "ecosistema" de la biblioteca de Java, tiene un buen sitio con documentación / bibliotecas, y tiene una lista de correo oficial. Esto casi borra todos los problemas que encontré al intentar aprender Common Lisp hace un tiempo, y alienta a una comunidad más centralizada.
El hecho de que haya muchas implementaciones de Common LISP debería considerarse una buena cosa. De hecho, dado que hay aproximadamente el mismo número de implementaciones gratuitas de Common LISP que las implementaciones gratuitas de C ++, es notable, teniendo en cuenta la popularidad relativa de los lenguajes.
Las implementaciones Common LISP gratuitas incluyen CMU CL, SBCL, OpenMCL / Clozure CL, CLISP, GCL y ECL.
Las implementaciones gratuitas de C ++ incluyen G ++ (con variantes de Cygwin y MinGW32), Digital Mars, Open Watcom, Borland C ++ (¿heredado?) Y CINT (intérprete). También hay varias implementaciones de STL para C ++.
Con respecto a Scheme y Common LISP, aunque es cierto que es una analogía inexacta, hay momentos en los que consideraría Scheme es Common LISP qué C es para C ++, es decir, mientras Scheme y C son pequeños y elegantes, Common LISP y C ++ son grandes y (discutible) más adecuado para aplicaciones más grandes.
LISP no está tan fragmentado como BASIC.
Hay tantos dialectos y versiones de BASIC que he perdido la cuenta.
Incluso la implementación más comúnmente utilizada (MS VB) es diferente entre versiones.
Mi punto de vista es que Lisp es un lenguaje pequeño por lo que es fácil de implementar (comparar con Java, C #, C, ...)
Scheme y Common Lisp están estandarizados. SBCL parece el ceceo de fuente abierta de facto y hay muchos ejemplos de cómo usarlo. Es rápido y gratis. ClozureCL también se ve muy bien.
El esquema PLT parece el esquema de código abierto de facto y hay muchos ejemplos de cómo usarlo. Es rápido y gratis.
El CL HyperSpec me parece tan bueno como el JavaDoc.
En cuanto a la fragmentación de la comunidad, creo que esto tiene poco que ver con los estándares o los recursos. Creo que esto tiene mucho más que ver con lo que ha sido una comunidad relativamente pequeña hasta hace poco.
Creo que Clojure tiene buenas posibilidades de convertirse en The Lisp para la nueva generación de codificadores.
Tal vez mi punto es una implementación muy popular, es todo lo que se requiere para dar la ilusión de una comunidad cohesionada.
Tener muchas implementaciones es beneficioso, porque cada implementación es óptima en lugares únicos. Y los lenguajes principales modernos no tienen una implementación de todos modos. Piense en Python: su implementación principal es CPython, pero gracias a JPython también puede ejecutar Python en la JVM; gracias a Stackless Python puede tener simultaneidad masiva gracias a microthreads; etc. Tales implementaciones serán abarcadas de alguna manera: JPython se integra perfectamente con Java, mientras que CPython no. Lo mismo para Ruby.
Lo que no quiere es tener muchas implementaciones que son incompatibles con el hueso. Ese es el caso de Scheme, donde no puede compartir bibliotecas entre implementaciones sin reescribir una gran cantidad de código, porque Schemers no puede ponerse de acuerdo sobre cómo importar / exportar bibliotecas. Las bibliotecas de Common Lisp, OTOH, debido a la estandarización en las áreas centrales, son más propensas a ser portátiles, y existen recursos para escribir código de forma condicional que maneja las peculiaridades de cada implementación. De hecho, hoy en día se puede decir que Common Lisp se define por sus implementaciones (piense en la biblioteca de instalación de paquetes ASDF), al igual que los lenguajes principales.
La comunidad Lisp está fragmentada, pero todo lo demás también lo está.
¿Por qué hay tantas distribuciones de Linux?
¿Por qué hay tantas variantes de BSD? OpenBSD, NetBSD, FreeBSD, ... incluso Mac OS X.
¿Por qué hay tantos lenguajes de scripting? Ruby, Python, Rebol, TCL, PHP y un sinnúmero de otros.
¿Por qué hay tantas conchas de Unix? sh, csh, bash, ksh, ...?
¿Por qué hay tantas implementaciones de Logo (> 100), Básico (> 100), C (innumerables), ...
¿Por qué hay tantas variantes de Ruby? Ruby MRI, JRuby, YARV, MacRuby, HotRuby?
Python puede tener un sitio principal, pero hay varias implementaciones ligeramente diferentes: CPython, IronPython, Jython, Python para S60, PyPy, Unladen Swallow, CL-Python, ...
¿Por qué hay C (Clang, GCC, MSVC, Turbo C, Watcom C, ...), C ++, C #, Cilk, Objective-C, D, BCPL, ...?
Simplemente deje que algunos de ellos obtengan cincuenta y vean cuántos dialectos e implementaciones tiene en ese momento.
Supongo que Lisp es diverso, porque cada idioma es diverso o diverso. Algunos comienzan con una implementación única (McCarthy''s Lisp) y después de cincuenta años tienes un zoológico. Common Lisp incluso comenzó con múltiples implementaciones (para diferentes tipos de máquinas, sistemas operativos, con diferentes tecnologías de compilación, ...).
Hoy en día Lisp es una familia de idiomas , no un solo idioma. Ni siquiera hay consenso sobre qué idiomas pertenecen a esa familia o no. Puede haber algunos criterios para verificar (s-expresiones, funciones, listas, ...), pero no todos los dialectos Lisp admiten todos estos criterios. Los diseñadores de idiomas han experimentado con diferentes funciones y obtuvimos muchos, más o menos, lenguajes tipo Lisp.
Si observa Common Lisp, hay alrededor de tres o cuatro vendedores comerciales activos diferentes. Intenta conseguirlos detrás de una oferta! No funcionará Luego tiene un montón de implementaciones de código abierto activas con diferentes objetivos: una compila a C, otra está escrita en C, una intenta tener un compilador de optimización rápido, una intenta tener algo de terreno medio con compilación nativa, una apunta a la JVM ... y así sucesivamente. Intenta decirle a los mantenedores que abandonen sus implementaciones.
Scheme tiene alrededor de 100 implementaciones. Muchos están muertos, o casi todos muertos. Por lo menos de diez a veinte están activos. Algunos son proyectos de hobby. Algunos son proyectos universitarios, algunos son proyectos de empresas. Los usuarios tienen diversas necesidades . Uno necesita un GC en tiempo real para un juego, otro necesita incrustación en C, uno solo necesita construcciones barebones para fines educativos, y así sucesivamente. Cómo decirle a los desarrolladores que no sigan pirateando su implementación.
Luego hay algunos a los que no les gusta Commmon Lisp (demasiado grandes, demasiado viejos, no suficientemente funcionales, no suficientemente orientados a objetos, demasiado rápidos, no lo suficientemente rápidos, ...). A algunos no les gusta el Scheme (demasiado académico, demasiado pequeño, no escala, demasiado funcional, no es lo suficientemente funcional, no hay módulos, los módulos incorrectos, no las macros correctas, ...).
Entonces alguien necesita un Lisp combinado con Objective-C, entonces obtienes Nu. Alguien hackea algunos Lisp para .net. Luego obtienes algunos Lisp con concurrencia e ideas nuevas, luego tienes Clojure.
Es la evolución del lenguaje en el trabajo . Es como la explosión cambriana (cuando aparecieron muchos animales nuevos). Algunos morirán, otros vivirán, algunos nuevos aparecerán. En algún momento aparecen algunos dialectos que recogen el estado del arte (Scheme para todo con programación funcional en Lisp en los 70s / 80s y Common Lisp para todo tipo de MacLisp en los 80s) que hace que algunos dialectos desaparezcan principalmente ( a saber, Standard Lisp, InterLisp y otros).
Common Lisp es el cocodrilo de dialectos Lisp. Es un diseño muy antiguo (cientos de millones de años) con pocos cambios, parece un poco aterrador, y de vez en cuando se come a algunos jóvenes ...
Si quieres saber más, The Evolution of Lisp (y las diapositivas corresponding ) es un muy buen comienzo.