Voyez-vous une utilisation pour la «programmation de feuille de calcul»? [fermé]

Il y a quelque temps, je suis tombé sur le concept de l'utilisation de feuilles de calcul (je veux dire des cellules et des formules et non du code macro) comme moyen de spécifier la logique de programmation. L'idée est:

• créer une feuille de calcul avec un flux de calculs clairement défini (qui sont parfois mieux adaptés au paradigme de "flux de données" des feuilles de calcul au lieu des styles de programmation procéduraux ou orientés objet)

• définir des cellules d'entrée

• définir les cellules de sortie

• compiler le tout dans une classe exécutable autonome (ou fonction, procédure, ...)

• l'utiliser en code normal dans un projet logiciel plus large

• utiliser la feuille de calcul comme code source à maintenir dans le temps

L'idée est d'utiliser cette technique pour des problèmes qui s'intègrent vraiment dans le modèle et cela conduirait à un code naturellement bien documenté et facile à gérer. Je souhaite savoir si vous avez déjà utilisé la technique et pourquoi. Un exemple d'application qui m'est venu à l'esprit est les calculateurs de tarifs d'assurance, qui sont généralement rédigés, créés et validés par des actuaires sur des feuilles Excel et codés plus tard (c'est un processus douloureux) dans une logique de programmation difficile à maintenir.

Bien que ce ne soit pas précisément le style de "construire une feuille de calcul, compilez-le en code" que vous demandiez, l' extension de flux de données Cells à CLOS utilise un modèle similaire: que les formules exprimant les flux de données et les transformations soient la représentation du "matériau source" / " of record "pour la conception d'objet / classe. Considérez-le comme une façon alternative de construire ce que vous demandiez.

Et juste pour le plaisir: macro de feuille de calcul

qui sont parfois mieux adaptés au paradigme de "flux de données" des feuilles de calcul au lieu des styles de programmation procéduraux ou orientés objet

Honnêtement, je peux difficilement penser à des calculs réels où cela s'applique. La programmation "Dataflow" peut être effectuée facilement par de nombreux langages de programmation modernes (regardez LINQ dans le monde .NET, ou les opérateurs de traitement de liste de Perl et Python), et d'après mon expérience, cela donne un code beaucoup plus facile à gérer qu'un tas de "formules de tableur" avec des références de cellules difficiles à maintenir.

D'un autre côté, mes collègues et moi-même avons créé de nombreuses applications basées sur des feuilles de calcul (MS-Excel, pour être précis), où Excel a été utilisé soit comme un outil convivial pour saisir des données d'entrée / créer des masques de saisie très rapidement, soit pour créer une sortie formatée, ou les deux. Dans tous ces cas, le calcul ou le traitement de ces données n'a pas été fait (ou seulement partiellement) par des formules Excel, mais par code de programme, car les formules Excel n'étaient pas assez puissantes ou l'outil complètement mauvais (et croyez-moi, nous avons un beaucoup de connaissances sur ce qui est possible avec les formules Excel et ce qui ne l’est pas).

Depuis que j'ai lu cet article, je pense au concept. Je pense qu'il ya certainement une utilité.

Une chose à propos de l'optimisation d'une telle chose, une feuille de calcul est très similaire à l'espace mémoire. Il est également très similaire à l'espace d'affichage et d'impression (comme en x, y). Beaucoup d'avantages là aussi.

Lorsque vous avez noté la maintenabilité, cela m'a ouvert beaucoup d'idées. Je ne sais pas ce qu'il y a à compiler avec vraiment et les fonctionnalités de langage, les bibliothèques, etc. pourraient être assez pénibles. Pourtant, il pourrait y avoir un avenir quelque part.

Je n'ai vraiment écrit que des scripts VB pour les feuilles de calcul, les carnets de notes et les "logiciels" de comptabilité. Jamais créé des applications exécutables à partir de rien basé sur une feuille de calcul, sauf l'interface de fichier Excel à partir d'une application C ++.

Oui, mais je pense plus à cela comme "test de tableur" plutôt que "programmation de tableur". Par exemple, récemment, je travaillais sur une fonctionnalité de notre projet qui consiste à effectuer un calcul sur un grand nombre d'enregistrements de base de données. Le calcul était relativement simple mais important et nécessitait donc une attention particulière aux tests. De plus, la formule que nous utilisions nécessitait une petite quantité d'adaptation pour être applicable à notre situation.

J'ai effectué quelques calculs à la main pour écrire mes tests unitaires, tandis que le testeur avec lequel je travaillais a créé une feuille de calcul comme vous l'avez décrite pour l'utiliser dans ses tests de bout en bout. En raison de l'adaptation de la formule source, nous n'avions pas de données de test indépendantes pour comparer, donc la feuille de calcul a fourni une sorte de vérification de style "comptabilité à double entrée" qui nous a donné confiance que le code était correct.

Alors oui, je considère que cette technique est très utile comme source de données de test pour les cas où les calculs impliqués sont faciles à implémenter dans une feuille de calcul, mais doivent autrement être implémentés dans le code. Cependant, une telle feuille de calcul ne doit pas être utilisée pour «spécifier la logique de programmation» en soi, mais simplement le ou les résultats finaux requis.

Le tableur "programmation" est un type de programmation de flux de données.

Nous avons un problème linguistique avec cela, nous ne devrions pas l'appeler "programmation", car c'est beaucoup moins que nous appelons programmation, mais c'est certainement plus que d'entrer des données dans un programme.

La programmation de flux de données est une architecture et une discipline, où l'application est un réseau de modules indépendants, ils s'envoient des messages (données). Ce modèle n'est pas applicable à tous les problèmes, seulement pour ceux où il y a des données ou flux source (ou plus), qui vont sur le réseau de traitement et produisent des données / flux de sortie. Voir la liste ci-dessous.

La programmation de flux de données a plusieurs types, voyons-en:

• Feuille de calcul: les nombres saisis sont traités par des formules, puis des nombres de résultats et des graphiques. Caractéristiques spéciales: le temps d'exécution est "ponctuel", lorsque la valeur d'entrée (composant) change, la partie appropriée du graphique de traitement se réexécute et produit une sortie.
• Pipe Unix: le shell lance plusieurs programmes et relie stdout-> stdin. Caractéristiques spéciales: seule la liaison de type pipe est autorisée, le graphique est une file d'attente unique.
• Exécution synchronisée: il existe une horloge qui déclenche le traitement d'une trame ou d'un échantillon à une fréquence spécifiée. Chaque composant s'exécute une fois par cycle d'horloge. Les systèmes de traitement vidéo et audio les exemples, ils fonctionnent à une fréquence d'images / d'échantillonnage spécifiée.
• Exécution asynchrone: le graphe est en veille, jusqu'à ce qu'un événement externe se produise. Il traite ensuite l'événement, génère une sortie (ou non) et passe à l'état inactif.

Revenons à votre question: je pense que oui, c'est une bonne idée de publier une application de flux de données en tant qu'application autonome. Je l'ai déjà fait. Deux fois .

Un de mes amis et moi avons créé un prototype de système DF pour la domotique. Nous n'avons pas d'éditeur de graphique, donc l'application n'est pas modifiable par l'utilisateur, certains paramètres sont stockés dans un fichier de configuration, mais rien d'autre. Nous avons un langage de script DF, qui est "compilé" en code C ++ (une liste de création de composants et de définitions de messages), qui est compilé en un exécutable natif. Les modules sont des classes C ++ (autres classes, juste pour obtenir des informations sur notre système: Message, Dispathcer, Component (abstract), Port (abstract), ConsumerPort, ProducerPort).

De plus, nous avons été étonnés des avantages d'un système DF: nous avons créé une application de reniflage en série dans les 2 minutes, ou nous avons créé un programme de test sur place , qui clignote les lampes une par une (il n'y avait pas de documentation sur les identifiants matériels). Nous avons créé des composants MIDI et joypad juste pour le plaisir, j'ai également fait un orgue léger avec (voir http://homeaut.com/under_construction/ ).

Je ne vois qu'une seule difficulté dans le cas des feuilles de calcul: comme chaque nombre et formule (potentiellement: chaque cellule) est un composant, votre graphique n'est pas final. Lorsque vous ajoutez une ligne à votre application sum () simple, cela signifie que le graphique du flux de données est modifié. Donc, vous devez "reprogrammer" le graphique au moment de l'exécution, ou nous devrions l'appeler "métaprogrammation". Dans Excel, une macro ferait l'affaire, mais nous perdons ensuite la pureté du flux de données.

J'ai une solution pas trop mauvaise mais pas parfaite. J'ai créé une feuille de calcul, une application AJAX avec backend PHP. L'axe vertical représente le temps (jours), les lignes sont des composants. Il y a des composants, comme l'entrée (la ligne peut être modifiée par l'utilisateur), la moyenne verticale, la moyenne / somme horizontale et certains calculs statistiques spécifiques au domaine. Il n'y a qu'un seul problème: c'est "unidimensionnel". Tant que je veux juste additionner et moy et quoi que ce soit, je peux ajouter de nouvelles lignes et créer le composant, qui calcule les choses. Mais il y a une forte contrainte: les colonnes sont toujours des jours (j'ai fait des "vues" hebdomadaires et mensuelles, qui affichent les données quotidiennes sous forme de somme / moyenne, mais c'est toujours unidimensionnel). Je ne peux pas le montrer, c'est collaboratif et nécessite une tâche de backend PHP pour fonctionner 7/24, ce n'est pas pris en charge par mon fournisseur d'hébergement.

Ainsi, mon modèle (qui peut être décrit comme: "jours horizontalement") n'est pas en mesure de gérer d'autres types de problèmes.

J'ai une idée, comment résoudre ce problème: les onglets .

Lorsque vous êtes bloqué dans Excel et devez créer un autre tableau, vous pouvez utiliser une zone distincte sur le même onglet ou ouvrir un autre onglet. De plus, le référencement entre les onglets est inconfortable, je préfère la première méthode. Je pense que les onglets devraient être affichés sur le même écran, comme les fenêtres qui ne se chevauchent pas.

Chaque table doit avoir son axe de croissance: vertical, horizontal ou fixe. Les tables de croissance verticales ont des composants de ligne (comme ma feuille de calcul basée sur le jour), où toutes les colonnes ont la "même" formule, les composants horizontaux ont des composants de colonne, les tables de taille fixe sont comme n'importe quelle feuille de calcul.

Ainsi, lorsque l'utilisateur ajoute une nouvelle ligne / colonne, la nouvelle ligne / colonne aura la même formule.

De plus, dans les feuilles de calcul, je déteste le fait que je dois copier les mêmes formules 1000 fois, si j'ai 1000 lignes. C'est une source de bugs (garder l'ancienne version de la formule dans certaines lignes), un gaspillage de mémoire (stocker la même formule 1000x).

Peut-être que je me trompe, et il y a des bugs conceptuels dans ce modèle, mais j'espère que c'était une bonne réflexion.

Ma pensée serait d'utiliser la feuille de calcul pour définir la logique des calculs et, ce faisant, d'essayer de configurer la feuille de calcul de manière à la rendre conviviale pour le langage de programmation. Par convivial, je veux dire -> en utilisant des plages de noms / références au lieu des coordonnées cellXY, et en décomposant les formules en plus petits morceaux.