La "programación" de la hoja de cálculo es un tipo de programación de flujo de datos.
Tenemos un problema lingüístico, no deberíamos llamarlo "programación", porque es mucho menos de lo que llamamos programación, pero definitivamente es más que ingresar datos en un programa.
La programación de flujo de datos es una arquitectura y disciplina, donde la aplicación es una red de módulos independientes, se envían mensajes (datos) entre sí. Este modelo no es aplicable a todos los problemas, solo para aquellos, donde hay una fuente de datos o flujo (o hay más), que va a través de la red de procesamiento y produce datos / flujos de salida. Ver la lista a continuación.
La programación del flujo de datos tiene varios tipos, veamos algunos:
- Hoja de cálculo: los números de entrada son procesados por fórmulas, luego los números de resultados y gráficos. Características especiales: el tiempo de ejecución es "one-shot", cuando el valor de entrada (componente) cambia, la parte apropiada del gráfico de procesamiento se vuelve a ejecutar y produce la salida.
- Canalización Unix: el shell inicia varios programas y vincula stdout-> stdin. Características especiales: solo se permite la vinculación de estilo de tubería, el gráfico es una sola cola.
- Ejecución sincronizada: hay un reloj que activa el procesamiento de una trama o muestra en una frecuencia especificada. Cada componente se ejecuta una vez por ciclo de reloj. Los sistemas de procesamiento de video y audio son ejemplos, funcionan a una frecuencia de cuadro / muestra especificada.
- Ejecución asincrónica: el gráfico está inactivo, hasta que ocurre un evento externo. Luego procesa el evento, genera algo de salida (o no) y pasa al estado inactivo.
Volviendo a su pregunta: creo que sí, es una buena idea publicar una aplicación de flujo de datos como una aplicación independiente. Ya lo hice. Dos veces .
Un amigo mío y yo hemos creado un prototipo de sistema DF para domótica. No tenemos editor gráfico, por lo que el usuario no puede editar la aplicación, algunos parámetros se almacenan en un archivo de configuración, pero nada más. Tenemos un lenguaje de script DF, que se "compila" en código C ++ (una lista de creación de componentes y definiciones de mensajes), que se compila en un ejecutable nativo. Los módulos son clases de C ++ (otras clases, solo para obtener información sobre nuestro sistema: Mensaje, Dispathcer, Component (abstract), Port (abstract), ConsumerPort, ProducerPort).
Además, nos sorprendieron las ventajas que ofrece un sistema DF: creamos una aplicación sniffer en serie en 2 minutos o hicimos un programa de prueba en el sitio , que parpadea las lámparas una por una (no había documentación en ID de hardware). Hemos creado componentes MIDI y joypad solo por diversión, también he creado un órgano ligero con él (ver http://homeaut.com/under_construction/ ).
Solo puedo ver una dificultad en el caso de las hojas de cálculo: como cada número y fórmula (potencialmente: cada celda) es un componente, su gráfico no es final. Cuando agrega una línea a su aplicación sum () simple, significa que el gráfico de flujo de datos cambia. Por lo tanto, debe "reprogramar" el gráfico en tiempo de ejecución, o deberíamos llamarlo "metaprogramación". En Excel, una macro haría el trabajo, pero luego perderíamos la pureza del flujo de datos.
Tengo una solución no muy mala pero no perfecta. Hice una hoja de cálculo, una aplicación AJAX con backend PHP. El eje vertical es el tiempo (días), las líneas son componentes. Hay componentes, como la entrada (el usuario puede editar la línea), el promedio vertical, el promedio / suma horizontal y algunos cálculos estadísticos específicos del dominio. Solo hay un problema: es "unidimensional". Mientras quiera solo sum y avg y lo que sea, puedo agregar nuevas líneas y crear el componente, que calcula las cosas. Pero hay una fuerte restricción: las columnas son siempre días (he hecho "vistas" semanales y mensuales, que muestran datos diarios como sum / avg, pero aún son unidimensionales). No puedo mostrarlo, es colaborativo y requiere una tarea backend de PHP para ejecutarse el 7/24, no es compatible con mi proveedor de host.
Por lo tanto, mi modelo (que se puede describir mejor como: "días horizontalmente") no puede manejar otro tipo de problemas.
Tengo una idea, cómo resolver este problema: pestañas .
Cuando se atasca en Excel y tiene que crear otra tabla, puede usar un área distinta en la misma pestaña o abrir otra pestaña. Además, la referencia entre pestañas es incómoda, prefiero el primer método. Creo que las pestañas deberían mostrarse en la misma pantalla, como ventanas que no se superponen.
Cada mesa debe tener su eje de crecimiento: vertical, horizontal o fijo. Las tablas de crecimiento vertical tienen componentes de línea (como mi hoja de cálculo basada en el día), donde todas las columnas tienen la "misma" fórmula, los componentes horizontales tienen componentes de columna, las tablas de tamaño fijo son como cualquier hoja de cálculo.
Entonces, cuando el usuario agrega una nueva línea / columna, la nueva línea / columna tendrá la misma fórmula.
Además, en las hojas de cálculo, odio el hecho de que necesito copiar las mismas fórmulas 1000 veces, si tengo 1000 líneas. Es una fuente de errores (mantener la versión anterior de la fórmula en algunas líneas), desperdicio de memoria (almacenar la misma fórmula 1000x).
Tal vez me equivoque, y hay errores conceptuales en este modelo, pero espero que haya sido una buena reflexión.