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...
On est d'accord, donc .NET et Java n'ont pas une lacune de ce côté là. Merci d'avoir confirmé.
Quel organisme de bonne réputation a normalisé quelle partie de la plateforme java?
Ben, le JCP, organisme dédié avec des tarlouz comme Sun et IBM. Dans tous les cas il y a un effort de normalisation pour garantir l'interopérabilité. Et ca c'est le principal. On ne peut en dire autant de plateforme style Ruby, Python ou Php.
J'écoutais un discours de RMS qui rappellait qu'a la base, les logiciels étaient libres.
Rattrapes toi comme tu veux, Unix n'était pas libre à ses débuts. Heuresement RMS est arrivé.
Tu n'y es pour rien? Tu ne peux rien y faire? Pas très rassurant tout ça... brrr!
... T'es bête ou quoi ? Oui, si je me contente de développer une appli sur un OS, c'est évident que si y'a un trou dans l'OS j'y suis pour rien. Je suis responsable des trous dans mon appli uniquement. Alors moi je prégères contrôler au niveau de mon appli ce que je peux contrôler, et utiliser les services de sécurité de la VM (et l'indépendance vis-à-vis de l'OS) pour éviter que mon appli devienne une porte d'entrée vers mes données mais aussi l'OS (l'obstacle VM marche dans les 2 sens).
Il faut être capable de faire des compromis entre ces deux politiques de gestion mémoire pour arriver au meilleur résultat.
Dans tous les cas, quand tu utilises une plateforme, il faut que le modèle de gestion mémoire soit clairement exposé (et normalisé), pour assurer l'interopérabilité entre les composants. Alors désolé, mais y'a pas de "juste milieu", faut choisir quelque chose de standard pour la plateforme. En C/C++, c'est le joyeux bordel, chacun y va de sa technique exposée par ses libs. Dans les plateformes plus modernes, ca a été heuresement évité et normalisé : y'a un GC, il a un comportement dont les specs sont écrites noir sur blanc afin de garantir que toutes les implémentations produisent les mêmes résultats : interopérabilité.
Dans ce paragraphe, je parlais de langage, de syntax, de sémantique, pas de VM/runtime.
Justement ! Ces plateformes peuvent accueillir de nouvelles syntaxe/sémantique tout en profitant des services offerts !
Genre je prends .NET/Mono, certains voulaient une syntaxe ala Python, on a vu fleurir IronPython et Boo, et les composants écrits dans ces langages sont interopérables avec les autres composants sans qu'il n'y est de "pont" à écrire.
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.
Donc tu codes tout en C/C++. (et encore C++, y'a une gestion des exceptions et tout, y'a des services au runtime, ouahou, allé, C seulement !)
Et bien amuse toi bien, code ton serveur d'application en C, tes pages dynamique en C, tes clients lourd en C, amuse toi bonhomme, pendant ce temps là y'en a qui s'amuse avec d'autres plateformes : Java, Python, etc.
Pourquoi tu veux réinventer la roue? Utilise et améliore les libs existantes plutôt.
Ben justement, et en l'occurence en matière de serveur d'application, d'outil de mapping objet/relationnel, d'outils d'analyse de code, ben j'en ai marre de réinventer la roue dans des langages de bas niveau, je préfères largement utiliser celle de libs Java qui existent depuis des années.
C'est l'ensemble de la plateforme python, l'interpréteur python faire 5000 lignes de C
Avec des perfs de merde. Merci. Compare ce qui est comparable bordel ! C'est pour ca que je te parlais de Zope !
Arithmétique simple: HARD+OS/libs+VM+FRAMEWORK ou HARD+OS/libs pour faire la même chose.
Un calcul avec autant de mauvaise foi montre ton incompétence total.
Enfin au final t'es vraiment d'une incohérence totale dans tous tes propos. Moi j'essai juste de te démontrer que les VM apporte de réels atouts et avantages que les langages bas-niveau n'offre pas, que ce soit en matière de sécurité, de déploiement, de simplicité, d'interopérabilité, bref de productivité.
Toi tu fais quoi : tu cherches uniquement à dire le contraire de ce que je te dis. Un coup tu me dis que les langages de bas niveau c'est mieux, un autre coup tu me ressorts Erlang alors que c'est architecturé de la même manière que les plateformes que je prends en exemple, quand je te dis "oué mais tu peux pas profité de l'introspection quand tu code en C/C++" tu me dis "oué mais y'a Python etc.".
Bref tu te fou royalement de ma gueule, t'es inccapable de tenir une argumentation cohérente, on sait pas si t'aime bien les VM, un coup tu dis que tel ou tel langage c'est bien parcque pas de VM, un autre coup l'autre est bien aussi (parcqu'il en a une), ton seul objectif c'est de cracher avec une totale mauvaise foi sur des plateformes qui ont été initiées par des grosses boîtes. Si ca peut te faire bander, continue tout seul. (Ah oui au fait, Erlang, c'est pas issu d'une grosse boîte par hasard ? Bouuuuuh beurk.)
[^] # Re: Former des développeurs Python/Zope compétents
Posté par TImaniac (site web personnel) . En réponse à la dépêche Nuxeo CPS tournera sous Java. Évalué à 4.
On est d'accord, donc .NET et Java n'ont pas une lacune de ce côté là. Merci d'avoir confirmé.
Quel organisme de bonne réputation a normalisé quelle partie de la plateforme java?
Ben, le JCP, organisme dédié avec des tarlouz comme Sun et IBM. Dans tous les cas il y a un effort de normalisation pour garantir l'interopérabilité. Et ca c'est le principal. On ne peut en dire autant de plateforme style Ruby, Python ou Php.
J'écoutais un discours de RMS qui rappellait qu'a la base, les logiciels étaient libres.
Rattrapes toi comme tu veux, Unix n'était pas libre à ses débuts. Heuresement RMS est arrivé.
Tu n'y es pour rien? Tu ne peux rien y faire? Pas très rassurant tout ça... brrr!
... T'es bête ou quoi ? Oui, si je me contente de développer une appli sur un OS, c'est évident que si y'a un trou dans l'OS j'y suis pour rien. Je suis responsable des trous dans mon appli uniquement. Alors moi je prégères contrôler au niveau de mon appli ce que je peux contrôler, et utiliser les services de sécurité de la VM (et l'indépendance vis-à-vis de l'OS) pour éviter que mon appli devienne une porte d'entrée vers mes données mais aussi l'OS (l'obstacle VM marche dans les 2 sens).
Il faut être capable de faire des compromis entre ces deux politiques de gestion mémoire pour arriver au meilleur résultat.
Dans tous les cas, quand tu utilises une plateforme, il faut que le modèle de gestion mémoire soit clairement exposé (et normalisé), pour assurer l'interopérabilité entre les composants. Alors désolé, mais y'a pas de "juste milieu", faut choisir quelque chose de standard pour la plateforme. En C/C++, c'est le joyeux bordel, chacun y va de sa technique exposée par ses libs. Dans les plateformes plus modernes, ca a été heuresement évité et normalisé : y'a un GC, il a un comportement dont les specs sont écrites noir sur blanc afin de garantir que toutes les implémentations produisent les mêmes résultats : interopérabilité.
Dans ce paragraphe, je parlais de langage, de syntax, de sémantique, pas de VM/runtime.
Justement ! Ces plateformes peuvent accueillir de nouvelles syntaxe/sémantique tout en profitant des services offerts !
Genre je prends .NET/Mono, certains voulaient une syntaxe ala Python, on a vu fleurir IronPython et Boo, et les composants écrits dans ces langages sont interopérables avec les autres composants sans qu'il n'y est de "pont" à écrire.
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.
Donc tu codes tout en C/C++. (et encore C++, y'a une gestion des exceptions et tout, y'a des services au runtime, ouahou, allé, C seulement !)
Et bien amuse toi bien, code ton serveur d'application en C, tes pages dynamique en C, tes clients lourd en C, amuse toi bonhomme, pendant ce temps là y'en a qui s'amuse avec d'autres plateformes : Java, Python, etc.
Pourquoi tu veux réinventer la roue? Utilise et améliore les libs existantes plutôt.
Ben justement, et en l'occurence en matière de serveur d'application, d'outil de mapping objet/relationnel, d'outils d'analyse de code, ben j'en ai marre de réinventer la roue dans des langages de bas niveau, je préfères largement utiliser celle de libs Java qui existent depuis des années.
C'est l'ensemble de la plateforme python, l'interpréteur python faire 5000 lignes de C
Avec des perfs de merde. Merci. Compare ce qui est comparable bordel ! C'est pour ca que je te parlais de Zope !
Arithmétique simple: HARD+OS/libs+VM+FRAMEWORK ou HARD+OS/libs pour faire la même chose.
Un calcul avec autant de mauvaise foi montre ton incompétence total.
Enfin au final t'es vraiment d'une incohérence totale dans tous tes propos. Moi j'essai juste de te démontrer que les VM apporte de réels atouts et avantages que les langages bas-niveau n'offre pas, que ce soit en matière de sécurité, de déploiement, de simplicité, d'interopérabilité, bref de productivité.
Toi tu fais quoi : tu cherches uniquement à dire le contraire de ce que je te dis. Un coup tu me dis que les langages de bas niveau c'est mieux, un autre coup tu me ressorts Erlang alors que c'est architecturé de la même manière que les plateformes que je prends en exemple, quand je te dis "oué mais tu peux pas profité de l'introspection quand tu code en C/C++" tu me dis "oué mais y'a Python etc.".
Bref tu te fou royalement de ma gueule, t'es inccapable de tenir une argumentation cohérente, on sait pas si t'aime bien les VM, un coup tu dis que tel ou tel langage c'est bien parcque pas de VM, un autre coup l'autre est bien aussi (parcqu'il en a une), ton seul objectif c'est de cracher avec une totale mauvaise foi sur des plateformes qui ont été initiées par des grosses boîtes. Si ca peut te faire bander, continue tout seul. (Ah oui au fait, Erlang, c'est pas issu d'une grosse boîte par hasard ? Bouuuuuh beurk.)