Parfois il vaut mieux être un peu moins efficace (parce qu'on doit faire des copier-coller lorsqu'on crée une nouvelle classe, ce qui arrive une fois tous 36 du mois) tout le temps que bloquer tout pendant des années pour être un peu plus efficace dans quelques années.
Avec vos histoires d'écritures rapides, je pense qu'il est possible que vous passiez à côté du véritable intérêt de l'abstraction et de l'expressivité d'un langage moderne : la relecture de code.
En effet, en programmation, on passe une grosse partie du temps (la plus grosse ?) à relire du code (pour le comprendre ou le comprendre à nouveau) plutôt qu'à en écrire. C'est pour ça que je préfère m'intéresser à des langages qui permettent une meilleure lisibilité plutôt que ceux qui me facilitent la vie pour l'écriture. Quand les deux sont là, c'est encore mieux.
Je suis originellement un programmeur C, et si à une époque, j'ai pu louer les mérites d'une lib comme GTK (car elle permet par exemple de façon assez élégante de faire un peu polymorphisme), je pense que j'aurais maintenant pas mal de difficultés à "rentrer" dans une IHM écrite en C depuis que je connais autre chose. A une époque, j'étais très branché Qt qui a l'avantage de se concentrer sur une sous-partie de C++, maintenant, je pense en particulier aux langages fonctionnels comme Elm.
Si je comprends bien, le projet GIMP vit sa vie à son rythme et n'a pas nécessairement un besoin prégnant de drainer une marée de développeurs mais lorsqu'on se trouve dans une situation où l'attractivité du projet est centrale, les outils et les langages deviennent stratégiques.
[^] # Re: Paradoxe
Posté par Guillaume Denry (site web personnel) . En réponse à la dépêche Entretien avec Michael Natterer, mainteneur de GIMP. Évalué à 8. Dernière modification le 09 mars 2017 à 08:22.
Avec vos histoires d'écritures rapides, je pense qu'il est possible que vous passiez à côté du véritable intérêt de l'abstraction et de l'expressivité d'un langage moderne : la relecture de code.
En effet, en programmation, on passe une grosse partie du temps (la plus grosse ?) à relire du code (pour le comprendre ou le comprendre à nouveau) plutôt qu'à en écrire. C'est pour ça que je préfère m'intéresser à des langages qui permettent une meilleure lisibilité plutôt que ceux qui me facilitent la vie pour l'écriture. Quand les deux sont là, c'est encore mieux.
Je suis originellement un programmeur C, et si à une époque, j'ai pu louer les mérites d'une lib comme GTK (car elle permet par exemple de façon assez élégante de faire un peu polymorphisme), je pense que j'aurais maintenant pas mal de difficultés à "rentrer" dans une IHM écrite en C depuis que je connais autre chose. A une époque, j'étais très branché Qt qui a l'avantage de se concentrer sur une sous-partie de C++, maintenant, je pense en particulier aux langages fonctionnels comme Elm.
Si je comprends bien, le projet GIMP vit sa vie à son rythme et n'a pas nécessairement un besoin prégnant de drainer une marée de développeurs mais lorsqu'on se trouve dans une situation où l'attractivité du projet est centrale, les outils et les langages deviennent stratégiques.