stack - significado - ¿Por qué usar un lenguaje orientado a la pila?
significado de chimba en colombia wikipedia (5)
La orientación de la pila es un detalle de implementación. Por ejemplo, Joy se puede implementar utilizando la reescritura - sin pila. Es por eso que algunos prefieren decir "concatenativo" o "compositivo". Con las citas y los combinadores puedes codificar sin pensar en la pila.
Expresarse con composición pura y sin locales o argumentos con nombre es la clave. Es extremadamente sucinto, sin gastos indirectos sintácticos. La composición hace que sea muy fácil factorizar la redundancia y manipular "algebraicamente" tu código; hirviéndolo en su esencia.
Una vez que te hayas enamorado de este estilo sin puntos, te molestará incluso la más mínima sintaxis de composición en otros idiomas (incluso si solo es un punto). En los idiomas concatenativos, el espacio en blanco es el operador de la composición.
Hace poco eché un vistazo a Factor , y la idea de tener un lenguaje basado en el concepto de una pila es muy interesante. (Este fue mi primer encuentro con un lenguaje orientado a la pila.) Sin embargo, no veo ninguna ventaja práctica de dicho paradigma. Para mí, parece ser más problemático de lo que vale. ¿Por qué usaría un lenguaje orientado a la pila como Factor o Forth?
Estoy ignorando factores (perdón por el juego de palabras) como la disponibilidad de herramientas y bibliotecas. Solo estoy preguntando sobre el paradigma del lenguaje en sí.
No estoy seguro de si esto responderá completamente a su pregunta, pero encontrará que Factor se describe primero como un lenguaje concatenative . También pasa a tener un modelo de ejecución basado en pila. Desafortunadamente, no puedo encontrar la publicación de blog de Slava (¿o tal vez en la Wiki de factores?) Hablando de esto.
El modelo concatenativo básicamente significa que pasas "trozos de código" (bueno, así es como se programa de todos modos) y la composición se ve como una concatenación. Operaciones como currying también son fáciles de expresar en un lenguaje basado en pila ya que solo precompone con código que agrega una cosa a la pila. En Factor, al menos, esto se expresa a través de una palabra llamada curry . Esto hace que sea mucho más fácil hacer una programación de orden superior, y el mapeo sobre las secuencias finalmente se convierte en la "forma obvia de hacerlo". Vengo de Lisp y me sorprendió regresar después de programar en Factor por un tiempo que no podías hacer "cosas obvias" como bi en Lisp. Realmente cambia la forma en que expresas las cosas.
Por cierto, es inteligente no preocuparse demasiado por la manipulación de la pila. Usando el vocabulario de los locals (descrito aquí: http://docs.factorcode.org/content/article-locals.html ), no tiene que preocuparse por mezclar las cosas. A menudo hay una manera ordenada de expresar cosas sin variables locales, pero tiendo a hacer eso en segundo lugar.
Para algunas personas es más fácil pensar en términos de administración de pilas que otros paradigmas. Por lo menos, hacer algo de piratería en un lenguaje basado en pila mejorará su capacidad de administrar stacks en general.
Aparte: en los primeros días de las calculadoras de mano, usaron algo llamado notación polaca inversa , que es una notación postfix basada en pila muy simple, y es extremadamente eficiente en la memoria. Las personas que aprenden a usarlo de manera eficiente tienden a preferirlo a los cálculos algebraicos.
Una de las razones importantes por las que se desarrollan los lenguajes basados en pila es porque el minimalismo de su semántica permite la implementación directa de intérpretes y compiladores, así como la optimización.
Entonces, una de las ventajas prácticas de tal paradigma es que permite a las personas entusiastas construir fácilmente cosas y paradigmas más complejos sobre ellos.
El lenguaje de programación Scheme es otro ejemplo de eso: sintaxis y semántica minimalistas, implementación directa y mucha diversión.
Ya tenemos buenas respuestas y no sé nada sobre el lenguaje Factor.
Sin embargo, creo que es maravilloso comentar para completar:
- Tiempo de CPU: el costo de tiempo de la asignación de memoria en la pila es prácticamente gratuito: no importa si está asignando uno o mil enteros, todo lo que necesita es una disminución del puntero de la pila. example
- Fuga de memoria : no hay pérdidas de memoria cuando se usa solo la pila. Eso ocurre de manera natural sin costos adicionales de código para manejarlo. La memoria utilizada por una función se libera por completo cuando regresa de cada función, incluso en el manejo de excepciones o el uso de longjmp (sin contar referencias, recolección de basura, etc.).
- Fragmentation : las pilas también evitan la fragmentación de la memoria de forma natural. Puede lograr fragmentación cero sin ningún código adicional para tratar esto como un grupo de objetos o asignación de memoria de losa.
- Locality : los datos en la pila favorecen la ubicación de los datos, aprovechando el caché y evitando el intercambio de páginas.
Por supuesto, puede ser más complicado de implementar, dependiendo de su problema, pero preferiremos apilar más que siempre que podamos.