Culture de café ou culture d'entreprise?

Dans une récente analyse publiée pour Forester, Mike Gualtieri pose une question polémique: Est-ce que Java est une impasse pour les applications d’entreprises?

Une avalanche de commentaires passionnés s'en est suivie sur la toile. Il est vrai que les annonces de Mike ont de quoi titiller les égos: adopté par plus de 70% des grandes entreprises, près de 60 JSR, courbe d'apprentissage croissante, multiplications de frameworks palliatifs et enfin : 68% de projets inaboutis.

L'étude soutient que l'une des causes d'inadéquation de Java pour construire des applications d'entreprises est sa tentative de couvrir tout le spectre des sept qualités d'un logiciel: expérience, disponibilité, performance, échelonnage, adaptabilité, sécurité et économie.

Vouloir atteindre la perfection est certes une preuve d'ambition mais cela montre surtout un manque de pragmatisme, car de toutes ces qualités seulement deux se détachent aujourd'hui comme des tendances: l'expérience utilisateur et l'adaptabilité.
Un logiciel ennuyeux pour les utilisateurs est un échec et si l'on ne peut pas le modifier dans des délais et des coûts raisonnables, alors il disparaîtra. Il se trouve que Java n’a pas été inventé par des spécialistes des applications d’entreprise, d’où la faillite des premières versions d’EJB. Il n’a aussi jamais été pensé pour le confort de l’utilisateur final, d’où l’échec d’AWT puis de Swing et enfin de JSF. Java s'est embourbé dans des modèles inutilement complexes, des architectures "bitte schön, danke schön", comme les décrit Christophe Thiry, de manière hilarante dans son blog.

L’étude met en avant les nouveaux paradigmes de développement. L’avenir, pressenti depuis longtemps mais concrétisé depuis peu, appartient à ceux qui réduiront les délais, les coûts et la distance avec le cœur de métier de l’entreprise. Des architectures événementielles représentent cette nouvelle tendance où différents outils sont employés à différentes phases d’un modèle métier (et non plus d’un programme): conception, implémentation et action. Ces paradigmes offrent beaucoup plus qu'une évolution, ils promettent d'humaniser l'informatique.

Le principal argument mis en avant par les entreprises, pour justifier la continuité de la stratégie Java est… historique : J’ai investit dans Java, j’ai plusieurs applications en production, je suis obligé de supporter ma croix et pour longtemps encore…Cela ne vous rappelle-t-il pas un autre langage. Eh oui, Cobol, toujours là et pour longtemps encore ! De là à dire que Java subira le même sort, il n’y a qu’un pas. Je trouve cependant cette étude rassurante : il y’aura toujours du boulot pour les développeurs Java. Dieu merci !

Eloge de la lenteur

Un article étonnant de Philosophie Magazine chamboule notre rapport au temps et remet en question la paternité de l'horloge.
Tout le monde s'accorde à dire que l'horloge mécanique a été inventée en Europe au XIIIème siècle. Pourtant les chinois disposaient dès le premier millénaire, d'un système de clepsydre très sophistiqué, utilisé principalement dans l'étude du mouvement des astres, savoir nécessaire pour établir les prévisions astrologiques dont l'empereur se servira pour exercer son pouvoir. Le temps selon les chinois est donc un luxe réservé aux décisions de l'empereur. Le peuple quant à lui ne peut disposer de ce privilège. Alors dirons nous, comment prévoir le temps ou comment définir un délai et le respecter? Eh bien sur ce sujet, deux cultures s'opposent: dans l'occident, le temps sert à borner une réalisation par un début et une fin. Dans la civilisation chinoise, le temps importe peu pour une réalisation, seule la perfection compte!
Imaginons ce que serait nos projets dans un monde régit par la perfection et non pas par la "deadline". Nous n'aurions certainement pas des smartphones, mais nous aurions des moyens de communication qui répondent parfaitement à nos besoins sans bugs et sans stress pour les SAV.
Pensez à un travail que vous avez réalisé en prenant votre temps. Imaginez à quoi il aurait pu ressembler si on vous avait imposé de le livrer pour telle-date-au-plus-tard!
Le pouvoir dans la culture occidentale se mesure par la capacité à faire respecter les délais, quelle humiliation que de ne pas livrer en temps et en heure. On préfèrerait produire une immondice et y adjoindre une série de correctifs plutôt que de prendre le temps de tester et de peaufiner. J'ai déjà vu des chefs de projets à la limite de la dépression parce que leur projet risque de prendre du retard. J'ai souvent proposé de prendre le temps de produire quelque chose de correcte plutôt que de se précipiter et de perdre toute crédibilité vis-à-vis des utilisateurs. Eh bien non, rien n'y fait. La seule chose qui restera du projet ce n'est pas l'aventure humaine et technologique, la réalisation innovante ou la satisfaction des clients. Non, tout ce qui sera retenu ce sera le RETARD!
Dans la bande dessinée "Le petit Nicolas" de Sempé et Goscinny, Geoffroy est un garçon décrit comme lunatique et toujours en retard. D'ailleurs la maîtresse ne l'a jamais félicité à cause de son retard, sauf une fois: il venait d'avoir un p'tit frère.
Un long conditionnement qui a débuté sur nos bancs d'école et qui ressort et guide nos comportement d'hommes actifs. Maintenant que la cause est identifiée, levez vous du canapé et reprenez le dessus sur vos vieux démons scolaires!

Bonne année 2011 !

Une nouvelle année est une nouvelle itération dans notre histoire personnelle, un "sprint" de plus dans la réalisation de la fameuse oeuvre, dont on pourra savourer la ligne parfaite, épurée, aboutie... avant de recommencer de plus belle et en mieux. Nous sommes insatiables! En tout cas j'espère pour vous que vous l'êtes, autrement la vie serait insipide!
J’ai récemment découvert le blog d’Olivier Roland, un autodidacte éclairé doué d’un enthousiasme à toute épreuve. Il s’est fixé comme défi de lire 52 livres en 52 semaines ! Cette boulimie de savoir s’explique : combien de fois avez-vous changé d’avis sur un sujet après avoir lu quelque part un court article, découvert par hasard, ou après avoir écouté un débat télévisé. Vous êtes par la suite étonné d’une telle découverte qui a changé quelque chose en vous et vous vous jurez de revenir sur le site ou le blog en question, promesse évidemment non tenue. Combien d’occasions similaires avons-nous raté ? Vous vous résigner et vous vous dites que vous n’avez pas le dont d’ubiquité.
Un conseil : persévérez, lisez le plus possible ! Mais pas n’importe quoi. Olivier Rolland énumère quelques perles documentaires inconnues, pourtant étonnement célèbres, au vu des évaluations Amazon.
Dans le même ordre d’idées, un autre adepte de self-made-man, Josh Kaufman, présente la méthode Personal MBA pour atteindre soit-même un niveau équivalent à celui de MBA, en lisant de manière ciblée un panel de livres sur tous les domaines: économie, organisation, développement personnel, management... etc. Essayez, c'est passionnant et c'est mieux votre compte bancaire!
Donc pour cette nouvelle année, lisez! Autant que vous pouvez ! Pour sortir du nuage de flou dans lequel nous plongent tous les jours, les masses d'informations incertaines. Lisez, vous serez imbuvable quelques temps avec votre science infuse; juste le temps de digérer puis de réorganiser et enfin de piocher, non sans y avoir ajouté une pointe d'humour, dans la mine de savoir dont vous disposerez. Vous serez enfin quelqu'un qu'il sera bon de connaître.
Bonne année encore et n'oubliez pas de faire un geste pour Wikipedia et de relayer le message!

Agile ou contortioniste?

Pourquoi la méthode Agile a du mal à s'imposer dans les projets informatiques?
Une réponse intéressante à cette question a été postée sur le site DZone. L'auteur explique que que le client trop impliqué par Agile, se comporte comme s'il ne voulait pas qu'on lui reproche le disfonctionnement de l'application qu'il a contribué à spécifier. Plus crûment, il ne veut pas être blâmé en cas de problème. D'où vient ce sentiment?
Le plus souvent, une solution informatique en entreprise est imposée plus que choisie. Dès lors, elle cesse d’être une solution pour devenir un fardeau. La vision simplificatrice de l’entité « Client » occulte tous les aspects humains entourant la réalisation d'un projet.
Agile est une méthode pragmatique, bâtie sur l’hypothèse d’un monde faillible et d’un contexte humain contraint et donc peu coopératif et peu constructif par nature. Cette méthode a brisé la linéarité irréaliste de Waterfall en petits incréments, dont le but est de faire apparaître les imperfections, le plus tôt possible.
Voici un exemple type d'un dialogue Agile entre Marlene, du service de Gestion et Fred, un développeur:
F: Voici ma compréhension de ce cas d’utilisation. Êtes-vous d’accord ?
M: Oui.
F: Alors passons à la réalisation…. Qu’en pensez-vous maintenant ?
M: Ce n’est pas bon, vous n’avez pas bien compris ce que je voulais dire.
F: Pourtant je l'ai écrit et vous l’avez relu… Recommençons…. Qu’en pensez-vous maintenant ?
M: C’est beaucoup mieux. Il reste deux trois détails
….
M: Là c’est parfait !
Une fois l’application mise sur rails, on se rend compte que ce cas d’utilisation mérite d’être revu. Il faut refaire appel aux service de Fred et Marlene qui avait validé ce cas, risque d’être pointée du doigt et le vivra mal.
C’est de cette situation que souffre Agile. Le fait que le client s’implique à ce point dans le processus de développement et le risque qu’il en soit blâmé. Ceux qu’on doit blâmer, traditionnellement, ce sont les fournisseurs, non ?! Pourtant Marlene ne devrait pas avoir de soucis à se faire, l'éventualité de redévelopper un cas d'utilisation fait partie d'Agile et ne coûtera pas plus chère à l'entreprise.
Agile remet en question les situations schizophrènes comme par exemple: le client ne maîtrise pas son métier et ne peut pas l'admettre et le fournisseur n'a aucun moyen de lui soutirer des informations et ne peut pas s'en plaindre. Alors on fait avec... Une situation Ubuesque qui a mené en deux décennies, à une belle pagaille dans les SI.
Alors on tente de remplacer cela par un processus qui répartit les responsabilités ou, disons, en crée là où il n’y en avait pas auparavant. Une méthode qui tient compte de l'imperfection des hommes et des logiciels pour peut-être moins de stress inutile dans les projets.
Un projet ne peut être quantifié seulement par une durée, un budget et un taux de cas d’utilisations couverts. Il faudrait y ajouter une composante que nous avons totalement occulté : la sérénité.
J. Stiglitz a introduit un indicateur de « bien être » dans l’évaluation du PIB, ce qui révèle que des pays supposés riches ne le sont pas réellement. Pourquoi ne pas en faire autant pour les projets informatiques ? Cela révèlera peut-être que certains projets sont plus aboutis que d’autres, même si la sacro-sainte « deadline » n’a pas été respectée.

L'interface "est" le système

C'est en tout cas ce qu'affirme Vinayak Hegde dans la liste des 97. Dans cette même liste on peut lire une contribution de Einar Landre qui affirme pour sa part que l'architecte doit se focaliser principalement sur l'interface.
Le premier évoque la relation de l'humain avec le système, le second parle de la relation des systèmes entre eux. Peut-on établir un parallèle?
Dans ces deux affirmations, l'interface joue le rôle d'intermédiaire dans l'établissement de relations.
Dans la culture populaire, un agent intermédiaire peut faire ou défaire une bonne entente, quelle que soit la bonne foi des deux parties.
Pourquoi alors cette confiance en un intermédiaire incontournable? Quelle est la pérennité d'une telle association? Réponse: aucune des parties prenantes à la relation ne veut s'adapter à l'autre, car cette adaptation induit une dépendance. Autrement dit, chaque partie portera en elle, une définition de l'autre. L'intermédiaire devient alors un facilitateur!
Lorsque les systèmes s'interfacent entre eux, on parle de "découplage". Lorsqu'ils s'interfacent avec des humains, on évoque... "l'intuition". Dans les deux cas on fait appel à l'agent adaptateur.
Les systèmes entre eux, pour réduire leur dépendance, sont conçus en faisant appel à des modèles respectant les principes fondamentaux que sont la Séparation des responsabilités et l'inversion de contrôle. Quant à l'humain, sa communication avec le système passe par l'image au sens figuré, que lui retransmettent ses sens. Les interfaces se sont donc adapté à ce mode de communication: vue, ouïe, toucher, (goût et odorat?). Il y a quelques années elles étaient minimalistes: clavier, écran et symboles, ce qui nécessitait un effort cérébral important pour mémoriser l'association des symboles informatiques au monde réel. Au fil des années, de plus en plus de sens sont stimulés et la symbolique disparaît peu à peu: la communication est devenue graphique, s'est colorée, animée et sera bientôt holographique. L'action passait par le clavier, elle est devenue tactile, orale... bientôt télékinétique?
Nous déployons de moins en moins de moyens rationnels pour communiquer avec le système, qui pour sa part nécessite de plus en plus d'intelligence pour rendre possible cette simplification. Ne sommes-nous pas en train de nous atrophier à l'avantage des systèmes que nous concevons?
Disons que notre intelligence change; nous évoluons vers un futur plus heuristique que rationnel.
Un jour, doués de cette nouvelle forme d'intelligence, nous finirons par concevoir des systèmes qui seront intelligents, certes d'une intelligence à l'image de notre passé d'humain atrophié, mais alors une nouvelle étape sera alors franchie, celle où interfaces et systèmes se confondrons.

OWF!

Il y'a quelques jours, a eu lieu l'Open World Forum. Si vous y étiez, vous auriez remarqué que le perfecto en cuir de Simon Phipps tranchait franchement avec le costume-cravate du DSI de Sanofi-Aventis :-)
Il ne s'agissait pas d'une énièmme messe d'évangélisation de l'humanité à la voie sacrée de la FSF, avec RMS en post-babacool, pronant l'amour du software libre et le rejet de la vile monaie! Non, il s'agissait d'un autre type d'évennement, un show orchestré par des acteurs aguerris aux règles du business qui présentaient leurs solutions. De vraies solutions robustes; concurrentes directes de solutions commerciales, pour des utilisations stratégiques en entreprise: Cloud Computing, Virtualisation, BPM, BI, CMS...
Ce forum a soulevé de nombreuses questions de fond:
Comment cette culture, hérétique il y'a dix ans, est-elle devenue aujourd'hui une réelle alternative? Est-ce mimétique ou conjoncturel? Quel est l'avenir du logiciel libre face au logiciel commercial? Comment transformer une solution Open Source en opportunité business?
Je n'ai pas trouvé de réponses à toutes ces questions. J'ai cependant observé que la curiosité a disparu pour laisser place à une véritable adoption, réfléchie et pragmatique. Les DSI présents (Bull, Sanofi-Aventis, Safran, PriceMinister...) se sont tous déclarés comme déjà utilisateurs de solutions Open Source et prêts à considérer les offres; du moment que la performance est au rendez-vous. La révolution appartient déjà à l'histoire!
La gêne perceptible, car il y'en a, est due au fait que l'Open Source expose beaucoup plus la responsabilité des dirigeants. Point de contrat commercial exhorbitant, adossé à des clauses telles que que seules de puissantes firmes logicielles peuvent se permettre de parapher. L'Open Source ramène aux fondements d'un métier, de notre métier: la compétence, la passion, l'honnêteté. Aucun dirigeant n'est sûr de disposer, dans son projet d'intervenants sûrs, partageant ces valeurs. Alors, il préfèrera les firmes. A grand renfort de communication, elles ont imposé à notre subconscient l'image de la perfection. Personne ne reprochera à ce dirigeant de s'être mépris en choisissant une perfection admise par tous.
Seulement voilà, tout cela est en train de changer, la maturité de ce métier explique de moins en moins la délégation de responsabilité. Les défaillances répétées des firmes ont érodé définitivement le mythe de la perfection. Nous redescendons vers une réalité moins brillante: les paradigmes sur lesquels sont construites les nouvelles architectures d'aujourd'hui ont moins de dix ans d'existence. Alors faisons profil bas, dénouons le nœud de notre cravate et comme Simon Phips, revêtons notre blouson en cuir de baroudeur de l'informatique, abandonnons notre égo et tentons de construire, enfin, des systèmes par la seule force de notre intelligence.

L'art de la maquette

Lors d'une visite de la Sagrada Familia à Barcelone, j'ai été frappé par l'audace de Gaudi. Oser reproduire les frondaisons d'une forêt dans une cathédrale pour exprimer des sentiments abstraits: l'élévation, l'origine de la vie, la beauté maîtrisée de la nature et sa copie inachevée par l'homme. Audacieux!
Comment peut-on oser la réalisation d'oeuvres monumentales en gardant une totale assurance dans ces créations? Comment peut-on se permettre de telles audaces?
La réponse je l'ai eu un peu plus loin. Alors que je m'avançait dans la crypte je me suis retrouvé devant une reproduction inversée en structure de fil de fer de la Colonia Guëll. De petites bourses de sables maintenaient les arrêtes vers le bas en augmentaient la courbure de leur arc en fonction de leur poids. Le tout faisait penser à un hologramme sortie d'un logiciel de modélisation d'architecture. Gaudi avait, au début du 20ème siècle, inventé la maquette 3D!
Pourquoi cette structure de maquette complexe alors que du plâtre, comme il était d'usage à son époque, aurait suffit? Les maquettes en dur, il en a construit plusieurs, encore bien conservées à ce jour. Celle qui m'a attiré donnait au visiteur, une sensation de légèreté, une cathédrale immense, flotant dans les airs, comme les colonnes de la Sagrada, semblables à d'immenses arbres dont les sommets s'élèvent vers le ciel pour soutenir le plafond de la cathédrale. Tout un symbole... Gaudi ne voulait pas seulement modéliser une forme, mais un concept! Il tentait d'approcher et de "peaufiner" l'émotion que susciterait son oeuvre une fois terminée.
Lorsque l'on opère un changement dans les systèmes d'informations, nous réalisons ce que nous appelons des POC. Ces derniers, comme leur acronyme l'indique, doivent représenter un concept et non pas un sous ensemble de l'architecture finale. Le plus souvent nous nous contentons d'y tester des procédures d'installation, nous passons ensuite à la réalisation et nous nous étonnons de découvrir d'énormes disfonctionnements pendant le projet. Nous aurons non seulement perdu tout l'intérêt d'un POC, mais en plus, nous scellerons à jamais toute tentative de réarchitecture ou même de compréhension ou de modification future.
La plupart du temps, le système d'information est vu comme un agrégat de logiciels et de matériel plutôt que comme un ensemble de concepts.
Les partisants de SOA honnissent l'architecture en "silos", Je trouve cette image très éloquente... passer du silot à la cathédrale ne revient-il pas à délaisser l'alimentaire pour le spirituel. OK, me direz vous, mais seulement le dimanche!

Corrélation VS Causalité

Un jour, j'ai eu à traiter un incident de production qui s'est déclaré sous la forme d'une application de production qui s'est brusquement ralentie au point de ne plus fonctionner.Dans le même temps, un serveur hébergeant un service utilisé par cette application s'est arrêté de fonctionner.

Déferlement d'e-mails, cacophonie de sonneries de téléphone et confusion généralisée. Que faire?! Quelques redémarrages de services plus loin et le système était reparti tant bien que mal.
De par sa rareté, le problème était difficile à reproduire. Une démarche simpliste dans ce cas, est de tenter plusieurs interventions sur les différents services impliqués, dans différents ordres pour tenter d'en déduire la séquence fatale. Peu efficace. Cette Méthode empirique s'appuie sur la dépendance intuitive entre des phénomènes.
La seule conclusion à laquelle nous aboutissons (permettons nous un peu de probabilités), est que les variables aléatoires correspondant aux éventualités d'occurrence d'un résultat sont liées entre elles plus ou moins fortement. Cette liaison s'exprime, dans la théorie de la probabilité, par une corrélation définie par son coefficient. Plus ce dernier est élevé plus forte est cette liaison.
La corrélation ne suffit pas pour se prononcer sur ce que l'on tente de vérifier réellement: une causalité! La modéliser n'est pas une mince affaire!
Introduisons un autre niveau de probabilité: celui concernant l'occurrence de relations de causalité entre les variables aléatoires. Nous obtenons un graphe (de causalités) et une table de probabilité. Le tout est appelé: réseau Bayésien.
Dans ce graphe les relations de cause à effet ne sont pas déterministes mais probabilistes. Nous n'exprimons plus une cause mais une probabilité précise qu'un effet soit du à cette cause.
Appliqué à notre problème, cela nous aurais permis d'exclure les fausses pistes jusqu'à se rapprocher de l'origine du problème.
Dans une architecture distribuée modélisée par un graphe acyclique fortement connexe, les nœuds représentent des services (ou des serveurs) et les arcs sont les protocoles réseau les reliant. Nous disposons d'une connaissance (le savoir empirique cumulé par notre expérience sur cette architecture) et des inférences (observations intuitives sur notre système). Comment vérifier ces inférences? Posé ainsi, le problème se modélise de lui même en réseau Bayésien.
Combien de fois avons nous entendu des phrases contenant des termes comme: "très probable", "peu probable"... et combien de fois nous en avons été peu convaincus, nous avons cependant refermé le dossier par manque d'outils, mais aussi, avouons le... par paresse ;-)

Bonne année 2010!

"Souviens-toi que le Temps est un joueur avide
Qui gagne sans tricher, à tout coup!" Charles Baudelaire

C'est ainsi que commence l'exposé de Francesco Cirillo, intitulé: "La technique du Pomodoro".
Pomodoro signifie "Tomate" en italien. Ce fruit importé des amériques avait à l'époque la couleur jaune dorée, les italiens le baptisèrent "Pomme d'or". Le Pomodoro est aussi ce minuteur de la forme d'une tomate, gradué que l'on trouve souvent dans les cuisines. F. Cirillo a choisi ce nom d'objet anodin pour baptiser sa technique de gestion du temps.
Cette technique vient du constat suivant: nous ne savons pas estimer la durée de ce que nous accomplissons.
Selon Bergson, la perception du temps n'est pas celle d'une durée mais celle d'une succession de situations simultanées. Seule la mémoire permet d'estimer la durée entre deux successions. Cette durée est donc subjective.
Notre dépendence au temps est telle qu'une réalisation même aboutie peut être perçue comme inachevée, de par le caractère subjectif de la durée que nous y avons consacré. Ainsi, nos tâches journalières se suivent et le goût d'inachevé est chronique.

Faut-il reconsidérer notre perception du temps?

C'est en tout cas l'idée de la technique du Pomodoro basée sur une décomposition fine des tâches, bornées dans un intervalle de temps fini et mésurable (grace au minuteur). Cette technique ne s'arrête pas là, elle nous impose aussi des moments de réflexion ou de "feedback", ne serait-ce que pour apprécier, pour une fois qu'une tâche planifiée soit terminée...dans les temps. Ainsi, s'opère l'association dans l'esprit, des deux notions d'achèvement et de durée. On aquière alors la faculté de percevoir le temps en unités de tâches, en réalisations et non plus en positions simultanées des aiguilles d'une horloge.

Quant aux autres résolutions, inspirez-vous de la liste d'Andy Lester dans PragPub:

• Soyez positifs
• Améliorez votre expression écrite
• Soyez pertinents sur votre CV
• Arrêtez d'être omniscient
• Evitez de dramatiser
• Surveillez votre cote sur Internet

et j'ajouterais ... faites simple!

Gold rush

Récemment, un ami me disait toute la déception que lui avait apporté Java. Qu'il avait abandonné son vieux C pour se plonger dans la nouveauté de l'époque, pour se rendre compte qu'il était temps de renoncer.

Au début, mus par un enthousiasme euphorique, mon ami, tout comme des foules de développeurs chevronnés et d'apprentis gourous, se sont rués vers le Klondike de l'informatique de la fin des années 90: Java.

La majorité de ceux qui ont connu le Klondike, à en croire London, sont revenus, fourbus, alcooliques, avec comme seul gain, une pépite porte-bonheur en pendentif. Ceux qui ont connu Java ont eu un sort moins dramatique, quoique la déception a été à la hauteur des attentes, après quelques cycles interminables de Garbage Collector.

Cet ami qui se plaignait de Java, a aussi admis que ce langage lui a facilité l'apprentissage de la conception par objets et la notion de "Thread".

"Apprendre"…depuis la renaissance et jusqu'au début du 20ème siècle, les familles nobles apprenaient à leurs rejetons le grec et le latin. Non pas pour demander une adresse ou le chemin des toilettes dans un restaurant, mais juste pour… se distinguer. Il était alors de bon aloi d'auréoler son allocution de citations de Platon et de quelques proverbes latins.

Ce genre d'apprentissage élitiste avait pourtant une origine bien plus sérieuse. Les savants de la renaissance lisaient les écrits de leurs prédécesseurs grecs et latins, pour apprendre sur les réflexions anciennes et créer le système de pensée, qui distingua plus tard le siècle des lumières. Ces deux langues ont donc été perçues durant longtemps, comme vecteurs de savoir.

Ce mouvement est similaire à l'apparition de l'algèbre dans les démonstrations de physique du 19ème siècle. Grace à Newton, l'emploi d'équations différentielles s'est démocratisé et a ouvert la voie à de nouvelles théories mieux armées pour formaliser les observations informelles de Galilée. Cela a poussé, plus tard, des générations de chérubins, futurs apprentis nobelists, à verser dans l'étude du langage du moment, clé de toutes les portes de la science: les mathématiques.
Le grec et le latin ne sont plus appris à l'école. Sur des projets internationaux, le pragmatisme est de rigueur; on parle donc Globish! De même, les mathématiques sont de moins en moins considérées comme un passeport pour l'avenir social des enfants. On préférerait qu'ils apprennent le Jazz, la voile ou le Thaï-Chi.

Qu'adviendra t-il de Java?
Java est une langage qui s'inscrit dans la lignée des accélérateurs d'apprentissage. Il a démocratisé la conception par objets et par patterns. Il a permis d'élever la syntaxe des langages informatiques à un plus haut niveau, permettant ainsi de réduire la courbe d'apprentissage, de notions restées trop vagues même dans l'esprit de gens qui prétendaient le contraire: threads, accès concurrents, programmation réseau…etc
Nous sommes sûrs aujourd'hui que les langages informatiques modèlent le processus de pensée et donc d'innovation. Nous savons aussi que la richesse syntaxique et conceptuelle d'un langage, rendent réalisables des rêves d'architectes. Java fait partie d'une famille de langages dont les membres ont subi des mutations syntaxiques pour s'adapter aux mutations technologiques.
On continue d'étudier le grec et le latin à l'université…en plus d'autres langues. Les mathématiques sont toujours essentielles pour formaliser la science, en plus de la logique et des méta-langages.
Se demander quel langage sera celui de l'avenir, est réducteur de nos ambitions d'avenir. Il faudrait peut être se demander quels langages seront ceux de l'avenir. Cela conjugue d'emblée nos rêves au pluriel.