Si Lisp es un lenguaje tan bueno, ¿por qué no se usa más en el desarrollo de software?

Es una muy buena pregunta. Permítanme darle la vuelta y preguntar: “Si PHP es un lenguaje tan pobre, ¿por qué se usa tanto en el desarrollo de software?”

Comienzo respondiendo con otra pregunta, a saber: “¿Por qué el lenguaje de programación C es tan popular?”. Y aunque C tiene muchas desventajas, hay muchas razones para su popularidad: refleja la organización de la computadora von Neumann, por lo que le da a su programador un alto grado de control sobre la máquina y le permite escribir código eficiente; es relativamente pequeño, por lo que es fácil de transportar entre diferentes arquitecturas; Es relativamente fácil de aprender. Estos son, lo que podríamos llamar, factores internos de su popularidad. Sin embargo, el hecho es que hay muchos otros lenguajes que comparten esas características pero no obtuvieron una fracción de su popularidad, y el principal vehículo que impulsó la popularidad del lenguaje de programación C fue el sistema operativo UNIX. Escribir un compilador de C para una arquitectura en particular fue una buena inversión, ya que permitió a su proveedor portar un sistema operativo ya existente con un mínimo esfuerzo.

Por lo tanto, el sistema UNIX e Internet estaban cada vez más disponibles, hasta que apareció la web. Inicialmente, el contenido servido en la web consistía principalmente en archivos estáticos, pero la necesidad de generar contenido se desarrolló dinámicamente rápidamente. Inicialmente, se usó el lenguaje de programación Perl para esta tarea. Perl es una extraña amalgama de lenguaje de programación shell y AWK de UNIX, y solía ser popular para realizar diversas tareas administrativas, y aún puede encontrar algunos servicios web importantes que se escribieron utilizando Perl.

Por otro lado, los servicios web no resultaron ser un dominio particularmente bueno para el lenguaje de programación C, porque dificultaba ciertas tareas simples: el programador tenía que ocuparse de la administración de la memoria por sí mismo, y tenía que usar mucho bibliotecas para poder hacer incluso las cosas más simples.

En ese momento, Rasmus Lerdorf ha estado experimentando con un lenguaje de secuencias de comandos que podría integrarse en las páginas web: podría escribir código HTML “normal” y mezclarlo con bucles y condicionales que podrían generar algunas partes de su contenido.

Si eras nuevo en la programación, este tipo de libertad podría haber sido seductor, aunque el lenguaje en sí no estaba particularmente bien pulido. Pero como tenía sus usuarios, aparecían personas que podían ganar dinero mejorando el idioma. No sabían mucho sobre el diseño del lenguaje, por lo que algunas de sus decisiones fueron completamente aleatorias. Algunos de ellos eran buenos, otros se arreglaron más tarde y otros fueron imposibles de arreglar sin romper demasiada compatibilidad. Finalmente, se convirtió en un lenguaje suficientemente bueno.

Hay algunas cosas para notar aquí. Primero, PHP es un ejemplo del fenómeno llamado efecto de plataforma interna: fue escrito en C e implementa la sintaxis de C, así como parte de su semántica. Esto es algo bueno, porque facilitó a los programadores de C aprenderlo y usarlo.

Segundo, PHP era un lenguaje de revolución cultural. No se enseñaba en la escuela, por lo que sus usuarios eran autodidactas. Muchos de ellos eran adolescentes que lo usaban para impresionar a otros adolescentes (lo cual creo que fue la razón por la cual los chicos de Facebook llamaron a su versión de PHP “Hack”, porque suena genial). Esta es también la razón por la cual surgió el grupo cultural de “hipsters Ruby”, como una contracultura a PHP que se convirtió en la corriente principal. Tenga en cuenta que los argumentos que esos “hipsters Ruby” dan a favor de Ruby son principalmente estéticos.

Ahora a Lisp. Paul Graham, quien escribió una aplicación web avanzada en Common Lisp, esperaba que la revolución de Internet pudiera hacer que Lisp floreciera nuevamente, ya que los desarrolladores de back-end tienen total libertad en su elección de sistemas de back-end. Sin embargo, la brecha entre HTML y PHP es mucho menor que entre HTML y Lisp, y Lisp nunca se ha anunciado como el lenguaje para la web. Este argumento no le importa a las personas que conocen bien la programación y que entienden las ventajas de Lisp, pero las personas que no están familiarizadas (es decir, la mayoría de las personas) elegirán el “lenguaje especial para el desarrollo web, porque seguramente debe ser más fácil ”(y de alguna manera se convierte en una profecía autocumplida: a medida que hay más desarrolladores, también hay más bibliotecas y tutoriales). Es un poco como vender agua: si comienzas a vender “agua especial para mujeres embarazadas”, es probable que vendas más, aunque siga siendo la misma agua (incluso puede tener una calidad inferior, pero está bien, siempre y cuando ya que es lo suficientemente bueno).

TL; DR, las decisiones humanas rara vez son impulsadas por la razón.

El problema con Lisp es que es bastante difícil de aprender si conoce C. Podría llamar a esto “Aprendizaje de Lisp como segundo lenguaje (de programación)”. “Si comienzas con Lisp, ¡genial! La mayoría de los lenguajes como C, etc. son lenguajes de procedimiento; Lisp es declarativo. Los lenguajes de procedimiento se ejecutan de forma lineal con el programador definiendo pasos lineales para la solución. Lisp simplemente pone funciones ahí fuera y toma lo que necesita a medida que avanza. No linealmente Lisp te hace pensar de manera muy diferente a la programación procesal. He usado Scheme y Zeta-Lisp. Lisp común es también un dialecto popular.

Cambiar los paradigmas de programación siempre es difícil. Aprendes declarativo o de procedimiento. Los dos paradigmas realmente no juegan bien juntos; como agua y aceite.

Además, Lisp estaba destinado a ser un lenguaje de programación funcional. Ya sabes, transparencia referencial, reemplazo no destructivo de variables, etc. Consulta la conferencia del Premio Turing de Backus para obtener más información al respecto. No hace falta decir que Lisp no es un lenguaje de programación funcional como Eiffel.

Lisp también es un lenguaje uniforme, es decir, el código fuente también puede ser datos. Esto fue bastante útil al escribir sistemas expertos basados ​​en reglas. En las décadas de 1970 y 1980, cuando las primeras máquinas Lisp estaban disponibles, es decir, LMI Lambda, Symbolics, etc., eran geniales. La forma en que siempre pensé fue que en una máquina Lisp estabas escribiendo en el lenguaje máquina de la máquina.

Lisp es un gran ejemplo del poder de los bucles de retroalimentación positiva, es decir, los formatos de cinta Beta vs VHS, DOS vs CP / M OS, Silicon Valley vs Anywhere, etc. No hay nada inherentemente mejor en ninguno de los primeros rubores, pero uno atrapa al otro por razones particulares. En cuanto a las razones, no entraré en ellas aquí. Esto ya es demasiado largo.

“Genial” es un concepto extraño.

Por un lado, lisp se usa ocasionalmente en el desarrollo de software, por otro lado, lisp tiene algunas desventajas serias que dificultan su uso con las herramientas adecuadas.

Hablaré sobre las desventajas. Alguien más puede enumerar dónde se usa.

1. Se escribe dinámicamente. Esto es útil en proyectos pequeños, donde la velocidad de desarrollo es más importante que la robustez del software, pero he tenido momentos en los que ya no recordaba si mi función pedía una matriz de columnas principales o una matriz de filas principales. También inhibe el lisp para correr a velocidades C, pero ‘la incapacidad para escribir una biblioteca BLAS’ no es algo sobre lo que se deba disparar un lenguaje.
2. Falta de conceptos. En lisp todo es una lista. Suena simple y conveniente, pero desafortunadamente no es en proyectos grandes, donde desea tener certeza sobre el software indocumentado escrito por la gente de al lado.
3. Dificultad. Lisp tiene la inmutabilidad como valor predeterminado (y algunos conceptos para permitir la mutabilidad para permitir la aceleración, que han sido explotados por casi todos los desarrolladores), utiliza listas como una estructura de datos básica y es esencialmente un flujo de datos / lenguaje funcional, no un procedimiento uno.

¿Sabes cuál es el lenguaje empresarial más popular?

Java

¿Sabes por qué?

Porque es una mierda

Hace mucho tiempo, durante la época medieval, a la gente no le gustaban sus vecinos y fueron a la guerra con bastante frecuencia. Imagina una guerra así, con dos ejércitos uno frente al otro. Ahora imagina sus armas. ¿Qué llevan (recuerde: medieval, así que no hay armas, e ignoremos a los arqueros en la parte de atrás por un momento)?

Espadas? No.

Están usando lanzas.

Las espadas son efectivas, verdad. Son realmente poderosos en las manos correctas, pero también extremadamente caros, por lo tanto, dar uno a cada hombre en el campo era imposible.

Las lanzas, por otro lado, son baratas. Pueden ser producidos en masa, y son fáciles de manejar, por lo que podría barrer las ciudades, reclutar hombres en el ejército y entrenarlos para usar una lanza en poco tiempo. ¿Serán maestros luchadores en tres días? No. ¿Tendrán habilidades decentes para luchar con la lanza? Realmente no. Pero es suficiente. Tienes un ejército en tres días.

Java es como esa lanza. La mayoría de las empresas lo usan porque es muy fácil encontrar un desarrollador de Java, o incluso miles de ellos. Los programadores de Lisp, sin embargo, son más raros y, por lo tanto, más difíciles de encontrar y más caros.

Por otro lado, esos programadores de lisp probablemente estén programando realmente bien. Pero, ¿por qué emplearías un programador decente como programador? No, eso sería un desperdicio de sus capacidades. Mejor póngalo en la gerencia y contrate a otro programador de rockstar con un salario mucho menor.

Estado allí. Créeme. Las empresas casi nunca usan las cosas elegantes, poderosas y difíciles. Y realmente no puedo culparlos.

PD Piensa en un hombre que es un luchador, pero no en un ejército. Él trabaja solo. ¿Qué arma lleva?

Una espada de samurai.

Una espada realmente difícil de usar, costosa pero efectiva.

Simplemente porque la producción en masa y la capacitación ya no son un problema.

Respondí una pregunta similar en la respuesta de Mark Miller a ¿Por qué se usa tan poco LISP a pesar del hecho de que a menudo es aclamado como uno de los mejores lenguajes de programación?

Quizás te interese el artículo de Paul Graham, Beating the Averages. Tiene una sección donde habla sobre esta misma pregunta, llamada “La paradoja de Blub”.

He visto a otros escribir sobre esto, aunque olvido quiénes eran ahora. Lo que básicamente dijeron fue que la forma en que se organizan las tiendas de desarrollo de software no permite lenguajes como Lisp, porque para hacerlo bien, debes ser un buen programador y debes comprender algunos conceptos de programación avanzados. Tienes que entender su poder y cómo se expresa. Escuché decir que 2 programadores realmente buenos pueden igualar el logro de 20 programadores mediocres, algo así. El problema es que es difícil encontrar programadores estrella. Los gerentes que han trabajado con tales programadores tienen que preguntarse: “¿Y si se van? ¿Qué pasa si les pasa algo? ”Podrían ser SOL. Mientras que si codifican todo en un lenguaje más simple, más complejo pero más fácil de entender, pueden contratar a un grupo mucho mayor de desarrolladores. Entonces no tienen que preocuparse tanto por cómo reemplazarlos, si es necesario, y pueden pagarles menos. Otro beneficio percibido del que he oído hablar es que si el software requiere soporte de la mesa de ayuda, es más probable que encuentre personas que estén listas y capacitadas para hacerlo entre las filas de desarrolladores mediocres que con los desarrolladores estrella.

El primer enfoque (los desarrolladores de 2 estrellas) enfatiza hacer más con menos código, donde el ingenio de la implementación se traduce directamente en ganancias de productividad. El último enfoque (20 desarrolladores mediocres) enfatiza el control burocrático sobre el proceso, lo que respalda la continuación y expansión de la empresa, al menos en el departamento de TI, independientemente de los riesgos detectados. El primero es un enfoque más optimista, aunque arriesgado. Este último es un enfoque más pesimista y consciente de la seguridad.

Uno podría pensar que el segundo enfoque es mejor, porque un enfoque más seguro para la organización suena más defendible y estable. Como saben los inversores y los emprendedores, hay momentos en que no correr riesgos es, de hecho, lo más riesgoso. Uno puede entrar en una mentalidad engañosa donde seguir con lo que sabe y no probar ideas no probadas / experimentales en realidad lo hace más vulnerable en un mercado que alguien más dispuesto a asumir esos riesgos, porque pueden darse cuenta de una manera mucho mejor de hacerlo lo que estás haciendo, y puedes terminar perdiendo a tus clientes ante ellos. Eso es básicamente sobre lo que escribió Paul Graham, que su compañía pudo inventar un nuevo uso para la web, y fue capaz de vencer a todos los competidores en su mercado, porque su uso de Lisp le permitió agregar funciones más fácil y rápidamente de lo que podían (todos usaron tecnologías más probadas y verdaderas de la época: Perl con C ++). Fue un enfoque más arriesgado, porque la comunidad de desarrolladores de Lisp tiene un soporte notoriamente pobre para herramientas y bibliotecas (y estoy seguro de que este era aún el caso en el momento en que Graham lo hizo), y probablemente fue tan difícil como encontrar desarrolladores de Lisp como sería hoy Pudo hacerlo, porque el servicio era el bebé de él y sus socios comerciales. Eran sus principales desarrolladores. No necesitaban contratar a una gran cantidad de desarrolladores, aunque si alguno de ellos hubiera contraído una enfermedad grave o hubiera muerto, habría sido bastante difícil encontrar a alguien que los reemplazara. Lo más probable es que hubieran tratado de continuar sin su socio perdido o hubieran vendido el negocio.

Lo que he tendido a ver con el uso de estos lenguajes alternativos “en la naturaleza” es que básicamente tienen que ser proyectos nuevos. Es posible que pueda comenzar con algunas bibliotecas de código abierto de Lisp, pero tendrá que asumir que está escribiendo su propia infraestructura y herramientas para su creación particular. Las startups tienden a ser entornos más fértiles para esto, aunque existen relativamente pocas empresas establecidas que usan estos idiomas regularmente.

Lo que Graham experimentó fue que finalmente vendió su negocio a Yahoo (pasó a llamarse Yahoo Store), y terminaron traduciendo su servicio para usar Perl con C ++. Su razón declarada fue que no pudieron encontrar suficientes desarrolladores de Lisp para mantenerlo, pero como demostró, pudo encontrar lo suficiente para desarrollarlo hasta ese punto. Según recuerdo, no creía que estuvieran diciendo la verdad sobre su razón. Simplemente no querían aprender o tratar con Lisp.

Primero, una palabra de contexto.

Hay dos supuestos inválidos en esta pregunta:

1. Lisp es “genial”;
2. La “grandeza” es importante para la elección de la tecnología.

No digo que sean falsas , solo inválidas, principalmente porque están mal definidas y no han sido probadas. A las personas de software nos gusta pensar (y hablar) sobre nosotros mismos como si estuviéramos haciendo algo cercano a la “ingeniería”, pero, sinceramente, es mucho más como retocar y moverse hasta que algo haga clic y parezca que funciona, con una pista. de carga de culto.

La ingeniería adecuada requeriría dos cosas que casi nunca se hacen en la llamada “ingeniería de software”, y eso sería necesario para que la pregunta, bueno, tenga sentido:

1. Los investigadores llevarían a cabo experimentos y estudios científicos comparando los méritos de diferentes idiomas. Esto incluye controlar otros factores como el dominio del profesional, la complejidad del proyecto, el ecosistema de la biblioteca, etc. y mediría resultados objetivos como el costo total y el tiempo de desarrollo, la cantidad de errores, el grado de aptitud para el propósito, etc. Esto rara vez se hace. que ni siquiera estamos muy seguros de qué debemos medir.
2. Los practicantes habituales (“del mundo real”) estarían al tanto de estos estudios y sus resultados y los utilizarían para guiar sus elecciones tecnológicas.

Algunas personas creen que Lisp es genial. Sin embargo, la gran mayoría de los desarrolladores nunca han oído hablar de él. Incluso muchos investigadores universitarios en ciencias de la computación e ingeniería de software no tienen idea de qué es Lisp, por lo que no se enseña ni se discute mucho. Y muchos practicantes de software, investigadores de ciencias de la computación e investigadores de ingeniería de software en realidad no creen que el lenguaje de programación importe; Es una opinión muy común que los idiomas son solo una cuestión de preferencia personal. Las personas que creen eso (y no hay mucha evidencia para disuadirlos) no tienen ninguna razón para invertir ningún esfuerzo en aprender un segundo idioma si ya tienen una buena comprensión de uno.

Y aprender un segundo lenguaje de programación es aún más difícil que aprender el primero, por lo que la mayoría de las personas simplemente no lo hacen. O limitan su estudio a idiomas extremadamente similares y luego llegan a la conclusión lógica de que la elección del idioma no importa y los fanáticos del idioma son simplemente locos.

En definitiva, todo esto lleva a una situación en la que:

• Los equipos técnicos desean tomar decisiones tecnológicas basadas en el conocimiento muy limitado y la experiencia personal del equipo que considera el proyecto, y principalmente en sus preferencias personales entre las opciones limitadas que consideran;
• Profesionales con formación académica aprenden el idioma que se les enseña; Los profesores generalmente no piensan que los lenguajes de programación sean dignos de estudio y, como una herramienta práctica, simplemente enseñan cualquier idioma que se les enseñó cuando eran estudiantes;
• Los académicos más progresistas elegirán un lenguaje basado en la demanda percibida de la industria (por ejemplo, Java) o en valores pedagógicos esencialmente infundados (por ejemplo, “hola mundo en Python es 1 línea y no hay” vacío público estático principal “para explicar, por lo que es claramente el mejor lenguaje introductorio y deberíamos enseñar eso ”);
• Los profesionales autodidactas, en conjunto, generalmente toman la decisión económicamente sólida de aprender cualquier idioma que parezca ser más demandado en la industria que los rodea (es decir, lo que les proporcione la mejor combinación de seguridad laboral y salario alto);
• Las empresas desean tomar decisiones que reduzcan los riesgos (porque los proyectos de software suelen ser muy riesgosos) y, por lo tanto, optimizar para cosas como “fácil de contratar”, lo que tiende a crear más demanda de idiomas ya demandados, independientemente de sus méritos técnicos;
• Un grupo de pequeñas comunidades están convencidas de que han encontrado el único lenguaje verdadero o enfoque arquitectónico y tratan de gritar en voz alta al respecto en Internet. En general, nadie realmente les presta atención.

Tenga en cuenta que nada en esta respuesta es específico de Lisp; también se aplica a Haskell, OCaml, etc. Básicamente, las opciones tecnológicas, en un sentido amplio, son el resultado de muchos factores sociales e históricos, preferencias personales, y branding y marketing. Los méritos técnicos juegan un papel muy pequeño en la popularidad general.

El uso de LISP sufre por una combinación de razones:

1. Hasta hace relativamente poco, las computadoras multi-core no eran realmente una cosa.
2. El valor de cualquier herramienta individual es relativamente limitado en el desarrollo de aplicaciones modernas.

Comencemos con el punto 1 … la primera CPU de escritorio para el consumidor con múltiples núcleos fue el Pentium Dual-Core ( fallido ) en 2006. Si estaba escribiendo código LISP en 2001, todos estos beneficios, como la paralelización, no tenían sentido porque tenía un Bonito conjunto finito de núcleos.

No ibas a escribir juegos en LISP o navegadores web o Microsoft Word. Todo esto fue escrito en C / C ++, con una estructura muy similar a la CPU en la que se ejecutaban. LISP era popular en IA y algunos otros campos con un valor comercial limitado. Pero no estábamos entrenando a cientos de miles de desarrolladores de LISP porque el valor simplemente no estaba allí.

Por supuesto, esa ecuación ha cambiado, solo necesita saber dónde buscar. LISP y otros lenguajes funcionales han florecido en los últimos años. Si observa el surgimiento de lenguajes como Clojure, Scala y F #, verá que funcional ahora está incursionando en las grandes corporaciones. Netflix usa Scala, Jet.com se basa en F #, estas cosas se están generalizando.

Pero a pesar de sus características aparentemente mejores, la transición llevará tiempo. Gran parte del código que ejecuta las cosas que usa ya se ha escrito. No tenemos la costumbre de “no escribir” software solo para escribirlo en un nuevo idioma.

Lo que nos lleva al punto # 2 … la construcción de software moderno requiere una gran sección transversal de herramientas y tecnologías y LISP solo llenaría una pequeña pieza de ese rompecabezas. Escribir mi código en LISP no reduce el costo del control de calidad o la gestión de proyectos. No hace que mi DB funcione mejor, no me ayuda a optimizar la arquitectura de mi sistema ni a rastrear errores de producción complicados.

LISP sería solo una pequeña parte de una cadena de herramientas de tecnología muy grande. Cuando se trata de solucionar grandes problemas, la mayoría de las tiendas de desarrollo modernas son “entornos ricos en objetivos” . El valor marginal de cambiar de idioma es tan bajo en relación con la otra infraestructura importante que debe establecerse.

Principalmente debido a problemas de gestión (y del mismo modo para lenguajes de programación potentes pero apenas utilizados como Ocaml y Haskell).

Algunas pocas compañías están utilizando con mucho éxito Lisp, Ocaml, Haskell o Prolog.

Pero hay problemas de gestión:

• encuentre desarrolladores de software competitivos que conozcan estos idiomas (por cierto, a veces el conocimiento de un lenguaje de programación tan extraño es un criterio de selección, incluso si el trabajo diario no los usa)
• administrarlos lo suficientemente bien como para que estos desarrolladores de software permanezcan durante un tiempo significativo y trabajen felices y eficientemente

Mi opinión es que la especie humana no es capaz de un buen manejo (y ese hecho triste no es particular del desarrollo de software) …

Tenga en cuenta que el opuesto de los dos puntos anteriores es a menudo un síntoma de mala gestión (pero es extremadamente común)

• contratar a un desarrollador aleatorio (y tener malos criterios de contratación)
• no los maneje bien, y considere a las personas humanas como un gasto utilizable, así que tenga mucha rotación

Por cierto, muchos documentos dicen que la mayoría de los proyectos de software están fallando más o menos (lea The Mythical Man-Month …)

Además de las razones de adecuación del lenguaje para tareas específicas en sí, también existen muchas menos personas que podrían usarlo de manera eficiente.

Diría que Lisp y otros lenguajes de programación declarativos / funcionales parecen basarse en gran medida en los conceptos matemáticos de nivel universitario, pero esos conceptos no son en absoluto un hecho para los programadores en general.

Muchos programadores simplemente nunca han aprendido matemáticas más allá de la escuela secundaria. Y de aquellos que lo han hecho, no todos han comprendido los conceptos lo suficiente como para tener una programación fácil en lenguajes funcionales, como Lisp.

Yo soy uno de ellos. Aunque estaba haciendo Ciencias de la Computación en la universidad, no era muy bueno en matemáticas, aunque era bastante bueno en cursos de programación de procedimientos y lenguajes de programación en general, tenía cierta competencia con varios antes de la escuela secundaria, en realidad. Tampoco tuve ningún problema con la programación orientada a objetos, cuando llegó la locura.

Sin embargo, traducir una tarea a realizar en programación funcional es algo que aún no he dominado. Eché un vistazo a Lisp, pero no tengo mucho tiempo libre, es simplemente algo demasiado extraño para mí comenzar a aprender en este momento de la vida, aunque me encantaría dominarlo.

La mayor parte es un accidente histórico. C fue desarrollado para conmutadores telefónicos, que eran plataformas informáticas extremadamente débiles a principios de la década de 1970. Lisp fue desarrollado en minicomputadoras que tenían mucha más potencia de procesamiento disponible. Cuando llegó la revolución de las microcomputadoras en la década de 1980, C era el lenguaje perfecto para esos sistemas informáticos extremadamente débiles. Lisp requería máquinas de mayor calibre para funcionar. Por lo tanto, toda una generación de desarrolladores se esforzó en C. Por eso también C ++ ‘se ganó’ a Smalltalk. Esa generación de desarrolladores de C utilizó C ++ al explorar la programación orientada a objetos. Posteriormente, C ++ inspiró Java, que inspiró C #. Todo viene de C.

Ahora que tenemos máquinas disponibles y asequibles más que capaces de ejecutar Lisp, y lo hemos hecho desde mediados de la década de 1990, realmente no importa. La gigantesca C se había lanzado y no había una esperanza realista de retirar eso.

La única razón por la que Lisp está recibiendo tanta atención hoy es por la programación funcional. La razón por la que la programación funcional es tan popular es porque se ve como la solución al problema de los procesadores que ya no aumentan mucho su rendimiento: estamos aumentando el número de núcleos disponibles, en lugar de aumentar la capacidad de cálculo de cada núcleo. En teoría, la programación funcional hace que sea fácil aprovechar el poder de todos los núcleos en su programa sin todos los riesgos de la gestión explícita de subprocesos. En la práctica, los entornos de programación funcional no manejan múltiples núcleos, aunque podrían hacerlo, simplemente no lo hacen. La idea es que cuando llegue el día en que manejen múltiples núcleos, su programa se beneficiará automáticamente. No veo que esto suceda porque Lisp no es lo suficientemente ‘funcional’ para realmente beneficiarse de dicho procesamiento paralelo, ¡pero Lisps como Clojure fueron diseñados desde cero para este tipo de procesamiento paralelo!

Es algo así como.

Lisps inventó la recolección de basura y popularizó muchas otras cosas, como cierres léxicos.

Puede ver que Javascript está diseñado como un lisp barato sin macros, con las funciones más potentes cortadas, y es probablemente el lenguaje más popular en la actualidad.

Más o menos, todas las ideas generalmente buenas a escala que lisp se habían convertido en un lugar común en estos días.

Lo que deja las características sobresalientes de lisp como aquellas que generalmente no son buenas a escala.

Como las macros.

Las macros significan que si quiero entender cualquier fragmento de código en particular, necesito conocer todo el contexto de ese código desde la raíz.

¿Qué significa (abc)?

1. ¿Es una lista de tres símbolos?
2. ¿Es una llamada a un procedimiento llamado a con los valores de las variables byc?

1. ¿Son las variables byc o podrían macroexpandirse a las llamadas a procedimientos?

No podemos saber sin mirar lo que lo contiene o lo precede.

Las macros son una gran idea si todos los que leen su código ya lo saben todo.

Pero son una idea terrible si la mayoría de las personas que leen su código lo ven por primera vez.

Adivina cuál funciona para el hacker solitario y adivina cuál escala.

La terrible verdad es que siempre quieres usar el lenguaje menos potente suficiente para hacer el trabajo, y lisp siempre ha tratado de ser el lenguaje más poderoso en la sala.

Si desea comprobar este tipo de falla en acción, eche un vistazo a Shen, que es un ceceo que ataca los sistemas de tipos de esta manera.

Tenga en cuenta que lo anterior está en el contexto “usado más en el desarrollo de software” en lugar de “usado en mi piratería personal”: la falla aquí se trata de los costos de coordinación a escala debido al poder excesivo.

Porque la popularidad no está relacionada en gran medida con la calidad.

Esto es tan cierto para los lenguajes de programación como otras cosas: ¿quién no se ha quejado de lo mala que es la música o la literatura convencional?

La popularidad se refuerza a sí misma. Esto es particularmente visible con los lenguajes de programación: los lenguajes populares obtienen mejores herramientas y comunidades más activas, lo que fomenta un mayor uso y, por lo tanto, una mayor popularidad . En ese sentido, “popular = bueno” no es necesariamente cierto. JavaScript es a la vez popular y un mal terrible y terrible enviado a la Tierra para retrasar el progreso y destruir la felicidad.

Tampoco soy lo suficientemente hipster como para decir que “popular = malo”. No, es solo que los dos no están correlacionados en gran medida y, por lo tanto, cuestionar la calidad basada en la falta de popularidad percibida no es un gran argumento.

Lisp es un lenguaje importante para aprender, y excelente porque puede enseñar algo en particular muy bien (de hecho, Scheme es mejor para esto, pero la diferencia entre Scheme y Lisp es pequeña).

El problema es que Lisp tampoco es un gran lenguaje para el trabajo de producción en la industria, porque lo mismo que lo hace genial lo hace terrible; no tiene sintaxis para hablar, en cambio es una notación para escribir directamente el árbol de sintaxis abstracta del compilador como código fuente. Lo cual es sorprendente, pero no muy legible.

Pasas mucho, mucho más tiempo leyendo código que escribiéndolo, por lo que un lenguaje que es fácil de leer se valora más que uno que es fácil de escribir … hasta cierto punto. Java y Cobol están en el lado equivocado de ese punto, aunque las opiniones varían sobre Java; El problema con esos idiomas es que la densidad de información de la fuente es tan baja que resulta difícil ver lo suficiente en la pantalla, y un serio desafío de memoria para recordar lo suficiente de la estructura del código. De ahí esto.

Así, la broma de que Lisp significa ‘muchos paréntesis tontos irritantes’:

(defun fibonacci (n & opcional (a 0) (b 1) (acc ()))
(si (zerop n)
(nreverse acc)
(Fibonacci (1- n) b (+ ab) (cons a acc))))

No existe un lenguaje que sea “excelente”, y Lisp no es una excepción.

Por ejemplo, Lisp es bastante malo para mantener a los programadores ocupados: hay millones de programadores que simplemente están barajando el código, esencialmente haciendo el trabajo manualmente de una macro Lisp; Si toda la industria cambiara a Lisp, esto significaría que la mayoría de las empresas deben disolverse o reemplazarse por equipos de 3 a 4 personas. Y adivine qué: en un equipo de 3 a 4 personas no hay necesidad de arquitectos, gerentes intermedios, gerentes superiores, RR.HH., líderes de equipo y muchos otros roles. Por cierto, esas también son las personas a menudo responsables de las decisiones tecnológicas, por lo que si son inteligentes, nunca se permitirían ser innecesarias.

TL; DR: Lisp definitivamente no es tan bueno para mantener a raya el desempleo.

TODOS los lenguajes de programación tienen sus pros y sus contras. No hay un lenguaje de programación ideal.

¿Lisp es “genial”? Desde algunas perspectivas, sí; de otros, no.

Lisp es genial en el mismo sentido que Smalltalk es genial.

Pero ser genial no es suficiente para garantizar un amplio uso. Muchos otros factores entran en la mezcla, tales como:

• compitiendo contra lenguajes bien arraigados como Java, Python, C ++, etc., que tienen enormes ecosistemas y comunidades de usuarios, así como enormes bases de código heredadas
• El costo de cambiar de una pila de software a otra (las empresas son extremadamente conservadoras)
• problemas con la educación: nadie está enseñando Lisp, y Lisp tiene una sintaxis de aspecto extraño con todos los paréntesis y la notación de prefijos
• no hay suficiente promoción y marketing para este idioma

Sin embargo, Clojure está haciendo algunos progresos.

Muchas personas tienen miedo a los paréntesis. Muchos editores populares tienen muy poco soporte de estructuras de edición basadas en paréntesis. Incluso Emacs, fuera de la caja no es tan impresionante. Entonces, la mayoría de los que lo han intentado tienen mala experiencia y se mantienen alejados de los idiomas Lisp.

Algunos idiomas hacen un gran esfuerzo para ayudarlo a evitar el uso de paréntesis. Haskell y su operador en dólares son ejemplos de ello. Eso te muestra que a la mayoría de las personas no les gustan los paréntesis.

Para sentirse cómodo con el uso de paréntesis, necesita un buen editor con un buen soporte de paréntesis. Utilizo Emacs con un complemento adicional llamado Paredit, consulte la Guía animada de Paredit. Y mi propia configuración que colorea los paréntesis por la profundidad. Aprender a manejar bien los paréntesis es una habilidad muy útil. Se requirieron pocas semanas para acostumbrarse. Supongo que es como tocar un instrumento musical. Muchas personas lo intentaron y se dieron por vencidos, pero los que perseveraron adquirieron una habilidad muy útil.

Este video muestra un código Emacs Lisp sin sentido con corchetes coloreados.

Porque no es particularmente bueno en la mayoría de las tareas de programación típicas.

Dos cosas dominan la mayoría del desarrollo de aplicaciones: la creación de interfaces de usuario y el procesamiento de bases de datos (particularmente el procesamiento de transacciones). Ambos encajan muy bien en los paradigmas estándar de OO.

A2A. Common Lisp es un lenguaje de programación funcional que utiliza un “estilo funcional” en una serie de aplicaciones específicas; sin embargo, “la programación en un estilo funcional también se puede lograr en lenguajes [de procedimiento] que no están diseñados específicamente para la programación funcional. Por ejemplo, lenguaje de programación PHP. C ++ 11, Java 8 y C # 3.0 todas construcciones agregadas para facilitar el estilo funcional “. La mayoría del desarrollo de software no necesita solo” estilo funcional “.

Como nota al margen, creo que puede encontrar Common Lisp – Myths and Legends que explica el uso de Lisp interesante.

Bueno, técnicamente …… emacs está escrito en gran parte en lisp, y mucha gente usa emacs para desarrollar software, por lo tanto, lisp se usa muchísimo en el desarrollo de software. QED

AGREGADO DESPUÉS:

Consideraciones de sistemas: LISP es un gran lenguaje para resolver ciertos tipos de problemas y construir ciertos tipos de sistemas. Está menos claro que es ideal para construir productos o sistemas modulares y mantenibles: tal vez sea demasiado poderoso y fluido frente a algo un poco más rígido, más susceptible de control de versiones, construcción y prueba automatizadas, etc. Y luego está la cuestión del contexto y el ecosistema: bibliotecas, entornos de tiempo de ejecución implementados, etc.

Porque Lisp es muy poco intuitivo y está lleno de paréntesis y personajes aparentemente aleatorios en lugares aleatorios. La mayoría de los programadores encuentran que los lenguajes imperativos son mucho más fáciles de entender que los lenguajes funcionales enrevesados. Intente leer y / o depurar un programa Lisp y vea a qué me refiero …

Básicamente, Lisp es demasiado abstracto y matemático en comparación con lo que realmente sucede a bajo nivel (CPU, memoria, etc.).