Décima regla de Greenspun, ¿todos los proyectos grandes incluyen un intérprete Lisp? [cerrado]

12

La décima regla de Greenspun (en realidad, la única regla) establece que:

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Mi memoria es que hay algunos documentos sobre el tema, tal vez para el proyecto Quattro (hoja de cálculo) de Borland y posiblemente otros. Google no es útil, tal vez los términos de búsqueda correctos no vienen a la mente. Estoy buscando documentos o artículos que respalden esta afirmación, en su caso.

    
pregunta casualcoder 27.02.2012 - 02:45

9 respuestas

16

La declaración es una hipérbole. Pero hay signos evidentes de la envidia de Lisp en otros idiomas. Mira a C # y cómo se está volviendo más funcional en la naturaleza. Mire los diversos marcos de Business Process Management, flujo de trabajo y EAI que hacen todo lo posible para que sea posible programar el sistema sin cambiar el programa.

Hay un libro sobre lenguajes específicos de dominio de Martin Fowler que habla sobre cómo realizar una metaprogramación en lenguajes orientados a objetos. Así que hay algo de verdad en la hipérbole.

Paul Graham dijo que Lisp es el lenguaje más poderoso al mirar la lista de los primeros en venir con Lisp , es fácil de ver por qué muchos idiomas palidecen en comparación.

La forma alrededor de la décima regla es la programación políglota. Al darse cuenta de que un lenguaje / marco no es el martillo de oro. Luego, en lugar de crear una implementación pobre y ad hoc de Lisp, solo puede usar Lisp.

    
respondido por el Michael Brown 27.02.2012 - 03:47
9

La "décima regla" de Greenspun fue un poco de snark. Cuando se estira lo suficiente, si lo hace cubrir "cualquier sistema de scripting o configuración", obviamente, la respuesta a esta pregunta tendrá que ser "sí", ya que la configuración es algo que cualquier programa no trivial requiere en algún grado, y el scripting es solo un poco menos común a medida que sube la escala de complejidad.

Por otro lado, echa un vistazo a GOAL , una variante Lisp inventada por Naughty Dog para la programación de juegos. No se parece mucho a Lisp "clásico" en absoluto. Es un sistema de estilo altamente imperativo, con funcionalidad orientada a objetos, sin intérprete, soporte mínimo para la recolección de basura (confiando en las instalaciones de limpieza a nivel de tiempo de ejecución en su lugar) y soporte extenso para el ensamblaje en línea.

En otras palabras, cuando intentaron usar Lisp para un proyecto suficientemente complejo, ¡encontraron que para hacer algo útil tenían que convertir el lenguaje en una implementación ad hoc, informalmente especificada de la mitad de C ++! ;) (Y finalmente tuvieron que dejar de usarlo después de que el tipo que diseñó GOAL se fue, porque nadie podía entender su código).

    
respondido por el Mason Wheeler 01.03.2012 - 02:12
8

Curiosamente, una respuesta a esta pregunta es ya en Programmers SE .

Para citar la parte relevante:

  

El punto de Greenspun fue (en parte) que muchos programas complejos tienen intérpretes incorporados. En lugar de construir un intérprete en un idioma, sugirió que podría tener más sentido utilizar un lenguaje como Lisp que ya tiene un intérprete (o compilador) incorporado.

     

En ese momento había estado trabajando en una aplicación bastante grande que realizaba cálculos definidos por el usuario utilizando un intérprete personalizado para un idioma personalizado. Decidí intentar reescribir su núcleo en Lisp como un experimento a gran escala.

     

Tomó aproximadamente seis semanas. El código original era ~ 100,000 líneas de Delphi (una variante de Pascal). En Lisp que se redujo a ~ 10,000 líneas. Sin embargo, aún más sorprendente fue el hecho de que el motor Lisp era 3-6 veces más rápido. ¡Y ten en cuenta que este fue el trabajo de un neófito de Lisp! Toda esa experiencia me abrió los ojos; Por primera vez vi la posibilidad de combinar rendimiento y expresividad en un solo idioma.
  - Michael Lenaghan

Para aclarar aún más esa parte, Michael respondió a un comentario con:

  

Wow, ¡ese debe haber sido un código Delphi realmente horrible si de alguna manera logró realizar 3 a 6 veces más lento que una implementación de Lisp! "Bien, lo consideraré como mi error por no explicarlo mejor. La implementación de Lisp fue capaz de transformar expresiones de usuario en expresiones Lisp, un proceso trivialmente sencillo, y luego compilar las expresiones Lisp a código nativo (con optimización completa). Ese es el significado de la Décima Regla de Greenspun.
  -– Michael Lenaghan

Dado que esta respuesta se compone de la respuesta de otra persona en otra parte, es un wiki de la comunidad.

    
respondido por el casualcoder 12.04.2017 - 09:31
2

La regla es una broma, pero hay algo de verdad en ella. Cualquier sistema complejo contendría una serie de partes interpretadas (vea cómo el "patrón de intérprete" es popular entre quienes creen en todos esos patrones mumbo-jumbo). Cualquier sistema complejo debe proporcionar algunos medios de configuración, a menudo estructurados, a menudo interpretados.

Es muy probable que cualquier sistema complejo tenga varios pases de generación de código y varios preprocesadores personalizados en su proceso de compilación (piense en cosas como moc en Qt o tablegen en LLVM).

Muchos sistemas están haciendo malabares con las complejas estructuras de datos tipo árbol utilizando un conjunto de (casi siempre) andanzas de árboles mal diseñadas y herramientas de transformación que se parecen mucho a la funcionalidad de biblioteca de Common Lisp.

Todas estas cosas vienen gratis con Lisp, y en la mayoría de los casos, todas las implementaciones ad hoc, no planificadas, no pensadas a fondo, serían absolutamente inferiores.

    
respondido por el SK-logic 27.02.2012 - 09:23
2

Cualquier sistema suficientemente complejo tendrá conceptos y requisitos específicos de dominio que son extremadamente difíciles de expresar con las abstracciones del lenguaje en el que está trabajando. Esto, de manera involuntaria, obliga a los programadores a crear abstracciones específicas de dominio para aliviar la carga de salvar la brecha semántica entre El lenguaje de programación y el dominio específico. Una vez que haya suficientes de estas abstracciones, básicamente tendrá un intérprete de un idioma específico del dominio. Esta es una parte inevitable del desarrollo de software.

    
respondido por el davidk01 08.10.2012 - 01:58
1

La regla probablemente podría ser más precisa (y menos divertida) ya que "se requerirá que todos los grandes sistemas basados en software implementen un comportamiento dinámico".

Esto se puede hacer de dos maneras:

  1. Un gran archivo de configuración compleja con docenas de parámetros y cientos de definiciones.

  2. Un lenguaje de script AD-HOC.

"sendmail" es probablemente el ejemplo canónico de tipo "1". No puedo pensar en ningún buen ejemplo del tipo "2" que no implique la incorporación de un lenguaje de script "real" a la Warcraft / LUA o incluso a Netscape / Javascript.

El problema es que para algunos parámetros es rápido y sencillo hacerlo con un archivo de configuración, pero esta solución realmente no se puede escalar. Sin embargo, en ningún momento será económico volcar el archivo de configuración a favor de un enfoque de script al agregar una o dos opciones al archivo de configuración. Entonces, el código que interpreta el archivo de configuración acaba siendo un intérprete realmente mal escrito.

    
respondido por el James Anderson 24.02.2014 - 05:26
0

Eso puede ser cierto, como lo han dicho otros, muchos programas requieren configurabilidad y, por lo tanto, contienen varios intérpretes similares a lisp.

Sin embargo, la declaración también implica con una sonrisa de suficiencia que todo lo que necesitas para hacer un programa es Lisp, y que todos los demás idiomas son inferiores a él.

Pero está mal, Lisp puede ser expresivo, pero también es demasiado abstracto, intenta ocultar los detalles de una plataforma y fingir que no existen más que listas en el mundo informático.

La realidad de la programación de alto rendimiento, es que a veces necesitamos mezclarnos con bits y bytes, y hacer cosas específicas del sistema operativo, por lo que no es posible hacer todo solo con Lisp como implica la declaración.

Es más bien al revés, no importa lo complicado, inteligente o sofisticado que sea el lenguaje que inventas, todo lo que termina es solo otra forma de escribir ensamblajes.

    
respondido por el vlsh 07.10.2012 - 21:53
0

Independientemente de si se lo tomó en serio o no, se aplica a los proyectos más grandes de C y C ++ en los que he trabajado.

Lo que no es cierto es que los lenguajes de script personalizados se parecen a Common Lisp. Los ejemplos positivos se parecen a Scheme (porque los diseñadores más inteligentes integraron Guile, SpiderMonkey y Lua en lugar de inventar su propio idioma). Los ejemplos más dignos de DailyWTF fueron un lenguaje similar a Forth y un lenguaje similar a MUMPS.

Otro ejemplo (no estoy seguro de si cuenta como Greenspunning, pero ciertamente es un WTF) fue un intérprete XSLT utilizado para scripts de propósito general. Esto fue más parecido a Lisp ya que agregaron un bucle de retroalimentación en el que la salida se transformaría por XSLT por segunda vez, por lo que ahora tiene macros. Sin embargo, el motivo aquí no era obtener acceso a las características de Lispy, sino eludir los procedimientos de control de calidad del código de la compañía (que agregaban 3 semanas de latencia a cada corrección de errores. XML se consideraba "datos" y estaba exento de este proceso).     

respondido por el finnw 01.11.2012 - 17:53
-1

Lamentablemente no!

Si bien es mejor incrustar un intérprete lisp (y) real (javascript o lua alos hace un buen trabajo), agregar un 4gl casero al proyecto reduce el tamaño general al tiempo que aumenta la flexibilidad.

Los proyectos que "codifican todo" tienen un número de módulos mucho mayor y se vuelven difíciles de manejar e inflexibles.

    
respondido por el James Anderson 27.02.2012 - 03:12

Lea otras preguntas en las etiquetas