Je reviens de quelques jours de vacances, donc je suis un peu en retard sur le sujet, néanmoins je voudrais faire quelques commentaires :
- Premièrement, j'ai effectivement écrit cet article dans le cadre d'un journal, pas d'une dépêche, d'où le ton un peu plus libre qui est utilisé. Je tiens à préciser que je n'ai pas été sollicité pour faire une version 'dépêche' de ce journal, ni même était prévenu du passage en dépêche. Ca s'est fait en tout cas, je découvre ça aujourd'hui. Je ne critique pas : si je ne voulais pas qu'on réutilise ma prose pour alimenter le site LinuxFR, je n'aurais pas posté un journal sur ce site à la base.
- Secundo, je n'ai jamais dit que GIL c'était nul, bien au contraire. J'ai juste souligné que ce n'était pas facile d'accès. Et ça, je crois pas que tu puisses prétendre le contraire. Comme tu le dis toi-même, il y a des tas de concepts à connaitre pour comprendre et utiliser correctement GIL. Je vais peut-être t'étonner, mais la plupart des spécialistes en TI (que je connais du moins) non seulement se foutent royalement de connaitre ces concepts, mais même s'ils le voulaient, ils n'ont même pas forcément l'expérience nécessaire de 15 ans qu'il faut pour les maitriser en C++.
Alors GIL, c'est bien joli, mais quand je vois le code qu'il faut pondre pour calculer un simple gradient (http://stlab.adobe.com/gil/html/giltutorial.html#ExampleSec)(...) je doute qu'à part les programmeurs de chez Adobe, il y ait beaucoup de monde intéressé pour élaborer des algos génériques non triviaux pouvant se mettre dans GIL.
- Troisièmement, tu m'as l'air d'être le type même de gens dont je dénonce les pensées uniques, quand tu dis :
Voilà, c'est tout. Il faut juste comprendre comment la programmation à base de concepts fonctionne, qui est d'ailleurs la manière recommandée de programmer en C++... (mais bon, peu de personnes la connaissent vraiment, en fait, et tout le temps rejette ce qu'on ne comprend pas)
Typiquement, vous oubliez que la force du C++ c'est justement qu'il est multi-carte, et que c'est un langage qui n'enferme pas le programmeur dans un style de programmation. C'est bien pour ça que ça a un tel succès d'ailleurs. Oui, tu peux faire de la programmation basée concept, ou pas, utiliser des templates, ou pas, etc... Il serait dangeureux de croire qu'il n'y a qu'un style unique permettant de faire du "bon" C++. Regarde juste la diversité des concepts derrière les bibliothèques de traitement d'images en C++ : Entre ITK, VIGRA, GIL, CImg, OLENA, et j'en passe, que de différences !! Et heureusement ! Tout le monde peut s'y retrouver, et choisir la bibliothèque qui convient le mieux à son profil de programmation. Ce qui est important, c'est d'avoir des ponts possibles entre les bibliothèques, c'est tout.
Clairement, CImg a opté pour une certaine facilité d'utilisation. Ce n'est pas ce qui motive les gens derrière GIL. CImg est pratique pour faire du prototypage rapide d'algorithme. Ce n'est pas le cas de GIL. GIL a pleins de qualités mais dans d'autres domaines (grande généricité "potentielle", intégration dans du code existant, etc..)
C'est à l'utilisateur de faire son choix, et CImg participe à élargir le panels d'outils disponibles.
[^] # Re: Commentaire personel
Posté par David Tschumperlé (site web personnel) . En réponse à la dépêche Sortie de CImg 1.3.0. Évalué à 2.
- Premièrement, j'ai effectivement écrit cet article dans le cadre d'un journal, pas d'une dépêche, d'où le ton un peu plus libre qui est utilisé. Je tiens à préciser que je n'ai pas été sollicité pour faire une version 'dépêche' de ce journal, ni même était prévenu du passage en dépêche. Ca s'est fait en tout cas, je découvre ça aujourd'hui. Je ne critique pas : si je ne voulais pas qu'on réutilise ma prose pour alimenter le site LinuxFR, je n'aurais pas posté un journal sur ce site à la base.
- Secundo, je n'ai jamais dit que GIL c'était nul, bien au contraire. J'ai juste souligné que ce n'était pas facile d'accès. Et ça, je crois pas que tu puisses prétendre le contraire. Comme tu le dis toi-même, il y a des tas de concepts à connaitre pour comprendre et utiliser correctement GIL. Je vais peut-être t'étonner, mais la plupart des spécialistes en TI (que je connais du moins) non seulement se foutent royalement de connaitre ces concepts, mais même s'ils le voulaient, ils n'ont même pas forcément l'expérience nécessaire de 15 ans qu'il faut pour les maitriser en C++.
Alors GIL, c'est bien joli, mais quand je vois le code qu'il faut pondre pour calculer un simple gradient (http://stlab.adobe.com/gil/html/giltutorial.html#ExampleSec)(...) je doute qu'à part les programmeurs de chez Adobe, il y ait beaucoup de monde intéressé pour élaborer des algos génériques non triviaux pouvant se mettre dans GIL.
- Troisièmement, tu m'as l'air d'être le type même de gens dont je dénonce les pensées uniques, quand tu dis :
Voilà, c'est tout. Il faut juste comprendre comment la programmation à base de concepts fonctionne, qui est d'ailleurs la manière recommandée de programmer en C++... (mais bon, peu de personnes la connaissent vraiment, en fait, et tout le temps rejette ce qu'on ne comprend pas)
Typiquement, vous oubliez que la force du C++ c'est justement qu'il est multi-carte, et que c'est un langage qui n'enferme pas le programmeur dans un style de programmation. C'est bien pour ça que ça a un tel succès d'ailleurs. Oui, tu peux faire de la programmation basée concept, ou pas, utiliser des templates, ou pas, etc... Il serait dangeureux de croire qu'il n'y a qu'un style unique permettant de faire du "bon" C++. Regarde juste la diversité des concepts derrière les bibliothèques de traitement d'images en C++ : Entre ITK, VIGRA, GIL, CImg, OLENA, et j'en passe, que de différences !! Et heureusement ! Tout le monde peut s'y retrouver, et choisir la bibliothèque qui convient le mieux à son profil de programmation. Ce qui est important, c'est d'avoir des ponts possibles entre les bibliothèques, c'est tout.
Clairement, CImg a opté pour une certaine facilité d'utilisation. Ce n'est pas ce qui motive les gens derrière GIL. CImg est pratique pour faire du prototypage rapide d'algorithme. Ce n'est pas le cas de GIL. GIL a pleins de qualités mais dans d'autres domaines (grande généricité "potentielle", intégration dans du code existant, etc..)
C'est à l'utilisateur de faire son choix, et CImg participe à élargir le panels d'outils disponibles.
David.