Je ne sais pas où tu as pris cet exemple, mais il est obsolète.
ici : gmic.eu/reference/managing_3d_vector_objects.html
Dans les exemples pour utiliser les object 3D pour faire du rendu 2D (ce qui a l'air d'être une feature assez énorme en fait).
mais juste efficace et concis (ce dernier point n'étant pas forcément toujours compatible avec la clarté de lecture de code).
On est d'accord la dessus.
Le langage G'MIC est un langage métier, très différent des langages "classiques" généralistes. Il a été imaginé pour créer des pipelines potentiellement complexes de traitement d'images, pas pour initier des gens à la programmation.
"Clean code" n'a rien à voir avec le fait d'apprendre à programmer mais sur la maintenance sur le long terme de code potentiellement énorme ou complexe, et pour la transmission de connaissance entre développeurs.
sed et imagemagick
Ils sont aussi ignoble à lire, ce n'est pas une raison de faire pareil. L'auteur de Perl n'a jamais compris que sa feature la plus populaire soit la moins lisible (les regexp, des "Modem Line Noise" pour certain).
J'imagine qu'on pourrait trouver plein d'autres exemples, avec l'utilisation de langages métiers très spécialisés dans leur domaine.
Oui, je connais la hype des DSL. Pour en avoir subi plusieurs, c'est surtout des mauvais langages de programmation incomplet qui pourraient se remplacer avec des appels de fonctions dans n'importe quel langage avec bien plus de souplesse (cela ressemble aussi au débat metamodèle vs bibliothèques).
le SQL, j'ai jamais réussi à comprendre des requêtes de plus de deux lignes.
Moi, j'en ai écrit de plusieurs centaines de lignes, et je confirme que c'est un langage ignoble mais puissant, mais ignoble.
Mais je dirais que dans notre projet, on veut permettre surtout à des utilisateurs d'accéder facilement à des ensembles de filtres et de traitements d'images, plutôt que de rallier des développeurs à l'utilisation du langage G'MIC.
On ne vise pas majoritairement le public des développeurs.
C'est dommage la lib nn semble avoir un potentiel énorme. Rendre un code lisible diminue l'intéret d'une documentation. J'imagine qu'il doit être parfaitement possible d'avoir les mêmes concepts que le code actuel et d'avoir une syntaxe plus "littérale" et avoir un convertisseur d'une syntaxe dans l'autre.
[^] # Re: La syntaxe...
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de G'MIC 3.0 : Une troisième dose pour un traitement efficace de vos images !. Évalué à 5.
Dans les exemples pour utiliser les object 3D pour faire du rendu 2D (ce qui a l'air d'être une feature assez énorme en fait).
On est d'accord la dessus.
"Clean code" n'a rien à voir avec le fait d'apprendre à programmer mais sur la maintenance sur le long terme de code potentiellement énorme ou complexe, et pour la transmission de connaissance entre développeurs.
Ils sont aussi ignoble à lire, ce n'est pas une raison de faire pareil. L'auteur de Perl n'a jamais compris que sa feature la plus populaire soit la moins lisible (les regexp, des "Modem Line Noise" pour certain).
Oui, je connais la hype des DSL. Pour en avoir subi plusieurs, c'est surtout des mauvais langages de programmation incomplet qui pourraient se remplacer avec des appels de fonctions dans n'importe quel langage avec bien plus de souplesse (cela ressemble aussi au débat metamodèle vs bibliothèques).
Moi, j'en ai écrit de plusieurs centaines de lignes, et je confirme que c'est un langage ignoble mais puissant, mais ignoble.
C'est dommage la lib nn semble avoir un potentiel énorme. Rendre un code lisible diminue l'intéret d'une documentation. J'imagine qu'il doit être parfaitement possible d'avoir les mêmes concepts que le code actuel et d'avoir une syntaxe plus "littérale" et avoir un convertisseur d'une syntaxe dans l'autre.
"La première sécurité est la liberté"