jeudi 29 janvier 2009

Disque dur externe et capitalisation

Pourquoi faire simple quand on peut faire compliqué. Étant en possession d’un disque dur externe de 120Go Western Digital (il n'en font plus des comme ça, le remplaçant étant le Western Digital My Passport Essential), j’ai pour objectif d’y déposer tout mon environnement de travail, que ce soit les applications ou les données que j’utilise au jour le jour.

Mon but est de ne plus avoir besoin de quoi que ce soit sur le disque dur interne du PC sur lequel je travaille, de considérer réellement le PC comme un terminal banalisé, interchangeable de façon transparente avec n’importe quel autre PC Wintel compatible.

Mais pourquoi tant d’efforts pour être indépendant de la machine ? Tout simplement parce que je suis parti du constat suivant :

- tout d’abord entre mes lieux de travail (j’en ai plusieurs), chez moi, chez des amis ou la famille, je suis amené à travailler avec 8 PC différents :
  • 3 PC au travail (1 desktop pour le développement, 1 ordi portable, 1 desktop chez le(s) client(s) )
  • 4 ordinateurs chez moi (3 ordi portable + 1 vieux PC de 1998)
  • 1 PC différent par ami ou la famille

- Sur tout ces PC, des systèmes d’exploitations différents sont installés (principalement Windows et Linux, mais aussi un OpenBSD).

- Quand je change de projet, de mission ou de client, quand le temps passe et que mes PC deviennent obsolètes, je dois les changer et me retrouve avec des PC vierge de toute installation environ tous les deux ans.

- J’aime travailler avec des environnements riches en outils (130 applications installées sur mon disque dur externe pour le moment)

Bref, l’installation d’environnements complets entièrement adaptés à mes besoins prend beaucoup de temps et je ne peux pas me permettre d’installer certains outils sur tous les PC que je rencontre.

Ainsi, il est apparu bien pratique de posséder un disque dur externe d’une capacité suffisante pour y stocker :

- toutes les applications de bureautique, de développement (y compris des serveurs comme par exemple Jboss Server, Apache httpd/php/mysql), de loisirs dont j'ai besoin

- Toutes mes données de travail, et ce de façon sécurisée et facilement backupable.

Globalement, sur le disque dur externe, j’ai :

- à la racine, un fichier script d’initialisation par type d’environnement (1 pour Windows, 1 pour Linux, etc.) qui s’exécute au branchement sur le PC du disque dur et configure le PC d’une certaine manière pour me permettre de lancer n’importe quelle application sans problème. Il s’agit notamment de déclarer des variables d’environnement utilisées par les outils.

- Dans un répertoire soft non-crypté, j’ai rassemblé l’ensemble des applications Windows de mon environnement. Chaque application est dans son répertoire dont le nom est construit de la manière suivante : nomduproduit-version (par exemple emacs-22.2). Les applications sont la plupart du temps déposées directement dans ce répertoire, sans configuration particulière. Je ne backup pas le répertoire soft, considérant que si le disque dur est défaillant, je pourrai toujours retrouver les applications sur internet et les réinstaller.

- Je crée des volumes truecrypt (plusieurs s’il le faut) pour y stocker toutes mes données de travail. Ces volumes sont encryptés avec un mot de passe dur. Je crée des volumes truecrypt d’une taille de 4Go histoire de pouvoir facilement les graver sur un DVD-ROM pour faire des backups, et formatés en FAT32 histoire de ne pas avoir de sécurité associée à tous les fichiers et pouvoir ainsi passer de PC en PC sans problème. Les scripts de démarrage me demandent mon mot de passe et montent automatiquement ces volumes sur le système hôte. L'intérêt de truecrypt, c'est qu'il fonctionne aussi sous linux, ça permet d'ouvrir mes volumes truecrypt quelque soit le système d'exploitation.

- Un script de fermeture (appelé « stop ») permet de déconfigurer proprement l’environnement pour le remettre comme précédemment, d’arrêter toutes les applications issues du disque dur externe et de démonter les volumes truecrypt

- Un menu avec des liens vers toutes les applications installées sur mon DD externe est placé dans le menu Démarrer / Programme de l’utilisateur en cours. Cela permet de retrouver des liens pour lancer toutes les applications disponibles.

- J’ai même mis un Raccourci vers Emacs dans le menu contextuel SendTo (Envoyer vers) histoire de pouvoir envoyer n’importe quel fichier vers mon éditeur préféré.

Concrètement, lorsque je branche mon DD externe sur un machine Wintel, une fenêtre me demande automatiquement mon mot de passe truecrypt, puis monte les volumes truecrypt grâce à ce mot de passe et configure tout l’environnement pour permettre à toutes les applications de fonctionner.

Je lance automatiquement svnserve sur un repository placé sur un disque crypté. J’ai ainsi tout un environnement de développement avec versionning prêt à l’emploi et configuré pour s’intégrer avec Emacs.

Ainsi, dès que j’ai une nouvelle application à essayer, des nouveaux composants emacs lisp à installer, le temps que je passe à installer les composants sur le disque dur externe est capitalisé pour l’avenir et je n’ai pas à refaire toutes les manipulations sur chaque PC que j’utilise.

Pour ce qui est des applications Windows qui doivent absolument utiliser la base de registre, j’utilise l’outil sandboxie qui permet de faire fonctionner toute application dans un bac à sable entièrement fermé. Mais finalement, après 2 ans d’utilisation de mon disque dur externe, je m’aperçois que je n’utilise jamais d’application de ce type, et donc je ne recours jamais à sandboxie.

Quand mon installation prend un certain nombre d’opérations manuelles non évidentes, ou pas très bien décrites dans le manuel utilisateur, je me construis une check-list reprenant l’ensemble des étapes que j’ai réalisé pour installer le logiciel. Cela m’assure que si mon disque dur externe plante, je peux très rapidement réinstaller le logiciel sans trop réfléchir.


Globalement, je ne regrette vraiment pas d’avoir tout passé sur ce disque dur externe. Avec 5400RPM sur USB 2.0 (480Mb/s), la vitesse de transfert me suffit amplement pour travailler correctement.

jeudi 22 janvier 2009

La base de données cette inconnue...

Aujourd'hui, la plupart des applications développées sont des applications Web. Non pas qu'on ne construise plus d'autres types d'applications, mais, en quantité d'applications développées, ce sont bien les applications de types Web qui sont les plus nombreuses.

Quand on analyse ce qui constitue la plupart des applications Web, on s'aperçoit ensuite que chaque site Web est secondé par une base de données en arrière plan. Ce qui fait la force du Web c'est la facilité avec laquelle il est possible de publier des données en grand nombre et d'offrir des fonctionnalités sur ces données. Quand les années passent, les technologies de présentation des données (client lourd, client Web...) sont les premières à faire les frais de l'apparition de nouveaux concurrents. Mais, en arrière plan, la base de données est toujours là, fidèle au poste, toujours aussi importante dans l'architecture globale de l'application.

Quand on veut faire carrière dans l'informatique, on cherche à maitriser les outils dont on dispose et qui sont généralement mis en œuvre dans les projets. Personnellement, je n'ai pas le temps de réapprendre tous les 3 ans une nouvelle technologie de présentation (par exemple, en ce moment, c'est le phénomène Adobe AIR et toutes les technologies Flex qui ont le vent en poupe). Je n'ai plus l'age de passer des heures inconsidérées sur mon ordi à essayer la moindre nouveauté.


Et puis, les technologies se succédant les unes aux autres, on s'aperçoit que, bien que nouvelles, elles ne sont pas innovantes, ce ne sont que de nouvelles créations, très reluisantes, mais n'apportant pas de réelle nouveautés. Dans ce cadre là, un programmeur a tout intérêt à maîtriser au moins un système de gestion de base de données quel qu'il soit pour avoir à se pencher sur les défis réels de la mise en place de sites web : la montée en charge d'une application à accès concurrents.

Le coût global d'une requête Web sur un site Web secondé par une base de données est en grande partie due à l'accès et au traitement de la donnée, pas à se mise en forme à travers des pages HTML, Ajax, ou autre. Avec un jeu de données de test automatisé, et un grand nombre de requêtes clientes, le programmeur est tout de suite confronté à un problème de capacité. Il doit surtout faire preuve de maîtrise de son système de gestion de bases de données pour pouvoir le régler correctement pour répondre à la demande, et ce pour toutes les requêtes concurrentes.

La maîtrise d'une technologie comme Oracle, PostgreSQL ou MySQL prend déjà tant de temps que je ne vois pas où est l'intérêt de passer tout son temps sur des technologies de GUI qui évoluent au gré des modes et du temps. De toute manière, il existe de nombreux outils de développement suffisamment évolués pour ne pas avoir à taper une ligne de codes pour réaliser les tâches les plus classiques de la couche présentation.

Je ne comprend pas pourquoi tant de développeurs que j'ai côtoyé utilisent le système de gestion de base de données comme une boîte noire, comme étant juste un système de persistance d'objets. L'erreur classique est de trouver du code itératif dans une couche métier Java alors qu'une simple requête SQL aurait suffit. Les systèmes de persistance comme Hibernate ont longtemps promu des méthodes de programmation où le système de gestion de bases de données est réduit à une réceptacle abstrait et dont on doit absolument pouvoir interchanger si l'humeur nous en dit. Or, tous ces systèmes d'abstraction vis à vis du SGBD sont finalement la plus part du temps complètement inutiles sachant :

- qu'il est extrêmement rare de changer brusquement de technologies de base de données puisque, à part faire un mauvais choix, la plus part des SGBD sont maintenant extrêmement bien rodés pour ce qu'ils ont à faire.

- qu'on a tout intérêt à tirer au maximum partie des services offerts par le SGBD pour réaliser les fonctionnalités à implémenter car le paradigme de programmation SQL, bien qu'imparfait, reste toujours supérieure à une approche procédurale classique quand il s'agit de traîter des lots de données.

- si on doit utiliser un SGBD payant comme Oracle, c'est vraiment du gâchis de le considérer comme une boîte noire et de ne pas utiliser toutes les fonctionnalités que vous avez chèrement payées.

Tom Kyte résume très bien cette situation dans son livre Expert Oracle Database Architecture :
The single most common reason for database project failure is insufficient practical knowledge of the database - a basic lack of understanding of the fundamental tool that is being used. The black box approach involves a conscious decision to protect the developers from the database - they are actually encouraged to not learn anything about it ! In many cases, they are prevented from exploiting it. The reasons for this approach appear to be related to FUD (Fear, Uncertainty, and Doubt). The accepted wisdom is that database are "hard", and that SQL, transactions, and data integrity are "hard". The solution: don't make anyone do anything "hard". They treat the database as a black box and have some software tool generate all of the code. They try to insulate themselves with many layers of protection so that they do not have to touch this "hard" database.
Philip Greenspun le disait déjà de son temps dans Philip and Alex's Guide to Web Publishing :
Any interesting Web/RDBMS problem can be solved using just the standard software shipped with the RDBMS. If you can't solve it with those tools, you can't solve it with any tool no matter how glitzy and turnkey. The critical element is not the tools, it is the programmer.

In terms of maintainability, clarity of code, software development cycle, and overall Web server performance and reliability, the simplest tools such as Microsoft Active Server Pages are superior to virtually any of the expensive Web development systems out there.

Il est vraiment dommage de ne pas s'intéresser à son SGBD car il permet pourtant de réaliser de grandes applications, solides et montant correctement en charge. De plus, il permet de faire face à des situations délicates de façon élégante.

jeudi 15 janvier 2009

Propriété intellectuelle et développement au forfait

A chaque fois que je développe un logiciel au forfait, je ne sais jamais quelle licence mettre en haut de chaque fichier source. Les contrats de développement au forfait ne sont pas toujours explicites sur le sujet de la propriété intellectuelle. Quelle est la loi qui s'applique ? quelles sont les jurisprudences en la matière ? Je suis tombé sur la collection de ressources juridiques du Munci qui donne pas mal de pointeurs vers des documents intéressants, notamment à propos du contrat de développement de logiciel spécifique. La nature juridique est énoncée en ces termes :
La nature juridique du contrat de création (développement) de logiciel ne pose donc pas de problème particulier : l’élaboration d’un logiciel constitue une prestation de service et entre donc dans le cadre d’un contrat d’entreprise ou louage d’ouvrage (article 1710 Code civil contrat « par lequel l’une des parties s’engage à faire quelque chose pour l’autre moyennant un prix convenu par elles »).

L’originalité juridique du louage d’ouvrage est double : le contrat est valable, bien que les prestations essentielles, l’ouvrage et le prix, puissent être dans les faits largement indéterminées ; le concepteur de logiciel ne peut savoir à l’avance quelles seront les difficultés présentées par celui-ci et le prix dépendra souvent du temps passé qui ne peut être fixé avec précision. Ces contrats échappent à la nullité car les parties s’entendent pour enfermer l’indétermination dans certaines limites.
En effet, ce qui est assez déroutant pour le chef de projet néophyte, c'est que le contrat n'est pas complet sur ce qui va être livré tout en obligeant à s'engager sur le résultat. La programmation s'apparente à une œuvre de l'esprit et tombe ainsi sous la loi des droits d'auteurs :
Le contrat de développement n’emporte pas cession automatique de la propriété du logiciel ; les règles du contrat de louage veulent que la propriété du résultat soit transmise au client, mais le contrat doit le prévoir expressément, faute de quoi le droit commun s’applique et c’est le créateur du logiciel qui en est le propriétaire.

Néanmoins, CA Bordeaux 24 sept. 1984 décide que même dans le silence du contrat, le prestataire est tenu de transmettre le code source du logiciel au client afin que celui-ci puisse en faire assurer la maintenance. L’arrêt, isolé, ne va pas jusqu’à dire que le prestataire doit transmettre ses droits de propriété au client, et CA Montpellier (2 juillet 1991) a jugé que « la mise à disposition de l’utilisateur des sources, surtout s’agissant d’un logiciel spécifique, n’est pas de nature à établir une cession de tous les droits d’auteurs ». La doctrine estime toutefois qu’il peut s’agir d’un indice permettant de déduire, combiné par exemple au prix payé, que les droits d’exploitation ont bien été cédés.
Ainsi, si rien n'est dit, le propriétaire du code source est le fournisseur, et celui-ci donne le droit au client d'exploiter (maintenir) le code source uniquement pour son usage personnel. Le code source étant la propriété du fournisseur, il peut réutiliser les sources pour un nouveau projet au forfait. Les marchés publics contiennent toujours une partie cession de la propriété intellectuelle au client et il est malheureusement impossible d'utiliser le code source pour d'autres projets. Ainsi, je met toujours :

Copyright (c) [ANNEE], [PROPRIETAIRE]
All rights reserved.

en haut de chaque fichier source, avec pour PROPRIETAIRE soit ma société si le client ne requiert pas de transfert de propriété, soit le client, s'il y a transfert de propriété. Normalement, un logiciel avec transfert de propriété intellectuelle doit être vendu plus cher qu'un logiciel sans cession de propriété. Il est toujours assez triste de laisser partir du code source qu'on a mis tant de temps à peaufiner, tous les jolis composants réutilisables que vous avez concoctés ne peuvent même pas vous servir. Dans le cas de cession de propriété intellectuelle, cela ne pousse pas à concevoir l'architecture du logiciel pour promouvoir la réutilisation.

Parfois les clauses de cession de propriété intellectuelle sont abusives, c'est ce que nous rappelle le document Clauses et Pratiques des Contrats Informatiques de Droit Privé :
Les prestataires informatiques ont pris note de l’insertion de nombreuses clauses inacceptables dans les contrats parmi lesquelles on compte, notamment, les clauses suivantes :

- Clauses précisant que les spécifications développées par le prestataire dans le cadre de l’exécution du contrat appartiennent au client et cela même dans le cadre de la sous-traitance et lorsque ces développements sont réalisés atour d’un progiciel. [...]

- Clauses donnant le sentiment au prestataire que le client lui impose la cession de la propriété d’un progiciel ou encore la délivrance des codes sources dans le cadre de contrats portant sur des licences d’utilisation de progiciel standard ou en cas de résiliation du contrat,

- Clauses excluant toute possibilité de résilier une licence accordée à un utilisateur lorsque ce dernier l’a revendue à un tiers. Ce type de clause organise la violation du droit d’auteur.

Il convient de prêter attention au moment auquel intervient le transfert de propriété. Les clients demandent souvent au prestataire de prévoir un transfert de propriété au fur et à mesure de la réalisation alors que le transfert doit s’opérer postérieurement au prononcé de la recette sans réserve et après complet paiement.
L'aspect propriété intellectuelle est souvent mise de coté, ignorée, sous-estimée alors qu'elle peut avoir des conséquences importantes sur les projets futurs qu'ils soient chez le client ou chez le fournisseur. Des sociétés entières ont fondé leur succès commercial uniquement sur la propriété intellectuelle, comme par exemple ARM, ou encore Thomson qui tire la majeure partie de son chiffre d'affaire de vente de licence d'utilisation de ses brevets et logiciels.

mardi 13 janvier 2009

Mémorisation, apprentissage et éducation

Tout le monde cherche à être "productif". Mais on peut vouloir être productif dans son travail :
  • soit pour pouvoir faire plus avec autant de temps,
  • soit pour pouvoir faire la même chose avec autant de temps mais avec beaucoup moins d'effort.
En informatique, où les lazy programmeurs sont légions, c'est souvent le deuxième point qui est mis en pratique. C'est bien sur mon cas. Les outils, techniques, procédures, templates servent à faire autant avec beaucoup moins d'effort. Tous ces artifices sont le reflet des limites de nos capacités mentales et physiques... S'il y a bien un domaine où je suis limité c'est ma mémoire. J'ai toujours du mal à retenir des choses sur le long terme...


C'est pour cette raison que j'ai découvert avec énormément de bonheur que les techniques et mnémoniques décrites dans Your Memory de Kenneth L. Higbee, fonctionnent et son vraiment puissantes. Je me suis dit, quand à essayer de nouvelles techniques pour apprendre à mémoriser, la première chose à apprendre est l'ensemble des techniques d'apprentissage décrites dans ce livre.

J'ai utilisé la mnémonique de liaison (Link Mnémonique) pour apprendre l'ensemble des éléments essentiels du livre. Un des principes évoqués est l'organisation du contenu à apprendre. On oubli beaucoup plus vite du contenu non-structuré par rapport à du contenu organisé logiquement. Il est donc conseillé d'organiser ce que l'on apprend autour d'un système d'archivage mental ("mental filing system"). Les mnémoniques sont des outils puissant, mettant en œuvre naturellement tous les principes de base de la mémorisation, dont l'organisation.

Ainsi, j'ai commencé par apprendre la liste des chapitre sur une première chaine de liaison mnémonique, puis sur chaque chapitre j'ai créé une sous chaine de liaison mnémonique pour tous ces sous-chapitres, etc. jusqu'à arriver à mémoriser chaque idée principale de chaque sous-chapitre de chaque chapitre. Ce qui est étonnant c'est avec quelle facilité on arrive à apprendre des choses concrète et visuelle par rapport à des choses abstraites. Grâce à la mnémonique de liaison, on mémorise uniquement des aides à remémoration sous forme d'objet concret et nets, mis en scène avec les objets suivants à travers des scènes frappantes pour l'esprit.

Suite à ce petit succès, qu'est-ce qu'il serait intéressant de retenir pour être encore plus productif en tant qu'informaticien : les design patterns du GoF ? bof..., Java for dummies ? Certainement pas. Tous les trucs et astuces pour nettoyer la maison, évidemment, car avec ça, on optimise le temps passé sur une activité essentielle, cela permet après de se concentrer sur l'informatique. Bon, ok, on peut toujours faire appel à une femme de ménage...

Personnellement, s'il y a un seul bouquin informatique pour lequel je serais prêt à investir du temps à en mémoriser les bonnes pratiques, c'est Code Complete 2 de Steve McConnell, car c'est un bouquin assez "intemporel" (le mot fait rire en informatique) et est assez bien organisé. Mais bien sur, la programmation ne s'apprend pas dans les livres, mais uniquement avec la machine pour interlocuteur.

Il y a la mémoire à court-terme, la mémoire à long-terme et la mémoire sensorielle. Cette dernière sert aussi grandement en informatique. En effet, la mémoire sensorielle est ce qui est le plus essentiel en informatique car c'est elle qui vous permet de taper sur votre clavier à la vitesse d'un éclair. La vitesse de frappe est ce petit secret inavouable du monde de l'informatique. La productivité d'un programmeur se mesure au nombre de caractères à la minute qu'il est capable de débiter puisque le résultat de son travail passe par le clavier.

Enfin, quel que soit le type de mémoire, j’ai toujours l’impression que les techniques de mémorisation sont méprisées par les enseignants, quelles sont vues de haut et ne sont pas considérées comme suffisamment noble comme peuvent l’être la compréhension, la pensée créative et critique, pour être étudiées et transmises à travers de véritables cours d’apprentissage. Kenneth L. Higbee nous rappelle très clairement ce qu’il en est :

Two points may be made regarding the role of memory relative to loftier goals or “more laudable, higher mental processes” in school. First, whether we like it or not, there is lot of straight memory work in school. Education consists of “basic school tasks” involving list and paired-associate learning, as well as “complex school tasks” like meaningful prose learning. […] The fact is that the loftier educational goals are in addition to, not instead of, memorization.

[…] The second point regarding the role of memory in education is that remembered facts serve as the basis for the loftier goals.
Je me rappelle du collège et du lycée, je trouve qu’il aurait été intéressant de connaître ces techniques à ce moment là. Enfin, le passé n’existe plus, seul le présent est important mais la mémoire s’écrit au futur.

dimanche 11 janvier 2009

Incantation Perl

Étant en train de lire Object Oriented Perl de Damian Conway, de petites perles de programmation m'apparurent comme cette merveilleuse façon d'implémenter un itérateur en Perl :
package Iterator;
$VERSION = 1.00;
use strict;

sub new {
my ($class,@data) = @_;
@data = @$class if !@data && ref($class);
bless [ @data ], ref($class)||$class;
}

sub each {
my ($self) = @_;
my @next = splice @$self, 0, 2;
return wantarray? @next : $next[0];
}

Pour le hacker en Perl, rien de plus trivial que de coder de cette manière. Pour celui qui ne parle pas cette langue, c'est tout de même assez déroutant. Le succès de Perl en son temps, était du en parti à sa simplicité de mise en œuvre, à sa disponibilité sur toutes les plateformes. Comme nous le dit très bien Michael Schwern dans sa présentation "Perl is unDead" lors de la YAPC::Asia 2008, il s'agit de ce qu'il nomme le Folk Programming :



Ce qui fait qu'un langage de programmation émerge et fini par être utilisé par tout le monde, c'est son adoption par le peuple des programmeurs de base, puis le constat de son omniprésence par les managers dans les entreprises. L'adoption se réalise quand le langage apporte avec lui une nouveauté, un moyen de faciliter et d'accélérer le développement. En son temps, Perl apportait une facilité de programmation sans commune mesure avec ce qui se faisait alors. De plus, il profita de l'arrivée du Web et de son modèle de développement très rapide et itératif car il était devenu très simple de coder quelque chose en Perl et d'avoir immédiatement le résultat sur son écran, un feedback en quasi temps-réel en quelque sorte.

Mais tout ça c'était les années 90. Aujourd'hui pour faire de la programmation orienté objet en Perl, on est loin de la simplicité des autres langages. Cela fait longtemps que Perl n'est plus le choix le plus évident, qu'il n'offre plus de nouveautés vraiment intéressantes pour le programmeur de base. Depuis, nombreux sont les logiciels qui ont apportés des nouveautés que Perl n'a pas su fournir le premier : Rails sur Ruby, PHP et son extrême simplicité (un langage fourre-tout), JavaScript et Web2.0 ... Si Perl veut revenir sur le devant de la scène, c'est en proposant des moyens aussi simples et puissants tout en proposant de nouvelles techniques encore plus indispensables.

C'est l'objet notamment de Perl6 et de sa machine virtuelle Parrot. Comme pour s'approprier les succès de ses pseudo-concurrents, Perl6 vise à proposer une machine virtuelle réellement optimisée pour les langages dynamiques, et réellement portée sur de nombreuses architectures (pas comme Java qui se targue de permettre de la programmation multi-plateforme, mais qui ne supporte que 3 systèmes (Linux sur x86/x64, Solaris, et Windows) alors que perl a été portés sur une centaine de systèmes)

Cette machine virtuelle permettra de faire fonctionner ensemble des programmes écrits dans des langages différents, un peu comme la .NET CLR (ou la JVM aujourd'hui où l'on voit apparaître de nombreux langages compilant du bytecode, comme JRuby). L'important c'est que cette machine virtuelle ait été conçue dans le même esprit que perl : TIMTOWTDI. Elle permet de faire fonctionner des langages aussi compliquer à implémenter que Perl tout en permettant de faire tourner des langages comme Ruby, PHP, et pourquoi pas Java d'ailleurs. C'est ce que nous explique le Primer Parrot :
Parrot is designed with the needs of dynamically typed languages (such as Perl and Python) in mind, and should be able to run programs written in these languages more efficiently than VMs developed with static languages in mind (JVM, .NET). Parrot is also designed to provide interoperability between languages that compile to it. In theory, you will be able to write a class in Perl, subclass it in Python and then instantiate and use that subclass in a Tcl program.
Personnellement, je verrais bien Parrot comme machine virtuelle d'un Emacs refondu à la sauce XXIème siècle. En ajoutant à Parrot les types de base de Emacs (buffer, window, frame, ...) on devrait pouvoir porter un compilateur elisp vers Parrot et avoir l'éditeur de texte le plus puissant du marché :) Ça permettrait de palier à la lenteur de la machine VM de Emacs (qui d'ailleurs, et ce n'est peut-être pas une coïncidence, a été codée initialement par James Gosling, le papa de Java et de la JVM).