Re: anti-pattern NIH

Donc, j'ai choisi la solution la plus facile et la plus rapide, à savoir de placer ces fichiers dans le dépôt.

La plus facile pour toi, et la plus rapide pour toi. Le problèmes que tu évoques est exactement celui résolu par les autotools ou autre framework du genre. Sans avoir à mettre des fichiers générées dans le VCS.

Le reste, ce n'est que l'adaptation aux particularités des différentes plateformes sur lequel il peut être lancé. Qu'est-ce qui sort donc de l'ordinaire, et par quoi peut-on le remplacer qui soit plus conforme aux standards en la matière ?

Tu pourrais simplement l'omettre si tu utilisais un des framework cités. Comme ça, queluqu'un d'autre que toi n'aurait pas à se former à ton outil. Tu trouveras ça inutile, mais c'est ce que je te disais plus haut : les solutions que nous t'évoquons sont utiles pour tout le monde, pas que pour toi.

J'ai l'impression que tu penses que mes Makefile sont plus sophistiqués qu'ils ne le sont réellement. Mes scripts de générations prennent en compte juste la nature du binaire à générer (exécutable ou bibliothèque) et la liste des fichiers sources. C'est tout. Pas de dépendances à gérer (il y a CEF maintenant, mais c'est une exception, et cela ne concerne qu'un seul Makefile). A nature de binaire identique, la seul chose qui change d'un Makefile à l'autre, c'est le tout début, qui contient la liste des fichiers source. Tout le reste est identique.

Si, d'aventure, j'avais effectivement fait le choix d'utiliser autotools et/ou consorts, au lieu de placer les Makefile générés dans le VCS, et bien j'y aurais placé les fichiers 'source' d'autotools et consorts, qui auraient également été générés, à l'instar des Makefile. Donc, cela n'aurait fait que déplacer le problème, si problème il y a, avec, en outre, une complexification induite par l'utilisation d'autotools et/ou consorts.

La principale différence avec XSL (mis à part que XPP n'est de loin pas aussi puissant que XSL), c'est que les directives XSL doivent être placées dans un fichier disjoint de celui qui contient le XML sur lequel on va appliquer ces directives, alors que les directives XPP, quant à elles, sont directement placées dans les fichiers XML sur lesquels elles portent.

Comme les feuilles de style « intégrées » (traduction pourrie de "embedded") ? https://www.w3.org/TR/xslt#section-Embedding-Stylesheets
Tu ne t'intéresses juste pas à ce qui existe, et c'est ce qui dérange un peu ici, je pense.

Je ne connaissais pas. J'ai un peu regardé, pas beaucoup, car il semble que ce ne soit implémenté que dans les navigateurs. Or, j'ai besoin, d'une part, de pouvoir utiliser ce mécanisme dans mes propres logiciels (pour l'appliquer sur les fichiers de configuration de mes logiciels), et, d'autre part, de pouvoir mettre ce mécanisme en œuvre via un utilitaire en ligne de commande. Mes deux utilitaires (sablotron et xsltprocess) ne semblent pas l'implémenter, et je n'ai pas trouvé d'utilitaire ou de bibliothèque qui implémente ce mécanisme. Donc, aujourd'hui, connaissant l'existence des embedded stylesheet, si j'étais confrontés aux même besoins que ceux qui m'ont poussés à développer XPP, je serais obligé de faire le même choix qu'à l'époque, à savoir développer ma propre solution.

Ceci dit, je n'ai jamais écrit que je ne m’intéressais pas aux solutions alternatives, mais que je n'utilisais pas ces solutions (forcément, puisque j’utilise mes alternatives), et c'est bien ce dernier point qui dérange. Comme déjà évoqué, si je ne m'étais pas intéressé à ce qui existe, je n’utiliserais pas XML, mais mon propre langage de balisage...

Utiliser gettext aurait impliqué un travail de codage supplémentaire, que j'économise avec le système que j'utilise.

Travail économisé une fois pour toi. Travail qui sera à fournir pour chaque personne qui souhaite s'intéresser à ce travail. C'est donc complètement inintéressant en terme de temps pour quiconque d'essayer de contribuer ou de s'intéresser à ton travail.

Je l'ai développée pour répondre aux besoins d'un client. Ce dernier devait pouvoir stocker des dates classiques, mais aussi approximatives.

Ah, intéressant, je n'avais pas vu cette fonctionnalité.

Ta réaction à bibliothèque DTE est typiquement celle que je ne comprends pas. Parce certains ne voient pas l'utilité de réimplémenter une telle bibliothèque, ces derniers décrètent que c'est une erreur, sans chercher à comprendre les motivations derrières.

Le problème c'est que je ne vais pas chercher des heures à comprendre ce que fait ta bibliothèque si j'ai l'impression qu'elle ne m'apporte rien. Pas de description, etc, je laisse tomber. Alors encore, si elle s'intégrait bien à l'existant, et que c'était utilisable en dehors de tout ton framework, pourquoi pas, mais je n'ai pas l'impression : tout semble très imbriqué, du coup je n'ai même pas espoir que cette fonctionnalité intéressante puisse être utilisée ailleurs. (déjà je fais du C, donc c'est niet)

Je comprends tout à fait que tu ne veuilles pas te plonger dans le code de cette bibliothèque (j'aurais la même réaction à ta place), mais alors, pourquoi ne pas me laisser le bénéfice du doute, c'est-à-dire de considérer que, peut-être, après tout, j'avais de bonnes raisons d'implémenter cette bibliothèque, au lieu de considérer d'office que c'était une erreur ?

on ne comprend pas, donc, au lieu d'approfondir, ou de demander des éclaircissement au développeur si l'on a pas envie de se plonger dans le code (ce que je comprends tout à fait), on se répand en généralités sans rapports pour discréditer le framework en question.

Essaye de penser que tu n'es pas au centre du monde : malheureusement, ton « standard » n'est pas le standard, et c'est en général plutôt à toi de t'adapter aux autres que l'inverse.

Et je ne dis pas ça pour t'embêter, mais juste pour que tu remettes les pieds sur terre et te rende compte que personne ne s'intéressera à ton travail si tu le présente et le développe ainsi. Ce n'est peut-être pas ce que tu cherches, mais tu disais vouloir au moins avoir des retours, et je t'explique pourquoi je pense que tu n'en auras pas.

Je ne comprend pas le rapport de ta réponse avec l'extrait de mon intervention que tu cites. Encore une fois, je n'ai jamais demandé à qui que ce soit de s’intéresser à mon framewok. Tu dis que j'ai demandé des retours ; je ne m'en souviens pas, et je ne vais pas relire l'ensemble des commentaires de ce journal, donc je vais supposer que c'est vrai, mais, ça serait, à priori, vu ce que j'avais à l'esprit en rédigeant ce journal, au sujet des particularités du logiciel, pas de la manière dont elles sont implémentées. Je pense qu'il est préférable d'avoir un bon logiciel, fût-il réalisé avec des solution non-standards, qu'un logiciel inutilisable, fût-il réalisé avec des solutions standards...

je n'aurais pas développé ce framework si je pouvais développer aussi vite et aussi bien avec d'autres outils.

Tu sais, tout programmeur a un jour pensé à faire ça. Puis on a appris le principe de « standard » : ça n'est pas toujours parfait, ça ne fait pas exactement ce qu'on veut, mais c'est ce qui permet de travailler en commun. Avec ta méthode, désolé mais tu travailleras toujours tout seul.

Peut-être pas, si c'est mes solutions qui deviennent les standards :-). Mais, je le concède, c'est mal parti, d'autant plus que ce n'est pas mon but à ce jour.

Et, en fait, le problème avec les standards, outre, qu'effectivement, cela ne permet pas toujours de réaliser ce que l'on veut, c'est surtout, et c'est bien plus grave, que cela ne permet pas toujours de réaliser ce que le client veut.

Quel est le problème de travailler seul ? Les clients ne se sont jamais plaints de mes délais (une fois qu'ils ont assimilé qu'on ne peut pas leur livrer le produit pour avant-hier), et j'ai toujours pu intégrer mes développements à l'environnement de production du client, quel qu'il soit.

De manière générale, les clients veulent un logiciel vite et bien fait. Que ce logiciel soit réalisé par une seule personne ou par plusieurs, (généralement, moins il y a de personnes impliquées, moins c'est cher, donc ils préfèrent), en utilisant ou non des solutions standards (je parle là des solutions de développement, pas des formats de fichiers), généralement peu leur chaut.

Bon courage quand même dans ta voie

Merci !

---

Développer un logiciel n'est pas trivial. Pour cette raison, la majorité des développeurs utilise les solutions qu'ils considèrent (à tord ou à raison) les plus faciles à utiliser. Pour beaucoup, apparemment, notamment au vu des commentaires ici, il s'agit des solutions 'standards'. Bien que, moi aussi, j'utilise certaines solutions standards (XML est peut-être décrié, mais c'est néanmoins un standard ; ce n'est pas une de mes inventions), il se trouve que j'ai été amené à développer mes propres solutions parce que celles existantes ne me convenaient pas. Comme toi et certains des intervenants ici n'ont pas manqués de le souligner, c'est une démarche rare. Cependant, elle n'est pas unique. Et heureusement, sinon l'écosystème informatique serait bien pauvre. Toutes les solutions considérées comme 'standards' aujourd'hui ne l'ont pas été à leurs débuts, et se sont certainement vu opposer les 'standards' de l'époque. Heureusement, cela n'a pas découragé les concepteurs de ces solutions, sinon elles ne seraient pas considérées comme les 'standards' d'aujourd'hui...

Contrairement à ce que certains pensent ici, et je me demande bien sur quel base, je n'essaie pas de promouvoir mon framewok. Je ne fais que présenter quelques logiciels que je développe, à l'instar de celui présenté dans ce journal, qui ont comme particularité d'être tous basés sur mon framework (c'est simplement un fait technique), ce qui fait qu'ils ont certains points communs (manière de gérer les traductions, les arguments de la ligne de commande, possibilité de placer des directives XPP dans les fichiers de configuration...) qui les distinguent des autres logiciels. Mon but premier est de produire des logiciels qui satisfassent ses utilisateur (et, parmi ces utilisateurs, le plus exigeant de tous : moi) , et mon framework est un outil essentiel pour parvenir à ce but. Si, parmi ces utilisateurs, il y a des développeurs qui estiment que certaines particularités de ces logiciels, et donc, par conséquent, du framework sur lequel ils sont basés, sont suffisamment intéressantes pour contrebalancer le fait qu'il ne s’appuie pas sur des solutions 'standards', alors peut-être que, de concert, on pourra mettre en place les éléments qui lui permettront de gagner en popularité. Ou pas.

Zelbinium: pour la génération qui crée, pas celle qui scrolle...