Et tu m'expliques pourquoi Java et .NET ne serait pas des assemblages cohérents ? Ils ont été conçus justement pour être cohérents !
La plateforme python est cohérente, la plateforme perl avec leur système CPAM est cohérente, la plateforme erlang est cohérente etc etc... et il est tout à fait possible d'assembler des solutions hétérogènes qui forment un tout cohérent.
Tout comme avec une plateforme Java, qui elle est déjà normalisée, tu choisies les briques qui t'intéresse, de la simple VM embarquée au serveur d'application, du composant sous licence libre au composant proprio, et tu gardes une cohérence technique de A à Z.
Quand c'est une norme, ça veut dire que c'est passé par un organisme de normalisation. Ces organismes sont nombreux. Certains ont plus ou moins bonne réputation. Dernièrement je traîne pas mal sur le site de l'organisme OASIS qui a normalisé le format open document et toujours sur le même site je m'intéresse à la norme docbook. Quel organisme de bonne réputation a normalisé quelle partie de la plateforme java? Ça me trouble car normé avec un degré de rigueur correcte des plateformes gigantesques et tentaculaires comme java qui évolue assez vite donc rendrait la norme vite obsolète me semble utopique.
Oué elle était facile, mais pas si dénuet d'intérêt : Unix à la base c'est du 100% proprio, si on t'écoute on aurait dû garder la philosophie ;)
Oué mais c'est totalement indépendant de ton appli, j'y suis pour rien. Et si ca arrive trop souvent, je peux justement changer facilement d'OS vers un OS moins troué grâce à l'indépendance que me procure la VM ;-)
Tu n'y es pour rien? Tu ne peux rien y faire? Pas très rassurant tout ça... brrr! Portez une VM et tout son framework sur un OS prétendu "moins troué". Quelles jolies galipettes! (Cf J2ME). Mettre au point et maintenir des combinaisons de HARD+OS c'est déjà pas forcément facile, alors les combinaisons HARD+OS+VM... euh... non merci.
Oué, si tu veux. Sauf que globalement t'es bien obligé de respecter les libs que t'utilises, tu t'amuses pas à utiliser un GC dans ton coin, une autre lib utilise le sien, l'autre fait des malloc à la main et libère, l'autre fait des malloc mais sous-entend que c'est à l'utilisateur de libérer, enfin un vrai foutoir d'intégration qui se finit en fuites mémoires. (attention je dis pas qu'avec les VM c'est impossible, juste que le modèle mémoire est normalisé).
Tu n'as besoin de respecter le GC que là où tu as en besoin, ailleurs, ça serait du gâchis de ressources. Perso, je n'aime pas beaucoup les garbage collector, ce gâchis et cette perte de contrôle.... beurk! Mais, j'essayerais un jour de coder quelquechose en C++ avec un garbage collector. Lorsque j'ai travaillé en téléphonie mobile, pour "vendre super sécure"(TM), un composant de la solution n'avait tout bonnement pas d'allocation mémoire dynamique, tout était statiquement alloué à la compilation et préparé aux petits oignons. Mais seulement le composant exposé, les autres était pénards et pouvait utiliser la politique de gestion mémoire qu'ils souhaitaient.
Oué ca c'est dans le meilleur des mondes... Y'a 2 approches :
- "la gestion mémoire est tellement importante que je préfères ne pas laisser la machine s'en occuper"
- "la gestion mémoire est tellement importante que je préfères ne pas laisser un humain s'en occuper"
Choisi celle que tu veux moi c'est tout vu :-)
Pourquoi exclusivement machine ou humain? La meilleurs solution n'est certainement pas l'une ou l'autre, ça dépend de ce que tu as besoin de faire et des ressources dont tu disposes. En aucun cas l'un ou l'autre n'est magique: "les humains sont tous de nullards" et "les ordinateurs sont super intelligents"? Il faut être capable de faire des compromis entre ces deux politiques de gestion mémoire pour arriver au meilleur résultat.
Tu vas rire, mais les plateformes comme Java ou .NET/Mono peuvent accueillir de nouveaux langages, même que si tu google un peu Erlang + Java ...
Dans ce paragraphe, je parlais de langage, de syntax, de sémantique, pas de VM/runtime. Si j'ai bien compris la VM parrot à l'intention de devenir la VM universelle. Après une bref recherche sur google j'ai trouvé ça: http://www.sics.se/~joe/ericsson/du98024.html Bon... il faut avouer que les benchs.... ça se détournent... à tel point que les benchs hurlés partout sur le net valent encore quelque chose...
Ben justement, je préfère amplement avoir une plateforme cohérente de A à Z, de la couche d'accès aux données aux clients lourds en passant par le serveur web, pour justement éviter la complexité et la lourdeur de ponts intermédiaires artisanaux qui engendre de nombreux problèmes techniques.
Moi aussi, je préfère largement avoir une plateforme cohérente qui répondent au besoin métier du clients. Et je me passe très bien de VM qui est une dépendance qui ne fait qu'alourdir ma solution par l'ajout d'une quantité de code loin d'être négligeable qu'il va falloir gérer et maintenir.
Je préfères encore une fois faire confiance à la VM qui n'a sûrement pas été codée avec les pieds qu'à moi même pour réinventer la roue ;)
"sûrement"? Si ça te suffit... :D "L'OS de MS est le meilleur du monde(TM) car c'est la plus grosse boîte du monde et que donc par définition il ne peuvent pas faire de la mBIP!" te suffit également? Je suis désolé mais ça n'est pas suffisant: Ce que je vois, c'est un mastodonte de code à gérer et à maintenir qui duplique les services qui me sont offerts par mon OS préféré et ses libs de base, donc si je peux m'en passer je m'en passe. Pourquoi tu veux réinventer la roue? Utilise et améliore les libs existantes plutôt.
Une plateforme comme Mono (je parle de ce que je connais), c'est le même ordre de grandeur en nombre de lignes de code...
...dans le pb de dépendance vis-à-vis de MS, comme JAVA de Sun? C'est l'ensemble de la plateforme python, l'interpréteur python faire 5000 lignes de C, combien de ligne de code C pour la VM de Mono? Erlang 41000 pour la VM tu disais? Il faudrait aussi voir du côté de la VM parrot, de ruby, de perl et des autres.
Le problème ne vient pas des composants en soit (qui sont souvent auditer de manière individuel), les problèmes viennent de l'assemblage "sur-mesure" que tu créés, qui est nouveau, et apporte une complexité et des risques supplémentaires.
En général, il n'y a pas tant de libs que ça, et souvent les combinatoires sont les mêmes. Les risques et les efforts de maintenance sont proportionnels à la quantité de code modulé par sa complexité. Arithmétique simple: HARD+OS/libs+VM+FRAMEWORK ou HARD+OS/libs pour faire la même chose.
C'est passionnant!
Oué bah j'espère que t'as la chance de ne pas faire la maintenance :)
J'ai fait de la maintenance sur des applications complexes tapant les millions de lignes: un cauchemar, C'était plus des amas de rustines et de code tordu pour compenser le design malfoutu et les bugs des "produits"(TM) de boîtes qui "certifiait"(TM) et "supportait"(TM) ta mère ton oncle et la paix dans le monde(TM)... ct pas passionnant plutôt irritant et dévalorisant, par contre tous les projets que j'ai fait sur du libre dans une optique unix, ct passionnant et intéressant.
[^] # 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é à -1.
La plateforme python est cohérente, la plateforme perl avec leur système CPAM est cohérente, la plateforme erlang est cohérente etc etc... et il est tout à fait possible d'assembler des solutions hétérogènes qui forment un tout cohérent.
Quand c'est une norme, ça veut dire que c'est passé par un organisme de normalisation. Ces organismes sont nombreux. Certains ont plus ou moins bonne réputation. Dernièrement je traîne pas mal sur le site de l'organisme OASIS qui a normalisé le format open document et toujours sur le même site je m'intéresse à la norme docbook. Quel organisme de bonne réputation a normalisé quelle partie de la plateforme java? Ça me trouble car normé avec un degré de rigueur correcte des plateformes gigantesques et tentaculaires comme java qui évolue assez vite donc rendrait la norme vite obsolète me semble utopique.
J'écoutais un discours de RMS qui rappellait qu'a la base, les logiciels étaient libres. C'est en train de revenir, et c'est tant mieux! Les bonnes choses reviennent toujours. Pour en revenir à la philosophie d'unix et autre motto bourrés de bon sens... http://en.wikipedia.org/wiki/Unix_philosophy et http://en.wikipedia.org/wiki/Live_free_or_die#Use_in_Unix
Tu n'y es pour rien? Tu ne peux rien y faire? Pas très rassurant tout ça... brrr! Portez une VM et tout son framework sur un OS prétendu "moins troué". Quelles jolies galipettes! (Cf J2ME). Mettre au point et maintenir des combinaisons de HARD+OS c'est déjà pas forcément facile, alors les combinaisons HARD+OS+VM... euh... non merci.
Tu n'as besoin de respecter le GC que là où tu as en besoin, ailleurs, ça serait du gâchis de ressources. Perso, je n'aime pas beaucoup les garbage collector, ce gâchis et cette perte de contrôle.... beurk! Mais, j'essayerais un jour de coder quelquechose en C++ avec un garbage collector. Lorsque j'ai travaillé en téléphonie mobile, pour "vendre super sécure"(TM), un composant de la solution n'avait tout bonnement pas d'allocation mémoire dynamique, tout était statiquement alloué à la compilation et préparé aux petits oignons. Mais seulement le composant exposé, les autres était pénards et pouvait utiliser la politique de gestion mémoire qu'ils souhaitaient.
Pourquoi exclusivement machine ou humain? La meilleurs solution n'est certainement pas l'une ou l'autre, ça dépend de ce que tu as besoin de faire et des ressources dont tu disposes. En aucun cas l'un ou l'autre n'est magique: "les humains sont tous de nullards" et "les ordinateurs sont super intelligents"? Il faut être capable de faire des compromis entre ces deux politiques de gestion mémoire pour arriver au meilleur résultat.
Dans ce paragraphe, je parlais de langage, de syntax, de sémantique, pas de VM/runtime. Si j'ai bien compris la VM parrot à l'intention de devenir la VM universelle. Après une bref recherche sur google j'ai trouvé ça: http://www.sics.se/~joe/ericsson/du98024.html Bon... il faut avouer que les benchs.... ça se détournent... à tel point que les benchs hurlés partout sur le net valent encore quelque chose...
Moi aussi, je préfère largement avoir une plateforme cohérente qui répondent au besoin métier du clients. Et je me passe très bien de VM qui est une dépendance qui ne fait qu'alourdir ma solution par l'ajout d'une quantité de code loin d'être négligeable qu'il va falloir gérer et maintenir.
"sûrement"? Si ça te suffit... :D "L'OS de MS est le meilleur du monde(TM) car c'est la plus grosse boîte du monde et que donc par définition il ne peuvent pas faire de la mBIP!" te suffit également? Je suis désolé mais ça n'est pas suffisant: Ce que je vois, c'est un mastodonte de code à gérer et à maintenir qui duplique les services qui me sont offerts par mon OS préféré et ses libs de base, donc si je peux m'en passer je m'en passe. Pourquoi tu veux réinventer la roue? Utilise et améliore les libs existantes plutôt.
...dans le pb de dépendance vis-à-vis de MS, comme JAVA de Sun? C'est l'ensemble de la plateforme python, l'interpréteur python faire 5000 lignes de C, combien de ligne de code C pour la VM de Mono? Erlang 41000 pour la VM tu disais? Il faudrait aussi voir du côté de la VM parrot, de ruby, de perl et des autres.
En général, il n'y a pas tant de libs que ça, et souvent les combinatoires sont les mêmes. Les risques et les efforts de maintenance sont proportionnels à la quantité de code modulé par sa complexité. Arithmétique simple: HARD+OS/libs+VM+FRAMEWORK ou HARD+OS/libs pour faire la même chose.
J'ai fait de la maintenance sur des applications complexes tapant les millions de lignes: un cauchemar, C'était plus des amas de rustines et de code tordu pour compenser le design malfoutu et les bugs des "produits"(TM) de boîtes qui "certifiait"(TM) et "supportait"(TM) ta mère ton oncle et la paix dans le monde(TM)... ct pas passionnant plutôt irritant et dévalorisant, par contre tous les projets que j'ai fait sur du libre dans une optique unix, ct passionnant et intéressant.