Le gars devra coder en Jakouski s'il veut *modifier* la partie spécifique écrite en Jakouski, mais avec de la programmation par composants qui se fait de nos jours (pour la JVM, c'est OSGi), quelqu'un qui voudra utiliser les fonctionnalités de Jakouski dans son programme ou même l'étendre pourra le faire en Java ou un autre langage de la JVM.
Je n'ai jamais prétendu que la VM résolvait tous les problèmes et la fin de de la guerre dans le monde, si c'est ce que tu as tiré de mes commentaires je suis désolé :).
Ces capacités d'interopérabilité entre langages n'existent que dans les VMs récentes (et en pratique, dans le monde logiciel industriel, que .NET et JVM)... Comme je l'ai déjà dit, l'avantage de cette interop est qu'elle est automatique, transparente et bi-directionnelle, à la différence de bindings C vers Python (qui va faire un programme écrit en C qui tourne sur Zope ?).
Bien évidemment, si quelqu'un veut modifier du code écrit dans un langage donné, il lui faut apprendre ce langage. Comme je l'ai déjà dit (ça aussi), mon problème c'est de passer trop de temps à écrire en Jakouski, pas de modifier légèrement le code. Pour des raisons de séparation des concerns, je ne vais pas faire faire au programme Jakouski des conneries qui dépassent le cadre de son activité ; pour ça j'écrirai une extension qui peut être dans un autre langage.
Il y a aussi le fait qu'en entreprise les langages doivent être validés, donc évidemment on va éviter de coder dans n'importe quel langage sous prétexte qu'il tourne sur la JVM, il faut de bonnes raisons (je me répète).
Enfin inutile de passer encore 3 semaines à discuter de ça, on a chacun nos points de vue issues d'expériences différentes et peut être que tu changeras d'avis, peut-être pas. Je partageais ton opinion donc c'est possible d'en changer... par contre je ne vais pas retourner en arrière. Y'a rien qu'à voir la merde qu'est le classloading avec des dépendances en C++ ou dlopen en C ; les bindings pour chaque langage c'est mieux que rien, mais des bindings on peut aussi en faire pour la JVM (et c'est tout aussi chiant).
[^] # Re: Ça passe très bien :)
Posté par smc . En réponse à la dépêche Jython supporte maintenant Python 2.5. Évalué à 2.
Le gars devra coder en Jakouski s'il veut *modifier* la partie spécifique écrite en Jakouski, mais avec de la programmation par composants qui se fait de nos jours (pour la JVM, c'est OSGi), quelqu'un qui voudra utiliser les fonctionnalités de Jakouski dans son programme ou même l'étendre pourra le faire en Java ou un autre langage de la JVM.
Je n'ai jamais prétendu que la VM résolvait tous les problèmes et la fin de de la guerre dans le monde, si c'est ce que tu as tiré de mes commentaires je suis désolé :).
Ces capacités d'interopérabilité entre langages n'existent que dans les VMs récentes (et en pratique, dans le monde logiciel industriel, que .NET et JVM)... Comme je l'ai déjà dit, l'avantage de cette interop est qu'elle est automatique, transparente et bi-directionnelle, à la différence de bindings C vers Python (qui va faire un programme écrit en C qui tourne sur Zope ?).
Bien évidemment, si quelqu'un veut modifier du code écrit dans un langage donné, il lui faut apprendre ce langage. Comme je l'ai déjà dit (ça aussi), mon problème c'est de passer trop de temps à écrire en Jakouski, pas de modifier légèrement le code. Pour des raisons de séparation des concerns, je ne vais pas faire faire au programme Jakouski des conneries qui dépassent le cadre de son activité ; pour ça j'écrirai une extension qui peut être dans un autre langage.
Il y a aussi le fait qu'en entreprise les langages doivent être validés, donc évidemment on va éviter de coder dans n'importe quel langage sous prétexte qu'il tourne sur la JVM, il faut de bonnes raisons (je me répète).
Enfin inutile de passer encore 3 semaines à discuter de ça, on a chacun nos points de vue issues d'expériences différentes et peut être que tu changeras d'avis, peut-être pas. Je partageais ton opinion donc c'est possible d'en changer... par contre je ne vais pas retourner en arrière. Y'a rien qu'à voir la merde qu'est le classloading avec des dépendances en C++ ou dlopen en C ; les bindings pour chaque langage c'est mieux que rien, mais des bindings on peut aussi en faire pour la JVM (et c'est tout aussi chiant).