C'est bien d'être têtu - ceci dit sans aucune référence aux préférences sexuelles de quiconque, mais ça devient agaçant à la longue.
La phrase précédente nous apprend que les développeurs ont fait le même programme sous NeXTstep et leur "système" précédent.
Le ton général de ces quelques lignes est à la gloire de NeXTstep, dont le nom est cité (au moins sous la forme de "NeXT") 4 fois en 6 lignes. 3 fois sur 4 pour dire que "c'est mieux avec NeXT".
Alors, sans doute, pour respecter vraiment la forme, aurait-il mieux valu écrire explicitement l'élément de comparaison, ajouter une cinquième fois NeXT(step), puis refaire mention du "système précédent" qui est l'élément auquel on le compare.
Mais franchement, à part les gens tâtillons ou de mauvaise foi, qui irait blâmer l'auteur de l'enquête (que Nicolas Roard ne fait que citer, a priori) de ne pas avoir alourdi son "bilan" de la sorte?
Ensuite, je passe une bonne partie de mon temps depuis quelques mois à pondre (sans prétention) des applications avec interface graphique en Java (Swing mon amour, je sais, sapusaipalibre mais ce n'est pas moi qui choisis) sous emacs et Eclipse, et j'ai regardé la petite vidéo de démo de NeXTstep.
Je trouve sympa la rapidité avec laquelle on peut développer une application graphique comme c'est montré. Il faut voir à l'usage comment ça rend pour des applications plus complexes, avec un vrai MVC derrière (i.e. avec un vrai modèle...).
Il faut également comparer ça aux outils de développement du même type (si j'ai bien compris le fonctionnement de cette partie de Gorm) qui existent comme Bean Builder pour Java.
Or les Beans sont très "à la mode", parce que ça permet de développer plus vite. (Plus vite que quoi? Je te laisse deviner, mais ça parle de réinventer la roue et de taper encore une fois les mêmes bouts de code que d'habitude...)
Nier le fait que le développement d'applications à base de composants fait gagner du temps, c'est un sacré défi.
Alors oui, par rapport à Eclipse + Bean Builder (ou l'environnement de développement Delphi qui permet il me semble ce genre de choses), on ne gagne peut-être pas de temps.
Mais ça reste un gain de temps par rapport à la programmation "à l'ancienne" qui est encore la majorité des cas.
Montrer aux gens qu'ils peuvent développer rapidement et facilement avec NeXTstep, comme ils pourraient le faire avec d'autres logiciels pour d'autres langages et avec d'autres contraintes (notamment de liberté, cf. le Java de Sun avec Swing) ce n'est pas inutile.
Y a-t-il un équivalent vraiment libre à ce que propose NeXTstep?
(C'est une vraie question ouverte, tous éléments de réponse bienvenus...)
En tout cas, NeXTstep a le mérite d'exister sur ce créneau, et c'est tant mieux.
(Pour la peine, j'y donnerai peut-être un galop d'essai un de ces quatre.)
[^] # C'est pas si compliqué pourtant...
Posté par kwikwi . En réponse à la dépêche Sortie de la distribution GNUSTEP 0.9.4, GNUstep news, et vidéo. Évalué à 6.
La phrase précédente nous apprend que les développeurs ont fait le même programme sous NeXTstep et leur "système" précédent.
Le ton général de ces quelques lignes est à la gloire de NeXTstep, dont le nom est cité (au moins sous la forme de "NeXT") 4 fois en 6 lignes. 3 fois sur 4 pour dire que "c'est mieux avec NeXT".
Alors, sans doute, pour respecter vraiment la forme, aurait-il mieux valu écrire explicitement l'élément de comparaison, ajouter une cinquième fois NeXT(step), puis refaire mention du "système précédent" qui est l'élément auquel on le compare.
Mais franchement, à part les gens tâtillons ou de mauvaise foi, qui irait blâmer l'auteur de l'enquête (que Nicolas Roard ne fait que citer, a priori) de ne pas avoir alourdi son "bilan" de la sorte?
Ensuite, je passe une bonne partie de mon temps depuis quelques mois à pondre (sans prétention) des applications avec interface graphique en Java (Swing mon amour, je sais, sapusaipalibre mais ce n'est pas moi qui choisis) sous emacs et Eclipse, et j'ai regardé la petite vidéo de démo de NeXTstep.
Je trouve sympa la rapidité avec laquelle on peut développer une application graphique comme c'est montré. Il faut voir à l'usage comment ça rend pour des applications plus complexes, avec un vrai MVC derrière (i.e. avec un vrai modèle...).
Il faut également comparer ça aux outils de développement du même type (si j'ai bien compris le fonctionnement de cette partie de Gorm) qui existent comme Bean Builder pour Java.
Or les Beans sont très "à la mode", parce que ça permet de développer plus vite. (Plus vite que quoi? Je te laisse deviner, mais ça parle de réinventer la roue et de taper encore une fois les mêmes bouts de code que d'habitude...)
Nier le fait que le développement d'applications à base de composants fait gagner du temps, c'est un sacré défi.
Alors oui, par rapport à Eclipse + Bean Builder (ou l'environnement de développement Delphi qui permet il me semble ce genre de choses), on ne gagne peut-être pas de temps.
Mais ça reste un gain de temps par rapport à la programmation "à l'ancienne" qui est encore la majorité des cas.
Montrer aux gens qu'ils peuvent développer rapidement et facilement avec NeXTstep, comme ils pourraient le faire avec d'autres logiciels pour d'autres langages et avec d'autres contraintes (notamment de liberté, cf. le Java de Sun avec Swing) ce n'est pas inutile.
Y a-t-il un équivalent vraiment libre à ce que propose NeXTstep?
(C'est une vraie question ouverte, tous éléments de réponse bienvenus...)
En tout cas, NeXTstep a le mérite d'exister sur ce créneau, et c'est tant mieux.
(Pour la peine, j'y donnerai peut-être un galop d'essai un de ces quatre.)