Alternative à C# : tu n’as pas répondu. Normal, il n’y en a pas d’aussi sérieuse. Java est une grosse bouse, C++ n’a rien à voir.
Première phrase, premier Troll.
Esthétiquement, on peut préférer .NET ou JAVA pour la syntaxe et les noms des libs, mais grosso-merdo, ils ont les mêmes limites et les mêmes concepts.
Alternative à CLI : les JVM, avec toutes leurs subtiles incompatibilités.
Je ne veux pas dire, mais travaillant sur JAVA depuis 2000 surtout dans les applis web.
Dans ce cadre là, j'ai rencontré 2 cas, ou il fallait recompiler les jar sur la plate-forme de production, parce qu'on avait pas une JVM du même éditeur sur les postes développeurs, et encore c'était en 2001-2002 avant que la norme J2EE soit mieux respectée.
Alternative à .Net :
Il faut bien comprendre que MS à commencer a pousser .NET quand Linux est devenu une menace plus sérieuse pour eux dans la mesure ou Linux n'est pas limité au x86 pour les applications dont on dispose le source.
Pour distribuer un "binaire" tout en étant indépendant du matériel sous jacent, il faut une VM.
Il y a quelques années, MS annonçait de migrer toutes leurs applications sous .NET pour être indépendant du matériel.
Je constate que depuis que les technologies de virtualisation sont plus courantes, MS se fait plus discret sur cette migration.
Autrement pour Python, je suis d'accord, j'adore ce langage, mais il manque une certaine cohérence pour le choix d'une bibliothèque.
mais si aujourd’hui je devais concevoir une nouvelle application de plus de quelques milliers de lignes de code,
Si les gros éditeurs décidaient du jour au lendemain de basculer tout en Python/Ruby/OCAML/Lisp/Haskell/..., tu aurais exactement les outils qu'ils te manquent à l'heure actuelle qui accompagnerait ce nouveau choix "industriel"
Pour faire des applications "professionnelles" (c'est à dire développé pour une entreprise par elle même ou une société de service), il faut une taylorisation des moyens pour interchanger les développeurs entre projets. Donc il faut pouvoir tenir les développeurs par la main.
Forcément le monde du libre, c'est la liberté de faire ses propres choix, c'est moins cadré.
[^] # Re: Microsoft va-t-il LIBÉRER .net ?
Posté par darkleon . En réponse à la dépêche Tomboy vs Gnote. Évalué à 7.
Première phrase, premier Troll.
Esthétiquement, on peut préférer .NET ou JAVA pour la syntaxe et les noms des libs, mais grosso-merdo, ils ont les mêmes limites et les mêmes concepts.
Alternative à CLI : les JVM, avec toutes leurs subtiles incompatibilités.
Je ne veux pas dire, mais travaillant sur JAVA depuis 2000 surtout dans les applis web.
Dans ce cadre là, j'ai rencontré 2 cas, ou il fallait recompiler les jar sur la plate-forme de production, parce qu'on avait pas une JVM du même éditeur sur les postes développeurs, et encore c'était en 2001-2002 avant que la norme J2EE soit mieux respectée.
Alternative à .Net :
Il faut bien comprendre que MS à commencer a pousser .NET quand Linux est devenu une menace plus sérieuse pour eux dans la mesure ou Linux n'est pas limité au x86 pour les applications dont on dispose le source.
Pour distribuer un "binaire" tout en étant indépendant du matériel sous jacent, il faut une VM.
Il y a quelques années, MS annonçait de migrer toutes leurs applications sous .NET pour être indépendant du matériel.
Je constate que depuis que les technologies de virtualisation sont plus courantes, MS se fait plus discret sur cette migration.
Autrement pour Python, je suis d'accord, j'adore ce langage, mais il manque une certaine cohérence pour le choix d'une bibliothèque.
mais si aujourd’hui je devais concevoir une nouvelle application de plus de quelques milliers de lignes de code,
Si les gros éditeurs décidaient du jour au lendemain de basculer tout en Python/Ruby/OCAML/Lisp/Haskell/..., tu aurais exactement les outils qu'ils te manquent à l'heure actuelle qui accompagnerait ce nouveau choix "industriel"
Pour faire des applications "professionnelles" (c'est à dire développé pour une entreprise par elle même ou une société de service), il faut une taylorisation des moyens pour interchanger les développeurs entre projets. Donc il faut pouvoir tenir les développeurs par la main.
Forcément le monde du libre, c'est la liberté de faire ses propres choix, c'est moins cadré.