¿Por qué los mensajes polimórficos son mucho más poderosos en la práctica que la combinación de unificación y retroceso?

Question

Una forma de ver la historia del diseño del lenguaje de programación es que hubo una revolución con la introducción de la subrutina. Veinte o treinta años más tarde, dos refinamientos de la llamada del subprograma fueron consideradas seriamente:

• mensajes polimórficos
• unificación y dar marcha atrás

Me acaban de programación en Prolog después de un paréntesis de 20 año y darse cuenta de cuán increíblemente poderosa es la unificación y el retroceso. Sin embargo, el polimorfismo ganó. ¿Por qué?

Answer 1

Adivinar: el paso de mensajes se pegaba más fácilmente a las prácticas entonces populares y se absorbía gradualmente. Una aceptación gradual de las ideas de Prolog tomaría un vehículo como Oz, inventado solo en los años 90, algo así como 20 años detrás de Smalltalk. Dado que Oz afirma que admite tanto la programación procedimental como la lógica en un paquete limpio, no veo ninguna razón en principio de que el mundo no podría haber tomado ese camino si hubiera sabido cómo hacerlo en el momento correcto. En cambio, el paradigma se vinculó a una actitud de más quemaduras en los discos y la decepción de la 5ta. Generación.

(no he probado Mozart/Oz mí hasta ahora. He jugado con Prolog.)

Answer 2

Mi experiencia con Prolog es que es excelente cuando funciona el retroceso de búsqueda es un buen ajuste para su dominio del problema. Sin embargo, si ese no es el caso, gran parte del esfuerzo de programación se dirige a luchar contra la búsqueda de retroceso, flexionándolo a las propias necesidades.

Así que mi opinión sobre la situación es que la búsqueda de retroceso es una característica del lenguaje demasiado estrecha para ser generalmente útil. Si hubiéramos visto la unificación junto con una búsqueda más flexible, podríamos haber visto un curso diferente de desarrollo.

Answer 3

He hecho MUCHA programación en Prolog, y si bien amo el lenguaje por su poder expresivo, tengo que estar de acuerdo con svenningsson en que tan pronto como intentes hacer algo no declarativo se convierta en un acertijo usar el ! operador (corte, descarta las opciones de retroceso) en los lugares correctos, que es extremadamente propenso a errores.

Aunque no es perfecto, un idioma que combina de forma elegante el código de retroceso y no declarativo (imperativo/efecto secundario) es Icon. Básicamente, aísla las expresiones que pueden retroceder de forma natural desde la estructura general del programa (por ejemplo, declaraciones) de manera que es relativamente fácil ver que retroceder no conducirá a resultados inesperados, como en Prolog. No estoy seguro de por qué no hay más idiomas basados ​​en este modelo de ejecución, mi suposición es que la mayoría de los programadores están realmente atrapados en el pensamiento secuencial, y retroceder es confuso.

No estoy seguro de si el retroceso se compara directamente con el polimorfismo. Para mí, es más una alternativa a los cierres, ya que el uso n. ° 1 para cierres en la mayoría de los idiomas es la iteración personalizada (pensar mapa/filtro/plegar, etc.). Por ejemplo, en el icono puedo decir:

every write 10<(1..10)*2 

que tiene una secuencia de números, los multiplica por dos, los filtros a aquellos> 10, e imprime el resultado ("todos" es algo así como un bucle de repetición quebrar en Prolog).En un lenguaje basado en la lista/cierre, tengo que escribir:

for (filter (map [1..10] \x.x*2) \x.x>10) \x.(write x) 

sentado, esto es un poco contived como listas por comprensión & currificación puede simplificar esto, y no todo el código icono es el escueto, pero usted consigue la idea . La versión de Icon no solo es más expresiva obviamente, sino que también tiene la ventaja de que no usa listas intermedias y es "floja" en un sentido de co-rutina, es decir, escribirá el primer número antes de llegar a hacer * 2 en el segundo elemento. Esto significa que le permite escribir código que es igualmente eficiente incluso si termina no utilizando todos los resultados generados.

Answer 4

inmediatamente al operador corte vino a mi mente: Prolog es bella y concisa al igual que el tiempo que desee y puede programar de forma declarativa. Una vez que empiece a utilizar el operador de corte (es decir, corte todos los retrocesos en esa posición), debe pensar en situaciones demasiado complejas para encontrar una buena solución o comprender el código de otros/su código anterior.

Por lo tanto, los problemas con la optimización del retroceso parecen ser el consenso aquí, con 3 de 4 respuestas (hasta el 12 de agosto de 2011) que lo indican (+1 a Aardappel y svenningsson).

Answer 5

Backtracking es muy difícil de depurar cuando todo el sistema dirá es "No"! Hay mejores compiladores de Prolog, pero la mayoría de la gente ya tuvo suficiente cuando se vieron obligados a usar un compilador deficiente en la universidad.

El código de IU es donde comienzan la mayoría de los programadores, y es lo que el usuario ve, Prolog nunca pareció una buena opción para escribir código de IU.

Antes de que los "mensajes polimórficos" se volvieran normales, las personas usaban punteros de función para obtener el mismo resultado, por lo que había un paso más pequeño.

código Prolog es todavía difícil para la mayoría de los programadores para leer, sin embargo la mayoría de los programadores podían comprender al menos algo de código C++ dado que saben C.