211service.com
Tout ce que vous pouvez faire, je peux le faire méta
Le 9 avril, sur une rampe de lancement distante dans les plaines du Kazakhstan, un contrôleur au sol terminera son compte à rebours ; une fusée Soyouz va tirer ; et Charles Simonyi, ancien architecte en chef de Microsoft, génie tutélaire de ses applications les plus célèbres, inventeur de la méthode d'écriture de code utilisée depuis 25 ans par les programmeurs de l'entreprise et désormais promoteur d'un ambitieux projet de reprogrammation de logiciels, commencera son ascension dans l'espace.
Charles Simonyi président et chef de la direction d'Intentional Software.
Bien au chaud dans une combinaison spatiale russe, sentant quatre G le presser contre une doublure de siège moulée, le milliardaire de 58 ans deviendra le cinquième touriste de l'espace à visiter la Station spatiale internationale. Le voyage, qui coûtera environ 20 millions de dollars à Simonyi, réalisera son rêve de devenir un nerd dans l'espace (pour emprunter un nom qu'il a choisi pour le site Web qui documente son aventure extraterrestre : www.nerdinspace.com ). Cela lui donnera également l'occasion de voir notre planète d'en haut et au-delà.
Cela a toujours été le point de vue préféré de Simonyi. Au cours d'une carrière s'étalant sur quatre décennies, chaque fois qu'il a été confronté à un problème insoluble dans le logiciel ou dans la vie, il a essayé de le résoudre en sortant ou en dépassant. Il a même un nom pour son pari préféré : il l'appelle devenir méta. Dans sa jeunesse dans la Hongrie des années 1960, il a appris les bases de l'informatique sur un ordinateur central soviétique archaïque alimenté par des tubes à vide, puis a conçu sa propre évasion vers l'Ouest. Dans les années 1970, au légendaire Palo Alto Research Center (PARC) de Xerox, en tant que membre de l'équipe qui a inventé l'informatique personnelle, Simonyi a écrit la première application moderne : un traitement de texte qui bannit les codes complexes puis utilisé pour baliser le texte et afficher un document sous la forme ça aurait l'air sur papier. Que ce soit dans sa thèse de doctorat à l'Université de Stanford sur une approche de méta-programmation pour augmenter la productivité des programmeurs, sa carrière chez Microsoft organisant des légions de développeurs de logiciels et leur apprenant à structurer leur code, ou son voyage prévu en orbite terrestre ce printemps, dépassant les voies établies de faire les choses a toujours été la méthode de Simonyi. Maintenant, il prépare ce qu'il espère être son méta-mouvement le plus important de tous. Simonyi pense qu'il peut résoudre une multitude de problèmes tenaces qui ont toujours affligé les ordinateurs en offrant à tous ceux qui les utilisent, et aux codeurs qui les programment, une vue d'ordre supérieur du logiciel.
Bill Gates appelle Simonyi l'un des grands programmeurs de tous les temps. En effet, Simonyi est sans doute le plus codeur à succès dans le monde, mesuré en termes de récompense financière et de nombre de personnes qui utilisent ses créations. (D'autres programmeurs-milliardaires célèbres, tels que Larry Ellison et Bill Gates lui-même, ont gagné leur argent et leur nom en fondant et en gérant des entreprises technologiques.) Simonyi pourrait facilement choisir de passer le reste de sa vie à doter des entreprises philanthropiques, à piloter des avions ou à naviguer dans son yacht. Au lieu de cela, dit-il, il programme probablement plus dur que jamais. Il est obsédé par un projet qu'il poursuit depuis une décennie et demie et qui, il y a quatre ans, l'a mené à la porte de Microsoft. Il est fier de son métier. Mais il est également hanté par la pensée de ce à quoi les programmeurs doivent faire face chaque fois qu'ils s'assoient pour coder. Il demande : Pourquoi est-il si difficile de créer un bon logiciel ?
Multimédia
Photos supplémentaires de Simonyi
Code Napoléon
Notre civilisation fonctionne sur des logiciels, déclare Bjarne Stroustrup, l'inventeur du langage de programmation C++ (voir Le problème avec la programmation) . Mais le logiciel lui-même ne fonctionne pas très bien. Partout où vous regardez, les logiciels sont hors budget, en retard, peu sûrs, peu fiables et difficiles à utiliser. Chaque fois qu'une organisation tente d'introduire un nouveau système ou de mettre à niveau un ancien, elle prend un risque colossal ; aujourd'hui, les grands projets informatiques sont des goudrons technologiques qui immobilisent les institutions. Des études rapportent régulièrement que les deux tiers de ces projets connaissent des retards importants, des dépassements de coûts importants, ou les deux. Le gouvernement américain a trouvé qu'il était presque impossible d'introduire ou de mettre à niveau des systèmes logiciels à grande échelle : les efforts déployés pendant une décennie par la Federal Aviation Administration et le FBI se sont effondrés dans le chaos. Les entreprises n'ont pas fait mieux. Pour ne donner qu'un seul exemple, les dirigeants de McDonald's rêvaient d'un système de gestion basé sur le Web qu'ils appelaient Innovate qui suivrait le flux en temps réel de hamburgers, de frites et de nuggets de poulet dans chacun de leurs restaurants à travers le monde. Au moment où ils ont abandonné et annulé le projet, ils ont dû radier 170 millions de dollars de son coût total estimé à 1 milliard de dollars.
De tels échecs s'additionnent. Chaque année, selon une étude de 2002 du National Institute of Standards and Technology, les pannes logicielles coûtent 59,5 milliards de dollars. Mais le prix d'un mauvais logiciel peut aussi se mesurer en misère humaine et même en vies perdues. Pendant la guerre du Golfe de 1991, une batterie de missiles Patriot n'a pas tiré sur un Scud entrant à cause d'un logiciel défectueux ; le coup direct sur une caserne a tué 28 soldats américains.
Le dernier demi-siècle d'informatique a connu des progrès formidables. Les programmeurs ont abandonné les cartes perforées et les télétypes. Ils nous ont fourni un ordinateur sur chaque bureau, des outils pour travailler, des jouets pour jouer et un réseau qui relie les foyers et les entreprises pour former un vivier mondial d'informations et de divertissements. Ces progrès ont été alimentés par la courbe exponentielle de la loi de Moore, la prédiction du fondateur d'Intel, Gordon Moore, selon laquelle la puissance des micropuces doublerait (ou leur coût diminuerait de moitié) tous les un à deux ans. Mais même si la loi de Moore a rendu les nouveaux ordinateurs de chaque année plus rapides et moins chers, la flexibilité et l'utilité de nos systèmes informatiques ont été limitées par l'évolution plus lente et inégale des logiciels. Une formulation de ce problème est connue sous le nom de loi de Wirth, d'après l'expert en programmation Niklaus Wirth : le logiciel devient plus lent plus vite que le matériel devient plus rapide.
Simonyi partage une grande partie de l'insatisfaction commune avec les logiciels. Le logiciel tel que nous le connaissons est le goulot d'étranglement de la corne d'abondance numérique, dit-il. Cela demande d'énormes ressources en talent et en temps. C'est décevant et difficile à changer. Il bloque l'innovation dans de nombreuses organisations.
L'ambition de Simonyi est de débloquer ce goulot d'étranglement logiciel, de manière caractéristique, en devenant méta. Il a développé une approche qu'il appelle programmation intentionnelle (ou, plus récemment, logiciel intentionnel), qui, espère-t-il, bouleversera la programmation. Si Simonyi réussit, les programmeurs cesseront d'essayer de gérer les besoins de leurs clients. Au lieu de cela, pour chaque problème qu'ils sont invités à résoudre, qu'il s'agisse de suivi d'inventaire ou de guidage de missiles, ils créeront des outils génériques que les utilisateurs d'ordinateurs eux-mêmes pourront modifier pour guider l'évolution future du logiciel.
Par un après-midi gris d'octobre dernier, je me suis assis avec Simonyi à Bellevue, WA, devant deux écrans adjacents dans son bureau chez Intentional Software, la société qu'il a fondée après avoir quitté Microsoft en 2002 pour développer et commercialiser sa grande idée. Simonyi me faisait courir à travers une présentation qu'il préparait pour une conférence à venir ; il a utilisé des diapositives Microsoft Office PowerPoint pour décrire sa vision du grand bond en avant proposé dans la programmation. Il était en train de déplacer une diapositive lorsque l'application a juste cessé de répondre.
Dans le coin de l'écran de gauche, un trombone aux yeux de lunettes est apparu : l'assistant de bureau largement vilipendé que Microsoft a introduit en 1997. Simonyi a essayé d'ignorer l'agitation de l'assistant du dessin animé, mais il a été bloqué. Rien ne marche, soupira-t-il. C'est parce que Clippy m'aide.
J'étais perplexe. Vous voulez dire que vous n'avez pas désactivé Clippy ? Il y a longtemps, j'avais parcouru les menus d'Office et coché la case requise pour étouffer l'anthropomorphe ennuyeux une fois pour toutes.
Je ne sais pas comment, admit Simonyi avec un petit rire qui semblait dire : Oui, je sais, n'est-ce pas ironique ?
C'était. Simonyi a passé des années à diriger les équipes d'applications de Microsoft, les développeurs de Word et Excel, dont les produits sont utilisés chaque jour par des dizaines de millions de personnes. Il est largement considéré comme le père de Microsoft Word. (J'utilise bien sûr Word pour écrire ces phrases.) Charles Simonyi aurait-il pu rencontrer son partenaire dans Clippy ?
Simonyi fixa son adversaire, comme s'il était enfermé dans un combat télépathique. Puis il se tourna vers moi, les yeux bleus brillants. J'ai besoin d'un assistant : un Super-Clippy pour me montrer où l'éteindre ! Simonyi avait envie d'un méta-Clippy.
En 2004, Simonyi a proposé sa propre loi : tout ce qui peut être fait peut être fait « méta ». fais, je peux faire de la méta ! Mais comme beaucoup de prodiges qui ont bien fait et bien vieilli, Simonyi a appris à couper son arrogance avec des touches d'humilité et de grâce. Il y a dix ans, il se décrivait comme un gars à l'air hirsute avec un accent étranger. Il privilégie les cols roulés noirs et les blazers croisés. Avec sa posture droite et son visage carré, une touffe de cheveux noirs peignés en avant sur son front, on dit souvent qu'il ressemble à un Napoléon aux os plus gros.
Le logiciel intentionnel est un grand schéma dans un domaine où les grands schémas ont rarement fonctionné. Chaque innovation précédente présentée comme une solution complète aux problèmes des logiciels a fini par n'apporter que des améliorations modestes et incrémentielles. Mais Simonyi déborde de la confiance d'un immigrant autodidacte qui a toujours eu une prise ferme sur ses propres bootstraps. Sur une photo accrochée au-dessus de son bureau, il se tient à la Maison Blanche sous un portrait de Ronald Reagan. Son large sourire reflète celui du président. La légende lit les deux optimistes.
Les bureaux de la nouvelle entreprise de Simonyi occupent une suite dans un élégant gratte-ciel en verre, et si vous vous penchez vers la fenêtre et regardez en bas, vous pouvez voir le toit du bâtiment blanc et trapu qui abritait son premier bureau chez Microsoft, en 1981. ( C'est une banque maintenant.) Depuis lors, Microsoft a grandi au-delà de toute reconnaissance. L'industrie du logiciel a transformé le monde. Alors pourquoi Simonyi entreprendrait-il de réécrire toutes ses règles ? Le problème est si grand qu'il semble faire partie de l'ordre établi des choses. La solution proposée par Simonyi pourrait prendre des décennies et ses détracteurs sont extrêmement sceptiques. Personne ne lui demande de quitter les routines connues de la programmation et de partir pour un nouveau monde. Mais de telles migrations ont été payantes pour lui dans le passé.
Le langage de la machine
Simonyi est né à Budapest en 1948. Fils d'un professeur de physique, il est tombé amoureux à 15 ans de son premier ordinateur, un gigantesque Oural II russe de l'Office central des statistiques de Hongrie. Dans les années 1960, l'Oural, qui recevait ses instructions par des clés de type caisse enregistreuse et disposait d'une salle remplie de tubes à vide pour effectuer des calculs, aurait déjà été une relique partout ailleurs dans le monde. Mais les dirigeants communistes hongrois essayaient d'utiliser le renversement soviétique pour optimiser les horaires des transports ferroviaires et routiers. L'Oural n'était pas à la hauteur : il n'y avait aucun moyen de saisir des données en temps réel sur les expéditions. C'était complètement désespéré, se souvient Simonyi. Cela aurait pu être fait très facilement par l'offre et la demande. Malheureusement, c'était politiquement incorrect.
Mais Simonyi s'en fichait. J'ai adoré cet ordinateur, dit-il, même s'il ne servait à rien. Enfant, il avait construit une voiture Erector Set avec une transmission à quatre vitesses, non pas tant parce qu'il voulait jouer avec elle que simplement pour comprendre comment cela fonctionnait. Un ancien élève de son père a trouvé à Simonyi un emploi d'infirmière de nuit de l'Oural. Parce que la machine soufflait un tube à chaque fois qu'elle était allumée et éteinte, le bureau des statistiques a préféré lui permettre de fonctionner toute la nuit. Ainsi, du crépuscule à l'aube, l'ordinateur central appartenait entièrement à Simonyi ; il avait un ordinateur personnel avant que de telles choses n'existent. Il a appris à le programmer en écrivant des routines intelligentes mais inutiles pour générer des carrés magiques – des tableaux numériques dans lesquels les sommes des lignes, des colonnes et des diagonales correspondent toutes.
Des programmeurs ailleurs dans le monde avaient déjà inventé une Babel de langages de programmation – Fortran, Cobol, Lisp (un langage légendaire : voir Ancient Text, p. 20), etc. ensembles élaborés d'instructions à exécuter par les ordinateurs. Dans ces langues, les instructions prenaient la forme de lignes de texte saisies sur des claviers et fréquemment stockées sur des cartes perforées. Ce code source a ensuite été compilé ou traduit en code machine - le un sable 0 s qu'un ordinateur numérique pourrait comprendre. La méthode reste largement inchangée aujourd'hui, même si la plupart des programmeurs utilisent désormais des outils de programmation fonctionnant sur des PC ordinaires. Mais sur l'Oural, Simonyi a appris à programmer à un niveau plus primitif, en tapant laborieusement dans les opcodes du langage machine, en spécifiant, instruction par instruction, les séquences de récupération de mémoire, d'ajouts, de stockage de mémoire et de sauts que le processeur de l'ordinateur devait suivre. pour exécuter même l'opération la plus triviale. C'était (comme Simonyi l'a dit à l'auteur Steve Lohr dans le livre de 2001 Aller à ) Programmation de l'âge de pierre. Simonyi se souvient encore des codes. Vingt-deux, c'est JUMP, dit-il aujourd'hui. Il est gravé dans ma ROM.
La Hongrie des années 1960, encore tremblante de la répression soviétique de sa révolte de 1956, n'était pas un endroit pour un jeune homme ambitieux avec un goût prononcé pour la résolution de problèmes. À 17 ans, Simonyi a décroché un stage dans une entreprise informatique danoise en montrant à certains de ses programmeurs des échantillons de ses programmes ouraliens codés à la main. Les autorités hongroises attendaient le retour de Simonyi ; il avait déjà gagné une place universitaire convoitée. Au lieu de cela, avec les encouragements de son père, il s'enfuit aux États-Unis.
Une lettre de recommandation de l'expert en programmation danois Peter Naur l'a aidé à entrer à l'Université de Californie à Berkeley. Il a payé les factures avec un travail au centre informatique de Berkeley, où il a attiré l'attention d'un membre du corps professoral nommé Butler Lampson. Lampson était l'un des chefs de file du projet Genie de la Defense Advanced Research Projects Agency des États-Unis, une expérience sur les systèmes informatiques à temps partagé, dans laquelle plusieurs utilisateurs assis sur des terminaux pouvaient partager le temps cérébral d'un seul ordinateur. Lorsque les créateurs de Project Genie ont lancé une entreprise, appelée Berkeley Computer Corporation (BCC), dont le but était de construire une machine qui commercialiserait leur travail, Lampson a recruté Simonyi.
Chez BCC, Simonyi déboguait le prototype hésitant de l'entreprise toute la nuit, en collaboration avec le concepteur du système Chuck Thacker. Une nuit, Simonyi s'est présenté dans une tenue noire transparente – une sorte de truc hippie de l'un des magasins de Telegraph Avenue, dit-il. Aujourd'hui, il ne se souvient plus exactement pourquoi – venant d'une fête, peut-être ? Le débogage s'est particulièrement bien passé cette nuit-là et la tenue est devenue un porte-bonheur - la combinaison de débogage de Simonyi.
BCC a fait faillite après seulement quelques années, mais Lampson, Thacker et une grande partie de l'équipe de BCC ont migré vers Xerox PARC. Simonyi – alors juste un étudiant hongrois au hasard sans carte verte, comme il le dit maintenant – les a rejoints en 1972, travaillant chez Xerox tout en poursuivant son doctorat à Stanford. Bob Taylor, qui a supervisé le laboratoire d'informatique de PARC pendant une partie de cette ère légendaire, dit que la créativité de Simonyi s'est démarquée même dans la célèbre foule du laboratoire : il pouvait juste imaginer des façons d'exprimer du code et des idées qui le mettaient hors des charts.
C'était une période grisante. L'équipe d'ingénieurs visionnaires créait une série d'innovations qui façonneraient le prochain quart de siècle de l'ère du PC : l'interface utilisateur graphique, la mise en réseau (Ethernet), l'imprimante laser, la programmation orientée objet (Smalltalk), l'informatique portable (le Dynabook), et plus encore. Ces avancées ont toutes convergé vers un ordinateur personnel prototype appelé Alto.
L'Alto était une invention étonnante, mais ce que vous pourriez en faire n'était pas clair jusqu'à ce que Simonyi et ses collègues créent son application la plus connue : un traitement de texte appelé Bravo, dont l'affichage à l'écran correspondait à ce que le système produirait. à la nouvelle imprimante laser. Les traitements de texte existants disposaient de systèmes élaborés de codes pour formater le texte à l'écran (quiconque utilisait WordPerfect sur un PC dans les années 1980 se souviendra de ses codes intégrés) ; Bravo vous permet d'oublier les codes, de manipuler directement la conception d'un document et d'être immédiatement témoin des changements. Un cadre de Citibank en visite a regardé une démo et a cité une ligne de signature du personnage impertinent du comédien Flip Wilson, Geraldine : ce que vous voyez est ce que vous obtenez ! Le nom (réduit à l'acronyme Wysiwyg et prononcé wizzywig ) coincé. Du coup, Bravo avait des utilisateurs : les parents et amis des chercheurs du PARC ont commencé à demander à l'utiliser pour imprimer des bulletins scolaires et formater des documents académiques. La femme de Lampson a imprimé sa thèse à l'aide du système, et quand il était temps pour Simonyi d'imprimer la sienne, il a fait de même.
Niveaux d'abstraction
Wysiwyg est un exemple de couche d'abstraction, un outil de niveau supérieur qui permet aux utilisateurs d'ordinateurs d'ignorer certaines complexités de niveau inférieur. Les programmeurs utilisent des abstractions tout le temps. Le code texte écrit dans un langage de programmation est une abstraction du code machine qu'un ordinateur comprend réellement. Un nom de domaine Web est une abstraction de l'adresse IP numérique d'un serveur.
Mais la plupart des couches d'abstraction dans les systèmes informatiques sont moins visibles et plus obscures que Wysiwyg. Depuis que les programmeurs ont cessé de mémoriser les opcodes que Simonyi utilisait dans sa jeunesse, ils ont superposé de nouvelles abstractions sur des abstractions plus anciennes. Chaque génération de programmeurs utilise les langages et outils de programmation de son époque pour créer les programmes de la prochaine génération. Des couches d'abstraction se sont accumulées comme des strates géologiques. Les messages montent constamment du socle binaire de votre machine et redescendent, permettant à un clic de souris d'accomplir sa fonction. Votre clic de souris déclenche du code dans le système d'exploitation, qui envoie un message au programme de traitement de texte, qui demande au système d'exploitation d'enregistrer votre fichier sur un disque dur. Mais ce processus apparemment simple n'est possible que grâce à de très nombreuses couches d'abstraction.
L'histoire du logiciel est l'histoire de ces couches, chacune d'entre elles éloignant les programmeurs du binaire, les laissant mieux à même d'amener les ordinateurs à effectuer des tâches utiles. Progressivement, les programmeurs gagnaient en puissance. Mais ils s'attaquaient aussi à des problèmes toujours plus ambitieux. Les programmes ont gonflé en taille et les programmeurs ont commencé à se perdre dans des enchevêtrements de ce qu'ils appelaient du code spaghetti, qui s'est avéré impossible à démêler et à réparer. Ainsi, les grands projets logiciels sont devenus des épopées de frustration et de retard. Les responsables de programme ont été confrontés à des problèmes commerciaux tels que : Comment planifier un projet de manière réaliste ? Comment améliorer la productivité individuelle ? Comment coordonner un travail complexe au sein d'une grande équipe ? Chacune de ces questions s'est avérée étonnamment difficile à répondre.
La difficulté de coordonner le travail d'une équipe a inspiré le dicton le plus célèbre du génie logiciel, connu sous le nom de loi de Brooks : ajouter de la main-d'œuvre à un projet logiciel tardif le rend plus tardif. Frederick P. Brooks Jr. est arrivé à cette sombre conclusion après avoir dirigé les efforts troublés d'IBM pour écrire des logiciels pour ses 360 mainframes dans les années 1960. Dans son livre de 1975, Le mois de l'homme mythique , Brooks a observé que le travail se déroule plus lentement dans les grandes équipes en raison des coûts de coordination – le temps que les programmeurs perdent à se tenir au courant de leur travail.
C'était la toile de fond de la thèse de Simonyi en 1977, Meta-Programming: A Software Production Method. Simonyi a proposé une nouvelle approche pour optimiser la productivité, dans laquelle un programmeur principal, ou méta-programmeur, a conçu un produit et défini tous ses termes, puis a remis un plan aux techniciens, programmeurs ouvriers-abeilles qui feraient la mise en œuvre. Simonyi voulait échapper à la loi de Brooks en interdisant aux techniciens de se parler : toute communication devait passer par le méta-programmeur. Pour sa thèse, il a testé l'idée en utilisant deux groupes sur deux projets, A et B. Son approche despotique de la programmation n'a jamais fait son chemin, mais cela ne l'a guère troublé. L'objectif principal de Simonyi dans la recherche de sa thèse n'était pas de prouver la valeur de ses idées mais d'obtenir Bravo, le nouveau traitement de texte Wysiwyg, écrit plus rapidement. Il n'arrivait pas à persuader les responsables du PARC d'embaucher des programmeurs supplémentaires, il a donc utilisé sa thèse comme un subterfuge pour apporter de l'aide. Bravo lui-même était le projet B.
Alors que les années 1970 avançaient, Simonyi s'impatientait de l'incapacité de Xerox à transformer les recherches pionnières de PARC en produits à succès. Un jour, un ami lui a montré VisiCalc, le nouveau tableur pour Apple II. Cela a ravi Simonyi. Voici une autre application, comme Bravo, qui pouvait changer la vie des gens, mais contrairement à Bravo, elle fonctionnait sur un ordinateur grand public que les gens pouvaient se permettre d'acheter. Le travail de PARC, réalisa-t-il, ne verrait jamais le jour. Il a demandé à son ancien collègue du PARC, Bob Metcalfe, qui avait quitté le laboratoire en 1979 pour fonder 3Com, de recommander des patrons potentiels dans l'industrie naissante du PC. En tête de liste se trouvait Bill Gates.
En 1981, Simonyi a déménagé à Seattle pour lancer le groupe de nouvelles applications chez Microsoft, qui jusque-là vendait des langages de programmation et des systèmes d'exploitation. Il avait 33 ans, mais cela faisait de lui un adulte parmi les jeunes de Microsoft (Gates avait alors 26 ans, Steve Ballmer 25).
Pendant toutes les années où Simonyi a supervisé les produits qui ont finalement fusionné dans la suite de programmes connue sous le nom de Microsoft Office, il a continué à rechercher de nouvelles efficacités dans de nouveaux types d'abstractions de programmation. Plus particulièrement, il a formé des générations de programmeurs Microsoft à la discipline du suivi de la myriade de noms de variables utilisés dans les grands programmes. En programmation informatique, les variables représentent des informations qui peuvent changer au cours de l'exécution d'un programme. Par exemple, le programme de panier d'achat d'une boutique en ligne aura des variables qui représentent le nombre d'articles de chaque type à acheter, le prix de chaque article, ainsi que les frais d'expédition et les taxes. À l'aide de ces variables, un programmeur peut écrire une simple ligne de code qui multiplie la quantité par le prix, ajoute les frais d'expédition et les taxes et calcule le coût total, qui devient la valeur d'une autre variable.
Un grand programme peut avoir des milliers de variables différentes qu'une équipe de programmation doit conserver. Les nommer soigneusement devient crucial. Aujourd'hui, la plupart des codes comportent des noms de variables conçus pour transmettre un sens aux programmeurs qui le liront, des noms tels que NumberOfItems ou ShoppingCartTotal. Dans le schéma de dénomination de Simonyi, qu'il avait inventé pour son propre usage des années auparavant, chaque nom de variable est accompagné d'un préfixe qui vous donne des informations utiles à son sujet, comme son type (entier, disons, ou fraction décimale, ou chaîne de lettres). Certains systèmes limitent la longueur des noms de variables à huit caractères ; Simonyi a simplement omis les voyelles.
Le code résultant était dense et difficile à lire. Le système de Simonyi est devenu connu sous le nom de notation hongroise, à la fois en hommage au lieu de naissance de son créateur et parce qu'il donnait l'impression que les programmes avaient été écrits dans une langue étrangère impénétrable, selon le pionnier de la programmation Andy Hertzfeld. Le hongrois est largement maudit par ses détracteurs. L'expert canadien en Java, Roedy Green, l'a appelé en plaisantant l'arme nucléaire tactique des techniques d'obscurcissement du code source. Le programmeur Mozilla Alec Flett a écrit cette parodie :
prepBut nI vrbLike adjHungarian ! qQu'est-ce que l'artL'adjBig nProblem ?
Hertzfeld, écrivant à propos d'une rencontre chez Apple avec un code hongrois écrit par un collègue qui avait travaillé avec Simonyi au PARC, a déclaré que les noms semblaient avoir été choisis par l'ennemi de Superman de la 5e dimension, M. Mxyzptlk.
Mais alors que les critiques pensent que le hongrois rend le code illisible, Simonyi en reste fier et l'emploie à ce jour.
Méta-euphorie
Au début des années 90, le succès de Microsoft avait fait la fortune de Simonyi. (Pour plusieurs années, Forbes l'a estimé à 1 milliard de dollars.) Mais il se sentait toujours le remorqueur des affaires inachevées. La confusion des logiciels avait rendu la création d'Office angoissante pour Microsoft. Mais maintenant, avec des ordinateurs plus puissants que l'Alto sur chaque bureau et Internet les reliant, la crise des logiciels était la crise de tout le monde. Simonyi a commencé à penser qu'il était temps de revenir à la méta.
Charles a toujours essayé de construire ses systèmes de manière à élever le niveau d'abstraction, afin que vous puissiez gérer la complexité du système. Parce que la complexité, c'est la mort, explique Chuck Thacker, ancien collègue de Simonyi de BCC et PARC, qui dirige un projet de recherche sur l'architecture informatique chez Microsoft. Et malheureusement, de nos jours, fournir les installations que les gens veulent réellement aboutit à un système complexe. Nous nous accrochons du bout des doigts en ce moment.
Passant à un poste chez Microsoft Research, Simonyi a commencé à définir le concept de programmation intentionnelle, ou IP en abrégé. La programmation intentionnelle ajouterait une toute nouvelle couche d'abstraction à la pratique de l'écriture de logiciels. Cela permettrait aux programmeurs d'exprimer leurs intentions sans sombrer dans le bourbier des soi-disant détails d'implémentation qui menaçaient toujours de les avaler. Comme les méta-programmeurs de la thèse de Simonyi, transmettant des instructions aux codeurs ouvriers-abeilles, le programmeur intentionnel confierait le travail de découpe, mais pas à un collègue junior. Au lieu de cela, la programmation intentionnelle a fait appel à une sorte d'usine de code appelée générateur, un programme qui prend en charge un ensemble de commandes de niveau relativement élevé et crache un code de travail plus détaillé. L'objectif n'était pas tant de faciliter le travail de programmation que de permettre aux programmeurs de se vider la tête des trivialités afin qu'ils puissent réellement être créatifs.
Depuis son initiation à la programmation en tant qu'adolescent en tapant des opcodes dans l'Oural, Simonyi avait gravi les échelons de l'abstraction. Mais il sentit qu'il n'était pas assez haut. À bien des égards, la programmation semblait encore primitive. Pourquoi les programmeurs étaient-ils toujours aux prises avec des syntaxes de langage de programmation incompatibles ? Pourquoi a-t-il été si difficile d'étendre leurs langues préférées à de nouveaux domaines ? Pourquoi les programmeurs travaillaient-ils toujours avec du texte brut, organisant un petit nombre de caractères en chaînes linéaires comme ils l'avaient fait dans le passé avec les cartes perforées ? Le travail Wysiwyg de Simonyi avait libéré les employés de bureau pour créer et éditer des documents complexes. Les ingénieurs et les concepteurs utilisaient des outils CAD/CAM avancés pour concevoir et modifier les plans des gratte-ciel et des avions. Pourquoi les programmeurs, les sorciers qui avaient rendu tout cela possible, continuaient-ils à piocher leur code un caractère à la fois ?
Son équipe de recherche Microsoft s'est mise au travail et, en mars 1995, ils avaient construit un système fonctionnel pour la construction de programmes utilisant l'approche de programmation intentionnelle. Simonyi a déclaré que la propriété intellectuelle avait atteint une autosuffisance complète : c'est-à-dire que tous les travaux futurs sur la propriété intellectuelle seraient effectués en utilisant la propriété intellectuelle elle-même. Il a récompensé son équipe avec des T-shirts arborant l'une de ses images préférées d'enfance : l'image du baron Munchausen se sortant lui-même et son cheval d'une tourbière en tirant sur ses propres cheveux. Simonyi a annoncé une programmation intentionnelle au monde dans un article de septembre 1995 intitulé The Death of Computer Languages. Il était temps, comme il le dira plus tard, que les enfants du cordonnier se procurent des chaussures.
Au cours des années 1990 et dans le nouveau millénaire, tandis que Microsoft menait ses guerres avec Netscape et le ministère américain de la Justice et sortait de la bulle et de l'éclatement des dot-coms, Simonyi et son équipe travaillaient et apprenaient.
Pendant ce temps, à partir de 2001, Microsoft poussait les armées de développeurs qui écrivaient des logiciels pour Windows à adopter un nouveau système de programmation appelé .Net Framework. Contrairement à la programmation intentionnelle, .Net était terminé et nécessitait une rupture moins radicale avec les techniques de programmation existantes. Simonyi avait hâte de sortir son idée du laboratoire et de la présenter aux clients, mais c'était gênant dans les circonstances. Il explique : Ce n'était pas pratique, lorsque Microsoft faisait d'énormes progrès avec .Net à court terme, d'envoyer d'une manière ou d'une autre quelqu'un de la même organisation qui dit : Ce n'est pas ainsi que vous devriez faire les choses – Et si vous faisiez les choses dans cet autre , manière plus perturbatrice?
Simonyi était homme d'entreprise depuis plus de 20 ans. Mais en 2002, il quitte Microsoft et lance une société indépendante. Il est sorti avec un accord de licence croisée de brevets qui lui permettait d'utiliser les concepts et les idées de sa recherche en programmation intentionnelle, mais ne lui permettait pas d'emporter avec lui l'un de ses anciens codes. Il devrait commencer à écrire une nouvelle base de code à partir de zéro.
Sous la bannière de sa nouvelle entreprise, Simonyi a abandonné le mot programmation et a renommé son projet en logiciel intentionnel. L'idée de base n'avait pas changé, mais maintenant il commençait à souligner la valeur de l'approche pour les non-programmeurs. Le pitch de Simonyi ressemblait à ceci : Aujourd'hui, seul le programmeur est capable d'avoir un effet direct sur le logiciel. Les experts en la matière ou les experts du domaine - les personnes qui comprennent réellement ce que le logiciel doit faire, qu'il s'agisse de la tenue de dossiers médicaux, de la comptabilité d'entreprise ou de la modélisation climatique - ne peuvent pas modifier leurs outils ; ils sont obligés de soumettre une sorte de demande humble au programmeur. Intentional Software vendrait des outils de développement de logiciels non seulement aux programmeurs, mais aux experts du domaine qui connaissaient vraiment leur domaine.
La stratégie d'Intentional Software emprunte à une tendance de la programmation connue sous le nom de langages spécifiques à un domaine ou DSL - de petits dialectes de programmation adaptés aux besoins de disciplines spécifiques. Simonyi fait l'éloge des DSL mais dit qu'ils ne vont pas assez loin. Ils sont difficiles à créer et donc coûteux ; vous finissez par en avoir besoin de plus d'un (pour un système de facturation médicale, vous auriez besoin d'au moins un langage médical et financier) ; et ils sont incompatibles les uns avec les autres. Le système d'Intentional Software est comme une usine pour plusieurs DSL qui peuvent communiquer entre eux.
Voici comment cela pourrait fonctionner : supposons qu'une banque internationale souhaite développer un nouveau système de gestion des transactions dans plusieurs devises. Premièrement, les propres experts du domaine de la banque définiraient la fonctionnalité du système, en utilisant leurs termes et symboles habituels et en identifiant les variables les plus importantes (durée ou valeur ou taille de la transaction) et les procédures les plus courantes (convertir les avoirs d'une devise à une autre ou acheter des couvertures contre valeur décroissante). Ensuite, les programmeurs prendraient ces informations et créeraient un générateur de programme spécifique à un domaine qui incarnerait ces informations. Un outil logiciel distinct permettrait aux experts du domaine d'expérimenter différents ensembles de données et différentes manières de visualiser ces données aussi facilement que les hommes d'affaires réorganisent aujourd'hui leurs feuilles de calcul.
Le programmeur n'aurait pas besoin d'être convoqué à chaque fois qu'un nouveau développement dans le monde de la banque internationale, ou dans tout autre domaine, nécessiterait une nouvelle fonctionnalité logicielle. Le client ne se sentirait pas entravé par un langage de programmation. Tout le monde serait content.
Simonyi soutient que son approche résout plusieurs des problèmes les plus persistants du génie logiciel. Les programmeurs d'aujourd'hui, dit-il souvent, sont des cryptographes inconscients : ils recueillent les exigences et les connaissances de leurs clients, puis, littéralement, cachent ces informations précieuses dans une montagne de détails d'implémentation, c'est-à-dire de code. Le hic, c'est qu'une fois le code écrit, les programmeurs doivent faire des ajouts ou des changements en modifiant le code lui-même . Ce travail est pénible, lent et sujet aux erreurs. Nous ne devrions pas du tout toucher au code, dit Simonyi. Nous devrions être capables de concevoir des fonctions et des structures de données – que la programmation intentionnelle représente comme des arbres intentionnels – et laisser le générateur modifier le code en conséquence. (Pour une description plus complète de la programmation intentionnelle, voir Programmation intentionnelle expliquée )
En 2002, Simonyi a réuni une nouvelle équipe de développement ; il comprend aujourd'hui une dizaine de programmeurs, répartis entre Bellevue et la Hongrie. Ils ont commencé à recréer le code de programmation intentionnelle de Simonyi à partir de zéro et à travailler avec une poignée de clients pour tester leurs hypothèses et obtenir des commentaires. Il y a un an, inspirés par une nouvelle idée de la manière de présenter plusieurs vues de types de données hétérogènes, ils ont jeté une grande partie de leur code et ont recommencé. C'est une destruction créatrice, dit Simonyi. Chez Microsoft, c'était assez dur de faire ça, de tout jeter. Mais il faut abandonner les choses difficiles à prolonger.
ThoughtWorks, un cabinet de conseil informatique mondial, est l'un des premiers clients d'Intentional Software. Mais le PDG de ThoughtWorks, Roy Singham, a déclaré que nombre de ses collègues de l'entreprise étaient initialement sceptiques quant au nouveau projet de Simonyi : meilleurs cerveaux techniques pour aller chercher, et ils sont tous revenus et ont dit qu'il était sur la bonne voie. Oui, c'est dur. Oui, cela va prendre du temps, peut-être plusieurs années. Mais intellectuellement, il a la chose clouée. C'est le bon problème à résoudre.
J'ai ressenti une certaine frustration que nous n'ayons pas encore quelque chose que nous puissions réellement utiliser en production, déclare Martin Fowler, scientifique en chef chez ThoughtWorks. Charles ne semble pas très pressé d'expédier. Mais une chose à garder à l'esprit est qu'il a expédié des choses dans le passé – des choses assez dramatiques, avec Office.
Le fruit visible du travail d'Intentional à ce jour est un outil astucieux appelé Domain Workbench, qui stocke les informations vitales d'un programme dans une base de données intentionnelle et vous propose ensuite de nombreuses projections différentes de ces informations. Dans une démonstration qu'Intentional a donnée lors de deux conférences l'automne dernier, le Workbench - utilisant une fonctionnalité appelée Kaleidoscope - a pris une série de fragments de code et les a affichés dans une variété vertigineuse de formats. La façon dont la syntaxe du code avait été spécifiée n'avait pas d'importance ; vous pouvez le visualiser et le modifier, en utilisant la notation que vous préférez. Vous pouvez modifier votre programme en tant que code traditionnel entre crochets et en retrait, ou passer à la forme de contour, ou le faire ressembler à un schéma de câblage électrique, ou choisir quelque chose appelé un diagramme de chemin de fer, une sorte de notation d'organigramme dérivée de cartes de train à l'ancienne . Chaque vue est une traduction de l'arbre sous-jacent, que vous pouvez également examiner et modifier.
Les travaux d'Intentional Software suscitent deux grandes lignes de critique. Certains sceptiques à l'esprit théorique disent que l'objectif de Simonyi de capturer les intentions des utilisateurs d'ordinateurs est invraisemblable. Comment représentez-vous l'intention ? demande l'informaticien Jaron Lanier. Dès que nous savons comment le cerveau stocke les informations, nous pouvons peut-être représenter l'intention. Pour moi, cela ressemble à un fantasme. Un autre argument, courant chez les programmeurs, est plus pratique. De nombreux programmeurs aiment leurs éditeurs textuels et se méfient des outils qui les éloignent du code brut. Quant aux langages de programmation graphiques comme Visual Basic et les environnements de développement intégrés (IDE) qui automatisent les tâches de programmation de routine, ils les considèrent avec condescendance : de tels outils, disent-ils, imposent leurs propres façons de faire, limitent la créativité et empêchent les programmeurs de code auquel, tôt ou tard, ils doivent affronter. (Pour comprendre pourquoi les programmeurs sont si méfiants, voir The Law of Leaky Abstractions ) Les programmeurs sceptiques regardent Intentional Software et voient la perspective d'un autre IDE. Pour ceux qui pensent que les vrais programmeurs écrivent du texte, la programmation intentionnelle n'est ni très originale ni très recherchée.
Mais surtout, il y a étonnamment peu de discussions sur les logiciels intentionnels dans les forums de codeurs grouillants d'Internet. C'est en partie parce que si peu ont vu son logiciel. Le travail d'Intentional s'est déroulé dans le secret.
Lorsqu'il a lancé Intentional Software, Simonyi s'est associé à un professeur de l'Université de la Colombie-Britannique, Gregor Kiczales. Simonyi admirait le travail de Kiczales sur la programmation orientée aspect, une manière d'organiser et de modifier le code en fonction de préoccupations transversales qui ressemblent à une programmation intentionnelle. Kiczales, un autre vétéran de PARC, a passé sa carrière à travailler sur des moyens de faire ressembler le code à la conception. Kiczales a vu en rejoignant Simonyi une chance d'aller plus loin. Mais Kiczales faisait confiance au développement open source, contrairement à Simonyi. L'approche d'atelier fermé de style Microsoft ne semblait tout simplement pas organique pour Kiczales. Je l'aurais fait à Java, dit-il. La première sortie aurait eu lieu dans six mois. Le désaccord était amical mais irréconciliable, disent les deux hommes, et peu de temps après, Kiczales était parti.
Pour l'instant, à l'abri de la richesse de Simonyi, Intentional Software n'a pas de date cible ni de date limite d'expédition. Mais l'un de ses deux principaux clients se dit sur le point de déployer des outils intentionnels. Capgemini, une société internationale de conseil et de services informatiques basée à Paris qui dessert les grandes entreprises et dont le CTO, Andy Mulholland, est une connaissance de Simonyi, a commencé à travailler avec Intentional en mars dernier et envisage d'utiliser le système d'Intentional pour des projets dans le secteur des retraites européennes. Les règles très complexes du domaine, liées à la structure complexe du domaine d'activité, rendent l'approche de Simonyi attrayante, explique Henk Kolk, responsable de la technologie des services financiers de Capgemini, qui dirige les travaux de l'entreprise avec Intentional.
Contrôle au sol
La fascination de Simonyi pour l'espace dure depuis toujours. À 13 ans, il a remporté un concours pour devenir l'astronaute junior hongrois et s'est rendu à Moscou pour rencontrer un cosmonaute. En tant que nouvelle recrue chez Microsoft en 1981, il a convaincu le cofondateur Paul Allen de jouer au crochet du développement du nouveau système d'exploitation de l'IBM PC et de s'envoler pour la Floride pour assister au premier vol de la navette spatiale.
Le décollage à venir de Simonyi lui offre une réunion complète avec la technologie de l'ère soviétique qui a tracé le cours de sa vie. Il s'est entraîné pendant des mois au centre de formation des cosmonautes Yuri Gagarin en Russie à Star City, maîtrisant les détails des combinaisons spatiales et des toilettes spatiales, et apprenant le russe.
Le voyage dans l'espace confirmera le statut de Simonyi en tant que chose hautement improbable : un programmeur de célébrités. Il a deux jets et une licence de pilote pour les piloter. Il apparaît dans les tabloïds en tant que compagnon fréquent de la grande prêtresse du foyer, Martha Stewart. Il a construit un yacht de 233 pieds avec un pont enveloppant aux parois de verre. Il a financé une chaire à Oxford pour son ami Richard Dawkins, le théoricien darwinien.
Rien de tout cela, bien sûr, ne fera de différence dans le résultat de la quête de Simonyi pour atténuer les malheurs chroniques du domaine du logiciel. Il ne suffit pas d'être un grand programmeur, a dit Simonyi à Michael Hiltzik, auteur d'une histoire de PARC. Vous devez trouver un gros problème. Intentional pourrait ne jamais tenir ses grandes promesses. Mais personne ne peut accuser Simonyi d'avoir choisi un problème trop modeste.
Sa maison ces jours-ci est un manoir sur le lac Washington, sur la rive de la maison de Bill Gates, avec une galerie d'art, une piscine vitrée, un héliport, un laboratoire informatique avec des murs doublés magnétiquement, et un tour et une perceuse à colonne dans le sous-sol (pour satisfaire ces envies d'Erector Set). La maison a coûté 10 millions de dollars à construire : elle est inclinée à un angle de sept degrés et ressemble à un léger tremblement de terre qui l'a frappée, selon les mots de New York Times l'écrivain Patricia Leigh Brown, qui s'est émerveillée de sa précision mathématique hermétiquement scellée et l'a trouvée si vaste qu'un visiteur peut se sentir comme un astéroïde solitaire qui cliquette autour du système solaire.
[Seulement] Charles construirait une maison de 20 000 pieds carrés avec une chambre, a fait remarquer un jour le directeur de thèse de Simonyi et collègue de PARC, Butler Lampson. La chambre isolée dispose d'un centre de contrôle semblable à un cockpit qui permet à Simonyi de régler tous ses systèmes (chauffage, divertissement, téléphone, éclairage et arrosage) à sa satisfaction. Comme un sous-marin, expliqua-t-il à Brown. Ils doivent tous être verts avant de vous immerger. Il y a aussi un lit pivotant, que Simonyi peut utiliser pour affiner sa vue sur le lac ; ou vers la ligne d'horizon de Seattle, avec ses dédales d'employés de bureau aux prises avec leurs documents et leurs feuilles de calcul ; ou dans le ciel étoilé, où son dernier voyage l'emmènera bientôt.
Scott Rosenberg est vice-président des projets spéciaux chez Salon.com. Il est l'auteur de Rêver en code.
Programmation intentionnelle expliquée
Simonyi et la société sont les pionniers d'une approche de programmation par bouton-poussoir.
[ Cliquez ici pour un schéma de l'approche envisagée par Simonyi]
Shane Clifford, développeur chez Intentional Software, raconte cette fable.
Il était une fois un village avec quatre parcs, entretenu par quatre associations de quartier compétitives. La première association a décidé d'embellir son parc avec un nouveau banc. Il a sollicité des propositions de trois des plus grands fabricants de bancs au monde. Aucun des designs n'a remporté la majorité des votes des voisins, l'association a donc choisi le design le plus populaire. Le processus était démocratique, mais en fin de compte, la plupart n'étaient pas satisfaits du nouveau banc.
La deuxième association a décidé qu'elle voulait son propre banc, mais que tout le monde aimait. Il a trouvé un fabricant qui a construit des bancs personnalisés à partir de pièces mélangées. Mais le siège en bois que les membres aimaient n'était pas de la bonne longueur et le dossier décoratif ne fonctionnait pas avec les pieds verts qu'ils aimaient. Ils ont donc fait des compromis sur des pièces qui fonctionnaient ensemble. Les voisins étaient fiers du banc fini, mais personne ne s'y asseyait très souvent.
Les membres de la troisième association ont vu combien d'argent les deux premières avaient dépensé et ont décidé qu'ils pouvaient faire mieux. Les artisans du groupe ont demandé des suggestions à tout le monde, et à la fin, ils ont construit un banc simple et élégant que tout le monde considérait comme le plus beau du village. Malheureusement, il vacillait dangereusement.
La quatrième association voulait aussi un banc, mais elle ne voulait pas répéter les erreurs des autres groupes. Les voisins se sont tournés vers un fabricant de bancs peu connu qui a annoncé une nouvelle expérience de fabrication de bancs. Le fabricant de bancs est arrivé avec un camion à plateau chargé de machines étranges. Il a commencé à poser des questions telles que Quelle est la caractéristique la plus importante de ce banc ? Quelle est la prochaine fonctionnalité la plus importante ? Quels matériaux aimez-vous ? Quelle est votre forme préférée pour les pieds du banc ?
Après chaque réponse, le fabricant de bancs tournait quelques boutons sur ses machines, et une nouvelle image du banc en cours apparaissait sur un grand écran. Parfois, l'image n'était pas tout à fait correcte, alors les voisins faisaient marche arrière et répondaient aux questions différemment. Après 50 questions, le fabricant de bancs a appuyé sur un gros bouton. Les machines ronronnèrent un moment, puis dégorgeèrent un beau banc correspondant à l'image finale à l'écran. Tout le monde était heureux d'avoir eu l'occasion de contribuer, et de nombreuses personnes s'asseyaient sur le banc chaque jour.
Pour obtenir un banc qui rend tout le monde heureux, vous devez construire une machine de fabrication de bancs automatique ; aider les clients à définir leurs espoirs précis pour leur banc ; traduire ces espoirs en instructions comprises par la machine à fabriquer les bancs ; puis appuyez sur le bouton Créer. Les clients contrôlent étroitement le résultat et les fabricants d'établis, libérés des parties répétitives et mécaniques de la fabrication d'établis, passent plus de temps à utiliser leurs compétences pour alimenter les souhaits de leurs clients dans la machine.
Substituez un logiciel aux bancs, dit Clifford, et vous comprendrez la programmation intentionnelle - ainsi nommée parce que les programmeurs se concentrent sur la façon dont leurs clients entendent un programme fonctionner, et non sur l'encombrement du code requis pour mettre en œuvre ces intentions.
La programmation intentionnelle est similaire dans son concept aux programmes de traitement de texte ce que vous voyez est ce que vous obtenez, dont Charles Simonyi, le patron de Clifford, a été le pionnier. Les éditeurs de texte Wysiwyg permettent aux utilisateurs d'ordinateurs de manipuler l'apparence d'un document à l'écran sans les forcer à maîtriser le code sous-jacent. De même, la programmation intentionnelle encourage les utilisateurs d'ordinateurs à exprimer leurs besoins dans leur propre langage familier, puis leur montre des vues ou des projections compréhensibles de la conception émergente avant que le code exécutable ne soit assemblé. Ce n'est pas la seule philosophie de programmation qui repose sur de telles représentations graphiques ; le langage de modélisation unifié (UML), développé au milieu des années 90 chez Rational Software (qui fait maintenant partie d'IBM), utilise également des diagrammes graphiques pour représenter la fonction, la structure et le comportement d'un programme. Mais les diagrammes UML ne peuvent pas être transformés en logiciels finis, ce qui est le rêve de Simonyi pour la programmation intentionnelle.
Comment Intentional Software espère-t-il réaliser ce rêve ? Mettons le plan de Simonyi dans son propre diagramme (cliquez ici). Le processus de création de logiciels commence, naturellement, avec le client : toute organisation avec une tâche gourmande en informations qui doit être automatisée. Simonyi appelle les personnes de ces organisations des experts du domaine ; eux, et non les programmeurs, savent ce que le programme doit faire.
Avec l'aide des programmeurs, les experts du domaine répertorient tous les concepts et définitions que le logiciel devra englober. Toutes ces définitions entrent dans une base de données que Simonyi appelle le schéma de domaine.
À l'instar du fabricant de bancs tournant ses boutons, les programmeurs incorporent ensuite les définitions du schéma de domaine dans un code de domaine - une représentation de haut niveau des fonctions du logiciel, exprimée dans un langage spécifique au domaine, ou DSL, qui peut être adapté pour s'adapter au l'industrie en question. Mais si les DSL peuvent varier, chaque action que le logiciel doit effectuer est stockée dans un format uniforme, une arborescence intentionnelle. Les arbres intentionnels ont l'avantage d'être visuellement simples mais logiquement complets, ce qui signifie qu'ils peuvent être manipulés, révisés et projetés ou réenvisagés à volonté.
Par exemple, le calcul représenté par l'instruction de programme simple
renvoie a = b / (c +1) ;
est représenté par l'arbre intentionnel suivant :
Retourner
(
Attribuer
(
à,
Div
(
b,
Plus
(
c,
un
)
)
)
)
Une fois codé sous forme d'arbre, le calcul peut être projeté de nombreuses autres manières qui pourraient être plus familières aux experts du domaine, telles que
b
renvoie a = ——- ;
c + 1
Comme première tâche concrète, Simonyi et ses collègues d'Intentional Software travaillent à la création d'un outil spécial, le Domain Workbench, conçu pour gérer ces projections. Les experts du domaine et les programmeurs utilisent le Domain Workbench pour éditer et rééditer les projections jusqu'à ce qu'elles paraissent correctes. Après cela, le code de domaine est introduit dans un générateur - l'équivalent du camion de machines du fabricant de bancs - qui produit du code cible dans un langage tel que C++ ou Java que d'autres ordinateurs sont capables de comprendre, de compiler et d'exécuter.
Une fois le code cible généré, il ne peut pas être reconverti en code de domaine. À cet égard, le générateur est comme un programme de chiffrement qui transforme de manière irréversible le texte en clair en texte chiffré.
Cependant, et c'est peut-être le plus gros avantage de la programmation intentionnelle, il est facile de supprimer l'ancien code cible et de générer un code amélioré à partir de zéro. Révisez simplement le code de domaine à l'aide de l'éditeur Wysiwyg de Domain Workbench et exécutez-le à nouveau dans le générateur. Dans la plupart des approches plus anciennes, même le moindre changement dans les hypothèses d'origine peut obliger les programmeurs à passer au crible des millions de lignes de code, en mettant à jour chaque instance d'un concept, d'une définition ou d'un calcul à la main.
Le générateur reste la plus grande boîte noire du processus d'Intentional Software. Dans les publications techniques, tout ce que l'entreprise dira de ce mystérieux composant, c'est que le prototype est écrit dans le langage de programmation C# de Microsoft et qu'il accède au schéma du domaine et au code du domaine à l'aide d'une interface de programmation d'application, un moyen pour deux programmes de communiquer, qui est intégré à Domain Workbench. Il est clair, cependant, que l'écriture du générateur lui-même, ou son personnalisation pour une industrie ou un DSL spécifique, représentera une grande partie du coût de tout projet de programmation intentionnelle.
Wysiwyg a permis à des millions d'utilisateurs supplémentaires de créer de superbes documents, écrit Simonyi sur le blog de l'entreprise. Il est temps de faire de même pour les utilisateurs de logiciels.
Par Wade Roush
La loi des abstractions qui fuient
Extrait de Rêver dans le code : deux douzaines de programmeurs, trois ans, 4 732 bogues et une quête pour un logiciel transcendant , par Scott Rosenberg, à paraître par
Livres de la Couronne en janvier 2007.
Le logiciel, nous l'avons vu, est une affaire de couches, chaque couche traduisant des informations et des processus pour les couches supérieures et inférieures. Au bas de cet empilement de couches se trouve la machine avec ses uns et zéros binaires purs. Au sommet se trouvent les êtres humains, qui construisent et utilisent ces couches. Le logiciel intentionnel de Simonyi, au fond, propose simplement une couche de plus entre la machine et nous.
Les couches du logiciel sont son essence, et ce sont elles qui font progresser le domaine, mais elles ont une faiblesse persistante. Ils fuient. Par exemple, les utilisateurs de nombreuses versions de Microsoft Windows sont assez familiers avec le phénomène de l'écran bleu de la mort. Vous travaillez à l'intérieur d'une application logicielle comme un navigateur Web ou Microsoft Word, et tout à coup, de nulle part, votre écran devient bleu et vous voyez du texte blanc dessus qui se lit comme ceci :
Une exception fatale 0E s'est produite à
0167 : BFF9DFFF.
L'application en cours sera terminée.
En regardant l'aspect monochrome de l'écran et la police de caractères en bloc, les utilisateurs chevronnés peuvent sentir qu'ils ont été renvoyés en arrière dans le temps de l'ordinateur. Certains peuvent même comprendre que la référence alarmante du message à une exception fatale signifie que le programme a rencontré un bogue dont il ne peut pas récupérer et s'est écrasé, ou que les nombres cryptiques hexadécimaux (base 16) décrivent l'emplacement exact dans la mémoire de l'ordinateur où le crash a eu lieu. Aucune des informations n'a de valeur pour la plupart des utilisateurs. L'interface confortable et familière de l'application qu'ils utilisaient a disparu ; une couche d'abstraction plus profonde - dans ce cas, le shell Windows ou le programme de contrôle de niveau inférieur - a éclaté comme une couche inclinée de substrat rocheux qui traverse des couches géologiques plus récentes et pénètre dans la lumière du soleil.
(Aussi déconcertant que soit l'écran bleu de la mort, il représentait en fait une grande avancée par rapport aux versions antérieures de Windows, car il permet parfois à l'utilisateur d'arrêter le programme incriminé et de continuer à travailler. Avant l'écran bleu, le plantage d'un programme Windows est presque toujours a démonté toute la machine et tous ses programmes.)
Dans un essai intitulé The Law of Leaky Abstractions, Joel Spolsky a écrit : Toutes les abstractions non triviales, dans une certaine mesure, ont des fuites. Les abstractions échouent. Parfois un peu, parfois beaucoup. Il y a des fuites. Les choses tournent mal. Pour les utilisateurs, cela signifie que parfois votre ordinateur se comporte de manière bizarre et déroutante, et parfois vous voudrez, comme l'a dit Mitch Kapor dans son Manifeste de conception de logiciels , jetez-le par la fenêtre. Pour les programmeurs, cela signifie que les nouveaux outils et idées qui regroupent un peu de complexité informatique de bas niveau et les emballent dans une nouvelle abstraction plus facile à manipuler sont excellents, mais seulement jusqu'à ce qu'ils se brisent. Ensuite, toute cette complexité cachée s'infiltre dans leur travail. En théorie, la nouvelle couche supérieure pratique permet aux programmeurs d'oublier le désordre en dessous; en pratique, le programmeur a encore besoin de comprendre ce bordel, car il finira par y atterrir. Spolsky a écrit :
Les abstractions ne simplifient pas vraiment nos vies autant qu'elles étaient censées le faire. … La loi des abstractions qui fuient signifie que chaque fois que quelqu'un propose un nouvel outil de génération de code astucieux qui est censé nous rendre tous aussi efficaces, vous entendez beaucoup de gens dire : Apprenez d'abord à le faire manuellement, puis utilisez l'outil wizzy pour gagner du temps. Les outils de génération de code qui prétendent extraire quelque chose, comme toutes les abstractions, les fuites, et la seule façon de traiter les fuites de manière compétente est d'apprendre comment les abstractions fonctionnent et ce qu'elles abstrait. Donc les abstractions nous font gagner du temps à travailler, mais elles ne nous font pas gagner de temps à apprendre. … Et tout cela signifie que paradoxalement, même si nous avons des outils de programmation de plus en plus élevés avec des abstractions de mieux en mieux, devenir un programmeur compétent devient de plus en plus difficile.
Ainsi, même si les abstractions que nous avons créées au fil des ans nous permettent de traiter de nouveaux ordres de complexité dans le développement de logiciels auxquels nous n'avions pas à faire face il y a dix ou quinze ans, et même si ces outils nous permettent d'obtenir beaucoup de du travail effectué incroyablement rapidement, a écrit Spolsky, un jour, nous devons soudainement résoudre un problème où l'abstraction a fui, et cela prend deux semaines.
La loi des abstractions qui fuient explique pourquoi tant de programmeurs à qui j'ai parlé roulent des yeux avec scepticisme lorsqu'ils entendent des descriptions de programmation intentionnelle ou d'autres idées similaires pour transcender la complexité du logiciel. Ce n'est pas qu'ils n'apprécieraient pas de franchir un nouveau palier dans l'échelle de l'abstraction ; mais ils craignent que, quelle que soit la hauteur à laquelle ils grimpent sur cette échelle, ils devront toujours la monter et la descendre plus qu'ils ne le souhaiteraient – et plus elle grandit, plus le voyage est long.