On Thu, Oct 14, 2004 at 04:11:05PM +0200, Yves Martin wrote:
> Donc on passe par l'étape "prototype" - ce qui a mon avis a conduit à
> cette idée de réutilisation d'une VM existante.
Oui, il est courant de passer pas une VM existante pour prototyper des
idées.
>
> > Oui, c'est une solution ... plein d'embuche. Une solution interessante.
> > Une autre serait d'incorporer une JVM embarquée dans le noyau.
>
> Le noyau ?!? J'ai l'impression que nombreux pensent que quand tout sera
> dans le noyau on aura les meilleures performances...
Oui, on aura une meilleure performance. L'histoire même d'Unix nous le
montre. Le pb est effectivement après la maintenabilité d'une telle VM,
sa stabilité, etc.
Le fait de pouvoir être dans le noyau ppurrait permettre par exemple
d'utiliser la gestion mémoire sans avoir à passer par des appels
systèmes par exemple. Par contre, le code Java des applis lui restera portable.
>
> > Non, ce dont tu parles en guise de recherche, c'est comment faire une JVM
> > qui soit efficace tout simplement, avec les erreurs de conceptions que
> > l'on a.
>
> Conception ? Non, la JVM est une spécification qui découle de besoins
> définis par la "portabilité" (en fait spécificité des systèmes cibles)
> et les contraintes du langage Java.
> A mon avis, la recherche consiste justement à définir une conception et
> une implémentation efficace de la spécification.
C'est ce que j'ai dis ... ou ce que je voulais dire :)
> Si j'ai compris le message, il faut que je conseille SmallTalk a mon chef.
> Mais tu l'as dit toi-même, peu le comprenne vraiment. Mon chef ne risque
> pas d'être content si les Vietnamiens ne savent pas écrire en SmallTalk
> ou si les ingénieurs européens "smalltalkistes" coûtent deux fois plus
> chers...
Le pb de Smalltalk, soit tant que ce soit un pb, est que sa
programmation est en faite ... de la méta programmation. A l'époque
donc, c'était assez déroutant. Maintenant, on s'appercçoit que peu à peu
on tend vers se genre de programmation. Néanmoins, il existe déjà un
langage cohérent qui permet de programmer simplement de cette manière
sans artifices : Smalltalk.
Contrairement à tout ce qui existe, Smalltalk est un véritable
environnement/système objet.
Je pense que pour mieux l'apprécier rien ne vaut que l'essayer.
Tu peux essayer squeak pour te donner un apperçu.
Je ne pense pas que les ingé Smalltalk coûtent plus chère. Je pense que
l'on peut en trouver plus facilement que l'on croit. Bcp de concepteurs
objets connaissent déjà Smalltalk et ne demanderaient qu'à y revenir si
on leur donnait l'occasion. Mais je peux me tromper.
>
> On m'a aussi beaucoup parlé de Eiffel. Influence Suisse de l'EPFZ oblige.
> Perl n'est pas un langage très joli (à mon avis) mais sa machine virtuelle
> est impressionnante. Vivement, Parot et Perl 6...
Eiffel est effectivement un très bon langage. Vous avez une bonne
influance là bas :) Eiffel a l'avantage d'être encore un langage simple et
de plus l'un des plus modernes ... alors qu'il est apparu dans les
années 80 !
Dans la lignée de Perl, il y a Python ou Ruby. Python a l'avantage
d'être plus mature et d'être compilé en bytecode intérprétable par son
interpreteur. En plus, on peut compiler du Python en bytecode Java !
--
Miguel Moquillon
jabber:moqui@???, moqui@???
http://miguel.moquillon.free.fr
