La version 2.0 de Rubinius vient de sortir ! Pour rappel, Rubinius est une alternative à l'interpréteur du langage Ruby de référence nommé MRI (de l'anglais Matz's Ruby Interpreter). Rubinius est une machine virtuelle qui s'appuie sur LLVM pour compiler dynamiquement du code Ruby en code machine natif. Les nouveautés de cette nouvelle version sont profondes :
- compatibilité avec Ruby 2.1 (qui n'est pas encore sorti), en plus des versions 1.8 et 1.9 ;
- transformations de plusieurs couches de Rubinius en gems pour simplifier les mises à jour : compilateur, parser, débogueur, bibliothèque standard Ruby, etc. (tout ça est écrit en Ruby !) ;
- amélioration des performances et de la stabilité dans le but avoué de rester compétitif face à des langages tels que Go, Clojure, ou encore Node ;
- traditionnelles corrections de bugs.
Vous pouvez tester cette nouvelle version de Rubinius dès maintenant grâce à RVM, rbenv ou chruby !
L'annonce de sortie de cette nouvelle version est accompagnée d'une réflexion autour de Ruby et de sa compétitivité face aux autres langages de programmation (notamment Erlang, Go, Clojure et Node). D'après l'auteur du billet, les applications concurrentes et distribuées sont devenues essentielles à la réussite d'un projet aujourd'hui. Les langages interprétés sont très souvent pénalisés par leur Global Interpreter Lock (de son petit nom GIL), Rubinius est bien entendu une réponse à ce problème car il permet à Ruby d'être exécuté en parallèle sur tous les cœurs d'un microprocesseur.
Cette observation est intéressante et semble honnête, même si empreinte d'une certaine crainte vis-à-vis de la fuite des talents de la communauté Ruby. Néanmoins Python semble être moins impacté par ses limitations techniques car le langage est toujours autant plébiscité par le secteur professionnel. D'où cette question : les programmeurs sont-ils tous des Mouton de Panurge, des victimes de la mode, ou y a-t-il de vrais arguments derrière le choix d'un langage de programmation ? Le débat est ouvert !
Aller plus loin
- Annonce de la sortie (114 clics)
- Projets LLVM (51 clics)
- Dépôt GitHub (51 clics)
- Commment installer Ruby avec rbenv (65 clics)
# Oui mais...
Posté par Midnight . Évalué à 1. Dernière modification le 07 octobre 2013 à 19:11.
N'ayant fait que regarder Ruby (de loin et d'un oeil), loin de moi l'idée de vouloir critiquer, mais en ce qui concerne une quelconque concurrence (jolie phrase :) entre Ruby, Golang, Clojure et Node, je dirai que c'est pas fait pour les mêmes choses.
Je m’explique:
Ruby, pour ce que j'en ai vue est très utilisé pour le développement web (avec un framework, on est pas maso), l'administration serveur et quelques outils cli. (c'est un langage qui à l'air pratique à l'usage)
Go à l'air sympathique pour le développement réseau (système d'après ses créateurs) au sens large (outils cli, admin et serveurs ..etc) et apporte le typage statique, la compilation et les binaire statique facile a distribuer.
Clojure, alors lui est magnifique (sérieusement c'est un jolie langage et puis Leiningen bits Ant/Maven/…) mais alors pourquoi avoir construit un LISP/Scheme par dessus toute la stack java ? (c'est une vraie question), à mes yeux, si je devais utiliser un lisp-1 ou -2 d’ailleurs, j'utiliserai bien volontiers un compilo vers du natif à la place de l'immonde (dans le sens de trop gros/lourd/compliqué) java stack.
Node, que dire sinon que c'est un framework et pas un langage. Mais si on veut évoquer le js alors je dirais simplement aller voire sur altjs pour voire le nombre de meta-compilo vers js pour comprendre qu'il y a un gros problème dans les fondation du langage.
P.S. : Mon premier poste \ø/ et super boulot les gars super site.
P.S. (hors-sujet) : Désoler pour l'orthographe, mais je suis français et ai été à l'école en France, sois deux grossières erreurs, vue le système scolaire que l'on nous imposes.
KISS
[^] # Re: Oui mais...
Posté par xcomcmdr . Évalué à 4.
Ben tous ces langages sont plutôt généralistes, à la fois de part leur conception et les bibliothèques disponibles. Par exemple, pour Ruby, certes Ruby est surtout connue à travers Ruby On Rails, mais rien n'empêche le langage d'être utilisé pour tout et n'importe quoi (sauf les environnements où on ne peut avoir la VM Ruby, comme l'embarqué. Ou pour les applications où Ruby serait jugé trop lent.).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Oui mais...
Posté par Midnight . Évalué à -2.
Généraliste oui, je suis d'accord avec toi mais plus pratique pour certaines choses que pour d'autres.
Ruby en tant que langage de script est adapté au … attention les mirettes, scripting ;) et donc pas forcement en concurrence avec les langages cités.
Là ou il peut êtres sur un pied d'égalité ce serrai en comparaison avec Python, Perl, TCL.
Par contre pour ce qui est de la disparition du GIL et tout ce qui vas avec (SMP, utilisation des cores et tout et tout), pour un langage de script, je me pose des questions sur l'utilité de la chose.
KISS
[^] # Re: Oui mais...
Posté par xcomcmdr . Évalué à 5. Dernière modification le 07 octobre 2013 à 20:21.
define "langage de script".
Python et Ruby (souvent décrits "langages de scripts") sont avant tout des langages orientés objet, et multi-paradigmes.
Ce n'est pas l'usage traditionnel du langage qui définit les possibilités du langage.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Oui mais...
Posté par Sekigo . Évalué à 1.
Pour moi, c'est un langage qui "lie" des bibliothèques plus bas niveau entre elles, et abstrait l'utilisation au mieux. Python répond facilement à cette définition. Il est excellent pour du scripting rapide et propre (ce que je demande à un langage de script).
Ruby, j'ai un peu plus de mal à l'appréhender, n'ayant jamais eu l'occasion de le manipuler. Pour moi, c'est un mélange entre Python et JS. J'aime bien ces deux langages qui ont leurs propre méthodologie, Ruby peut éventuellement me plaire.
Mais je dois déjà terminer mon apprentissage de Haskell (qui ne me servira probablement jamais dans un environnement professionnel…).
[^] # Re: Oui mais...
Posté par grim7reaper . Évalué à 4.
Si tu restes en France oui évidemment…
Sinon, Haskell est utilisé dans le monde pro’(y’a une une petite liste ici)
J’ai déjà vu passer plusieurs offres d’ailleurs.
[^] # Re: Oui mais...
Posté par neil . Évalué à 3. Dernière modification le 08 octobre 2013 à 21:47.
Il y a assez souvent des offres Haskell sur /r/haskell, ou sur Functional Jobs. Sans compter l'entreprise mentionnée dans ton (Sekigo) icône, qui débauche les meilleurs hackers de ghc.
[^] # Re: Oui mais...
Posté par neil . Évalué à 2. Dernière modification le 09 octobre 2013 à 19:11.
Quand on parle du loup… Simon Marlow (ancien développeur du compilateur Haskell de référence, GHC, et auteur du livre Parallel and Concurrent Programming in Haskell, qui avait été présenté en dépêche) vient de faire un podcast sur le projet Haxl (en Haskell chez Facebook).
[^] # Re: Oui mais...
Posté par reno . Évalué à 1.
Excellent? Bof, pas de possibilité de forcer la déclaration de variable (l'équivalent d'use strict en Perl), pas de typage statique possible (comme Groovy).
Python est un bon langage que j'aime bien mais il est loin d'être "excellent" malheureusement..
[^] # Re: Oui mais...
Posté par Sekigo . Évalué à 3.
C'est bien ce que je dis, il est excellent pour du scripting rapide et propre :)
Blague à part, autant pour la déclaration de variable, je suis plus ou moins d'accord, mais ça fait un tas de ligne en trop. Ce que j'accepte dans un langage compilé, mais pas dans un langage de script.
Le typage statique n'a aucun intérêt en Python, parce que ce n'est pas dans sa philosophie (je pense en particulier aux variable-références). Et je n'en ai jamais ressenti le besoin parce que, par exemple, pour ce que j'accepte comme argument dans les fonctions, je ne vérifie jamais le type, je m'assure qu'il a les propriétés adéquats. Si l'objet est un dict qui veut se travestir en string, grand bien lui fasse, du moment qu'il est capable de me sortir une string (et ça facilite grandement les tests unitaires). Je sais que ça peut sembler incohérent à d'autres développeurs, mais si vraiment j'ai besoin de faire un tas de vérification sur les types, j'utilise un langage compilé parce que ça demande une bonne machinerie que je qualifierais de bas niveau. Tout ce que je demande à un langage de script, c'est qu'il ne soit pas faiblement typé en allant me mélanger des choux et des carottes pour me donner un chat, sans me prévenir avant.
Évidemment, c'est très subjectif, et c'est propre à chaque développeur/équipe. Pour moi, je reste sur ma position, c'est un excellent langage pour les besoins que j'ai quotidiennement. Il ne m'a jamais fait défaut et fait des trucs dans le dos que je ne voulais pas. Bien entendu, je connais assez bien le langage, et ça doit être la même chose pour une personne habitué de longue data à perl/ruby/autres.
Je conçois tout à fait que pour quelqu'un d'autres, le fait d'avoir les déclarations de variables ou le typage statique soit un préliminaire indispensable pour tout excellent langage. Nous n'avons pas les mêmes attentes, voilà tout.
[^] # Re: Oui mais...
Posté par reno . Évalué à 5.
Euh, tu sais on est plus dans les années 80 avec déclaration séparée..
Maintenant dans les langages de bon gout, une déclaration de constante/variable c'est juste un mot clef: "def x = valeur' ou "var x = valeur" le type est inféré..
Et si tu as besoin de spécifier le type "def/var x : type = valeur": pas de ligne supplémentaire dans les 2 cas, ce qui évite que x soit déclaré mais pas initialisé.
Pas d'accord, par exemple ça m'aurait permis de gagner pas mal de temps sur un script ou je passais sans m'en apercevoir un pointeur de fonction et non pas le résultat de la fonction (oubli d'un ())..
Note bien que le langage dont je parlais Groovy n'est pas uniquement statiquement typé: il a les deux!
Typiquement tu commence par faire un script sans préciser les types et si ça ne marche pas comme tu le voudrais ou si tu as besoin de perf, tu rajoute des annotations de type.
[^] # Re: Oui mais...
Posté par neil . Évalué à 2. Dernière modification le 09 octobre 2013 à 19:36.
Il n’y a pas que pour les déclarations séparés. L’inférence de type, les fonctions de haut niveau, les syntaxes avancées, et les puissantes bibliothèques standards font qu’un code Haskell (typage fort) est beaucoup plus concis qu’un code Python. Un exemple bateau, imagine que je veuille définir une fonction qui trie, supprime les doublons et inverse, en Haskell ça s’écrira :
Difficile de faire plus concis que ça. En Python, dès que tu veux avoir un niveau d’abstraction même basique, tu perds en performance. En Haskell, dès que tu augmentes le niveau d’abstraction, tu gagnes en rapidité d’exécution, en abstraction sur la réflexion, et en concision de code. Enfin, en même temps vu la rapidité du Python, que ça aille lentement ou très lentement, ça ne changera pas grand chose. On peut aussi remarquer que les déclarations de type ne sont pas obligatoires. Si ces trois fonctions étaient dans une classe (au sens Haskell, pas POO), on pourrait appliquer cette fonction à tout un tas de types, y compris ceux déjà définis dans la bibliothèque standard ou d’autres.
De plus, dès que tu dépasses l’utilisation de Python comme calculatrice, tu as des énormes problèmes en faisant du refactoring. Tout pète, et tu dois relancer continuellement le programme pour t’apercevoir à l’exécution qu’il y a un problème. En Haskell, si ça compile, les chances que ça tourne sont quasi absolues.
[^] # Re: Oui mais...
Posté par reno . Évalué à 6.
Au sujet des choix de langage, ce blog est intéressant( http://roscidus.com/blog/blog/2013/06/20/replacing-python-round-2/ ) il voulait remplacer du Python, il a évalué plein de langages (dont Haskell qui ne lui a pas convenu trop différent du code actuel) et il a choisi OCaml en final.
[^] # Re: Oui mais...
Posté par neil . Évalué à 3.
C’est un post de blog pas mal, du point de vue du développeur qui souhaite transformer son code Python dans un langage compilé. Son code Haskell ressemble extrêmement à du OCaml, il est notamment très verbeux, n’utilise pas les possibilités de la bibliothèque standard (fonctions monadiques ou d’environnement par exemple), mais ça reste une vue très honnête sur les langages qu’il compare.
[^] # Re: Oui mais...
Posté par Midnight . Évalué à -3.
Sur la définition d'un langage de script je serais plutôt d'accord avec Sekigo.
Alors là je crois que tu mélange tout. Sa n'a juste rien a voire donc je sais pas trop comment argumenter.
Ah si je sais : "Tu préfère quoi, une jambe en bois ou des dents en mousse ?" ;)
En effet, si on met de coté les DSLs, tout langage généraliste est par définition capable de tout faire (le truc de Turing :) par contre si je te dit qu'il ne faut pas compter sur moi pour implémenté un OS en Ruby, est-ce que tu me comprend ?
Je crois que c'est aussi pour sa qu'il existe tant de langages généralistes ou pas d’ailleurs.
Enfin comme l'a dit autrefois un humain quelque part "A chaque problème sa solution".
p.s.: Un humain a aussi déclaré "C'est au pied du mur que l'on voit le mieux le mur" donc à prendre avec des pincettes tout de même ;)
KISS
[^] # Re: Oui mais...
Posté par Dr BG . Évalué à 5.
Eh bien non, il te dit juste qu'on s'en fout que ce soit un langage interprété ou non, que ce n'est pas là dessus que doit se fonder le choix d'un langage, mais sur ses caractéristiques plus essentielles. Par exemple qu'il soit objet et multiparadigme.
[^] # Re: Oui mais...
Posté par the_grammar_nazi . Évalué à -3.
[^] # Re: Oui mais...
Posté par Midnight . Évalué à -1.
Merci. dixit post scriptum 2 ;)
KISS
[^] # Re: Oui mais...
Posté par ariasuni . Évalué à 1.
Vu que queluqu’un a relevé, j’explique quand même pourquoi:
Car on peut dire
Désolé est un nom commun, et non un verbe à l’infinitif.
Sinon pour les longs pavés, rien de mieux que Grammalecte (pour LibreOffice et OpenOffice.org). Je m’en sers pour la dépêche que je suis en train de rédiger, et ça rend bien service!
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Oui mais...
Posté par jyes . Évalué à 4. Dernière modification le 09 octobre 2013 à 08:20.
Non. C'est un participe passé : dans « désolé pour l'orthographe », « je suis » est sous-entendu en début de phrase.
[^] # Re: Oui mais...
Posté par ariasuni . Évalué à 0. Dernière modification le 09 octobre 2013 à 20:01.
Au temps pour moi, ça n’est pas un nom commun. Mais ça n’est pas un participe passé pour autant…
En effet, j’ai d’abord pensé que «désolé» était un nom commun comme «pardon» par exemple. Néanmoins, ça fonctionne comme «s’il te plait» qui n’est pas un nom commun.
En réalité, «désolé», «pardon» et «s’il te plait» sont des interjections — même si le dernier de la liste est appelé «locution interjective» vu que c’est une phrase.
Se tromper en corrigeant quelqu’un qui corrige quelqu’un, les grammaro-nazis ne sont plus ce qu’ils étaient. :p
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Oui mais...
Posté par the_grammar_nazi . Évalué à 1.
Un désolé, deux désolés, trois désolées…
# Du pourquoi du GIL
Posté par Sekigo . Évalué à 6.
Je me souviens d'une discussion. Par contre, impossible de me souvenir si c'était sur une mailing list avec Guido dedans ou sur un obscur forum. N'hésitez pas à corriger, c'est de mémoire ce que je vais dire, et elle peut me jouer des tours.
Le GIL (qui oblige l'utilisation d'un seul thread. Contrairement à un processus, un thread partage l'espace mémoire avec ses autres potes thread) a été introduit dans Python pour simplifier l'implémentation du langage. Plus tard, des personnes ont voulu débrayer le GIL et Guido n'a pas été super enthousiaste, car il ne voulait pas voir débarquer les soucis de la programmation concurrente. Après, il y a une histoire avec ces personnes qui ont crée Stackless Python, mais je n'ai pas très bien compris si il y avait encore un GIL dedans. Bref.
Une autre raison pour le GIL, d'après Guido, c'est la perte de performance sur l'ensemble du langage. Si j'ai bien compris, le fait de débrayer le GIL oblige à faire un tas de vérification sur une large portion du langage pour éviter les deadlock, inversion de priorité et autres joyeuseté de la prog concurrente, ce qui serait ballot pour quelqu'un qui ne s'intéresse pas vraiment aux threads. Ces vérifications seraient bien plus couteuse que le fait d'empêcher le multi-threading.
Cet histoire de GIL est donc une histoire de compromis. Si quelqu'un est capable d'apporter un compromis qui penche plus en faveur du multi-thread, nul doute que ce sera intégré à l'implémentation standard.
Désolé d'avoir parasiter ce fil Ruby, mais j'imagine que ça doit être la même chose pour l'implémentation de référence en Ruby.
[^] # Re: Du pourquoi du GIL
Posté par jeberger (site web personnel) . Évalué à 4.
Note pour compléter que Python a un module multiprocessing, qui permet de faire du vrai multi tâches (i.e. sans GIL) de manière simple en gérant plusieurs processus un peu comme s'ils étaient des threads. Pour autant que je sache, Ruby n'a pas d'équivalent pour l'instant bien que certains considèrent que ce serait quelque chose d'intéressant à avoir…
[^] # Re: Du pourquoi du GIL
Posté par xcomcmdr . Évalué à 4. Dernière modification le 07 octobre 2013 à 23:18.
J'ai fait du multiprocessing avec Ruby 1.9 et DRb : http://www.ruby-doc.org/stdlib-2.0.0/libdoc/drb/rdoc/DRb.html
Ça m'a permis d'exploiter deux cores en même temps.
Après, ce n'est pas un strict équivalent, mais c'est possible au moins de faire du multiprocessing.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Du pourquoi du GIL
Posté par Trollgouin . Évalué à 3.
Tiens, je n'avais pas pensé à utilisé une couche de Ruby distribué pour contourner les limitations des threads de Ruby 1.9 (enfin natifs mais toujours avec GIL). Merci pour l'astuce. Je vois des plus qu'on peut utiliser des sockets Unix pour éviter de se farcir une couche TCP, sympa!
Par contre, ça a l'air plus lourd que de la programmation multi-threadée classique… Tu en penses quoi, en terme de surcoût de complexité du code ?
[^] # Re: Du pourquoi du GIL
Posté par xcomcmdr . Évalué à 3.
Ben c'est un architecture client/serveur, faut s'habituer à la logique de DRb.
Mais comme DRb fournit tout, le surcoût en ligne de codes est léger.
Après il y a d'autres manières de faire du multiprocess (IO.popen, par exemple), mais c'est bien plus fait pour juste lancer une commande.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Du pourquoi du GIL
Posté par Yusei (Mastodon) . Évalué à 3.
En ruby, j'utilise le module parallel, et ça marche plutôt bien pour mon usage (parallélisme de données). Je ne connais pas multiprocessing, mais ça a l'air d'être le même genre de fonctionnement.
[^] # Re: Du pourquoi du GIL
Posté par wolowizard . Évalué à 3.
Pendant ce temps là chez pypy, on enlève le GIL:
http://za.pycon.org/talks/15
et je crois que sous IronPython il n'y a pas de Gil non plus (https://wiki.python.org/moin/IronPython).
Par contre, oui ces interpréteurs n'ont pas le même avancement que CPython et il manque quelques bibliothèques bien utiles…
[^] # Re: Du pourquoi du GIL
Posté par grim7reaper . Évalué à 6.
Oui, tout comme IronRuby.
Ou encore Jruby et Jython (étant basé sur la JVM ils font du vrai multithreading évidemment).
[^] # Re: Du pourquoi du GIL
Posté par Antoine . Évalué à 5.
Non non. Le GIL oblige la sérialisation des threads quand ils exécutent du code Python. Mais tu peux très bien créer des tas de threads en Python (et ceux qui font des I/O s'exécuteront bien en parallèle).
C'est surtout qu'enlever "naïvement" le GIL fait baisser les performances mono-thread d'environ 30 ou 40%.
# Macruby ?
Posté par karteum59 . Évalué à 2.
Question de béotien: ça a l'air de ressembler un peu à Macruby, qui utilise aussi LLVM. Les deux projets sont-ils en concurrence ? (modulo le fait que Macruby ne fonctionne que sous Mac, mais j'imagine que l'adapter à d'autres plate-formes POSIX ne devrait pas être une tâche insurmontable…)
[^] # Re: Macruby ?
Posté par Thomas J. (site web personnel) . Évalué à 4.
MacRuby est au Mac, ce que JRuby est à Java, ce qu'IronRuby est à .Net :
- MacRuby te permet d'accéder à l'environnement de programmation Cocoa. D'ailleurs, le projet dérivé RubyMotion te permet de programmer en Ruby sur iOS !
- JRuby te permet d'appeler des fonctionnalités Java (par exemple, la très puissante JDBC)
- J'imagine que IronRuby (il existe encore lui ?) te permet de faire la même chose avec le .NET Framework de Microsoft.
Concernant Rubinius, le moteur du projet semble être d'implémenter un interpréteurs Ruby écrit essentiellement en Ruby.
Bref, même s'il s'agit d'interpréteurs Ruby dans tous les cas, le but de ces projets n'est jamais tout à fait le même.
[^] # Re: Macruby ?
Posté par Midnight . Évalué à 0.
Salut tout le monde, au faite c’était ma première participation sur linuxfr.
Pour ce commentaire je voudrais juste comprendre pourquoi les gens continuent d’appeler Ruby, Python, TCL, Perl/… des langages interprétés ?
Ils sont bien semi-interprété, mais derrière c'est pourtant bien un bit-code qui est utiliser par la VM ( -> VM et non interpréteur donc).
Et qu'on vienne pas me dire que la VM interpréte le bit-code :).
KISS
[^] # Re: Macruby ?
Posté par Yusei (Mastodon) . Évalué à 3.
La raison principale est qu'on les lance habituellement en appelant un programme sur le fichier source (ruby fichier.rb) au lieu d'exécuter un fichier exécutable.
Mais dans l'absolu, la frontière entre les deux est ténue, mouvante, et ne sert pas à grand chose.
[^] # Re: Macruby ?
Posté par ariasuni . Évalué à 3.
Quand on compile du Java, ça fonctionne partout (enfin tant qu’on en change pas de version majeure de Java), c’est prévu pour être redistribuable.
Quand on lance un programme Python, le bytecode (qui se prononce «baïtecode» et qui signifie «code octal») produit est spécifique à la version de Python, et n’est pas facilement redistribuable.
Bref, c’est une philosophie complètement différente. Un exemple tout bête, comme on veut pas attendre longtemps avant de lancer le programme, un bytecode Python sera moins optimisé qu’un bytecode Java (qui expliquent en partie la différence de performances). D’ailleurs j’ai l’impression que beaucoup plus de choses sont gérées au runtime dans ces langages interprétés.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Macruby ?
Posté par tyoup . Évalué à -2.
Merde, encore quelqu'un qui y croit…
[^] # Re: Macruby ?
Posté par ariasuni . Évalué à 2.
C’est quoi cette réponse hautaine? Si t’as un argument, vas-y je t’écoute.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Macruby ?
Posté par tyoup . Évalué à 1.
Ben.. par où commencer ? Des arguments j'en ai quelques uns, alors, petit, écoute moi bien car je suis effectivement très hautain MOI. Sorti de ton monde merveilleux où tu as codé ton petit hello world tu verras que l'écosystème java est très fragmenté et que cela pose rapidement des petits soucis. Tu te rendras compte qu'avoir une dépendance JNI peut être fatale en terme de portabilité. Tu verras peut-être des applications qui ont été conçues avec des dépendances sur des briques logicielles spécifiques à un serveur d'application JEE et qui ne pourront pas tourner sur un autre serveur JEE. Tu verras peut-être qu'une librairie devra peut-être être intégrée de diverses manières dans différents contextes. Tu verras peut-être des librairies qui ne sont pas compatibles avec ton classpath alors qu'ailleurs ça aurait été comme sur des roulettes. J'espère juste que tu aies tout plein de contre arguments :-).
[^] # Re: Macruby ?
Posté par ariasuni . Évalué à 1.
Non je n’ai pas de contre-exemples. Merci de ta réponse, c’était très instructif (sincèrement).
Je préfère ça qu’un commentaire trollesque et pas très sympa qui n’apporte aucune information. :p
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Macruby ?
Posté par djano . Évalué à 4.
Pareil pour toute dépendance vers une librairie native pour Python, etc.
Pareil pour toute appli Python WSGI qui dépend de fonctionnalités non specificiées d'un serveur précis.
La gestion des dépendances en Python est pas connue pour etre super facile non plus.
J'ai utilisé l'exemple de Python, mais j'aurais pu parler de Ruby, etc.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.