En fait j'ai l'impression que ton argument est plus: pq les langage n'offre pas plus de facilité? on est d'accord.
Pas exactement; mon argument était plutôt, certes Corba apporte des trucs sympas, mais en pratique, a-t-on réellement besoin de tout ça ? dans la plupart des cas, non. Utiliser Corba est donc trop lourd pour un intérêt assez limité. Dans ce cas, je trouve qu'utiliser un modèle plus léger est plus efficace et sensé.
Là ou je suis moins d'accord c'est sur le fait de pouvoir utiliser un composant depuis n'importe quel langage: en local c'est déjà assez courant (regarde le nombre de binding c++, python, perl, php, whatever qu'il existe pour des lib c... alors qu'avec un format "standard" on pourrait s'en passer). Mais une fois en remoting, c'est capital il me semble: tu ne peux pas contraindre tout tes projets à être en objective-C! Ce langage est sous doute adapté à certaines choses, mais le sera moins à d'autre, particulièrement en tenant compte de l'existant.
Non, je maintiens ce que je dis : dans un programme donné, il est rare d'avoir plusieurs langages. Les bindings existent, certes, mais sont-ils largement employés? pas tant que ça. Enfin, je ne dit pas du tout qu'utiliser DO est la panacée qui répondra à tous les besoins, simplement que DO est idéal pour utiliser des objets répartis dans ton application, si tu programmes en Objective-C.
Et accessoirement, faire un pont DO <-> Corba ne serait pas si compliqué, vraiment. Personne ne l'a implémenté dans le libre, parce que l'intérêt est honnêtement limité ... mais c'est ce que NeXT avait fait (début des années 90).
Pour synthétiser, intellectuellement, un modèle de composant qui fonctionne avec n'importe quoi, à la Corba, peut être intéressant. Mais en pratique, tu vas utiliser ça dans 1% des cas... il est logique alors de privilégier une solution plus simple -- mais plus efficace. C'est que font GNUstep et KDE. De toute façon, rien n'empêche de réaliser des ponts vers corba si vraiment tu y tient !
Pour le reste, c'est soit des répétions, soit de la mauvaise fois (tu ne connais ni C# ni .NET mais c'est pas une bonne idée...)
Evidemment que je suis un peu de mauvaise foi :-)
mais bon, je n'ai pas dit non plus que je ne connais absolument pas C# ou .Net -- juste que ce que j'en sais ne m'a pas intéressé et donc que je ne m'y suis pas penché plus avant (les journées de 24h, toussa). Mais je n'ai jamais clamé être un expert de C#/.Net donc bien évidemment j'ai pu (du?) rater des choses absoument géniales...
juste pour rajouter: "En tout cas écouter MDI chanter les louanges de la POO et du C# lors du FOSDEM 2003, c'était assez comique (si on est un peu cynique) quand on se souvient que GNOME a été lancé en bonne partie en rejet à C++ ..."
A sa place: objective C, non, trop peu connu, communauté trop "faible". C++: rappelle toi les début de KDE, les difficulté du compilo, le nombre moins important de de développeur et le fait qu'ils se soient basés sur Qt une libre existante comme une base de leur framework (qu'ils ont du changer quelques fois).
Qu'ajouter à ça ? je dit simplement que MDI a surfé sur la vague du C, pour finalement changer d'avis et utiliser un langage OO. Le reproche n'est pas dans le fait qu'il ait changé d'avis, juste que c'était couru d'avance et qu'il aurait du s'en rendre compte. Parce que même moi qui n'aime pas C++, entre programmer en C "objet" et programmer en C++, y'a pas photo -- de toute façon, un langage qui supporte le paradigme de programmation que tu utilises sera toujours plus efficace qu'un langage qui ne le supporte pas, ça paraît pourtant évident !
Sinon, oui, Objective-C était peu connu, mais allez, MDI a suffisamment de charisme pour intéresser les gens. Surtout que franchement, Objective-C est largement plus proche de la notion de "C objet" que C++ ne l'est ...
Le C était à l'époque le langage à la mode, connu de bcp de gens,
Oui, donc c'est bien ce que je disais, MDI a poussé le C par calcul "politique"/marketing plus que par choix technique. Je trouve ça dommage, pour le moins.
... Et tu le dis toi même: tu n'aimes pas le C++, et moi je l'aime bien, parce qu'on peut faire d'affreuse bidouille en C++ (ce qui est exactement ce que je ne voudrais pas dans un projet que je dois maintenir).
Y'a pas comme une légère contradiction, là? de toute façon, le fait que je n'aime pas C++ ne veut pas pour autant dire que je ne l'ai pas utilisé, et que je ne l'utiliserais pas dans le futur : tout simplement, selon moi, un programmeur doit utiliser le bon outil pour le travail qui lui convient. C++ a des atouts, et si j'en ai besoin, je l'utiliserais. Maintenant, j'ai rien vu de mieux pour la programmation objet d'applications graphiques que OpenStep, donc j'utilise GNUstep pour les applis graphiques. Au pire, Qt, vu que les concepts sont franchement inspirés d'OpenStep.
Et finalement, on en revient toujours au même: la critique est si simple, mais toi qu'as tu fait? ;)
Pas autant que je voudrais, mais j'essaie de faire avancer les choses en participant à divers projets et ayant écrit quelques articles dans lmf, bref d'apporter un peu ma pierre à l'édifice.
[^] # Re: XAML et l'avenir de GNOME
Posté par Nicolas Roard . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
Pas exactement; mon argument était plutôt, certes Corba apporte des trucs sympas, mais en pratique, a-t-on réellement besoin de tout ça ? dans la plupart des cas, non. Utiliser Corba est donc trop lourd pour un intérêt assez limité. Dans ce cas, je trouve qu'utiliser un modèle plus léger est plus efficace et sensé.
Là ou je suis moins d'accord c'est sur le fait de pouvoir utiliser un composant depuis n'importe quel langage: en local c'est déjà assez courant (regarde le nombre de binding c++, python, perl, php, whatever qu'il existe pour des lib c... alors qu'avec un format "standard" on pourrait s'en passer). Mais une fois en remoting, c'est capital il me semble: tu ne peux pas contraindre tout tes projets à être en objective-C! Ce langage est sous doute adapté à certaines choses, mais le sera moins à d'autre, particulièrement en tenant compte de l'existant.
Non, je maintiens ce que je dis : dans un programme donné, il est rare d'avoir plusieurs langages. Les bindings existent, certes, mais sont-ils largement employés? pas tant que ça. Enfin, je ne dit pas du tout qu'utiliser DO est la panacée qui répondra à tous les besoins, simplement que DO est idéal pour utiliser des objets répartis dans ton application, si tu programmes en Objective-C.
Et accessoirement, faire un pont DO <-> Corba ne serait pas si compliqué, vraiment. Personne ne l'a implémenté dans le libre, parce que l'intérêt est honnêtement limité ... mais c'est ce que NeXT avait fait (début des années 90).
Pour synthétiser, intellectuellement, un modèle de composant qui fonctionne avec n'importe quoi, à la Corba, peut être intéressant. Mais en pratique, tu vas utiliser ça dans 1% des cas... il est logique alors de privilégier une solution plus simple -- mais plus efficace. C'est que font GNUstep et KDE. De toute façon, rien n'empêche de réaliser des ponts vers corba si vraiment tu y tient !
Pour le reste, c'est soit des répétions, soit de la mauvaise fois (tu ne connais ni C# ni .NET mais c'est pas une bonne idée...)
Evidemment que je suis un peu de mauvaise foi :-)
mais bon, je n'ai pas dit non plus que je ne connais absolument pas C# ou .Net -- juste que ce que j'en sais ne m'a pas intéressé et donc que je ne m'y suis pas penché plus avant (les journées de 24h, toussa). Mais je n'ai jamais clamé être un expert de C#/.Net donc bien évidemment j'ai pu (du?) rater des choses absoument géniales...
juste pour rajouter: "En tout cas écouter MDI chanter les louanges de la POO et du C# lors du FOSDEM 2003, c'était assez comique (si on est un peu cynique) quand on se souvient que GNOME a été lancé en bonne partie en rejet à C++ ..."
A sa place: objective C, non, trop peu connu, communauté trop "faible". C++: rappelle toi les début de KDE, les difficulté du compilo, le nombre moins important de de développeur et le fait qu'ils se soient basés sur Qt une libre existante comme une base de leur framework (qu'ils ont du changer quelques fois).
Qu'ajouter à ça ? je dit simplement que MDI a surfé sur la vague du C, pour finalement changer d'avis et utiliser un langage OO. Le reproche n'est pas dans le fait qu'il ait changé d'avis, juste que c'était couru d'avance et qu'il aurait du s'en rendre compte. Parce que même moi qui n'aime pas C++, entre programmer en C "objet" et programmer en C++, y'a pas photo -- de toute façon, un langage qui supporte le paradigme de programmation que tu utilises sera toujours plus efficace qu'un langage qui ne le supporte pas, ça paraît pourtant évident !
Sinon, oui, Objective-C était peu connu, mais allez, MDI a suffisamment de charisme pour intéresser les gens. Surtout que franchement, Objective-C est largement plus proche de la notion de "C objet" que C++ ne l'est ...
Le C était à l'époque le langage à la mode, connu de bcp de gens,
Oui, donc c'est bien ce que je disais, MDI a poussé le C par calcul "politique"/marketing plus que par choix technique. Je trouve ça dommage, pour le moins.
... Et tu le dis toi même: tu n'aimes pas le C++, et moi je l'aime bien, parce qu'on peut faire d'affreuse bidouille en C++ (ce qui est exactement ce que je ne voudrais pas dans un projet que je dois maintenir).
Y'a pas comme une légère contradiction, là? de toute façon, le fait que je n'aime pas C++ ne veut pas pour autant dire que je ne l'ai pas utilisé, et que je ne l'utiliserais pas dans le futur : tout simplement, selon moi, un programmeur doit utiliser le bon outil pour le travail qui lui convient. C++ a des atouts, et si j'en ai besoin, je l'utiliserais. Maintenant, j'ai rien vu de mieux pour la programmation objet d'applications graphiques que OpenStep, donc j'utilise GNUstep pour les applis graphiques. Au pire, Qt, vu que les concepts sont franchement inspirés d'OpenStep.
Et finalement, on en revient toujours au même: la critique est si simple, mais toi qu'as tu fait? ;)
Pas autant que je voudrais, mais j'essaie de faire avancer les choses en participant à divers projets et ayant écrit quelques articles dans lmf, bref d'apporter un peu ma pierre à l'édifice.
http://freshmeat.net/~nicolasroard/(...)
http://www.nongnu.org/backbone/(...)
http://www.nongnu.org/latexfr/(...)
http://www.roard.com/docs/(...)