CodeWorker 4.4

Posté par  (site Web personnel) . Modéré par j.
Étiquettes :
0
25
nov.
2007
Technologie
CodeWorker est un outil d'automatisation du développement, sous GNU LGPL. Cet outil se propose d'être un générateur de code universel, capable non seulement de générer du code, mais de générer celui-ci en l'injectant dans du code existant.

Cordeworker se matérialise comme un interpréteur d'un langage de script intégrant la possibilité de définir une grammaire BNF du langage à parser ou du source cible dans lequel on veut injecter du code. La génération se décrit à l'aide de modèles de génération (template-based scripts), décrivant le remplissage d'un graphe de parsing pendant l'analyse. Ce graphe pourra ensuite être manipulé.

Sa force réside dans sa souplesse totale : on peut lui faire lire un source en C++ ainsi que des information en XML, pour injecter du code dans du Java. Partant de là, et de grammaire BNF decrivant XML, Java, etc... on peut imaginer toutes sortes d'outils. Notons le mode JEdit prenant en charge la coloration syntaxique pour CodeWorker.

CodeWorker est donc un outil puissant, stable, qui a sûrement besoin de contributions comme des scripts pour analyser toutes sortes de langages et ainsi permettre de nombreuses manipulations ! Le langage de script est un petit langage adapté à la manipulation de graphe.

La définition de variable est assez simple et non typée :

local nombre = 26.7;
local chaine = "vingt six virgule sept";
local booleen = (nombres == chaines);

local dictionnaire;
insert dictionnaire["Requin"] = "Petit poisson marinant dans l'huile";
insert dictionnaire[3.141592] = "Premiers chiffres de Pi";

local jouet;
insert jouet.categorie = "voiture";
insert jouet.alimentation = "piles";
insert jouet.alimentation.quantite = 4;
insert jouet.alimentation.taille = "LR6";
insert jouet.nombrepiece["aileron"] = 1;


La syntaxe, se veut proche des standard C/Java avec une teinte langage de script sans typage.

local especeAnimale;
insert especeAnimale["Mireille"] = "abeille";
insert especeAnimale["Camille"] = "chenille";

function traiteespeceAnimale(esp : node) {
foreach i in esp {
if first(i) {
traceLine("premier élément = '" + i.key() + "'");
} else if last(i) {
traceLine("dernier élément = '" + i.key() + "'");
}
traceLine("clé = '" + key(i) + "' valeur = '" + i + "'");
}
return false;
}


esp : node signifie passage par référence, le comportement par défaut étant de passer par valeur.


Le grand intérêt de ce langage est de permettre de définir une grammaire BNF pour récupérer des données :

nombre ::= #ignore(blanks) flottant | entier;
entier ::= ['-']? ['0'..'9']+;
flottant ::= entier '.' entier ['e' entier]?;
identifiant ::= [lettre | '_'] [lettre | '0'..'9' | '_']*;
lettre ::= 'a'..'z' | 'A'..'Z';

l'intérêt étant ensuite de pouvoir définir des règles de générations :

flottant ::=
#!ignore
entier '.' #continue !'-' entier
[
'e' #continue
entier:iExposant
=> traceLine("valeur de l'exposant = " + iExposant);
]?

Des manipulations beaucoup plus complexes sont décrites dans le tutoriel disponible sur le site Developpez.com

Aller plus loin

  • # Parser du C++

    Posté par  . Évalué à 8.

    Parser du C++ n'est pas trivial. En particulier, la syntaxe n'est pas LALR et l'analyse sémantique doit se faire en même temps.
    Je doute qu'un tel outil en soit capable, étant donné que même le fameux Doxygen n'a qu'un parser C++ approximatif.
    • [^] # Re: Parser du C++

      Posté par  . Évalué à 5.

      g++ le fait, pourquoi codeworker ne le ferait pas ? au pire il faut regarder comment les createurs de g++ ont fait, libre powa ! \o/ Tout ca pour dire qu'avec le temps et la motivation, c'est faisable, et que donc je ne vois pas pourquoi ils n'en seraient pas capables...

      et doxygen a t'il reellement besoin d'un parser exact ?
    • [^] # Re: Parser du C++

      Posté par  (site Web personnel) . Évalué à 5.

      Effectivement, d'après http://en.wikipedia.org/wiki/C%2B%2B :

      It is relatively difficult to write a good C++ parser with classic parsing algorithms such as LALR(1).[5] This is partly because the C++ grammar is not LALR. Because of this, there are very few tools for analyzing or performing non-trivial transformations (e.g., refactoring) of existing code. One way to handle this difficulty is to choose a different syntax, such as Significantly Prettier and Easier C++ Syntax, which is LALR(1) parsable. More powerful parsers, such as GLR parsers, can be substantially simpler (though slower).


      Mais je crois que la parseur est assez flexible, savoir s'il l'est assez je ne sais pas.
      Mais il faut noter que ce parseur prend directement une grammaire écrite en BNF, et non une suite de règles à la lex/yacc.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Parser du C++

        Posté par  . Évalué à 7.

        En fait dans le cadre du refactoring, la plus grosse difficulté n'est pas tant le fait que la grammaire ne soit pas LALR, mais le préprocesseur.

        La seule chose pour laquelle on peut avoir une grammaire fiable, c'est après le passage du préprocesseur. Avant, c'est virtuellement n'importe quoi.

        C'est pour cela par exemple que les outils de traitement de source pagayent souvent avec du C++.
        • [^] # Re: Parser du C++

          Posté par  . Évalué à 1.

          Et encore, c'est pas si simple.

          Prenons l'expression suivante :
          A<b> c;

          Si A identifie un template, alors c'est une instanciation de template.
          Sinon, c'est une comparaison.
  • # ...

    Posté par  . Évalué à 10.

    CodeWorker est donc un outil puissant, stable, qui a surement besoin de contributions comme des scripts pour parser toute sortes de langages et ainsi permettre de nombreuses manipulations !
    C'est bien beau, mais j'ai du mal à voir des applications pratiques.

    L'article aurait pu cité des exemples concret d'utilisation.
    • [^] # Re: ...

      Posté par  . Évalué à 6.

      C'est un travers courant de certains techniciens : définir un outil en décrivant comment il est constitué plutôt que sa finalité. Effectivement ça donne quelque chose qui ressemble beaucoup à de la masturbation intellectuelle (injecter du C++ dans du Java, dit l'article... heu quel intérêt ?).
      • [^] # Re: ...

        Posté par  . Évalué à 4.

        Les applications peuvent être multiples.

        Cela peut permettre de développer son propre compilateur pour un DSL (Domain Specific Language, exemple de DSL le plus probant est le SQL). Autre exemple la documentation en HTML de codeworker est générer avec Codeworker, de même qu'une grqnde parie de codeworker est coder avec codeworker (Car il dispose aussi d'un langage de script).
        Ensuite en sortie d'un BNF tu peut avoir un AST que tu peux manipuler a loisir. Par exemple tu peux parser du C analyser l'arbre pour générer du C optimisé ;).
    • [^] # Re: ...

      Posté par  (site Web personnel) . Évalué à 1.

      Un peu d'imagination !

      On peut faire plein de chose, par exemple : http://www.codegeneration.net/tiki-index.php?page=InlineCode(...)
      ce qui revient à une super macro

      On peut l'utiliser pour faire de la coloration syntaxique pour toute sorte de langage que l'on veut traduire en html coloré, pour des besoins de documentations.

      On peut aussi l'utiliser pour faire de la génération de code à partir d'un langage décrivant le modèle de classe.

      On peut modifier le modèle de classe en le rafraichissant, tout en respectant le code source contenu à l'intérieur.

      Générer une grammaire BNF à partir d'une DTD.

      Générer un source pour graphviz à partir d'un source Java/C++/Python, etc...

      On peut imaginer plein d'applications avec cette outil, car son langage de script permet de gérer autant d'entrée et de sortie qu'on désir.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: ...

        Posté par  . Évalué à 4.

        Un autre exemple les éléves de 3éme année d'Epitech on un projet majeur dans leur année, qui est de créer un compilateur d'un language orienté objet nomé KOOC, qui transforme du KOOC en C. Ils apprenent ainsi le fonctionnement interne d'un langage Objet (ex: les phases de construction/destruction des objets, le dynamic binding ou le static binding, le mangling (ok ce n'est que valable pour les langages orientés objets)).

        Enfin bon il y a que l'imagination qui peut limiter son utilitée.
        • [^] # Re: ...

          Posté par  . Évalué à 5.

          le mangling (ok ce n'est que valable pour les langages orientés objets)

          AMHA la plupart des langages objets n'ont que faire du "mangling". Idem pour la notion de "static binding" qui est propre à C++. Bref ça commence plutôt mal pour "le fonctionnement interne d'un langage Objet"...
          • [^] # Re: ...

            Posté par  . Évalué à -2.

            Essais d'un langage parser orienter objet puis de le généré en C de faire de l'a surcharge de méthode sans mangling.
            • [^] # Re: ...

              Posté par  (site Web personnel) . Évalué à 2.

              La surcharge n'est pas un concept orienté objet (*), c'est une émulation boiteuse du multiple dispatch de CLOS, quand on cherche à faire du static binding (* CQFD).
              • [^] # Re: ...

                Posté par  . Évalué à 2.

                Certe c'est plus une feature d'un langage. N'empéche qu'on leur demande cette feature :). Il y a toujours des moyens de le faire sans mangling c'est sur mais la décoration reste le plus simple.
                • [^] # Re: ...

                  Posté par  . Évalué à 2.

                  pourquoi vous ne leur demandez pas de compiler directement en ASM ? nous c'est ce qu'on nous a demandé en 2A pour le projet de compil, et ca permet de voir d'autres problematiques en plus de celles données ici, sauf le mangling certes mais bon, c'est pas le plus important je pense.
            • [^] # Re: ...

              Posté par  . Évalué à 2.

              Essais d'un langage parser orienter objet puis de le généré en C de faire de l'a surcharge de méthode sans mangling.

              Vu la grammaire je ne suis pas sûr de bien comprendre la phrase, mais pas besoin de mangling pour écrire un interpréteur ou compilateur de langage objet (voir par exemple la VM de CPython). Tu voulais dire probablement faire une traduction en C de concepts objets, ce qui est évidemment une vision très particulière de la question.
              • [^] # Re: ...

                Posté par  . Évalué à 1.

                Tu voulais dire probablement faire une traduction en C de concepts objets, ce qui est évidemment une vision très particulière de la question


                C'est exactement ce que je voulais dire désolé je me suis peut être mal exprimé et un peut trop dans la hâte.
      • [^] # Re: ...

        Posté par  . Évalué à 1.

        Sans vouloir fermer la porte à toute innovation, en général, un truc qui affirme permettre de faire tout et n'importe quoi est à peu près aussi convaincant qu'un truc qui ne fait rien. En gros, tu nous proposes une machine de Turing, chouette :-)
        • [^] # Re: ...

          Posté par  . Évalué à 1.

          Le but reste toujours la génération bien sur.
          • [^] # Re: ...

            Posté par  . Évalué à 1.

            Mais aussi le parsing (désolé pour le flood)
        • [^] # Re: ...

          Posté par  . Évalué à 2.

          Avec du C tu peut faire tout et n'importe quoi que ce soit un noyau, un compilatuer ou le dernier client msn.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Meta-object protocol?

    Posté par  (site Web personnel) . Évalué à 4.

    Toute cette machinerie de parsing, de templates et de manipulation d'AST illustre bien que tout ça fonctionne à un mauvais niveau de représentation des données : celui de la syntaxe au lieu du modèle métier. Quelle est l'avantage de CodeWorker par rapport aux parsers habituels (yacc, antlr, packrat…) ?

    D'ailleurs il existe un outil de ce genre appelé Ometa, inspiré d'un autre qui date des années 70 : http://www.cs.ucla.edu/~awarth/ometa/
    Voir aussi une implémentation de brainf*ck avec Ometa, pour illustrer le bidule : http://www.swa.hpi.uni-potsdam.de/tutorials/cola/index.html

    Sinon pour la manipulation de programmes qui semble l'utilité première de CodeWorker, rien ne vaut un langage réflexif. En Smallltalk pour rajouter programmatiquement une variable d'instance à une classe on fait Foo addInstVarName: 'baz'. Pour ajouter une méthode à une classe :

    String compile: 'pan ^ self = ''coin'' ifTrue: [''argh''] ifFalse: [''mm po mal'']'

    Et baste, le code est visible dans l'IDE, compilé et committable. Si il y a besoin de faire des traitements plus compliqués l'arbre syntaxique abstrait est dispo, et c'est le même que les refactorings et le compilateur manipulent. En Lisp c'est pareil (voire plus puissant) mais je laisse les experts préciser.
    • [^] # Re: Meta-object protocol?

      Posté par  . Évalué à 1.

      Toute cette machinerie de parsing, de templates et de manipulation d'AST illustre bien que tout ça fonctionne à un mauvais niveau de représentation des données : celui de la syntaxe au lieu du modèle métier.

      La je comprend pas tout tu peux expliquer un peut?
      • [^] # Re: Meta-object protocol?

        Posté par  . Évalué à 5.

        Une façon d'illustrer cette phrase est d'essayer de séparer dans sa tête le "que fait t'on?" et le "comment le fait on?". Le modèle métier est le "que fait t'on" et le code (la syntaxe) est le "comment fait on".

        Notre boulot d'informaticien est de transformer le "quoi" en "comment", et il en résulte le code, qui tout en représentant le quoi, il ne l'est pas vraiment. Ce qui est un problème, parce que la seule et unique chose qui nous intéresse vraiment c'est le "quoi" : le "comment", finalement n'est qu'une machinerie technique.

        Donc ce que Damien veut dire, c'est qu'on essaie d'extraire le quoi du comment (le métier a partir de la syntaxe), et il a parfaitement raison de dire que c'est une approche imparfaite : le code n'est pas fait pour représenter ce qu'on veut faire, mais uniquement comment on le fait.

        Le souci est d'essayer d'élever le modèle métier a un niveau d'abstraction au plus près de la conception "humaine", c'est a dire, de l'épurer au maximum du "bruit" causé par les problématiques informatiques : le code, le "comment c'est fait". Le tout doit permettre de transformer ce modèle métier en code, autant que possible. (sinon on fait de l'UML au autre qui sert a rien mis a part faire aide mémoire et joli sur le paper board).

        Pour compléter je suis tenté de faire un comparaison avec un code en un langage tel le C (qui serait le métier), et sont "image" assembleur (qui serait donc le code), de ce même code compilé. Les deux font la même chose, le même "comment", pourtant il est très difficile d'extraire le "quoi" du code assembleur, on a perdu de l'information précieuse sur le modèle d'origine, qui est dans la tête du développeur.
        • [^] # Re: Meta-object protocol?

          Posté par  (site Web personnel) . Évalué à 3.

          humm… presque ;-)

          Modèle métier = les données et ce qu'on en fait, au niveau d'abstraction idéal (un dessin)

          Syntaxe = la représentation, l'encodage de ces données sous un format précis, adapté au stockage/transport ou autre mais pas au manipulations "métier" (une suite d'octets en PNG)

          Et si, le code est fait pour représenter ce qu'on veut faire. Le tout est d'avoir un langage de prog qui te force pas à explique comment à tout bout de champ. Même en Smalltalk:


          "comment"
          1 to: collection size do: [ :i | (collection at: i) faisCeciCela ]

          "quoi"
          collection do: [ :each | each faisCeciCela ]
          • [^] # Re: Meta-object protocol?

            Posté par  (site Web personnel) . Évalué à 1.

            Mouais... Le principe de séparer le code en fonctions appelable consiste à rendre le code déclaratif à certain endroits.

            Le type Block de smalltalk/ruby/lisaac permet de faire plus de chose, mais il n'en reste pas moins que la sémantique opérationnelle, ie. effet de bord sur des données en mémoire, reste une sémantique du comment faire.

            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

            • [^] # Re: Meta-object protocol?

              Posté par  (site Web personnel) . Évalué à 1.

              Oui bien sûr, mais tant que le "comment faire" est rangé dans les bonnes couches d'abstraction c'est pas trop grave.
              Je voulais surtout faire remarquer que le code, idéalement, c'est lisible. Ce n'est pas une sorte de produit "sale" pour donner aux machines, comme le binaire :-)
              • [^] # Re: Meta-object protocol?

                Posté par  . Évalué à -1.

                Ce n'est pas une sorte de produit "sale" pour donner aux machines, comme le binaire :-)


                Ce code "sale" tu en as forcement besoin un moment ou un autre ;)
      • [^] # Re: Meta-object protocol?

        Posté par  (site Web personnel) . Évalué à 3.

        Je bosse en Smalltalk depuis deux ans. En Smalltalk, l'un des grands trucs c'est que tous les objets sont persistants par défaut. Donc en général on ne sérialise ni on ne parse jamais rien, et on n'utilise que très rarement des fichiers.
        Si tu veux garder des des données il suffit de mettre les objets en question dans une variable, soit globale, soit d'instance de classe (par exemple l'équivalent du database.yml de ruby on rails, c'est un objet "connexionSpec" avec database/host/port/user/password en variables d'instances).

        Donc si on a besoin d'accéder à des données, suffit de taper dans l'API des objets en question. Si l'API convient pas ou que pour raisons algorithmiques il faut vraiment réorganiser les données, pas besoin de parser, pas besoin de générer du code, il y a juste à créer la nouvelle structure de données à partir de l'originale.

        Avec l'habitude on en vient à trouver ça pénible quand il faut manipuler des fichiers, parce que un fichier c'est comme une chaine, c'est plat, amorphe et ça sait rien faire d'intéressant (alors que mon connectionSpec je peux lui demander de devenir actif et il va me répondre d'autres objets qui représentent les tables etc)
        • [^] # Re: Meta-object protocol?

          Posté par  . Évalué à 1.

          C'est pas lourd en mémoire ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Meta-object protocol?

            Posté par  (site Web personnel) . Évalué à 1.

            Pourquoi ça le serait ? Les objets individuels ne prennent pas plus de place que dans les autres langages.

            Si tu veux un ordre d'idées, une image Squeak de base prend une vingtaine de Mo. Et là dedans il y a le code de tout l'environnement, compilateur, débogueur, interface graphique, gestionnaire de versions, etc soit un peu plus de 2000 classes, 45000 méthodes, et 670000 objets en tout). Qui est chiche de lancer eclipse et compter ? :-)
        • [^] # Re: Meta-object protocol?

          Posté par  . Évalué à 1.

          En fait je n'utilise Codeworker que pour faire des compilateurs.

          Quoiqu'il arrive quelque soit le langage il faudra un moment ou un autre le parser un flux, vérifier son lexique, vérifier sa syntaxe, vérifier sa sémantique puis soit générer quelque chose soit l'interpréter.

          Et je ne vois pas pourquoi dans ce cas précis, on est a un mauvais niveau de représentation de donnée.
          • [^] # Re: Meta-object protocol?

            Posté par  (site Web personnel) . Évalué à 1.

            Dans ce cas, non (le compilo Smalltalk lit des chaines et produit du bytecode, tout pareil). C'est le "métier" d'un compilo de transformer du code d'une représentation à une autre.
        • [^] # Re: Meta-object protocol?

          Posté par  . Évalué à 1.

          Mouai la sérialisation 'par défaut' c'est pas forcément une idée géniale: dans Eros ils avaient ça comme fonctionnalité et ils en sont revenus..
          Le problème c'est quand tu fais évoluer ton code, si tu n'as pas conçu les snapshot 'version N' et version 'N+1', passer d'une version à l'autre peut devenir un cauchemar..
          • [^] # Re: Meta-object protocol?

            Posté par  (site Web personnel) . Évalué à 1.

            Il n'y a pas de sérialisation, l'image est juste un snapshot de la mémoire après un full GC. Si tu ajoutes une variable d'instance, tous les objets concernés sont mis à jour (évidemment pour les objets qui se font mettre à jour, la nouvelle variable d'instance est vide donc ça peut poser problème is on ne fait rien).
        • [^] # Re: Meta-object protocol?

          Posté par  . Évalué à 1.

          Rien à voir, mais je peux savoir dans quelle société on a encore la chance de faire du smalltalk ?
          • [^] # Re: Meta-object protocol?

            Posté par  (site Web personnel) . Évalué à 2.

            JP Morgan, UBS je crois bien, et sinon SOOPS à Amsterdam. Je cherche pas de taf dans l'industrie, donc c'est celles que je connais par des contacts académiques.
          • [^] # Re: Meta-object protocol?

            Posté par  (site Web personnel) . Évalué à 1.

            Un ami travaillant pour MMA Assurances par exemple. J'avais eu comme prof un des principaux chef de projet de cette boite, et ils utilisent smalltalk depuis assez longtemps.

            Il nous racontait d'ailleurs que ces développeurs grinçaient des dents lorsqu'il s'agissait de repasser à Java, tellement ils se sentaient étriqués dans ce langage...

            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

            • [^] # Re: Meta-object protocol?

              Posté par  . Évalué à 4.

              J'ai envie de répondre que c'est un peu le cas de tout le monde ayant touché à Java... :-)

              Cela dit, si on sait utiliser l'introspection et la réflexion à bon escient, on peut faire pas mal de choses ... Mais la syntaxe reste assez rigide, elle. :-/
              • [^] # Re: Meta-object protocol?

                Posté par  (site Web personnel) . Évalué à 1.

                trop gros :-)


                Sinon comme boite il y a Heeg en Allemagne, aussi. Voir les sponsors de ESUG: http://www.esug.org/

                Le truc c'est que la plupart des développements sont pour des grosses boites, qui demandent des développements perso et qui n'en font pas la pub puisque c'est des outils internes. Soops par exemple leur truc gère les négociations et échanges d'électricité entre les producteurs européens. Je crois qu'AMD au une usine où les robots de production sont gérés en Smalltalk.

                Bref c'est un peu comme Erlang, il y a des millions de lignes de code dans le monde, mais planquées dans des gros systèmes.
    • [^] # Re: Meta-object protocol?

      Posté par  (site Web personnel) . Évalué à 1.

      Je suis entièrement d'accord avec toi.

      Mais le problème, c'est qu'il y a M. Le client.

      M. Le client, il veut du java/J2EE, parce que c'est la mode et qu'il trouvera très facilement un développeur pour reprendre et faire vivre son application.
      M. Le client, quand il a une appli en C/C++, il veut pas qu'on la recode en autre chose (trop cher), ou qu'on la mixe avec des bouts codés dans un langage mieux (parce que ça tue la cohérence).

      Donc on code avec des langages plus ou moins merdiques...

      C'est sur que si on codait dans un langage à la smalltalk/ruby/lisaac, on aurait beaucoup moins de problèmes, mais dans la vrai vie, on n'utilise pas ces langages là.

      donc on est obligé d'avoir des outils comme CodeWorker...

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: Meta-object protocol?

        Posté par  (site Web personnel) . Évalué à 2.

        Ah sisi on les utilise, je connais des spécimens de Smalltalk Sapiens Industrialis. C'est rare comme bestiole, certes, mais c'est intéressant à côtoyer :-)
  • # Et pour debugger le code généré?

    Posté par  . Évalué à 7.

    Il y a quelque-chose?

    Non parce que c'est toujours le même problème: la génération de code est toujours vendue comme quoi on va beaucoup plus vite pour produire du code, en oubliant commodément de mentionner qu'on va ensuite beaucoup lentement pour debugger le code généré..
    • [^] # Re: Et pour debugger le code généré?

      Posté par  . Évalué à 0.

      Oui et non, lorsque tu débugges tu corriges des problèmes de quelle nature ?

      Erreur de codage ou de conception ?

      S'il s'agit d'erreurs liées à l'utilisation du langage, a priori elles n'existent pas avec un générateur automatique, ou alors le générateur est lui même buggé et c'est un autre problème...

      S'il s'agit d'erreurs de conception, alors il existe une faille dans le processus de conception, et il est dommage de les identifier au niveau du codage. Dans ce cas, avec un générateur automatique, le "débuggage" de niveau conception doit se faire par d'autre outils que le débugger classique, essentiellement par exécution du modèle de conception.

      En gros avec un générateur automatique, il faut renoncer à exploiter le code en tant que tel. La valeur ajoutée se trouve réellement au niveau de la conception.
      • [^] # Re: Et pour debugger le code généré?

        Posté par  . Évalué à 2.

        Mais donc concrètement quand le truc que tu as générer marche pas tu fais quoi ?

        Tu prie que le générateur n'ai pas de bug (c'est connu le soft 100% bug free ca se trouve partout) ?
        • [^] # Re: Et pour debugger le code généré?

          Posté par  (site Web personnel) . Évalué à 2.

          En même temps, les bugs de compilateurs ça se fait remarquer assez vite d'habitude…
          • [^] # Re: Et pour debugger le code généré?

            Posté par  . Évalué à 5.

            En même temps, les bugs de compilateurs ça se fait remarquer assez vite d'habitude…

            Heu... si c'est que le compilateur n'arrive pas à parser une construction légitime ok. Mais s'il génère du code potentiellement incorrect dans certaines circonstances particulières et plutôt rares, ça peut rester longtemps en l'état.
            Le pire, c'est quand tu te retrouves face à un bug pareil : tu peux perdre un bon bout de temps avant d'inspecter le code généré et te rendre compte que c'est le compilateur qui est dans l'erreur (intuitivement on a plutôt tendance à accuser notre propre code).
      • [^] # Re: Et pour debugger le code généré?

        Posté par  . Évalué à 2.

        le "débuggage" de niveau conception doit se faire par d'autre outils que le débugger classique, essentiellement par exécution du modèle de conception

        Oui, au pays des bisounours il y a un "modèle de conception" qu'on peut exécuter à loisir et qui garantit que tout va bien marcher. Dans le monde réel je ne vois pas trop comment exprimer un algorithme non-trivial dans un "modèle de conception", ou alors le "modèle de conception" est une implémentation à part entière de la solution.
        • [^] # Re: Et pour debugger le code généré?

          Posté par  (site Web personnel) . Évalué à 4.

          ou alors le "modèle de conception" est une implémentation à part entière de la solution


          Oui, par exemple une implémentation dans un langage de haut niveau, expressif, flexible… Y'en a même des comme ça qui compilent avec des perfs décentes :-]
        • [^] # Re: Et pour debugger le code généré?

          Posté par  . Évalué à 3.

          C'est effectivement au pays des bisounours, ou du moins dans les livres. Ce que je veux dire c'est que si l'on fait le choix du générateur de code automatique, il faut adapter son processus de développement et les méthode associé.

          Parceque si au final il faut débugger le code généré ça n'a strictement aucun intérêt.

          Personnellement je n'ai jamais réussi à utiliser un générateur de code de façon efficace, et principalement pour les raisons que tu cites. Mais ça n'empêche pas de raisonner sur la méthode. Si l'on envisage jamais d'autres façon de faire il n'y a jamais de progrès. Après il y a des technos qui survivent, d'autres qui restent des vues de l'esprit.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.