Entrada, salida y estado
Por ser sencillos, solemos olvidar algunos conceptos básicos.
Recuerdo que mi tío me explicó qué era un ordenador cuando yo era peque.
En aquel entonces eran máquinas poco comunes, desconocidas y misteriosas.
Tenía unos cartones con diagramas y dibujos que representaban la idea básica de una computadora.
Un ordenador, recibe una entrada, la procesa y genera una salida.
Evidente y sencillo.
Queda otro detalle vital.
La salida, puede no ser resultado de la entrada inmediata. Quizá la salida sea consecuencia de la última entrada y de... algunas anteriores. El estado.
Desde una pequeña función o método de un puñado de líneas de código, un módulo, un objeto, closures, componentes, procesos o servicios; hasta los grandes sistemas informáticos de bancos, el CERN, gigantes sistemas con millones de líneas de código... Todos tienen una entrada, una salida y gestionan el estado.
El estado es enormemente común, pero no imprescindible.
Cuando un proceso computacional realiza su trabajo exclusivamente con la entrada actual, sin dependencias de entradas previas, es un proceso sin estado.
Los procesos sin estado tienen ventajas muy interesantes que trataré en un futuro (y sus limitaciones de aplicación).
Ejemplos claros, son funciones matemáticas (log, sin, cos, etc...). Siempre devuelven lo mismo para la misma entrada suministrada en la llamada a la función.
Para interactuar con el exterior, la entrada y salida, utilizamos multitud de tecnologías...
Es lógico que tengamos tanta ayuda y tantas tecnologías. Es una tarea vital y necesaria en todos los niveles de abstracción y desarrollo de cualquier sistema informático.
Aun con tantas tecnologías, es muy conveniente buscar procedimientos específicos para reducir la carga de trabajo en este punto. Por ser tan común, se pueden obtener grandes beneficios.
¿Y qué hay del estado?
También es una tarea vital y común. Es obligado plantearnos...
¿Cómo lo hago? ¿Qué técnicas y tecnologías me ayudan?
La parte más común del estado son datos modificables. Los ordenadores consisten en máquinas con millones de valores modificables. Los lenguajes imperativos trabajan con la misma metáfora, su objetivo es hacer fácil esa gestión (y lo consiguen).
Pero para el estado, además de los datos de la situación actual, también puede ser vital el orden, la secuencia de acontecimientos.
Esto se modela bastante bien con automátas finitos, con autómatas de pila, con gramáticas, etc...
Pero en este caso, ni el ordenador ni sus lenguajes muy directos de programación (la programación imperativa), suelen ayudar demasiado.
No parece inteligente que la improvisación en cada momento, reinventando la rueda con mayor o menor inspiración según el momento, sea una buena idea.
Se puede modelar con un analizador descendente recursivo con predicción n a base de llamadas a funciones recursivas.
O se pueden utilizar herramientas como bison/flex [link].
Pero podría ser un inconveniente el no poder crear varias instancias independientes.
También podríamos optar por el espectacular boost::spirit [link], o podríamos utilizar la maravilla ANTLR [link]...
Yo empecé con implementaciones de autómatas finitos deterministas con programación imperativa estructurada y funciones recursivas (analizadores descendentes recursivos)
Luego traté de mejorar en C++ utilizando RAII.
Ahora utilizo un sencillo y humilde DSL dinámico LL(n) [link] con el típico truco de la estrella de Klein para derivar por la derecha.
Tanto los DSLs como las máquinas de estado y su relación con los sistemas informáticos, se merecen reflexiones específicas.
Computación (en microescala o sistemas gigantes) <-> Entrada, salida y estado
http://en.wikipedia.org/wiki/Finite-state_machine
http://en.wikipedia.org/wiki/State_(computer_science)
http://en.wikipedia.org/wiki/LL_parser
http://en.wikipedia.org/wiki/GNU_bison
http://www.antlr.org/
http://boost-spirit.com/home/
Recuerdo que mi tío me explicó qué era un ordenador cuando yo era peque.
En aquel entonces eran máquinas poco comunes, desconocidas y misteriosas.
Tenía unos cartones con diagramas y dibujos que representaban la idea básica de una computadora.
Un ordenador, recibe una entrada, la procesa y genera una salida.
Evidente y sencillo.
Queda otro detalle vital.
La salida, puede no ser resultado de la entrada inmediata. Quizá la salida sea consecuencia de la última entrada y de... algunas anteriores. El estado.
Desde una pequeña función o método de un puñado de líneas de código, un módulo, un objeto, closures, componentes, procesos o servicios; hasta los grandes sistemas informáticos de bancos, el CERN, gigantes sistemas con millones de líneas de código... Todos tienen una entrada, una salida y gestionan el estado.
El estado es enormemente común, pero no imprescindible.
Cuando un proceso computacional realiza su trabajo exclusivamente con la entrada actual, sin dependencias de entradas previas, es un proceso sin estado.
Los procesos sin estado tienen ventajas muy interesantes que trataré en un futuro (y sus limitaciones de aplicación).
Ejemplos claros, son funciones matemáticas (log, sin, cos, etc...). Siempre devuelven lo mismo para la misma entrada suministrada en la llamada a la función.
Para interactuar con el exterior, la entrada y salida, utilizamos multitud de tecnologías...
- Teclados, ratones, pantallas, pantallas táctiles, cámaras, sensores...
- La consola
- TCP, UDP, FTP, HTTP, SOAP...
- Bases de datos relacionales y noSQL
- HTML, json, yaml, xml, google buffers...
- QPID, CORBA, TIBCO, COM, DBUS...
Es lógico que tengamos tanta ayuda y tantas tecnologías. Es una tarea vital y necesaria en todos los niveles de abstracción y desarrollo de cualquier sistema informático.
Aun con tantas tecnologías, es muy conveniente buscar procedimientos específicos para reducir la carga de trabajo en este punto. Por ser tan común, se pueden obtener grandes beneficios.
¿Y qué hay del estado?
También es una tarea vital y común. Es obligado plantearnos...
¿Cómo lo hago? ¿Qué técnicas y tecnologías me ayudan?
La parte más común del estado son datos modificables. Los ordenadores consisten en máquinas con millones de valores modificables. Los lenguajes imperativos trabajan con la misma metáfora, su objetivo es hacer fácil esa gestión (y lo consiguen).
Pero para el estado, además de los datos de la situación actual, también puede ser vital el orden, la secuencia de acontecimientos.
Esto se modela bastante bien con automátas finitos, con autómatas de pila, con gramáticas, etc...
Pero en este caso, ni el ordenador ni sus lenguajes muy directos de programación (la programación imperativa), suelen ayudar demasiado.
No parece inteligente que la improvisación en cada momento, reinventando la rueda con mayor o menor inspiración según el momento, sea una buena idea.
Se puede modelar con un analizador descendente recursivo con predicción n a base de llamadas a funciones recursivas.
O se pueden utilizar herramientas como bison/flex [link].
Pero podría ser un inconveniente el no poder crear varias instancias independientes.
También podríamos optar por el espectacular boost::spirit [link], o podríamos utilizar la maravilla ANTLR [link]...
Yo empecé con implementaciones de autómatas finitos deterministas con programación imperativa estructurada y funciones recursivas (analizadores descendentes recursivos)
Luego traté de mejorar en C++ utilizando RAII.
Ahora utilizo un sencillo y humilde DSL dinámico LL(n) [link] con el típico truco de la estrella de Klein para derivar por la derecha.
Tanto los DSLs como las máquinas de estado y su relación con los sistemas informáticos, se merecen reflexiones específicas.
Computación (en microescala o sistemas gigantes) <-> Entrada, salida y estado
http://en.wikipedia.org/wiki/Finite-state_machine
http://en.wikipedia.org/wiki/State_(computer_science)
http://en.wikipedia.org/wiki/LL_parser
http://en.wikipedia.org/wiki/GNU_bison
http://www.antlr.org/
http://boost-spirit.com/home/
Comentarios