Le problème dans ton discours c'est que tu nous ressorts à chaque fois une solution différente pour chaque aspect alors qu'on insiste ici sur le fait que la force de Java ou de Mono est la mise à disposition d'une plateforme "cohérente" et pas composée de bouts assemblés dans tous les sens et inmaintenables.
Tout à fait, linux est inmaintenable, python non plus, ruby non plus, KDE, gnutls; openssh; xorg, mozilla, gcc.
Fort bien, tu as erlang qui traite mieux le developpement distribué. Mais il tourne sur un "runtime". Il offre donc lui aussi des services de l'OS ? Alors tu préfères un OS ou un runtime? Et comment tu fais pour prendre le meilleur de Erlang et de python ? Tu bases ton architecture sur des composants qui communiquent avec un protocole et une infrastructure communes (bus). C'etait pas un peu l'idée de Corba au départ. Hélas même les devs de KDE et de Gnome lui ont tourné le dos en l'adaptant à leur sauce parce que les perf étaient dégradées en environnement "non" distribué.
Euh... tu te goures, ORBit à la réputation d'être rapide. KDE à dropper corba car ct inutilement complexe et lourd pour les tâches d'un desktop. Miguel De Icaza, le MS copycat de gnome, à eu la très mauvaise idée de copier le modèle de composant MS COM pour le mapper sur corba. Gnome le drop pour embrayer sur dbus aussi à cause de la complexité.
Alors maintenant tu as ta dipsosition des plateformes libres ou "quasiment" qui offrent des services prêts à l'emploi et permettent de rajouter des composants (JEE, Mono, XPCOM-Mozilla, UNO -OpenOffice, ...). Mais le choix se réduit encore lorsqu'il faut couvrir le réparti, le local, le mutili OS.
JEE Mono sont des technologies dont l'indépendance et très discutable... je ne me contente pas d'une licence libre quand je parle de logiciel libre. XPCOM-Mozilla est très simple comparé à ces derniers. Je ne sais pas pour UNO.
Tu as aussi la solution de récupérer toutes les technos du libre éparses et de les assembler par des ponts divers et variés. Quid de la cohérence, la montée en charge, la stabilité sur une architecture exotique ?
Le piège du soi-disant "oligopoles" se transforme en la quête du mouton à 5 pattes et la chasse à la compléxité superflue?
Pour ma part, je préfère mettre ensemble des composants simples qui font bien leur boulot (cf moto d'unix), et cela ne signifie pas du tout "complexité" que d'avoir tout regroupé dans une super plateforme qui tente de tout faire. As-tu regardé les spécifications de java, celle de .net... c'est horriblement complexe, même corba m'a semblé plus simple à côté. Le bilan est le suivant: tu vois des frameworks d'une complexité inouïe passés en force, alors que de l'autre côté par la pratique et à la force de la raison, comme tu l'as souligné avec corba, on les abandonne ces bloats complexes pour un ensemble de petits éléments plus simples.
Et quelle librairie graphique portable s'interface avec Erlang. Qt ? Est-ce adapté pour tirer bénéfice des possibilités du langages. Quand on voit les trésors d'ingéniosité déployés par l'auteur de PyQt pour étendre le mécanisme des signaux/slots et les rendre dynamiques, on comprend qu'un langage conditionne une architecture.
Erlang bourrine dans les télécoms paraît-il. Si tu veux mettre un interface graphique à une framework pensé pour les télecoms, libre à toi.
Et pour revenir sur les services du runtime qui s'apparentent à celui de l'OS. Comment assurer simplement la portabilité entre OS justement, si tu bases ton code sur des spécificités d'un OS. suggeères tu que la portabilité soitassurée par l'OS. Ce que tu reproches à M$ tu voudrais l'imposer. Les runtimes encapsulent justement ces services avec une API commune et lorsque les spécificités de l'OS permettent d'optimiser ces
services, elles sont prises en compte.
La section critique se base sur des mécanismes offerts par l'OS (sans quoi elle ne serait pas fiable) et pourtant c'est bien un service offert par le langage ou le runtime qui est de plus haut niveau que le sémaphore (je ne connais pas les détails de l'implémentation, aussi je peux me tromper mais c'est sur l'idée que j'insiste).
Bon je récapitule MA vision des choses:
Je vois des frameworks d'une complexité à la all-in-one(cf specs), dont l'indépendance est sujettes à caution, qui sont poussés complètement artificiellement sur le devant de la scène. Leurs langages en terme de difficulté est similaire au C/C++ donc rien de significativement novateur (spécial dédicasse pour qui celui qui se reconnaitra).. Par contre , en cado bonux tu as une VM à maintenir pour chaque combinaison OS+HARD qui finalement fait du JIT car trop lente (chercher l'erreur).
Je vois la montée des langages dit dynamiques (python, ruby ...). Beaucoup plus simples que leur homologues précédent avec un interpréteur loin de la complexité des VM précédentes car ne se vantant pas d'aller plus loin que la complexité déjà élevée des OS courants, et puis surtout c'est "libre", pas Sun ni MS...
On me parle de cohérence d'une plateforme, alors que les termes adéquats seraient homogène et hétérogènes. Mais l'opposé de cohérent ça fait péjoratif. Donc tout ce qui n'est pas "cohérent" est BIP! Donc tout ce qui est pas leur framework est BIP! En fait, ces frameworks sont plus homogènes (comme zope)... par contre cela n'empêche en rien un système hétérogène d'être parfaitement cohérent!
Ensuite, quand on regarde ce qui se passe: beaucoup de projets du libre recherche la simplification par modularisation (divide and conquiere) ou carrément abandonne les bloat complexes: xorg qui se modularise et qui sous peu sera le berceau de XCB, gnome qui drope finalement corba car trop complexe, mozilla qui passe à xulrunner. Et malgré ça, on apprend toujours pas, tu en as toujours pour pousser de nouveaux giga bloat complexes et donc refaire les mêmes erreurs...
[^] # Re: Former des développeurs Python/Zope compétents
Posté par sylware . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 0.
Euh... tu te goures, ORBit à la réputation d'être rapide. KDE à dropper corba car ct inutilement complexe et lourd pour les tâches d'un desktop. Miguel De Icaza, le MS copycat de gnome, à eu la très mauvaise idée de copier le modèle de composant MS COM pour le mapper sur corba. Gnome le drop pour embrayer sur dbus aussi à cause de la complexité.JEE Mono sont des technologies dont l'indépendance et très discutable... je ne me contente pas d'une licence libre quand je parle de logiciel libre. XPCOM-Mozilla est très simple comparé à ces derniers. Je ne sais pas pour UNO.
Pour ma part, je préfère mettre ensemble des composants simples qui font bien leur boulot (cf moto d'unix), et cela ne signifie pas du tout "complexité" que d'avoir tout regroupé dans une super plateforme qui tente de tout faire. As-tu regardé les spécifications de java, celle de .net... c'est horriblement complexe, même corba m'a semblé plus simple à côté. Le bilan est le suivant: tu vois des frameworks d'une complexité inouïe passés en force, alors que de l'autre côté par la pratique et à la force de la raison, comme tu l'as souligné avec corba, on les abandonne ces bloats complexes pour un ensemble de petits éléments plus simples.Erlang bourrine dans les télécoms paraît-il. Si tu veux mettre un interface graphique à une framework pensé pour les télecoms, libre à toi.
Bon je récapitule MA vision des choses:
Je vois des frameworks d'une complexité à la all-in-one(cf specs), dont l'indépendance est sujettes à caution, qui sont poussés complètement artificiellement sur le devant de la scène. Leurs langages en terme de difficulté est similaire au C/C++ donc rien de significativement novateur (spécial dédicasse pour qui celui qui se reconnaitra).. Par contre , en cado bonux tu as une VM à maintenir pour chaque combinaison OS+HARD qui finalement fait du JIT car trop lente (chercher l'erreur).
Je vois la montée des langages dit dynamiques (python, ruby ...). Beaucoup plus simples que leur homologues précédent avec un interpréteur loin de la complexité des VM précédentes car ne se vantant pas d'aller plus loin que la complexité déjà élevée des OS courants, et puis surtout c'est "libre", pas Sun ni MS...
On me parle de cohérence d'une plateforme, alors que les termes adéquats seraient homogène et hétérogènes. Mais l'opposé de cohérent ça fait péjoratif. Donc tout ce qui n'est pas "cohérent" est BIP! Donc tout ce qui est pas leur framework est BIP! En fait, ces frameworks sont plus homogènes (comme zope)... par contre cela n'empêche en rien un système hétérogène d'être parfaitement cohérent!
Ensuite, quand on regarde ce qui se passe: beaucoup de projets du libre recherche la simplification par modularisation (divide and conquiere) ou carrément abandonne les bloat complexes: xorg qui se modularise et qui sous peu sera le berceau de XCB, gnome qui drope finalement corba car trop complexe, mozilla qui passe à xulrunner. Et malgré ça, on apprend toujours pas, tu en as toujours pour pousser de nouveaux giga bloat complexes et donc refaire les mêmes erreurs...