Je suis le projet depuis longtemps, je l'ai utilisé à l'époque où c'était encore un énorme .h de 6 Mo.
Non, G'MIC n'a jamais été un gros .h de 6 Mo. Tu veux parler de CImg peut-être ? Ce n'est pas du tout le même projet.
C'est une "A quite naive way of doing" an histogramme. Qui comprend ce que fait le code d'un coup d'oeil ?!
Je ne sais pas où tu as pris cet exemple, mais il est obsolète.
Aujourd'hui, on l'écrirait de manière équivalente, plutôt comme ça :
my_histogram :
256 eval.. ++i[#-1,i]
Tu vas me dire que ce n'est pas tellement plus clair. Et je serai d'accord.
Mais il faut bien comprendre que le but du langage G'MIC n'a jamais été d'être lisible, mais juste efficace et concis (ce dernier point n'étant pas forcément toujours compatible avec la clarté de lecture de code).
En encore, ce "problème" se pose si, en tant que développeur, tu souhaites implémenter tes propres algorithmes de traitement personnalisés en langage G'MIC. Ca concerne au final assez peu de monde.
Si, en tant qu'utilisateur de gmic en ligne de commande, tu souhaites juste utiliser les algorithmes existants, alors tu vas écrire des pipelines de commandes, beaucoup plus simples (pour l'exemple de l'histogramme ci-dessus, il faudrait juste utiliser la commande histogram :) ).
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.
C'est un peu comme si tu me disais que la syntaxe de sed n'est pas lisible pour le traitement des chaines de caractères : c'est vrai, c'est pas lisible, mais c'est concis et efficace. Et c'est utilisé par des milliers (millions) de personnes.
Par ailleurs, si tu regardes du côté de la "concurrence" (ImageMagick), c'est exactement pareil (voir les exemples d'utilisation sur leur site : https://legacy.imagemagick.org/Usage/thumbnails/ ). Illisible pour le néophyte.
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. Tiens au hasard, le SQL, j'ai jamais réussi à comprendre des requêtes de plus de deux lignes. C'est normal, c'est comme tout, il faudrait juste s'y mettre (mais je n'en ai jamais eu besoin pour ma part).
Pour ceux qui auraient besoin de se mettre au langage G'MIC, on a des pages de référence et de tutoriels pour cela. Quelques développeurs s'y sont mis et proposent aujourd'hui des filtres personnalisés pour G'MIC.
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.
[^] # Re: La syntaxe...
Posté par David Tschumperlé (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é à 7.
Non, G'MIC n'a jamais été un gros
.hde 6 Mo. Tu veux parler de CImg peut-être ? Ce n'est pas du tout le même projet.Je ne sais pas où tu as pris cet exemple, mais il est obsolète.
Aujourd'hui, on l'écrirait de manière équivalente, plutôt comme ça :
my_histogram :
256 eval.. ++i[#-1,i]
Tu vas me dire que ce n'est pas tellement plus clair. Et je serai d'accord.
Mais il faut bien comprendre que le but du langage G'MIC n'a jamais été d'être lisible, mais juste efficace et concis (ce dernier point n'étant pas forcément toujours compatible avec la clarté de lecture de code).
En encore, ce "problème" se pose si, en tant que développeur, tu souhaites implémenter tes propres algorithmes de traitement personnalisés en langage G'MIC. Ca concerne au final assez peu de monde.
Si, en tant qu'utilisateur de
gmicen ligne de commande, tu souhaites juste utiliser les algorithmes existants, alors tu vas écrire des pipelines de commandes, beaucoup plus simples (pour l'exemple de l'histogramme ci-dessus, il faudrait juste utiliser la commandehistogram:) ).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.
C'est un peu comme si tu me disais que la syntaxe de
sedn'est pas lisible pour le traitement des chaines de caractères : c'est vrai, c'est pas lisible, mais c'est concis et efficace. Et c'est utilisé par des milliers (millions) de personnes.Par ailleurs, si tu regardes du côté de la "concurrence" (ImageMagick), c'est exactement pareil (voir les exemples d'utilisation sur leur site : https://legacy.imagemagick.org/Usage/thumbnails/ ). Illisible pour le néophyte.
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. Tiens au hasard, le SQL, j'ai jamais réussi à comprendre des requêtes de plus de deux lignes. C'est normal, c'est comme tout, il faudrait juste s'y mettre (mais je n'en ai jamais eu besoin pour ma part).
Pour ceux qui auraient besoin de se mettre au langage G'MIC, on a des pages de référence et de tutoriels pour cela. Quelques développeurs s'y sont mis et proposent aujourd'hui des filtres personnalisés pour G'MIC.
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.