¿El principio KISS aplicado al diseño del lenguaje de programación?

13

KISS ("hazlo simple, estúpido" o "hazlo simple estúpido", consulta, por ejemplo, aquí ) es un principio importante en el desarrollo de software, aunque aparentemente se originó en la ingeniería. Citando el artículo de wikipedia:

  

El principio se ejemplifica mejor con la historia de Johnson entregando a un equipo de ingenieros de diseño un puñado de herramientas, con el desafío de que el avión a reacción que estaban diseñando debe ser reparable por un mecánico promedio en el campo en condiciones de combate con solo estas herramientas. Por lo tanto, el 'estúpido' se refiere a la relación entre la forma en que se rompen las cosas y la sofisticación disponible para solucionarlos.

Si quisiera aplicar esto al campo del desarrollo de software, reemplazaría "aviones a reacción" por "software", "mecánico promedio" por "desarrollador promedio" y "en condiciones de combate" por "bajo el software esperado Condiciones de desarrollo / mantenimiento "(fechas límite, limitaciones de tiempo, reuniones / interrupciones, herramientas disponibles, etc.).

Por lo tanto, es una idea comúnmente aceptada que uno debería tratar de mantener una pieza de software simple (o simple estupida , en caso de que omita la coma) para que fácil de trabajar en él más tarde.

¿Pero puede aplicarse el principio KISS también al diseño del lenguaje de programación? ¿Conoce algún lenguaje de programación que haya sido diseñado específicamente teniendo en cuenta este principio, es decir, "permitir que un programador promedio en condiciones de trabajo promedio escriba y mantenga la mayor cantidad de código posible con el menor esfuerzo cognitivo"?

Si cita un idioma específico, sería bueno si pudiera agregar un enlace a algún documento en el que los diseñadores de idiomas expresen claramente su intención. En cualquier caso, me interesaría conocer las intenciones (documentadas) de los diseñadores en lugar de su opinión personal sobre un lenguaje de programación en particular.

    
pregunta Giorgio 04.12.2012 - 23:23

11 respuestas

14

Cuando pienso en el minimialismo, pienso en Lisp y Go . Con Lisp, todo lo que tienes son funciones y listas, que es lo más simple que puedes obtener (bueno, hay un poco más, pero lo que sea). Sin embargo, creo que el caso Go es más interesante.

Go fue diseñado para ser simple (es una lectura decente). El término que usan es "ortogonalidad de características", lo que significa que cualquier característica solo debe agregarse si proporciona algo verdaderamente único. Esto parece derivarse de los autores ( Russ Cox y Rob Pike viene a la mente) involucrado con Plan9 , que fue una reimaginación de UNIX con simplicidad en mente (Si está interesado en un diseño minimalista, el artículo de Rob Pike en un sistema de ventanas simple es una buena lectura. )

Aquí hay algunos ejemplos simples de la sintaxis:

Sólo una construcción en bucle

Un bucle puede parecerse a uno de los siguientes:

Bucle infinito

for {
}

Mientras bucle

for <conditional> {
}

Tradicional para bucle

for i := 0; i < 10; i++ {
}

Foreach loop

// works for maps or arrays
for k, v := range arr {
}

Interruptor multiuso

switch {
    // cases must be evaluate to a boolean
}

switch <value> {
}

switch t := <value>; t {
    // can use t inside
}

Retorno múltiple

return val1, val2, ...
  • Elimina la necesidad de lanzar (pasar el error como último valor de retorno)
  • Elimina la necesidad de los parámetros de salida
  • Elimina la necesidad de tuplas

Interfaces

type X interface {
    DoSomething()
    String() string
}
  • Resuelve problemas similares a los genéricos
  • Permite la abstracción

Incrustación

type A struct {
    Thing string
}

type B struct {
    A // embeds A in B, so B.Thing refers to A.Thing
}
  • Resuelve el mismo problema que la herencia
  • Obvio necesario para las clases

Canales

Se puede usar para implementar semáforos

var c = make(chan bool, 1)
c<-true // semaphore lock
<-c // semaphore free

Se utiliza para pasar mensajes entre hilos

func produce(c chan<- bool) {
    for {
        c <- true
    }
}
func consume(c <-chan bool) {
    for {
        <-c
    }
}

var c = make(chan bool)
go produce(c)
go consume(c)

Puede usarse para manejar eventos asíncronos

func async() chan bool {
    var c = make(chan bool)
    go doSomethingAsync(c)
    return c
}

// wait for long async process to finish
c := async()
select {
    case _ = <-c:
}

Conclusión

No voy a entrar en cada parte de la sintaxis, pero espero que puedas ver lo que puede hacer el minimalismo. El idioma es intrigante no porque agrega un montón de funciones nuevas, sino porque usa las mejores funciones de otros idiomas sin nada adicional.

Generalmente hay una "mejor" forma de resolver un problema. Por ejemplo, en la lista de correo, muchos usuarios se quejan de no tener genéricos. Después de la discusión, se dan cuenta de que todo lo que quieren hacer se puede hacer con interfaces. Lea sobre eficaz para obtener ejemplos sobre la sintaxis idiomática.

El beneficio de los lenguajes KISS es que es posible escribir código idiomático, porque el estilo del código está restringido por el idioma. Por ejemplo, en Go, no puedes escribir algo como esto:

if <condition>
    statement;

Tienes que usar llaves:

if <condition> {
    statement;
}

Hay muchos otros ejemplos de esto en la sintaxis, lo que facilita la lectura del código de otras personas.

Beneficios del lenguaje KISS sobre lenguajes con características:

  • más fácil de entender el código de otros
  • más fácil de asimilar todo el lenguaje (C ++ es conocido por ser difícil de entender)
  • centrarse en el algoritmo, no en la sintaxis
respondido por el beatgammit 22.03.2013 - 09:00
12

Creo que el Zen of Python declarará por qué Python es un lenguaje simple mucho mejor que Yo puedo:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Editar en respuesta a @Giorgio

Como dice tu pregunta,

  

"¿Conoces algún lenguaje de programación que haya sido diseñado?   específicamente con este principio en mente, es decir, para 'permitir un promedio   programador en condiciones de trabajo promedio para escribir y mantener como   tanto código como sea posible con el menor esfuerzo cognitivo ""

Python es, para mí, lo que me viene a la mente de inmediato. El diseño de Python responde directamente a la metodología de Perl, el famoso "Hay más de una forma de hacerlo". Si bien eso es genial, permitir a los programadores escribir código con mucha facilidad, no ayuda con el mantenimiento. Habiendo manejado antes un programa (muy mal escrito, lo admito) escrito en Perl, aprecio que Python haya forzado las buenas prácticas de codificación y el lenguaje conciso en su garganta.

Python tampoco lo obliga a seguir una metodología particular al escribir programas. Puedo elegir seguir un estilo de programación estricto orientado a objetos, o puedo escribir un script simple para ejecutarlo secuencialmente. No tener que inicializar una clase, entonces llamar al método main() como te obligan a hacer en Java es muy bueno. (Además, imprimir en stdout en Python es maravilloso, pero ese es un punto bastante nulo).

Finalmente, la metodología "Baterías incluidas" de incluir una biblioteca estándar expansiva con el lenguaje es maravillosa. En lugar de buscar paquetes en un repositorio externo, la mayoría de lo que necesito ya está incluido en el idioma. También es bueno tener un repositorio externo, pero no es muy útil tener que buscarlo para realizar una operación básica.

    
respondido por el Zach Dziura 06.12.2012 - 03:31
2

Podría decirse que Tcl se desarrolló siguiendo estas líneas. El lenguaje completo se puede describir en solo 12 reglas en una sola página de manual . Es notablemente simple y consistente.

El creador de Tcl afirmó lo siguiente como los objetivos originales:

  • El lenguaje debe ser extensible: debe ser muy fácil para cada uno aplicación para agregar sus propias características a las características básicas de la idioma, y las características específicas de la aplicación deben aparecer naturales, como si hubieran sido diseñados en el lenguaje de la empezar.
  • El lenguaje debe ser muy simple y genérico, para que pueda funcionar. Fácilmente con muchas aplicaciones diferentes y para que no lo haga. restringir las funciones que pueden proporcionar las aplicaciones.
  • Dado que la mayoría de las funciones interesantes provendrán de aplicación, el propósito principal de la lengua es integrar o "pegar juntos" las extensiones. Así el lenguaje debe tener buena Facilidades para la integración.

De " Historia de Tcl " - enlace

    
respondido por el Bryan Oakley 06.12.2012 - 19:24
2

Si un idioma tiene un diseño fijo debido a KISS, no puede crecer. Un lenguaje que no puede crecer morirá.

En el siguiente video Guy Steele inteligentemente explica que se debe permitir que un lenguaje de programación crezca y por qué. Si aplica KISS, entonces, ¿cómo puede crecer un idioma porque una vez liberado, su conjunto de herramientas está arreglado y nunca se le permite cambiar?

  

Discurso de Guy Steele en la conferencia de 1998 de ACM OOPSLA en "Creciendo un   Idioma " discute la importancia y los problemas asociados con   Diseñando un lenguaje de programación que pueda ser desarrollado por sus usuarios.

Es un video de una hora, pero vale la pena verlo. Si no sabes quién es Guy Steele, deberías hablar de diseño lingüístico.

Elijo este video como respuesta porque creo que aplicar KISS al diseño de idiomas en general es incorrecto, y espero que ver un discurso de una persona destacada en el diseño de idiomas ayude a ampliar su comprensión del futuro del diseño de idiomas.

Desde que vino aquí para aprender sobre el diseño de idiomas y le di una razón para no usar KISS, es justo que señale algo que encuentro ayuda en el diseño de idiomas. Dimensiones cognitivas de las notaciones

EDIT

Cuando escribí la respuesta anterior, se basó en el razonamiento de: si un motor solo se puede mantener con un conjunto fijo de herramientas, mi reformulación de ese significado con respecto al diseño del lenguaje es que un idioma no puede cambiar una vez publicado. . Los comentarios indican que eso no era lo que se quería decir. Entonces permítame presentar esta respuesta modificada que estará más en línea con la comprensión revisada.

Si se analiza Dimensiones cognitivas de las notaciones , se aprende que hay muchas dimensiones en competencia asociadas con el diseño del lenguaje. más que la simplicidad y si te enfocas demasiado en uno, sufrirás en los demás. Con la pregunta de centrarse en gran medida en la simplicidad (KISS), y con el respaldo de personas destacadas en el diseño de idiomas, presenté el speech por Guy Steele para demostrar que tratar de mantener un diseño únicamente simple impactará otras dimensiones. Lo más importante es que estoy tratando de transmitir que es necesario tener en cuenta muchas dimensiones y sopesar los pros y los contras de ellas, no solo la simplicidad.

    
respondido por el Guy Coder 06.12.2012 - 03:06
2

Una de las principales claves para mantener la "simplicidad" es reconocer cuándo será necesaria la complejidad y tener las partes del sistema que mejor pueden lidiar con eso, hacerlo. Tener un solo tipo de referencia de objeto que no hace distinción entre valores inmutables, valores mutables y entidades, hace que Java sea "simple", no elimina la necesidad de distinguir entre valores y entidades; simplemente priva a los programadores de herramientas para ayudarles a hacerlo.

Más generalmente, si uno intenta que un lenguaje de programación o una característica de marco sea compatible con varios casos de uso, debe asegurarse de que no habrá situaciones en las que diferentes comportamientos sean apropiados en diferentes casos de uso, pero el compilador sería incapaz de diferenciarlos. Agregar más tipos a un lenguaje o marco puede parecer una complicación, pero en muchos casos puede hacer las cosas más fáciles.

Considere, por ejemplo, el lío de reglas que rodean a los tipos firmados y no firmados en C. La complejidad de estas reglas se deriva del hecho de que algunos códigos usan tipos de enteros sin signo para representar números, mientras que otros los usan para representar miembros de un envolviendo el anillo algebraico (específicamente, el conjunto de números enteros congruentes mod 2ⁿ). Las reglas de conversión de tipos se comportan de maneras que a veces son apropiadas para un uso y otras para maneras apropiadas para el otro. Tener tipos de envoltura separados y no empaquetados duplicaría el número de tipos enteros, pero podría simplificar las reglas asociadas con ellos:

  • Cualquier tipo de entero sin anillo de cualquier tamaño puede asignarse a un anillo de cualquier tamaño; un anillo puede asignarse solo a un anillo de igual o menor tamaño.

  • Las operaciones que no sean operadores relacionales que involucren un número entero que no sea de anillo y un anillo convertirán implícitamente el número entero al tipo de anillo.

  • Los anillos se pueden convertir explícitamente en números o en anillos más grandes; el valor de un anillo sin signo es el número entero no negativo más pequeño que, cuando se agrega al cero del anillo, generaría el valor del anillo. El valor de un anillo firmado es el número entero de menor magnitud que, cuando se agrega al cero del anillo, generaría el valor del anillo, prefiriéndose el valor negativo en caso de empate.

  • Excepto como se mencionó anteriormente, los anillos se limitan a operaciones con anillos del mismo tamaño o más pequeños.

  • Las operaciones en enteros que no son de anillo de diferentes tipos deben convertir los números a un tipo que pueda acomodar todos los valores de cualquiera de los operandos, o el compilador debe rechazarlos si no existe un tipo adecuado

Definir tipos de timbre parece duplicar el número de tipos enteros, pero simplificaría enormemente la escritura de código portátil. El uso de los mismos tipos no firmados para números y anillos reduce la cantidad de tipos, pero conduce a reglas complicadas que hacen que sea casi imposible escribir código portátil eficiente.

    
respondido por el supercat 14.03.2014 - 04:14
1

Aquí hay una gran cita de Hardcore Visual Basic de Bruce McKinney, que a su vez pone las palabras en la boca de los diseñadores de BÁSICO, Kemeny y Kurtz . Enfatiza lo mio.

  

Cada lenguaje informático tiene su propia sensación, su propia atmósfera, su propia   espíritu. Realmente no puedes definir este espíritu, pero sabes lo que es   cuando lo veas. Pienso en lo básico como la antítesis de una afirmación.   atribuido a Albert Einstein:

     
    

Haga las cosas lo más simples posible, pero no más simples.

  
     

Si esa cita hubiera sido escrita por los diseñadores originales de Basic, John   Kemeny y Thomas Kurtz, se habría simplificado aún más:

     
    

Haga las cosas más simples de lo posible.

  
     

Esa es la contradicción con la que viven los programadores de Visual Basic.   Queremos que las cosas sean simples, elegantes e intuitivas, pero no lo son.   Queremos que nuestros programas modelen la realidad, pero no lo hacen. Queremos nuestra   El lenguaje funciona de la manera en que pensamos, no la forma en que las computadoras o el funcionamiento   los sistemas quieren que pensemos, pero no estamos dispuestos a pagar el precio .

    
respondido por el AakashM 06.12.2012 - 11:00
1
  

¿Pero puede aplicarse el principio KISS también al diseño del lenguaje de programación? ¿Conoce algún lenguaje de programación que haya sido diseñado específicamente teniendo en cuenta este principio, es decir, "permitir que un programador promedio en condiciones de trabajo promedio escriba y mantenga la mayor cantidad de código posible con el menor esfuerzo cognitivo"?

Es bueno que haya aclarado lo que quiere decir con "simple", porque en mi opinión un lenguaje de programación simple es uno con una sintaxis mínima y pocas características (Scheme, Forth, ML), que no se traducen directamente a su definición . Creo que realmente estás buscando diseño de idiomas con RAD (desarrollo rápido de aplicaciones) en mente, y hay muchos de ellos. Consulte este hilo de StackOverflow, por ejemplo: enlace

    
respondido por el Nemanja Trifunovic 06.12.2012 - 14:26
1

Me sorprende que nadie haya mencionado C aún, aunque pone la simplicidad en primer lugar de varias maneras importantes, a menudo de una manera tan radical que los programadores no aprecian la simplicidad:

  • No hay magia oculta. Si escribe a + b en C, tiene la garantía de que se compilará en una única instrucción de ensamblador como máximo.

    Incluso en lenguajes relativamente simples como Java, una declaración simple como a + b puede tomar varios microsegundos (si las variables son cadenas). Otros idiomas agregan mucho, mucho más a esto con el ejemplo extremo de C ++, donde a + b puede estar sobrecargado para que aparezcan elefantes rosados. No es así en C: si no es una llamada de función, no llevará más que unos pocos nanosegundos. Esta previsibilidad del rendimiento es una de las características clave de C, y ciertamente es una forma de simplicidad.

  • Los tipos de datos son tan simples como pueden ser, al mismo tiempo que describen todas las estructuras de datos interesantes que quizás desee construir en la memoria: solo hay los tipos fundamentales que una CPU puede manejar + agregación ( struct ) + repetición ( matrices) + referencias (punteros).

    Es cierto que los distintos lenguajes basados en lisp son mucho más simples que C en este sentido. Sin embargo, no intentan permitir que el programador manipule libremente la memoria como lo hace C

  • Ortogonalidad de las características: puede combinar libremente las características y funcionarán juntas como se espera. Muchos idiomas fallan esto al permitir que ciertas construcciones solo aparezcan en contextos definidos.

    Tomemos, por ejemplo, las matrices de longitud variable en C y C ++: C permite longitudes de tiempo de ejecución en todas partes, mientras que las solicitudes más liberales para expandir el estándar de C ++ solo las permiten en ciertos contextos, como las matrices automáticas e incluso solo en la primera dimensión. Esto permite que C maneje matrices multidimensionales reales con tamaños conocidos solo en tiempo de ejecución, mientras que los programadores de C ++ se reducen a escribir data[k + (j + i*lineLength)*lineCount] una y otra vez.

    Otro ejemplo de esto es el puntero: un puntero de datos en C realmente no es más que una simple variable que contiene una dirección de memoria de otra variable. Dado que el puntero es en sí mismo una variable, el puntero doble es una cosa bien definida. Es decir. dado lo que son int y int* , está claro qué int** debe ser. Compare esto con las referencias de C ++ en las que no tiene ni idea de a qué int&& se le da el significado de int y int& !)

Es cierto que es precisamente esta simplicidad la que se ha ganado tanto odio por C: la simplicidad del lenguaje permite a los programadores más libertad de lo que es bueno para ellos, lo que genera muchos problemas con comportamiento indefinido y punteros mal manejados. Especialmente, la simplicidad de ortogonalidad que permite a un programador definir una variable como int (*array[m])(struct foo* (*arg)[n]) es del tipo que tiende a causarle dolores de cabeza a los lectores porque las cosas realmente complejas se pueden expresar de forma muy concisa mediante una combinación liberal de algunas características simples . Este es el tipo de simplicidad en la que C sobresale y le da la reputación de ser un lenguaje difícil de usar.

Además, la simplicidad del lenguaje obliga al programador a escribir mucho más código que lenguajes más ricos en funciones, lo que proporciona un terreno más fértil para que los errores florezcan. Sin embargo, sigue siendo el lenguaje de alto nivel más simple posible si su objetivo principal es programar una computadora real y no una máquina virtual.

    
respondido por el cmaster 07.12.2016 - 22:00
0

Java Wikipedia - aunque no se menciona explícitamente en Wikipedia, simplifaction se menciona varias veces y un objetivo de diseño original, ya que el único lenguaje serio capaz de OO (término utilizado de manera holgada) en esos días era C ++, que como todos sabemos, es poderoso pero tiene más de unas pocas trampas para los incautos.

La JVM fue pensada como una forma de simplificar el desarrollo multiplataforma, y "Escribir una vez Ejecutar en cualquier lugar" se convirtió en un mantra de Java durante algunos años. Una vez más, la intención era que el marco fuera sencillo de implementar.

Creo que C # cae en esa categoría de simplificación del lenguaje.

    
respondido por el mattnz 04.12.2012 - 23:47
-3

Hm ... esta es en realidad una pregunta difícil de responder 'positivamente', porque cuando pienso en la simplicidad en el diseño del lenguaje de programación (y en qué es 'más fácil' trabajar), inmediatamente pienso en:

  1. "Legibilidad" del código: cuán bien el lenguaje encapsula objetos, métodos, etc.
  2. La consistencia de las interfaces y API de lenguaje.

Hay varios idiomas que hacen estas cosas bien, pero lo que aparece en mi cabeza es un lenguaje que no hace las cosas bien 'como lenguaje de programación': PHP.

[Descargo de responsabilidad: he escrito PHP y PHP sigue siendo mi 'ir al idioma' para proyectos web simples. Esta es una crítica de amor ...]

Primero, PHP funciona bien para el entorno que normalmente ejecuta en servidores web. Es fácil de configurar, fácil de mantener, etc.

Donde lucho con PHP: cuando quieres hacer algo "inusual", algo que normalmente no haces regularmente (en caso de que esté pensando que estaba consumiendo un servicio web SOAP, no algo He hecho mucho con PHP), te enfrentas a dos opciones:

1) Varias extensiones de código abierto para PHP. El modelo de objetos PHP es lo suficientemente flexible como para que el diseño de la interfaz no sea tan coherente de una biblioteca a otra, de un desarrollador a otro. Cuando te enfrentas a un conjunto de códigos en los que alguien usó una biblioteca de la que nunca has oído hablar, pasas mucho tiempo pensando "qué diablos hace esto" porque el lenguaje permite una creación de API / biblioteca suelta.

2) Las funciones "incorporadas", de las cuales hay muchas . He pasado por algunos agujeros de conejos, ya sea para encontrar otra biblioteca o implementar un poco de funcionalidad para, de alguna manera, tropezar con impossiblyfound_basefunction()

En mi opinión, la simplicidad es la consistencia.

    
respondido por el Chad Thompson 07.12.2012 - 20:33
-3

Ahora, el enfoque de KISS para los lenguajes de programación es una noción graciosa, al menos si considera que los lenguajes de programación son una capa de abstracción para el conjunto de instrucciones de una CPU, etc. Si no define "KISS" más de cerca. Solo estoy diciendo aquí, que una carreta de buey es KISS aplicada a un automóvil en su máxima expresión.

Ahora, otra interpretación de KISS podría ser algo así como "hecho inteligentemente sin adornos innecesarios y no demasiado complicado". Especialmente, se podría argumentar que no debería haber demasiados casos específicos para cosas similares, etc. Por lo general, las matemáticas son bastante buenas para reducir el contenido a su esencia, y, por eso, los matemáticos han dedicado algo de tiempo a pensar en la programación y las computadoras. .

Para la programación, existen 2 modelos abstractos bastante famosos:

  • Una es la máquina de turing que define una máquina y un modelo instructivo simple que puede computar todo lo que una computadora podría hacer.
  • El otro es el Lambda-Calculus de Church et. Alabama. eso es equivalente en poder

Lo divertido es: si bien la máquina turing es bastante simple en su diseño, no es un sistema que sea fácil de manejar y no creo que califique para "smart KISS". Pero Lambda Calculus tiene más que ver con los lenguajes de programación que conocemos, y con las características pioneras de Lisp y Scheme del cálculo lambda, se ha abierto camino en muchos lenguajes.

Lisp y Scheme son REALMENTE simples, al menos en términos de sintaxis. La sintaxis es un problema importante con los lenguajes de programación (que es probablemente la razón por la que se reinventan todo el tiempo). En el caso de C ++, es casi imposible que el cerebro humano pueda predecir cómo el compilador interpreta algunas líneas de origen.

Lisps está reduciendo la complejidad sintáctica al introducir una forma común para comandos:

(command param1 param2 ...)

Esto puede ser una llamada a un método, como

(max 1 2 3 4)

así como una rama if, bucle, etc.

(if (< 1 2) 
    (write 4)
    (write 5))

(todo el código aquí es pseudo-Lisp / dialecto agnóstico)

El formulario

(command param1 param2 ...)

también se puede interpretar como una lista

(item1 item2 item3)

Y esa es la base de la simplicidad y la belleza de Lisps. Debido a que las listas anidadas (como en el ejemplo de la declaración if ) constituyen árboles y esas pueden ser fácilmente comprendidas tanto por la máquina como por el humano que está frente a la máquina.

Otra característica de Lisps son macros No entraré en detalles sucios aquí, pero como no hay una diferencia sintáctica entre las llamadas de función normales y la "Sintaxis (egg for loops, variable variable, etc.) ., todo lo que el analizador tiene que manejar en otros lenguajes de programación) puede crear su propia sintaxis. Las macros son esencialmente Manipulaciones del Árbol que constituye su programa.

Creo que Lisp tiene un KISS para la programación. El hecho de que pueda manipular la sintaxis mediante el uso de macros ha llevado a un fenómeno en el que Lisp ha evolucionado bastante dinámicamente. Necesita una nueva función de idioma como, por ejemplo, orientación de objetos, ¡simplemente escriba un sistema OOP con macros!

Mientras que C se extendió en la rotonda 2 veces con funciones OOP (C ++, Obj. C) Lisp se extendió varias veces, al final hubo un ganador.

Esa es otra peculiaridad acerca de Lisp, evoluciona (ver Clojure y Clojurescript para una interesante nueva mutación de lisp).

Por sus propiedades KISS, algunos dominan a Lisps como idiomas de enseñanza. Como Fogus describe en su proyecto de un lenguaje educativo ( enlace )

Para empezar, creo firmemente que cuando se aprenden temas nuevos y, a veces, complejos, es totalmente perjudicial que los estudiantes se sobrecarguen con reglas de sintaxis frívolas. Por lo tanto, Enfield está diseñado con reglas de sintaxis mínimas y lo que es más mínimo que una sintaxis tipo Lisp.
    
respondido por el wirrbel 22.03.2013 - 08:27

Lea otras preguntas en las etiquetas