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.
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é. 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.
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?
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.
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).
[^] # Re: Former des développeurs Python/Zope compétents
Posté par golum . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 3.
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é. 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.
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?
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.
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).