Philosophie directrice
1. Langages de programmation pour les gens
Les langages de programmation sont la façon dont les gens parlent aux ordinateurs. Un ordinateur sera content de communiquer dans n'importe quelle langue qui n'est pas ambiguë. La raison pour laquelle nous avons des langages de haut niveau est que les gens ne peuvent pas gérer le langage machine. L'essence des langages de programmation est d'empêcher notre pauvre cerveau humain fragile d'être submergé par une quantité de détails.
Les architectes savent que certains problèmes de conception sont plus concrets que d'autres. L'un des problèmes de conception les plus clairs et abstraits est celui de la construction de ponts. Dans ce cas, votre travail consiste à couvrir la distance requise avec le moins de matériau possible. À l'autre extrême, il y a la conception de chaises. Les concepteurs de chaises doivent passer leur temps à réfléchir aux derrières humains.
Le développement logiciel présente une distinction similaire. Concevoir des algorithmes pour acheminer les données à travers un réseau est un bon problème abstrait, tout comme la conception de ponts. En revanche, la conception de langages de programmation ressemble à la conception de chaises : il faut tenir compte des faiblesses humaines.
Il est difficile pour la plupart d'entre nous de le réaliser. Concevoir des systèmes mathématiques élégants semble beaucoup plus attrayant pour la plupart d'entre nous que de se plier aux faiblesses humaines. Le rôle de l'élégance mathématique réside dans le fait qu'un certain degré d'élégance rend les programmes plus faciles à comprendre. Mais l'élégance ne suffit pas.
Et quand je dis que les langages doivent être conçus en tenant compte des faiblesses humaines, je ne veux pas dire que les langages doivent être conçus pour de mauvais programmeurs. En fait, vous devez concevoir le logiciel pour de meilleurs programmeurs, mais même les meilleurs programmeurs ont leurs limites. Je ne pense pas que quiconque aimerait programmer dans un langage où toutes les variables seraient désignées par la lettre «x» avec des indices entiers.
2. Concevez pour vous-même et pour vos amis
Si vous regardez l'histoire des langages de programmation, la plupart des meilleurs langages ont été conçus pour l'utilisation de leurs propres auteurs, tandis que la plupart des pires ont été conçus pour d'autres personnes.
Lorsque les langages sont conçus pour d'autres personnes, cela implique toujours un groupe spécifique de personnes : les gens ne sont pas aussi intelligents que les créateurs du langage. Vous obtenez alors un langage qui vous parle de manière condescendante. Cobol en est l'exemple le plus frappant, mais la plupart des langages sont imprégnés de cet esprit.
Cela n'a rien à voir avec le niveau d'abstraction du langage. C est un langage assez bas niveau, mais il a été créé pour être utilisé par ses auteurs, c'est pourquoi les hackers l'aiment.
L'argument en faveur de la conception de langages pour de mauvais programmeurs est que les mauvais programmeurs sont plus nombreux que les bons. C'est probablement vrai. Mais ce petit nombre de bons programmeurs écrit de manière disproportionnée plus de logiciels.
Je m'interroge sur la manière de créer un langage qui plaira aux meilleurs hackers. Je pense que cette question est identique à celle de la manière de créer un bon langage de programmation, mais même si ce n'est pas le cas, c'est au moins une question intéressante.
3. Donnez au programmeur autant de contrôle que possible
De nombreux langages (surtout ceux conçus pour d'autres) agissent comme des nourrices : ils essaient de vous prévenir des choses qui, selon eux, ne vous seront pas utiles. Je maintiens l'opinion opposée : donnez au programmeur autant de contrôle que vous le pouvez.
Quand j'ai d'abord étudié Lisp, ce que j'ai le plus aimé, c'est que nous parlions d'égal à égal. Dans d'autres langages que j'avais étudiés à ce moment-là, il y avait le langage et mon programme dans ce langage, et ils existaient de manière assez séparée. Mais dans Lisp, les fonctions et les macros que j'ai écrites étaient les mêmes que celles sur lesquelles le langage lui-même était construit. Je pouvais réécrire le langage lui-même si je le voulais. Cela avait la même attrait que les logiciels open source.
4. La concision est la sœur du talent
La brièveté est sous-estimée et même méprisée. Mais si vous regardez au fond des cœurs des hackers, vous verrez qu'ils aiment beaucoup la brièveté. Combien de fois avez-vous entendu des hackers parler avec affection du fait que, disons, dans APL, ils peuvent faire des choses étonnantes avec seulement quelques lignes de code ? Je crois que les véritables intelligences aiment en fait prêter attention à cela.
Je pense que presque tout ce qui permet de rendre les programmes plus courts est bon. Il doit y avoir de nombreuses fonctions de bibliothèque, tout ce qui peut être implicite devrait l'être ; la syntaxe doit être davantage concise ; même les noms des entités doivent être courts.
Et pas seulement les programmes doivent être courts. Les manuels doivent aussi l'être. Une bonne partie des manuels est remplie d'explications, de nuances, d'avertissements et de cas particuliers. Si vous devez réduire un manuel, la meilleure solution est de corriger le langage qui nécessite tant d'explications.
5. Reconnaître ce qu'est le hacking
Beaucoup de gens souhaiteraient que le hacking soit comme les mathématiques ou, du moins, quelque chose de similaire aux sciences naturelles. Je pense que le hacking ressemble davantage à l'architecture. L'architecture est liée à la physique, en ce sens qu'un architecte doit concevoir un bâtiment qui ne s'effondre pas, mais le véritable objectif d'un architecte est de créer un grand bâtiment, et non de faire des découvertes dans le domaine de la statique.
Ce que les hackers aiment, c'est créer de grands programmes. Et je pense qu'au moins dans nos propres esprits, nous devons nous rappeler que rédiger des programmes remarquables est formidable, même si ce travail se traduit difficilement en monnaie intellectuelle des travaux scientifiques. D'un point de vue intellectuel, il est tout aussi important de développer un langage que les programmeurs aimeront, que de créer une idée horrible, dont vous pouvez publier un article.
Problèmes ouverts
1. Comment organiser de grandes bibliothèques ?
Les bibliothèques deviennent une partie essentielle des langages de programmation. Elles deviennent si volumineuses que cela peut poser problème. Si vous passez plus de temps à rechercher une fonction dans une bibliothèque qui fait ce dont vous avez besoin que de l'écrire vous-même, alors tout votre code ne fait que alourdir votre manuel. (Les manuels Symbolics en étaient un exemple.) Nous devons donc résoudre le problème de l'organisation des bibliothèques. Idéalement, il faudrait les concevoir de manière à ce qu'un programmeur puisse deviner quelle fonction de la bibliothèque conviendrait.
2. Les gens sont-ils vraiment effrayés par la syntaxe préfixe ?
C'est un problème ouvert en ce sens que j'y ai réfléchi pendant plusieurs années et je ne sais toujours pas la réponse. La syntaxe préfixe me semble tout à fait naturelle, sauf peut-être dans son utilisation en mathématiques. Mais il se peut que la grande partie de l'impopularité des Lisp soit simplement due à une syntaxe inconnue... Faut-il faire quelque chose à ce sujet, si cela s'avère vrai, est une autre question.
3. De quoi avez-vous besoin pour un logiciel serveur ?
Je pense que la plupart des applications qui seront écrites au cours des vingt prochaines années seront des applications web, dans le sens où les programmes seront hébergés sur un serveur et communiqueront avec vous via un navigateur web. Et pour écrire de telles applications, nous avons besoin de nouvelles choses.
Une de ces choses est le soutien d'un nouveau mode de publication pour les applications serveur. Au lieu d'un ou deux grands lancements par an, comme pour les logiciels de bureau, le logiciel serveur sera publié sous forme de petites modifications successives. Vous pouvez avoir cinq ou dix mises à jour par jour. Et tout le monde aura toujours la dernière version.
Saviez-vous comment concevoir des programmes pour qu'ils soient maintenables ? Le logiciel serveur doit être conçu pour être modifiable. Vous devez pouvoir le modifier facilement, ou au moins savoir ce qu'implique une petite modification et ce qui est important.
Une autre chose qui peut être utile dans le logiciel serveur est, soudainement, la continuité de la livraison. Dans une application web, vous pouvez utiliser quelque chose comme , pour obtenir l'effet des sous-programmes dans un monde stateless des sessions web. La continuité de la livraison peut en valoir la peine, si cette possibilité n'est pas trop coûteuse.
4. Quelles nouvelles abstractions restent à découvrir ?
Je ne suis pas sûr de la raisonnabilité d'un tel espoir, mais personnellement, j'aimerais vraiment découvrir une nouvelle abstraction — quelque chose qui pourrait être aussi significatif que les fonctions de premier classe ou la récursion, ou au moins que les paramètres par défaut. Peut-être est-ce un rêve irréalisable. De telles choses ne sont souvent pas révélées. Mais je ne perds pas espoir.
Secrets peu connus
1. Vous pouvez utiliser n'importe quel langage que vous souhaitez
Auparavant, créer des applications signifiait créer des logiciels de bureau. Et dans les logiciels de bureau, il y avait une forte tendance à écrire des applications dans le même langage que le système d'exploitation. Il y a dix ans, écrire des logiciels signifiait en général écrire des logiciels en C. Avec le temps, cette tradition a évolué : les applications ne doivent pas être écrites dans des langages atypiques. Et cette tradition s'est tellement développée que même les personnes non techniques, comme les managers et les investisseurs en capital-risque, l'ont également apprise.
Les logiciels serveur détruisent complètement ce modèle. Avec les logiciels serveur, vous pouvez utiliser n'importe quel langage que vous souhaitez. Presque personne ne comprend encore cela (surtout les managers et les investisseurs en capital-risque). Mais certains hackers le comprennent, c'est pourquoi nous avons entendu parler de langages indépendants comme Perl et Python. Nous n'entendons pas parler de Perl et Python parce que les gens les utilisent pour écrire des applications pour Windows.
Qu'est-ce que cela signifie pour nous, les personnes intéressées par la conception des langages de programmation, qu'il existe un public potentiel pour notre travail.
2. La vitesse provient des profileurs
Les concepteurs de langages ou, du moins, ceux qui les mettent en œuvre aiment écrire des compilateurs qui génèrent du code rapide. Mais je pense que ce n'est pas cela qui rend les langages rapides pour les utilisateurs. Knuth a depuis longtemps remarqué que la vitesse dépend de quelques goulets d'étranglement. Et quiconque a essayé d'accélérer un programme sait que vous ne pouvez pas deviner où se trouve le goulet d'étranglement. Le profileur en est la réponse.
Les développeurs de langages ne s'attaquent pas au bon problème. Les utilisateurs n'ont pas besoin que les benchmarks soient rapides. Ils ont besoin d'un langage qui peut montrer quelles parties de leur programme doivent être réécrites. À ce moment-là, la vitesse est réellement nécessaire. Il serait peut-être mieux que les développeurs de langages consacrent la moitié du temps qu'ils passent à optimiser le compilateur à écrire un bon profileur.
3. Vous avez besoin d'une application qui fait évoluer votre langage
Ce n'est peut-être pas une vérité absolue, mais il semble que les meilleurs langages se soient développés avec les applications qui les utilisaient. Le C a été écrit par des gens qui avaient besoin de programmation système. Le Lisp a été conçu en partie pour la différentiation symbolique, McCarthy était tellement impatient de commencer qu'il a commencé à écrire des programmes de différentiation dès le premier document sur le Lisp en 1960.
C'est particulièrement valable si votre application résout de nouveaux problèmes. Cela pousse votre langage à avoir de nouvelles fonctionnalités nécessaires aux programmeurs. Personnellement, je suis intéressé à écrire un langage qui soit bon pour les applications serveur.
[Lors de la discussion, Guy Steele a également exprimé cette idée, ajoutant qu'une application ne devrait pas se limiter à écrire un compilateur pour votre langage, à moins que votre langage ne soit destiné à écrire des compilateurs.]
4. Le langage doit être adapté à l'écriture de programmes jetables.
Vous savez ce qu'est un programme jetable : c'est lorsque vous devez résoudre rapidement une tâche limitée. Je suppose que si vous regardez autour de vous, vous trouverez de nombreux programmes sérieux qui ont commencé comme des programmes jetables. Je ne serais pas surpris si la plupart des programmes avaient commencé comme des programmes jetables. Ainsi, si vous voulez créer un langage qui soit approprié pour écrire des logiciels en général, il doit également être adapté à l'écriture de programmes jetables, car c'est le point de départ de nombreux programmes.
5. La syntaxe est liée à la sémantique
Il est traditionnellement considéré que la syntaxe et la sémantique sont des choses très différentes. Cela peut sembler choquant, mais ce n'est pas le cas. Je pense que ce que vous voulez obtenir dans votre programme est lié à la façon dont vous l'exprimez.
Récemment, j'ai parlé avec Robert Morris, et il a remarqué que la surcharge d'opérateurs est un grand atout pour la victoire des langages à syntaxe infixe. Dans les langages à syntaxe préfixe, toute fonction que vous définissez est en fait un opérateur. Si vous souhaitez additionner un nouveau type de nombre que vous avez inventé, vous pouvez simplement définir une nouvelle fonction pour son addition. Si vous faites cela dans un langage à syntaxe infixe, vous verrez qu'il y a une grande différence entre l'utilisation d'un opérateur surchargé et l'appel d'une fonction.
Des idées qui reviennent avec le temps
1. Nouveaux langages de programmation
En regardant en arrière vers les années 1970, il était à la mode de développer de nouveaux langages de programmation. Ce n'est plus le cas aujourd'hui. Mais je pense que les logiciels serveur remettront à la mode la création de nouveaux langages. Avec le logiciel serveur, vous pouvez utiliser n'importe quel langage que vous souhaitez, donc si quelqu'un crée un langage qui semble meilleur que les autres, il y aura des gens qui décideront de l'utiliser.
2. Séparation du temps
Richard Kelsey a proposé cette idée, dont le temps est de nouveau venu, et je la soutiens totalement. Mon hypothèse (et celle de Microsoft également) est que beaucoup de calculs se déplaceront des ordinateurs de bureau vers des serveurs distants. En d'autres termes, la séparation du temps est revenue. Je pense qu'un soutien au niveau du langage sera nécessaire. Par exemple, Richard et Jonathan Rees ont fait beaucoup de travail pour intégrer la planification de processus dans Scheme 48.
3. Efficacité
Il semblait récemment que les ordinateurs étaient déjà suffisamment rapides. De plus en plus, nous entendons parler de bytecode, ce qui, pour moi, signifie que nous avons de la puissance en réserve. Mais je pense qu'avec le logiciel serveur, nous ne l'avons pas. Quelqu'un devra payer pour serveurs, sur lesquels le logiciel fonctionne, et le nombre d'utilisateurs que le serveur peut supporter par machine sera le diviseur de leurs coûts d'investissement.
Je pense que l'efficacité comptera, au moins dans les goulets d'étranglement des calculs. Cela sera particulièrement important pour les opérations d'entrée-sortie, car les applications serveur effectuent un grand nombre de telles opérations.
Il se pourrait qu'à la fin, le bytecode ne soit pas la solution. Sun et Microsoft semblent actuellement se battre face à face sur le terrain du bytecode. Mais ils le font parce que le bytecode est un endroit pratique pour s'intégrer au processus, et non parce que le bytecode est une bonne idée en soi. Il se pourrait que toute cette bataille passe inaperçue. Ce serait intéressant.
Pièges et pièges
1. Clients
C'est juste une hypothèse, mais je pense que seules les applications entièrement serveurs vont gagner. Concevoir un logiciel qui fonctionne sous l'hypothèse que chacun aura votre client, c'est comme créer une société en supposant que tout le monde sera honnête. Ce serait définitivement pratique, mais vous devrez admettre que cela ne se produira jamais.
Je pense qu'il y aura une augmentation rapide des appareils avec accès au web, et on peut supposer qu'ils supporteront le HTML de base et des formulaires. Vous avez un navigateur sur votre téléphone ? Est-ce que votre PalmPilot peut se connecter à internet ? Votre Blackberry aura-t-il un écran plus grand ? Pourrez-vous accéder à internet depuis votre gameboy ? Depuis votre montre ? Je ne sais pas. Et je n'aurai pas besoin de le savoir si je parie que tout sera sur le serveur. Il est tout simplement beaucoup plus fiable d'avoir toute l'intelligence sur le serveur.
2. Programmation orientée objet
Je comprends que c'est une affirmation controversée, mais je ne pense pas que la POO soit quelque chose d'important. Je pense que c'est un paradigme approprié pour des applications spécifiques qui nécessitent des structures de données particulières, comme des systèmes de fenêtres, des simulations, ou des systèmes CAO. Mais je ne comprends pas pourquoi cela devrait être approprié pour tous les programmes.
Je pense que les gens dans les grandes entreprises aiment la POO, en partie parce qu'elle offre beaucoup de ce qui ressemble à du travail. Ce qui peut naturellement être représenté comme, disons, une liste d'entiers, peut désormais être représenté comme une classe avec toutes sortes de charpentes, de bruit et d'agitation.
Une autre caractéristique attrayante de la POO est que les méthodes vous donnent un certain effet de fonctions de premier ordre. Mais ce n'est pas nouveau pour les programmeurs Lisp. Quand vous avez de vraies fonctions de premier ordre, vous pouvez simplement les utiliser de n'importe quelle manière qui correspond à la tâche au lieu de tout forcer dans un modèle de classes et de méthodes.
Je pense que cela signifie pour la conception des langages que vous ne devez pas trop ancrer la POO en elle. Peut-être que la réponse réside dans le fait de proposer des choses plus générales et fondamentales, et de laisser les gens concevoir n'importe quel système d'objets sous forme de bibliothèques.
3. Conception par un comité
Si votre langage est conçu par un comité, alors vous êtes piégé, et pas seulement pour des raisons bien connues. Tout le monde sait que les comités ont tendance à créer un design de langage confus et incohérent. Mais je pense que le plus grand danger est qu'ils n'assument pas de risques. Quand un seul individu est à la tête, il prend des risques que le comité ne serait jamais d'accord pour prendre.
Faut-il prendre des risques pour créer un bon langage ? Beaucoup de gens pourraient soupçonner que la conception d'un langage est quelque chose où vous devez vous en tenir assez près de la sagesse traditionnelle. Je parierais que ce n'est pas le cas. Dans tout le reste de ce que font les gens, la récompense est proportionnelle au risque. Alors pourquoi la conception des langages devrait-elle être différente ?
Source : habr.com
