mcleod_ideafix escribió:programandala_net escribió:Por ejemplo, si sabes algún dialecto de BASIC, al leer un programa escrito en PHP podrás «adivinar» más o menos qué hace, pero eso no te sirve para ponerte a escribir PHP, ni mucho menos significa que PHP sea más o menos fácil.
Yo con esto discrepo: precisamente leyendo programas escritos en PHP, o cualquier otro lenguaje, es como precisamente he aprendido a usar alguno de esos lenguajes, o al menos a modificar el código de esos programas que he visto y que la modificación funcione. Y todo grcias a que aunque cada uno tenga la sintaxis de su padre y de su madre, visto uno vistos todos. Eso permite no sólo ponerse a hacer código en un lenguaje nuevo del que sólo has mirado algunos programas de ejemplo, sino que también permite al programador más experimentado trasladar algoritmos que ya están implementados en un lenguaje (pongamos C) a otro (pongamos PHP o Perl) con un móínimo de esfuerzo.
Estoy de acuerdo con lo que dices. Por una parte así es como se aprende, por supuesto, leyendo y modificando código, independiente o paralelamente al estudio en sí del lenguaje. Y por otra parte, está también claro que cuando dos lenguajes se parecen, es posible trasladar algoritmos con más facilidad de uno a otro, aunque el programador no conozca el lenguaje de origen. Pero esto no significa que discrepe conmigo mismo
Yo me refería a un aspecto diferente de la cuestión, a un aspecto previo: al hecho de sacar conclusiones acerca de la facilidad o no de un lenguaje con solo un primer vistazo, en función de si se parece más o menos a algo a lo que ya estamos acostumbrados. Eso no es un criterio objetivo sobre la facilidad en sí de ese lenguaje, cuyas reglas desconocemos. El hecho de que nos resulte familiar puede ayudarnos en el proceso de aprendizaje, pero no quiere decir que
en sí mismo sea más fácil de aprender o de usar.
mcleod_ideafix escribió:En el caso de Forth por ejemplo, en donde el programador debe ser consciente de que existe una pila, y que de hecho necesita esa pila para poder implementar cosas como la recursión, hace que escribir un programa recursivo sea más complejo, sobre todo si dicho programa usa muchas variables locales (y que por tanto necesitan salvarse en la pila en cada llamada recursiva).
No, no hay dificultad. La propia pila de datos sirve para guardar lo que necesitas en la recursión, de forma implícita; y las
variables locales en Forth usan la pila de retornos como almacenamiento, u otras estructuras a medida, para poder funcionar de forma recursiva. De todas formas en Forth se usan poco, pues no suelen hacer falta, aunque es cierto que en ocasiones facilitan mucho las cosas, y se están haciendo más populares. En todo caso, creo que tu planteamiento parte de cómo se programa generalmente en otros lenguajes, en largos bloques de código. En Forth el código se divide en unidades pequeñas (a menos que haya una buena razón en contra).
mcleod_ideafix escribió:programandala_net escribió:Código: Seleccionar todo
: lavadora ( programa -- ) Ejecutar un programa de lavado
puerta cierra
prelava lava desagua enjuaga desagua centrifuga
1 minutos espera
puerta abre ;
Lo mismo, escrito en C:
Código: Seleccionar todo
void lavadora()
{
puerta(CERRAR);
prelava();
lava();
desagua();
enjuaga();
desagua();
centrifuga();
espera(1);
puerta(ABRIR);
}Pues no sé... lo veo igual, o más claro.
Si lo ves tan claro será porque... esa función en C está escrita precisamente con el estilo de Forth
Es decir, cortita y sin estructuras de control. Puedes escribir lo mismo en cualquier lenguaje y se leerá igual de claro. Hasta en ensamblador, por supuesto.
Pero la cuestión es por qué se escribe de una manera u otra. Eso está muy relacionado con cómo funciona internamente cada lenguaje, y por tanto es difícilmente comparable.
mcleod_ideafix escribió:El número y tipo de los parámetros a la función (equiv a la palabra en Forth) está bien ubicado. En Forth, o pones un comentario explicando qué parámetros toma la palabra (y en qué orden tienen que estar en la pila) o tienes que ponerte a mirar el código de la palabra para adivinar de qué forma usa la pila.
Cierto. Eso puede pasar. Pero en buena medida es cuestión de método y de costumbre. Idealmente, en Forth escribes palabras muy cortas, cuya función y argumentos sean casi evidentes en la solución del problema particular. Cuando en la definición de una palabra no recuerdas lo que hay en la pila y necesitas anotarlo, es señal de que la palabra está haciendo más cosas de las que debería... A veces lo suyo es factorizar; otras veces un pequeño comentario de pila basta (pues nadie te obliga a no ponerlo). Además... ¿que otra cosa son, si no, los parámetros de las llamadas a las funciones de C? Son comentarios de pila en toda regla, y para colmo obligatorios
mcleod_ideafix escribió:En C no tienes por qué poner cada llamada a función en una línea diferente. Si quieres algo más compacto puedes escribir:
Código: Seleccionar todo
void lavadora()
{
puerta(CERRAR);
prelava(); lava(); desagua(); enjuaga(); desagua(); centrifuga();
espera(1);
puerta(ABRIR);
}
Cada lenguaje tiene su sintaxis para estas cosas. En Forth puedes poner lo que quieras donde quieras y como quieras... y por eso puedes hacerlo tan incompresible como quieras
La «maquetación» del código no forma parte de ninguna sintaxis, es solo un conjunto de convenciones clásicas de estilo, por ejemplo para separar en «frases» las palabras relacionadas, las que forman una unidad lógica. De hecho un método habitual es usar dos espacios entre grupos de palabras que están relacionadas.
mcleod_ideafix escribió:En tu código, qué hace la palabra PUERTA?. Qué hace CIERRA?. CIERRA no es parámetro de PUERTA porque aparece detrás, entonces...?
Precisamente el orden indica que la acción es `cierra`, mientras que `puerta` es el objeto, el dato, la palabra que dejaría en la pila aquello que `cierra` debe cerrar. Es lo habitual. En la práctica, que `puerta` sea una variable o una constante o un cálculo es irrelevante en ese nivel de abstracción del problema. Existen convenciones para nombrar las palabras, de forma que indiquen su función (lo que hacen, no lo que son), pero es posible usar cualquier otra convención para distinguir unos tipos de palabras de otros mediante el nombre.
En todo caso, generalizando el enfoque del ejemplo de la lavadora, podrías usar estos comandos (tanto directamente desde el teclado como dentro de un programa, esa es la «gracia»):
Y así puedes probar a fondo el programa controlador de tu lavadora
antes de publicarlo, sin necesidad de añadir al programa una interfaz o un menú o un arranque especial para probar la función que necesitas probar.
Hay también varias formas de poder hacerlo al revés:
Depende de lo que hagan exactamente las palabras y cómo. Pero suele ser más práctico y eficaz, y más fácil de generalizar y de mantener, dejar la acción al final.
Lo que se aplica a las lavadoras se aplica a los marcianos (es decir, la posibilidad de probar cada parte del programa por separado de forma interactiva):
Código: Seleccionar todo
1 marciano pinta 1 marciano 3 x mueve
2 marciano pinta 2 marciano -3 y mueve
2 marciano dup dup 100 200 apunta dispara
1 marciano estalla
mcleod_ideafix escribió:Debo suponer que MINUTOS es una palabra que convierte su parámetro al tipo de unidad de tiempo que usa la palabra ESPERA?
Eso es. También podría ser `1 espera`, que sería menos claro, o mejor simplemente `1 minutos`, de forma que `minutos` hace una pausa de los minutos indicados. La elección de nombres adecuados es importante.
El hecho de pasar los parámetros de forma implícita en la pila es lo que te permite escribir cosas como esta:
En lugar de esto (en seudocódigo):
Cada método tiene ventajas e inconvenientes. El método de Forth es inseparable del funcionamiento interno del lenguaje. No es una sintaxis arbitraria implantada en un compilador o en un intérprete. Por poner un ejemplo trivial: usar dos puntos para separar comandos en BASIC o punto y coma en C es irrelevante, es una decisión del autor que podría haber sido diferente, y no afectaría a cómo funciona el intérprete o el compilador correspondiente; y como ello tantas cosas. Pero la forma en que se escribe el código en Forth no es separable de su funcionamiento interno; es una consecuencia de él.
En cualquier caso influye también la costumbre. A mí me resulta más natural seguir un código que se va compilando o ejecutando tal cual se lee, de izquierda a derecha, igual que una operación en
notación polaca inversa, como se usa en Forth, que atisbar el código entre signos, desentrañar las anidaciones sin fin de las expresiones y las prioridades de los operadores y demás; a menudo esas expresiones me parecen estar escritas al revés, en «notación española torcida»
Por suerte hay cientos y cientos de lenguajes para elegir, aunque para nuestros queridos micros son muchos menos. No pretendo comparar Forth con otros lenguajes, que son muy útiles y muy prácticos y muy populares y muy conocidos y muy recomendables; y mucho menos decir que Forth es «superior» en todo para todo y para todos. Eso sería absurdo. Simplemente, Forth es menos conocido y además es diferente de lo habitual, pero tiene ventajas únicas que lo hacen muy atractivo y útil para quienes lo usamos.
