Le point important, c'est surtout qu'il n'y a aucun intérêt à se faire suer avec le modèle lourd de Corba dans la quasi-totalité des cas; se forcer à l'utiliser est alors sacrèment contre-productif selon mon point de vue !! c'est bien pour ça que la solution de KDE de passer par une archi légère est efficace; et c'est bien pour ça que OpenStep avant eux le proposait. Franchement, entre me faire suer à définir un IDL et simplement écrire 2 lignes de plus pour indiquer que j'utilise un objet qui en fait tourne sur une machine à 800 km de là, ben, je sais pas pourquoi, mais je préfère écrire deux lignes.
Je comprends ton point de vue, je suis d'accord, tu devrais aimer .NET ;) mais surtout: rapport avec Corba, COM, java remoting, whatever? Je n'ai jamais fait de corba en C (et heureusement), en java et en C++, c'est plutôt simple à mettre en oeuvre (une fois que t'as le naming service, si y'a un truc qui me bourre en corba c'est bien ça)..
En fait j'ai l'impression que ton argument est plus: pq les langage n'offre pas plus de facilité? on est d'accord.
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.
Accessoirement, l'utopie sur la transparence ou la couche réseau parfaite... heu... de toute façon le problème est identique avec Corba, non?
Oui, mais tu te situes un peu plus pas niveau, on te présente pas corba comme "ça marche juste, y'a rien à faire, c'est magique".
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...), 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). Le C était à l'époque le langage à la mode, connu de bcp de gens, ... 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).
Et finalement, on en revient toujours au même: la critique est si simple, mais toi qu'as tu fait? ;)
[^] # Re: XAML et l'avenir de GNOME
Posté par tene . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 2.
Le point important, c'est surtout qu'il n'y a aucun intérêt à se faire suer avec le modèle lourd de Corba dans la quasi-totalité des cas; se forcer à l'utiliser est alors sacrèment contre-productif selon mon point de vue !! c'est bien pour ça que la solution de KDE de passer par une archi légère est efficace; et c'est bien pour ça que OpenStep avant eux le proposait. Franchement, entre me faire suer à définir un IDL et simplement écrire 2 lignes de plus pour indiquer que j'utilise un objet qui en fait tourne sur une machine à 800 km de là, ben, je sais pas pourquoi, mais je préfère écrire deux lignes.
Je comprends ton point de vue, je suis d'accord, tu devrais aimer .NET ;) mais surtout: rapport avec Corba, COM, java remoting, whatever? Je n'ai jamais fait de corba en C (et heureusement), en java et en C++, c'est plutôt simple à mettre en oeuvre (une fois que t'as le naming service, si y'a un truc qui me bourre en corba c'est bien ça)..
En fait j'ai l'impression que ton argument est plus: pq les langage n'offre pas plus de facilité? on est d'accord.
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.
Accessoirement, l'utopie sur la transparence ou la couche réseau parfaite... heu... de toute façon le problème est identique avec Corba, non?
Oui, mais tu te situes un peu plus pas niveau, on te présente pas corba comme "ça marche juste, y'a rien à faire, c'est magique".
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...), 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). Le C était à l'époque le langage à la mode, connu de bcp de gens, ... 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).
Et finalement, on en revient toujours au même: la critique est si simple, mais toi qu'as tu fait? ;)