Je comprends pas bien: Application, tu dois sous entendre plusieurs process (sinon corba n'a pas de sens), et donc me dire que c'est rare d'avoir des process programmé à l'aide de langage différent, je suis pas trop... Ton explication semble être: tout faire en corba c'est pas top. D'accord, tout d'abord c'est impossible (ce n'est qu'un orb!), ensuite et surtout ce n'est pas le cas.
Ce que je veut dire, c'est que pour un 'bureau' ou l'on veut avoir des composants graphiques externalises, on a pas forcement besoin de tout ce que propose Corba. Le point qui est eventuellement litigieux est la possibilite d'etre independant du langage -- mais ce que je remarque, c'est que tres souvent, le langage utilise est le meme pour l'ensemble des applis/composants.
La tres tres grande majorite des applis KDE sont en C++, la tres tres grande majorite des applis GNOME en C, et cote GNUstep, je connais pas d'appli (graphique, cote serveur il y en a...) qui utilisent par exemple les bindings Java. Mixer differents langages est l'exception plus que la norme.
A mon avis ca s'explique par le fait que les bibliotheques sont d'abord faites pour un langage donne et tirent partie des avantages du langage, et que finalement, il est souvent prefererable d'utiliser le langage "reconnu" si l'on veut tirer partie de toutes les capacitees proposees. Ca peut aussi etre simplement un lag entre les versions des librairies accessibles par les bindings et les versions courante.. mais le resultat est le meme.
Enfin, pour les rares cas ou l'on veut effectivement utiliser un autre langage, encapsuler ton code (utilisant un autre langage que le "principal") dans un composant 'leger' code lui en utilisant le langage dans lequel les libs sont codes n'est pas bien complique.
Accessoirement, le coup d'utiliser du C parce que ca facilite les bindings est plus ou moins vrai... certes, ca peut faciliter, mais bon, KDE propose par exemple des bindings pour une foultitude de langages, et meme GNUstep, avec peu developpeurs, propose des bindings en Java, Ruby, Scheme..
Bref, emmerder tout le monde (utiliser un langage procedural pour faire de la POO) et reinventer la roue (C "objet") pour cette raison (facilite des bindings) est plutot une decision pas si justifiee, au final, non ?
Dans l'absolu, oui. En étant réaliste: c'est inévitable, l'histoire de compromis à nouveau...
Oui, mais c'est ce "compromis" que je trouve vaseux, justement. Mais bon, c'est juste mon opinion, je trouve contre-productif de faire du developpement objet en C, c'est tout.
ps: tu connaissais Miguel De Icaza avant Gnome? moi pas.
[^] # 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é à 2.
Ce que je veut dire, c'est que pour un 'bureau' ou l'on veut avoir des composants graphiques externalises, on a pas forcement besoin de tout ce que propose Corba. Le point qui est eventuellement litigieux est la possibilite d'etre independant du langage -- mais ce que je remarque, c'est que tres souvent, le langage utilise est le meme pour l'ensemble des applis/composants.
La tres tres grande majorite des applis KDE sont en C++, la tres tres grande majorite des applis GNOME en C, et cote GNUstep, je connais pas d'appli (graphique, cote serveur il y en a...) qui utilisent par exemple les bindings Java. Mixer differents langages est l'exception plus que la norme.
A mon avis ca s'explique par le fait que les bibliotheques sont d'abord faites pour un langage donne et tirent partie des avantages du langage, et que finalement, il est souvent prefererable d'utiliser le langage "reconnu" si l'on veut tirer partie de toutes les capacitees proposees. Ca peut aussi etre simplement un lag entre les versions des librairies accessibles par les bindings et les versions courante.. mais le resultat est le meme.
Enfin, pour les rares cas ou l'on veut effectivement utiliser un autre langage, encapsuler ton code (utilisant un autre langage que le "principal") dans un composant 'leger' code lui en utilisant le langage dans lequel les libs sont codes n'est pas bien complique.
Accessoirement, le coup d'utiliser du C parce que ca facilite les bindings est plus ou moins vrai... certes, ca peut faciliter, mais bon, KDE propose par exemple des bindings pour une foultitude de langages, et meme GNUstep, avec peu developpeurs, propose des bindings en Java, Ruby, Scheme..
Bref, emmerder tout le monde (utiliser un langage procedural pour faire de la POO) et reinventer la roue (C "objet") pour cette raison (facilite des bindings) est plutot une decision pas si justifiee, au final, non ?
Dans l'absolu, oui. En étant réaliste: c'est inévitable, l'histoire de compromis à nouveau...
Oui, mais c'est ce "compromis" que je trouve vaseux, justement. Mais bon, c'est juste mon opinion, je trouve contre-productif de faire du developpement objet en C, c'est tout.
ps: tu connaissais Miguel De Icaza avant Gnome? moi pas.
Oui, il avait ecrit midnight commander.