Pourquoi programme-t-on toujours avec des fichiers plats? [fermé]

https://stackoverflow.com/questions/160633

flat-file

03-07-2019
|

Question

Pourquoi les fichiers de texte plats sont-ils à la pointe de la technologie pour représenter le code source?

Bien sûr - le préprocesseur et le compilateur doivent voir une représentation de fichier à plat du fichier, mais celle-ci est facile à créer.

Il me semble qu'une certaine forme de données XML ou binaires pourrait représenter beaucoup d'idées très difficiles à suivre, sinon.

Par exemple, vous pouvez intégrer des diagrammes UML directement dans votre code. Ils pourraient être générés de manière semi-automatique et annotés par les développeurs pour mettre en évidence des aspects importants de la conception. Diagrammes d'interaction en particulier. Heck, incorporer n'importe quel dessin utilisateur pourrait rendre les choses plus claires.

Une autre idée consiste à incorporer des commentaires de révisions de code directement dans le code.

Il pourrait y avoir toutes sortes d’aides pour faciliter la fusion de plusieurs branches.

Ce qui me passionne, ce n’est pas seulement le suivi de la couverture de code, mais aussi les parties de code couvertes par un test automatisé. La partie difficile est de garder une trace de ce code, même si la source est modifiée. Par exemple, déplacer une fonction d'un fichier à un autre, etc. Cela peut être fait avec des GUID, mais il est plutôt compliqué de les intégrer directement dans le fichier texte. Dans un format de fichier riche, ils pourraient être automatiques et discrets.

Alors, pourquoi n'y a-t-il pas d'IDE (à ma connaissance, en tout cas) qui vous permettent de travailler avec du code de cette manière?

MODIFIER: le 7 octobre 2009.

La plupart d’entre vous sont très attachés au mot & "; binaire &"; dans ma question. Je le rétracte. Picture XML, très peu de marquage de votre code. Dès l'instant où vous le transmettez à votre préprocesseur ou à votre compilateur normal, vous supprimez tout le balisage XML et ne transmettez que le code source. Sous cette forme, vous pouvez toujours effectuer toutes les tâches habituelles dans le fichier: diff, fusionner, éditer, travailler dans un éditeur simple et minimal, les alimenter dans des milliers d'outils. Oui, le diff, la fusion et l'édition, directement avec le balisage XML minimal, deviennent un peu plus compliqués. Mais je pense que la valeur pourrait être énorme.

S'il existait un environnement de développement respectant l'intégralité du code XML, vous pourriez en ajouter bien plus que ce que nous pouvons faire aujourd'hui.

Par exemple, vos commentaires DOxygen pourraient en réalité ressembler à la sortie finale de DOxygen.

Lorsque quelqu'un souhaitait procéder à une révision du code, tel que Code Collaborator, il pouvait marquer le code source à la place.

Le code XML pourrait même être caché derrière des commentaires.

// <comment author="mcruikshank" date="2009-10-07">
// Please refactor to Delegate.
// </comment>

Ensuite, si vous souhaitez utiliser vi ou emacs, vous pouvez simplement ignorer les commentaires.

Si je veux utiliser un éditeur à la pointe de la technologie, je peux le voir de près d'une douzaine de façons utiles.

Donc, c'est mon idée approximative. Ce ne sont pas & "; Blocs de construction &"; des images que vous faites glisser sur l'écran ... Je ne suis pas si crade. :)

La solution

vous pouvez les différencier
vous pouvez les fusionner
n'importe qui peut les éditer
ils sont simples et faciles à utiliser
ils sont universellement accessibles à des milliers d'outils

Autres conseils

À mon avis, tous les avantages possibles sont compensés par le fait d'être lié à un outil particulier.

Avec une source en texte brut (cela semble être ce dont vous parlez, plutôt que des fichiers plats en tant que tels), je peux coller des fragments dans un courrier électronique, utiliser des systèmes de contrôle de version simples (très important! ), écrivez du code dans les commentaires sur Stack Overflow, utilisez l’un des mille éditeurs de texte disponibles sur un nombre quelconque de plates-formes, etc.

Avec une représentation binaire du code, je dois utiliser un éditeur spécialisé pour le visualiser ou le modifier. Même si une représentation textuelle peut être produite, vous ne pouvez pas trivialement annuler des modifications dans la version canonique.

Smalltalk est un environnement basé sur des images. Vous ne travaillez plus avec du code dans un fichier sur le disque. Vous travaillez avec et modifiez les objets réels au moment de l'exécution. C'est toujours du texte mais les classes ne sont pas stockées dans des fichiers lisibles par l'homme. Au lieu de cela, toute la mémoire de l'objet (l'image) est stockée dans un fichier au format binaire.

Mais le plus gros reproche que font ceux qui essaient de smalltalk est qu’il n’utilise pas de fichiers. La plupart des outils basés sur des fichiers que nous avons (outils vim, emacs, eclipse, vs.net, unix) devront être abandonnés au profit des outils propres à smalltalk. Non pas que les outils fournis en smalltalk soient inférieurs. C'est juste différent.

Pourquoi les essais sont-ils écrits en texte? Pourquoi les documents légaux sont-ils écrits en texte? Pourquoi les romans fantastiques sont-ils écrits en texte? Parce que le texte est la meilleure forme - pour les personnes - de persister dans leurs pensées.

Le texte indique comment les gens pensent, représentent, comprennent et persistent les concepts - ainsi que leurs complexités, leurs hiérarchies et leurs interrelations.

Les programmes Lisp ne sont pas des fichiers plats. Ils sont la sérialisation des structures de données. Ce code en tant que données est une vieille idée et en fait une des plus grandes idées en informatique.

<? xml version = " 1.0 " encoding = " UTF-8 "? > < code > Les fichiers plats sont plus faciles à lire. < / code > ; < / xml >

Voici pourquoi:

Lisible par l'homme. Cela rend beaucoup plus facile de repérer une erreur, à la fois dans le fichier et dans la méthode d'analyse. Peut également être lu à voix haute. C’est un problème que vous ne pouvez tout simplement pas obtenir avec XML et qui pourrait faire une différence, en particulier dans le support client.
Assurance contre l'obsolescence. Tant que les expressions rationnelles existent, il est possible d'écrire un très bon analyseur en seulement quelques lignes de code.
Effet de levier. Presque tout ce qui existe, des systèmes de contrôle de révision aux filtres en passant par les éditeurs, peut inspecter, fusionner et utiliser des fichiers plats. La fusion de XML peut être un désordre.
Possibilité de les intégrer assez facilement aux outils UNIX, tels que grep, cut ou sed.

C'est une bonne question. FWIW, j'aimerais voir un outil de gestion de code de style wiki. Chaque unité fonctionnelle aurait sa propre page wiki. Les outils de compilation rassemblent le code source hors du wiki. Il y aurait un & Quot; discuter & Quot; une page liée à cette page, où les gens peuvent discuter des algorithmes, des API et autres.

Heck, il ne serait pas si difficile d'en pirater une depuis une implémentation Wiki préexistante. Des preneurs ...?

Ironiquement, il existe des constructions de programmation qui utilisent précisément ce que vous décrivez.

Par exemple, SQL Server Integration Services, qui implique le codage du flux logique en faisant glisser des composants dans une aire de conception visuelle, est enregistré en tant que fichiers XML décrivant précisément ce back-end.

D'autre part, SSIS est assez difficile à contrôler à la source. Il est également assez difficile d’y intégrer une quelconque logique complexe: si vous avez besoin d’un peu plus de & "Contrôle &", Vous devez coder du code VB.NET dans le composant, ce qui apporte nous retour à l'endroit où nous avons commencé.

Je suppose qu’en tant que codeur, vous devez tenir compte du fait que chaque solution à un problème entraîne des conséquences. Tout ne pourrait pas (et certains ne le diraient pas) devrait être représenté dans UML. Tout ne pouvait pas être représenté visuellement. Tout ne peut pas être suffisamment simplifié pour avoir une représentation de fichier binaire cohérente.

Cela étant dit, je dirais que les inconvénients de la relégation du code dans des formats binaires (dont la plupart ont également tendance à être propriétaires) surpassent de loin les avantages de les avoir en texte brut.

Les formats IMHO, XML et binaires seraient un désordre total et ne procureraient aucun avantage significatif.

OTOH, une idée connexe serait d’écrire dans une base de données, peut-être une fonction par enregistrement, ou peut-être une structure hiérarchique. Un IDE créé autour de ce concept pourrait rendre la navigation dans les sources plus naturelle et masquer tout ce qui n’était pas pertinent pour le code lu à un moment donné.

Les gens ont essayé pendant longtemps de créer un environnement d'édition qui dépasse le fichier plat et tout le monde a échoué dans une certaine mesure. Le plus proche que j'ai vu était un prototype de la programmation intentionnelle de Charles Simonyi, mais il a ensuite été réduit à un outil de création visuelle DSL.

Peu importe la façon dont le code est stocké ou représenté en mémoire, il doit au final pouvoir être présenté et modifiable sous forme de texte ( sans modifier la mise en forme sur vous ), car c'est la manière la plus simple de connaître exprimer la plupart des concepts abstraits nécessaires à la résolution de problèmes par programmation.

Avec les fichiers plats, vous recevez ceci gratuitement et tout ancien éditeur de texte (avec le support de codage de caractères correct) fonctionnera.

Steve McConnell a raison, comme toujours - vous écrivez des programmes pour d’autres programmeurs (y compris vous-même), pas pour des ordinateurs.

Cela dit, Microsoft Visual Studio doit gérer en interne le code que vous écrivez dans un format très structuré, sinon vous ne pourriez pas faire des choses telles que " Find All References " ou renommer ou re-factoriser les variables et les méthodes si facilement. Je serais intéressé si quelqu'un avait des liens sur la façon dont cela fonctionne.

En fait, il y a environ 10 ans, le premier prototype de programmation intentionnelle de Charles Simonyi avait tenté de dépasser le fichier plat en une représentation arborescente du code, qui pouvait être visualisée de différentes manières. Théoriquement, un expert de domaine, un responsable de projet et un ingénieur en logiciel pourraient tous voir (et assembler) le code de l'application d'une manière qui leur serait utile, et les produits pourraient être construits sur une hiérarchie d'intentions & Quotatives & Déclaratives. quot ;, creuser dans le code de bas niveau uniquement si nécessaire.

ETA (selon la demande dans les questions) Il existe une copie de une de ses premiers articles sur le site Web de Microsoft. Malheureusement, depuis que Simonyi a quitté MS pour créer une société distincte il y a plusieurs années, je ne pense pas que le prototype puisse encore être téléchargé. J’ai vu des démos quand j’étais chez Microsoft, mais je ne sais pas dans quelle mesure son premier prototype a été distribué.

Sa société, IntentSoft , n'a toujours pas révélé ce qu'elle envisage de commercialiser. , si ce n’est pas le cas, mais certains des premiers éléments de MSR étaient assez intéressants.

Le modèle de stockage était un format binaire, mais je ne sais pas combien de ces détails ont été divulgués pendant le projet MSR, et je suis sûr que certaines choses ont changé depuis les premières mises en œuvre.

Pourquoi les fichiers texte sont-ils réglés? A cause du test de McIlroy. Il est essentiel que la sortie d’un programme soit acceptable en tant que code source d’un autre, et que les fichiers texte sont la méthode la plus simple qui fonctionne.

Labview et Simulink sont deux environnements de programmation graphiques. Ils sont tous deux populaires dans leurs domaines respectifs (interface avec le matériel à partir d’un PC et systèmes de contrôle de modélisation, respectivement), mais ils ne sont pas beaucoup utilisés en dehors de ces domaines. J'ai travaillé avec des personnes qui étaient de grands fans des deux, mais je ne les ai jamais abordées moi-même.

Vous dites que nous devrions utiliser & "; une certaine forme de XML &"; Que pensez-vous que XHTML et XAML sont?

De plus, XML n’est encore qu’un fichier plat.

Les vieilles habitudes ont la vie dure, je suppose.

Jusqu'à récemment, il n'y avait pas beaucoup de bibliothèques de grande qualité, performantes et performantes pour le stockage général de données structurées. Et je voudrais catégoriquement ne pas mettre XML dans cette catégorie, même aujourd’hui - trop détaillé, trop intensif pour être traité, trop complexe.

De nos jours, ce que je préfère utiliser pour les données qui ne nécessitent pas d'être lisibles par l'homme est SQLite et crée une base de données. Il est si incroyablement facile d'intégrer une base de données SQL complète dans n'importe quelle application ... il existe des liaisons pour C, Perl, Python, PHP, etc., et il est open source et très rapide, fiable et léger.

I < 3 SQLite.

Quiconque a déjà essayé Mathematica ?

La photo ci-dessus est issue d’une ancienne version, mais c’est le meilleur que Google puisse me donner.

Quoi qu'il en soit ... comparez la première équation à Math.Integrate (1 / (Math.Pow (& "; x &"; 3) -1), & "; x ") comme vous auriez à écrire si vous codiez avec du texte brut dans la plupart des langues courantes. Imo la représentation mathématique est beaucoup plus facile à lire, et c'est encore une assez petite équation.

Et oui, vous pouvez saisir et copier-coller le code en texte brut si vous le souhaitez.

Considérez cela comme la coloration syntaxique de la prochaine génération . Je parie qu'il y a beaucoup d'autres choses que les mathématiques qui pourraient tirer profit de ce genre de représentation.

Il est assez évident pourquoi le texte brut est roi. Mais pourquoi un format structuré serait-il encore meilleur?

Juste un exemple: si vous renommez une méthode, votre outil de contrôle de diff / merge / source sera capable de dire qu’une seule chose a changé. Les outils que nous utilisons aujourd'hui affichent une longue liste de modifications, une pour chaque lieu et fichier que la méthode a été appelée ou déclarée.

(Au fait, cet article ne répond pas à la question, comme vous l'avez peut-être remarqué)

La tendance que nous constatons au sujet des DSL est la première chose qui vient à l’esprit lors de la lecture de votre question. Le problème est qu’il n’existe pas de relation un-à-un entre les modèles (comme UML) et une implémentation. Microsoft, entre autres, s’efforce d’y parvenir afin que vous puissiez créer votre application comme un objet de type UML, puis générer du code. Et l’important: si vous choisissez de modifier votre code, le modèle le reflétera à nouveau.

Windows Workflow Foundation est un très bon exemple. Bien qu’il y ait des fichiers plats et / ou XML en arrière-plan, vous définissez généralement votre logique métier dans l’outil d’orchestration. Et c'est plutôt cool!

Nous avons besoin de plus de " usines de logiciels " penser, et verra une expérience plus riche IDE à l'avenir, mais tant que les ordinateurs fonctionnent sur des zéros et des uns, les fichiers de texte plats peuvent et (probablement) seront toujours une étape intermédiaire. Comme indiqué précédemment par plusieurs personnes, les fichiers texte simples sont très flexibles.

Je me suis demandé avec nostalgie la même chose, comme décrit dans la réponse à: Quel outil / application / quel que soit ce que vous souhaitiez exister?

S'il est facile d'imaginer un grand nombre d'avantages, je pense que le plus gros obstacle à surmonter est que personne n'a produit d'alternative viable.

Lorsque les utilisateurs envisagent des solutions de rechange au stockage de la source sous forme de texte, ils semblent souvent immédiatement penser en termes de représentation graphique (je fais ici référence aux produits commerciaux disponibles - par exemple, HP-vee). Et si nous examinons l’expérience de personnes telles que les concepteurs de FPGA, nous constatons que la programmation (exclusivement) graphique ne fonctionne tout simplement pas - d’où des langages comme Verilog et VHDL.

Mais je ne pense pas que le stockage de la source doive nécessairement être lié à la méthode d’écriture. La saisie de la source peut être en grande partie réalisée sous forme de texte - ce qui signifie que les problèmes de copier / coller peuvent toujours être résolus. Mais je vois aussi qu'en autorisant les fusions et les restaurations sur la base de méta-sources symbolisées, nous pourrions obtenir des outils de manipulation plus précis et plus puissants.

Visual FoxPro utilise des structures de table dbf pour stocker le code et les métadonnées de formulaires, de rapports, de bibliothèques de classes, etc. Il s’agit de fichiers binaires. Il stocke également le code dans les fichiers prg que les fichiers texte réels ...

Le seul avantage que je vois, c’est de pouvoir utiliser le langage de données VFP intégré pour effectuer des recherches de code sur ces fichiers ... à part cela, c’est une responsabilité imo. Au moins une fois tous les quelques mois, l’un de ces fichiers sera corrompu sans raison apparente. L'intégration avec le contrôle de source et les différences est également très douloureuse. Il existe des solutions pour cela, mais il faut convertir le fichier en texte temporairement!

Pour un exemple de langage qui supprime la programmation de texte traditionnelle, voir Lava Langue .

Une autre chose intéressante que je viens de découvrir récemment est sous-texte2 ( démo vidéo ).

Le code de votre programme définit la structure qui serait créée avec XML ou le format binaire. Votre langage de programmation est une représentation plus directe de la structure de votre programme qu'une représentation XML ou binaire. Avez-vous déjà remarqué à quel point Word se comporte mal lorsque vous structurez votre document? WordPerfect, au moins, "révélerait des codes" pour vous permettre de voir ce qui se cache sous votre document. Les fichiers plats font la même chose pour votre programme.

Idée soignée. Je me suis moi-même demandé à une plus petite échelle… beaucoup plus petite, pourquoi IDE X ne peut-il pas générer ceci ou cela?

Je ne sais pas si je suis encore capable, en tant que programmeur, de développer quelque chose d'aussi cool et complexe que ce dont vous parlez ou ce à quoi je pense, mais cela m'intéresserait d'essayer.

Peut-être commencer avec des plugins pour .NET, Eclipse, Netbeans, etc.? Montrez ce qui peut être fait et démarrez une nouvelle tendance en matière de codage.

Je pense qu'un autre aspect de ceci est que le code est ce qui est important. C'est ce qui va être exécuté. Par exemple, dans votre exemple UML, je penserais plutôt que d'avoir UML (vraisemblablement créé dans un éditeur, pas directement lié au & "Code &") Inclus dans votre & "Source blob source < !> quot; serait presque inutile. Il serait bien mieux d’avoir le fichier UML généré directement à partir de votre code. Il décrit donc l’état exact du code en tant qu’outil permettant de comprendre le code, plutôt que de rappeler ce qu’il aurait dû être.

Nous le faisons depuis des années en ce qui concerne les outils de documentation automatisés. Alors que les commentaires générés par le programmeur dans le code peuvent ne pas être synchronisés avec le code, des outils tels que JavaDoc et autres représentent fidèlement les méthodes sur un objet, les types de retour, les arguments, etc. Ils les représentent tels quels, et non comme artefact qui est sorti de réunions de conception sans fin.

Il me semble que si vous pouviez ajouter arbitrairement des artefacts aléatoires à un & "blob source &", ils seraient probablement obsolètes et inutiles. Si vous pouvez générer de tels artefacts directement à partir du code, le petit effort nécessaire pour que votre processus de génération le fasse est bien meilleur que les pièges mentionnés précédemment, consistant à s'éloigner des fichiers source en texte brut.

Dans le même ordre d'idées, une une explication de pourquoi 'voudrait utiliser un outil UML en texte brut ( UMLGraph ) semble s'appliquer presque également ainsi que la raison pour laquelle vous voulez des fichiers sources en texte brut.

Cela pourrait ne pas répondre exactement à votre question, mais voici un éditeur qui permet d’avoir une vue plus haute du code: http://webpages.charter.net/edreamleo/front.html

Je pense que la raison pour laquelle les fichiers texte sont utilisés dans le développement est qu’ils sont universels par rapport à divers outils de développement. Vous pouvez regarder à l'intérieur ou même corriger certaines erreurs en utilisant un simple éditeur de texte (vous ne pouvez pas le faire dans un fichier binaire car vous ne savez jamais comment un correctif détruirait d'autres données). Cela ne signifie toutefois pas que les fichiers texte conviennent mieux à toutes ces tâches.

Bien sûr, vous pouvez les différencier et les fusionner. Mais cela ne signifie pas que l'outil diff / fusion comprend la structure distincte des données encodées par ce fichier texte. Vous pouvez faire la diff / fusion, mais (surtout dans les fichiers XML), l’outil diff ne vous montrera pas correctement les différences, c’est-à-dire qu’il vous montrera où les fichiers diffèrent et quelles parties des données l’outil & "pense &"; sont identiques. Mais il ne vous montrera pas les différences dans la structure du fichier XML - il ne fera que faire correspondre les lignes qui se ressemblent.

Que nous utilisions des fichiers binaires ou des fichiers texte, il est toujours préférable que les outils diff / merge prennent en charge la structure de données représentée par ce fichier plutôt que les lignes et les caractères. Pour les fichiers C ++ ou Java, par exemple, indiquez que certains identificateurs ont changé de nom, indiquez que certaines sections étaient entourées de if () {} supplémentaire, tout en ignorant les modifications des retraits ou des caractères EOL. La meilleure approche serait qu'un fichier soit lu dans des structures internes et vidé en utilisant des règles de format spécifiques. De cette manière, les différences seront effectuées via les structures internes et le résultat de la fusion sera généré à partir de la structure interne fusionnée.

Les programmes modernes sont composés de pièces plates, mais sont-ils plats? Il y a des utilisations, des inclusions, des bibliothèques d'objets, etc. Un appel de fonction ordinaire est un coup d'œil dans un endroit différent. La logique n’est pas plate, car il y a plusieurs threads, etc.

J'ai la même vision! Je souhaite vraiment que cela existe.

Vous voudrez peut-être jeter un œil à Fortress, un langage de recherche de Sun. Il a un support spécial pour les formules dans le code source. La citation ci-dessous provient de Wikipedia

Fortress est conçu à partir du début d'avoir plusieurs syntaxique feuilles de style. Le code source peut être rendu sous forme de texte ASCII, en Unicode ou comme une image soignée. Cela permettra pour le support des symboles mathématiques et d'autres symboles dans le rendu sortie pour une lecture plus facile.

La principale raison de la persistance du texte en tant que source est l'absence d'outils puissants, comme le contrôle de version, pour les dates non textuelles. Ceci est basé sur mon expérience de travail avec Smalltalk, où le code à octets simple est conservé dans un core-dump tout le temps. Dans un système non textuel, avec les outils actuels, le développement d'équipe est un cauchemar.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow