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.