Hace un tiempo me topé con el concepto de usar hojas de cálculo (me refiero a celdas y fórmulas, no a código de macro) como una forma de especificar la lógica de programación. La idea es:
cree una hoja de cálculo con un flujo de cálculos claramente definido (que a veces se adapta mejor al paradigma de "flujo de datos" de las hojas de cálculo en lugar de los estilos de programación orientados a procedimientos u objetos)
definir celdas de entrada
definir celdas de salida
compilar todo en una clase ejecutable independiente (o función, procedimiento, ...)
úselo en código normal dentro de un proyecto de software más amplio
use la hoja de cálculo como código fuente para mantenerse a lo largo del tiempo
La idea es usar esta técnica para problemas que realmente encajan en el modelo y que esto conduciría a un código naturalmente fácil de documentar y fácil de mantener. Estoy interesado en saber si has experimentado el uso de la técnica y para qué. Una aplicación de ejemplo que me vino a la mente son las calculadoras de tarifas de seguros, que generalmente son redactadas, creadas y validadas por actuarios en hojas de Excel y solo codificadas posteriormente (es un proceso doloroso) en una lógica de programación difícil de mantener.
fuente
Respuestas:
Aunque no es precisamente el estilo de "construir una hoja de cálculo, compilarlo en código" sobre lo que estaba preguntando, la extensión de flujo de datos de Cells a CLOS usa un modelo similar: que las fórmulas que expresan flujos y transformaciones de datos sean la representación del "material de origen" / " de registro "para el diseño de objeto / clase. Considérelo una forma alternativa de construir lo que estaba preguntando.
Y solo por diversión: macro de hoja de cálculo
fuente
Honestamente, apenas puedo pensar en ningún cálculo del mundo real donde esto se aplique. La programación del "flujo de datos" se puede realizar fácilmente con muchos lenguajes de programación modernos (mire LINQ en el mundo .NET o los operadores de procesamiento de listas de Perl y Python), y según mi experiencia, eso resulta en un código mucho más fácil de mantener que un montón de "fórmulas de hoja de cálculo" con referencias de celda difíciles de mantener.
Por otro lado, mis colegas y yo hemos creado muchas aplicaciones basadas en hojas de cálculo (MS-Excel, para ser precisos), donde Excel se utilizó como una herramienta fácil de usar para ingresar datos de entrada / crear máscaras de entrada muy rápidamente, o para crear resultados formateados, o ambos. En todos esos casos, el cálculo o el procesamiento de esos datos no se realizó (o solo se realizó parcialmente) mediante fórmulas de Excel, sino por código de programa, ya que las fórmulas de Excel no eran lo suficientemente potentes o la herramienta completamente incorrecta (y créanme, tenemos un mucho conocimiento de lo que es posible con las fórmulas de Excel y lo que no).
fuente
Desde que leí este artículo , he estado pensando de vez en cuando sobre el concepto. Creo que definitivamente hay un uso para ello.
Una cosa sobre la optimización de tal cosa, una hoja de cálculo es muy similar al espacio de memoria. También es muy similar al espacio de visualización e impresión (como en x, y). Muchos beneficios allí también.
Cuando notó la capacidad de mantenimiento, eso me abrió muchas ideas. No sé qué hay para compilar realmente y las características del lenguaje, las bibliotecas, etc., pueden ser bastante dolorosas. Aún así, podría haber un futuro en alguna parte.
Realmente solo he escrito scripts VB para hojas de cálculo, libros de calificaciones y "software" de contabilidad principalmente. Nunca creó aplicaciones ejecutables a partir de nada basado en una hoja de cálculo, excepto la interfaz de archivo Excel de una aplicación C ++.
fuente
Sí, sin embargo, lo considero más como "prueba de hoja de cálculo" que como "programación de hoja de cálculo". Por ejemplo, recientemente estaba trabajando en una función para nuestro proyecto que implica realizar un cálculo en grandes cantidades de registros de bases de datos. El cálculo era relativamente simple pero importante y, por lo tanto, necesitaba una atención de prueba particular. Además, la fórmula que estábamos usando requería una pequeña cantidad de adaptación para ser aplicable a nuestra situación.
Realicé algunos cálculos a mano para escribir mis pruebas unitarias, mientras que el probador con el que estaba trabajando creó una hoja de cálculo como la que usted describió para usar en sus pruebas de extremo a extremo. Debido a la adaptación de la fórmula fuente, no teníamos datos de prueba independientes con los que comparar, por lo tanto, la hoja de cálculo proporcionaba una especie de verificación de estilo de "contabilidad de doble entrada" que nos daba la confianza de que el código era correcto.
Entonces, sí, veo que esta técnica es muy útil como fuente de datos de prueba para los casos en que los cálculos involucrados son fáciles de implementar en una hoja de cálculo, pero de lo contrario se requiere que se implementen en el código. Sin embargo, dicha hoja de cálculo no debe usarse para "especificar la lógica de programación" per se, sino simplemente los resultados finales requeridos.
fuente
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:
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.
fuente
Mi pensamiento sería utilizar la hoja de cálculo para definir la lógica de los cálculos y, mientras lo hago, intentar configurar la hoja de cálculo de manera que sea amigable con el lenguaje de programación. Por amigable quiero decir -> usar rangos de nombres / referencias en lugar de coordenadas cellXY, y dividir las fórmulas en partes más pequeñas.
fuente