Un système peut-il être 100% axé sur les données?

Mon nouveau chef travaille sur ce projet depuis de nombreuses années. Je ne suis ici que depuis quelques semaines, mais je ne suis pas sûr que ce soit possible. Il aimerait concevoir un système "100% data driven".

Donc, si nous mettons suffisamment de données, nous pouvons définir et générer n’importe quelle application. J'ai au moins réussi à lui faire accepter certaines choses, comme les utilisateurs, ou les applications devraient avoir des valeurs prédéfinies, mais il aime le concept de structure du système, l'interface utilisateur et la logique qui sont tous stockés sous forme de données.

Il y a quelques démos de choses simples et il a essentiellement redécouvert quelques idées simples de programmation orientée objet et de vos systèmes de gabarits de base, mais je pense que dans l’ensemble, cet objectif pourrait être en réalité impossible.

Je ne sais pas comment vous pouvez définir la logique en utilisant des données sans que le système devienne si complexe que vous réalisiez de toute façon une programmation réelle.

Je pense que théoriquement, ce n'est pas parce que la chose qui interprète les données finit par devoir devenir complète pour décrire l'application, de sorte que vous avez simplement déplacé le problème d'un niveau supérieur à aucun avantage net.

Une telle application 100% axée sur les données est-elle possible?

Votre patron devrait lire le texte suivant: Bad Carma: Le projet "Vision", un récit édifiant sur l’effet de plate-forme interne ou d’effet de second système.

Abstrait

Ceux d'entre nous qui travaillent dans les technologies de l'information (TI) ont tous été engagés dans un projet où quelque chose d'important n'est tout simplement pas correct. Nous le savons, tout le monde le sait, mais personne n’est tout à fait en mesure de cerner le problème de façon convaincante.

Cette histoire concerne un tel projet informatique, l'échec le plus spectaculaire que j'ai jamais connu. Cela a entraîné le licenciement complet d'un service informatique de taille moyenne et finalement la destruction d'une entreprise en pleine croissance dans un secteur en pleine croissance. La société, que nous appellerons "Upstart", était une entreprise de télévision par abonnement prospère et rentable.

Le projet a eu lieu au début des années 90. Il s’agissait d’une application personnalisée de saisie des commandes et de service à la clientèle, qui ressemblait beaucoup à ce que l’on appelle maintenant la gestion de la relation client (CRM). La fonctionnalité principale du système comprenait:

• Entrée de commande et inventaire
• Service client, centre d'assistance
• Grand livre, comptes à recevoir, facturation et comptes à payer

L'application s'appelait "Vision" et le nom était à la fois sa promesse officiellement annoncée pour Upstart et un clin d'œil auto-agrandissant à son architecte. L'application était innovante, en ce sens qu'elle avait été conçue pour être suffisamment flexible pour s'adapter aux futurs changements de l'entreprise. Pas n'importe quels changements futurs prévisibles dans l'entreprise, mais absolument n'importe quels changements dans l'entreprise, sous quelque forme que ce soit. C'était une affirmation assez remarquable, mais Vision devait être la dernière application jamais construite. Il a atteint cette flexibilité absolue en étant complètement basé sur les données, en fournissant une abstraction illimitée et en utilisant des techniques de programmation orientées objet qui étaient à la pointe de la technologie à l'époque.

Comme beaucoup de projets de ce type visant à créer une application essentielle à la mission, les efforts de développement ont duré deux ans, soit environ un an de plus que prévu initialement. Mais c’était acceptable, car c’était l’application qui durerait éternellement, s’adaptant à toutes les exigences futures, offrant un retour sur investissement (ROI) illimité. Lorsque l'application a finalement été "mise en production", presque tout le monde dans la société y avait tellement investi que le destin de la société dépendait de son succès.

Toutefois, en cas de dysfonctionnement total du projet, les applications essentielles à la mission qui dirigent l’activité principale des sociétés multinationales ne sont pas autorisées à jouir du type d’extinction rapide démontrée par des milliers d’entreprises de type "dot-com" à l’époque de la bulle Internet. Un mois après le lancement de Vision, il était évident pour tous, à l'exception de ceux dont la construction était la plus lourde, que c'était un échec.

Voir également

http://en.wikipedia.org/wiki/Inner-platform_effect

La réponse est oui, il est possible de créer un système entièrement basé sur les données et oui, c'est généralement une très mauvaise idée.

Un programme entièrement basé sur les données est un programme dans lequel toute la logique et la configuration sont gérées par des valeurs stockées de telle manière que, dans un autre contexte, elles seraient considérées comme des données. De nombreux produits 4GL produits dans les années 1980 permettaient de générer des rapports, des formulaires, des tableaux et une logique à l'aide d'éléments de données saisis dans un grand nombre de formulaires, stockés dans des tableaux et accessibles via des rapports. J'avais l'habitude de parler de "peinture par numéros", mais je vois maintenant qu'on l'appelle l'effet "système interne". Réputation.

Les personnes qui créent ces systèmes essaient (qu'ils le sachent ou non) de créer un nouveau langage de programmation. Puisqu'ils n'ont pas les compétences, ils le font mal. Du point de vue de la JVM / CLR, un programme Java / C # compilé est simplement une donnée. Dans ce cas, cela a été bien fait. Dans les deux cas, il est nécessaire que les programmeurs utilisent le langage, quel qu’il soit.

À ma connaissance, il existe un moyen spécifique de faire fonctionner ce travail. Vous créez le squelette de chacun des composants dont vous avez besoin: formulaire, rapport, tableau, etc. Vous fournissez un mécanisme pour configurer diverses parties de ces composants en définissant des éléments de données. Pour un ensemble choisi de fonctionnalités, vous prenez les décisions, vous les figez dans le système et vous refusez spécifiquement la possibilité de les configurer.

Vous implémentez également un langage capable de coder des opérations logiques. Ma recommandation est d'utiliser un langage existant tel que lua ou peut-être Python. Vous intégrez des morceaux de ce code partout où des opérations logiques sont nécessaires.

En procédant ainsi, vous réduisez considérablement le nombre d'écritures nécessaires pour implémenter chaque formulaire, rapport, tableau, etc. Le système semble être basé sur les données, mais seulement jusqu'à un certain point.

À ce stade, vous venez de mettre en place un nouveau 4GL. Si vous réussissez, faites-le moi savoir. La plupart des gens échouent lamentablement. Je serai le premier à vous féliciter pour votre réussite.

Je pense que vous avez fondamentalement raison. Un environnement linguistique est déjà un système entièrement flexible piloté par les données. Il prend une donnée (le programme) et l'utilise pour déterminer comment il doit agir sur les autres données. Il peut même avoir un système multi-utilisateurs pour stocker du code pour une utilisation ultérieure par d’autres programmes (allant d’un chemin d’inclusion à une gestion d’installation appropriée).

En gros, un "langage de script" est un langage d'exécution dans lequel cette entrée de code est lisible par l'homme. Un compilateur place une étape supplémentaire entre l'utilisateur et le moteur d'exécution. Les langages "Joke" comme Malbolge et APL ne doivent pas nécessairement être lisibles par l'homme. Mais c’est la même chose à un niveau, et de toute façon, lisible par l’homme ne signifie pas que tous les utilisateurs potentiels ont les compétences nécessaires pour le lire ou l’écrire, ou qu’on peut s’attendre à le développer.

Il y a de bonnes raisons pour lesquelles vous n'exposez pas normalement un environnement d'exécution directement aux utilisateurs finaux. Le principal étant que supprimer la flexibilité augmente la commodité.

Si je veux taper un message SO, je veux juste le taper. Je suis parfaitement capable d'écrire un programme C ++ pour le sortir, mais je n'utiliserais pas un navigateur Web qui exposerait un éditeur de programme C ++ au lieu d'une zone de texte normale. Les personnes qui ne connaissent pas le C ++ non seulement n'utilisent pas le navigateur, mais ne le peuvent pas.

Si je veux configurer certains paramètres métier, je ne veux pas nécessairement le faire en utilisant un langage de spécification complet de Turing, et même si je le faisais, cela ne serait probablement pas différent de la "codification en dur" de ces mêmes paramètres commerciaux dans une autre programmation. la langue. Vous devez toujours vous demander si ce que vous écrivez signifie ce que vous voulez dire. Vous devez toujours vérifier que les modifications sont correctes. C'est pour toutes les tâches qui ne sont pas négligeables et non anticipée par quelqu'un qui, vous avez encore besoin de compétences en programmation n'ont des compétences en programmation qui ont préparé pour vous un sous-système spécialisé ( « application ») pour configurer ( « utilisation »).

Donc, si vous êtes sur le point de vous lancer dans un système 100% basé sur les données, qui peut tout faire avec les bonnes données, vous avez deux questions à vous poser:

1. Sommes-nous en train d’inventer des langages de programmation, ou devrions-nous être?
2. Notre nouveau langage de programmation sera-t-il meilleur (pour nos besoins) que ceux que nous avons déjà et allons-nous le soutenir et le développer selon ses besoins?

Parfois, les réponses sont oui et vous écrivez un langage spécifique à un domaine. Ou même un vrai langage de programmation généraliste si vous êtes Sun / Microsoft / Stroustrup / van Rossum / beaucoup d'autres. Parfois, les réponses sont non et vous avez l'effet "plate-forme intérieure" - après beaucoup d'effort et de tâtonnements, vous vous retrouvez avec quelque chose. Si vous êtes chanceux, il n’est que légèrement inférieur au langage de programmation dans lequel vous l’avez écrit et n’est pas plus facile à utiliser.

Certaines langues sont plus difficiles ou plus faciles à utiliser que d'autres, en particulier si elles sont spécialisées dans un objectif tel que R, alors certains utilisateurs les trouveront beaucoup plus facilement. Ce que vous ne ferez probablement pas, c’est de simplifier fondamentalement la programmation d’applications générales. À tout moment, il y a probablement plusieurs personnes / organisations dans le monde susceptibles de le faire, mais votre patron / votre entreprise doit honnêtement déterminer si cela le concerne ou non.

Il existe une astuce souvent utilisée pour les jeux, qui consiste à exposer les liaisons Lua au moteur de jeu. Cela permet aux concepteurs de programmer dans un langage relativement simple, tout en faisant appel à un "vrai" programmeur, le cas échéant, pour obtenir des performances ou pour accéder à des fonctionnalités particulières du moteur ou de la plate-forme. Les scripts Lua résultants sont des "données" en ce qui concerne le moteur. Ils n'ont pas tous besoin d'inclure une grande partie de ce que vous appelleriez la "logique" par opposition aux données de configuration, et ils définissent souvent à peu près toute l'intrigue et l'environnement, mais pas le gameplay complet. Ce n'est pas à 100% basé sur les données et ce n'est certainement pas à 100% sans erreur, mais c'est un compromis pratique intéressant.

J'ai travaillé dans une entreprise où c'était l'objectif. Les extraits de code SQL étaient stockés dans des tables de base de données, lus au moment de l'exécution et exécutés. La performance était terrible, comme vous pouvez l’imaginer, et les bugs étaient fréquents. Il était également impossible de déboguer, sans trace de pile ni quoi que ce soit qui facilite la vie.

La "programmation pilotée par les données" résulte d'un manque fondamental de compréhension de ce que nous faisons, en tant que programmeurs; Toute donnée capable de créer un algorithme est en réalité une "programmation", même si vous avez réussi à mélanger (modifier ou masquer) les deux idées de l'interface utilisateur. Cela ne signifie pas pour autant que vous ne pouvez pas combiner les deux idées de l’autre sens, de sorte que tout le code est constitué de données; c'est la prémisse derrière lisp, rendue possible par son homoiconicité et exploitée par son système macro. Oui, ces concepts semblent similaires, mais leurs implications et applications sont très différentes dans la pratique.

De plus, cela peut être éditorial, mais les endroits que j'ai rencontrés et qui souhaitent une programmation "entièrement basée sur les données" n'apprécient vraiment pas leurs programmeurs. Ils pensent que le code est un centre de coûts, un élément à externaliser ou à ignorer.

Vous voulez dire que votre patron veut que vous écriviez ceci:

[
  {
    "statement": "Assignment ",
    "variable": "App",
    "value": {
      "type": "Function",
      "arguments": [],
      "function-body": [
        {}
      ]
    }
  },
  {
    "statement": "Assignment",
    "variable": "App.prototype.action",
    "value": {
      "type": "Function",
      "arguments": [
        "data"
      ],
      "function-body": [
        {
          "statement": "Call",
          "function-name": "console.log",
          "arguments": [
            "data"
          ]
        }
      ]
    }
  }
]

Pour générer ceci:

var App = function () {};
App.prototype.action = function ( data ) {
    console.log( data );
}

Le premier est JSON et le second est JavaScript .

Désincarcération

Je pense que théoriquement, ce n'est pas parce que la chose qui interprète les données finit par devoir devenir complète pour décrire l'application, de sorte que vous avez simplement déplacé le problème d'un niveau supérieur à aucun avantage net.

Une telle application 100% axée sur les données est-elle possible?

C'est là que je viens de commencer. Avec ma réponse, je suis d’accord avec le post original qui dit: C’est possible, mais vous avez raison, le problème ne fera que déplacer le problème d’un niveau supérieur sans aucun avantage [évident] .

Je pense que vous pourriez argumenter de manière convaincante que toute application de navigateur Web peut être considérée comme étant à 100% pilotée par les données ¹ .

Bien entendu, cela ne simplifie ni ne facilite la création d'applications sur le Web, mais les rend beaucoup plus difficiles.

Dites à votre patron qu'il réinvente le navigateur Web et qu'il devra éventuellement réinventer JavaScript pour créer quelque chose de raisonnablement complexe.

¹ Eh bien, si vous ignorez les plugins, JavaScript et HTML5 .

Oui. Autant que je sache, un système tel que Mathematica , qui est un langage de programmation puissant mais qui est essentiellement un shell, est construit sur la même idée que celle attendue par votre patron. Wolfram Mathematica est en train de devenir suffisamment complexe pour pouvoir effectuer facilement de nombreuses tâches de calcul.

Les données pilotées est un concept. Si nous, programmeurs, allons manipuler les données de manière simple, nous avons besoin d’un shell qui nous permet de jouer facilement avec les données. Essayez de comprendre qu’une fois que nous commençons à parler d’apprentissage d’un langage de programmation basé sur la syntaxe, nous apprenons réellement l’interface d’application ou simplement son shell. Si nous comprenons le shell, nous pouvons conduire les programmes.

Pour ce qui est des données à 100%, si le compilateur ou l'interpréteur peut comprendre le shell, le calcul est effectué. Si les données ont la même structure sous-jacente que le shell ou l'interface, les données peuvent également être gérées par le compilateur ou l'interpréteur. Je pense que Mathematica est une bonne explication de la raison pour laquelle je vous réponds par un oui.