En/Je/On 2015-12-02 01:21, Miguel Angel Rodriguez Jodar [email protected] [forth-es] escribió / skribis / wrote :
> > Java es una abstracción sobre otra abstracción sobre otra > > abstracción sobre otra abstracción... Como la mayoría de los > > lenguajes de programación. > Bueno... visto así, Forth también trabaja sobre otra abstracción, > ya que procesadores que usan instrucciones con datos en pila son los > menos, casi anecdóticos. Por supuesto. Todo lenguaje de programación es un abstracción. El ensamblador ya es una abstracción. Lo que quería decir es que la distancia que separa Java (o cualquier otro lenguaje similar, da igual) de cómo funciona realmente una máquina física es mucho mayor, porque tienes muchas más capas de abstracción entre medias. La distancia es tan grande que ni siquiera es necesario saber cómo funciona la máquina para programar. No quiero decir que eso sea bueno o malo. De hecho es útil que eso sea así para los objetivos para los que Java (repito: o cualquier otro lenguaje) está pensado. Cada lenguaje tiene sus ventajas, inconvenientes, fortalezas y debilidades para según qué tareas o entornos. También puedes programar en Forth sin saber cómo funciona la máquina (sobre todo en un Forth moderno, en que la descripción estándar del lenguaje no utiliza términos relacionados con ninguna implementación particular), pero es más difícil. Evidentemente, no se trata de representar exactamente con un lenguaje de programación cómo funciona el procesador... Para eso ya está el procesador, y se puede programar en ensamblador. > Los procesadores de 8 bits sobre los que se ha sustentado Forth en los > años 80 son procesadores orientados a registros, y en esos (como en la > gran mayoría), el lenguaje más cercano a la máquina es el C. Entiendo lo que quieres decir, pero no lo veo desde ese punto de vista. Si no te entiendo mal, te refieres al compilador de C en sí y a lo que el compilador puede hacer. Pero el programador de C no tiene por qué saber eso, no tiene por qué saber si el compilador utiliza un registro o una dirección de memoria para guardar una variable, por ejemplo. Sin embargo, que es a lo que me refiero, en Forth todo ello es trasparente. Por ejemplo, manejas directamente direcciones de memoria y sabes dónde están "las cosas". Hablo de un Forth clásico, con un pequeño núcleo implementado en ensamblador y el resto en Forth. En un Forth implementado con un núcleo escrito en C u otro lenguaje, por ejemplo, esta relación directa puede perderse, depende de cómo esté escrito. En todo caso, siempre es posible crear todas las abstracciones posibles, si se necesita. > Y del C al JAVA hay mucho menos trecho que del Forth al JAVA No sé si te entiendo bien. Creo que te refieres a la apariencia, a la sintaxis. Pero por el hecho de que la sintaxis de Java se parezca más a la de C que a la de Forth (que en realidad no tiene sintaxis propiamente dicha) no significa que Java funcione internamente más como C que como Forth, ni que esté más cerca de la máquina. De hecho, la máquina virtual de Java, que ejecuta su código de octetos seudocompilado, tiene muchas similitudes con cómo funciona el intérprete interior de Forth. > De hecho, procesadores basados en pila sólo conozco la máquina P, que > es curiosamente una máquina abstracta que Niklaus Wirth usó en su > famoso libro para explicar las interioridades del PASCAL, y el modelo > de programación del 80x87, que éste sí que parece hecho ex-profeso > para Forth. No sabía. Solo he leído algo sobre los procesadores creados por Charles Moore, diseñados expresamente para ejecutar Forth. > > organiza entre sus alumnos un concurso de programación para Amstrad > > CPC, llamado CPCRetroDev, es decir el tipo de programación en que > Ooooooh! Eso me interesa mucho, pero a ver qué cara me ponen si se me > ocurre hacer algo similar aquí :( Bueno, al menos ¡ya tienes un precedente en que apoyarte! -- Marcos Cruz http://programandala.net
