Philosophie directrice
1. Langages de programmation pour les gens
Les langages de programmation sont la façon dont les gens parlent aux ordinateurs. L'ordinateur se fera un plaisir de parler n'importe quelle langue qui ne soit 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’intérêt des langages de programmation est d’éviter que nos pauvres et fragiles cerveaux humains ne se laissent submerger par trop de détails.
Les architectes savent que certains problèmes de conception sont plus banals que d’autres. Certains des problèmes de conception les plus clairs et les plus abstraits concernent la conception des ponts. Dans ce cas, votre travail consiste à parcourir la distance requise avec le moins de matériel possible. À l’autre extrémité du spectre se trouve le design des chaises. Les concepteurs de chaises devraient consacrer leur temps à penser aux fesses des gens.
Le développement de logiciels présente une différence similaire. Concevoir des algorithmes pour acheminer les données via un réseau est un problème abstrait et intéressant, comme la conception de ponts. Alors que concevoir des langages de programmation, c’est comme concevoir des chaises : il faut faire face aux faiblesses humaines.
C’est difficile à réaliser pour la plupart d’entre nous. 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 est qu’un certain degré d’élégance rend les programmes plus faciles à comprendre. Mais ce n’est pas seulement une question d’élégance.
Et quand je dis que les langages doivent être conçus pour s'adapter aux faiblesses humaines, je ne veux pas dire que les langages doivent être conçus pour les mauvais programmeurs. En réalité, vous devriez concevoir des logiciels pour les 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 étaient désignées par la lettre "x" avec des indices entiers.
2. Concevez pour vous et vos amis
Si vous regardez l'histoire des langages de programmation, la plupart des meilleurs langages ont été conçus pour être utilisés par leurs propres auteurs, et la plupart des pires ont été conçus pour que d'autres personnes puissent les utiliser.
Lorsque les langues sont conçues pour d'autres personnes, il s'agit toujours d'un groupe spécifique de personnes : les gens ne sont pas aussi intelligents que les créateurs de la langue. C'est ainsi que vous obtenez une langue qui vous parle. Cobol en est l’exemple le plus marquant, mais la plupart des langages sont imprégnés de cet esprit.
Cela n'a rien à voir avec le niveau de la langue. C est un niveau assez bas, mais il a été créé pour être utilisé par ses auteurs, c'est pourquoi les hackers l'adorent.
L’argument en faveur de la conception de langages pour les mauvais programmeurs est qu’il y a plus de mauvais programmeurs que de bons. C'est peut-être le cas. Mais ce petit nombre de bons programmeurs écrivent de manière disproportionnée plus de logiciels.
Ma question est la suivante : comment créer un langage qui plaise aux meilleurs hackers ? Il me semble que cette question est identique à la question de savoir comment 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 personnes) agissent comme des nounous : ils essaient de vous mettre en garde contre des choses qui, selon eux, ne vous seront pas utiles. Je suis du point de vue opposé : donnez au programmeur autant de contrôle que possible.
Quand j’ai appris Lisp pour la première fois, ce que j’ai le plus aimé, c’est que nous parlions sur un pied d’égalité. Dans les autres langues que j'avais apprises à ce moment-là, il y avait une langue, et il y avait mon programme dans cette langue, et ils existaient tout à fait séparément. Mais en Lisp, les fonctions et macros que j’ai écrites étaient les mêmes que celles dans lesquelles le langage lui-même était écrit. Je pourrais réécrire la langue elle-même si je le voulais. Il avait le même attrait que les logiciels open source.
4. La brièveté est la sœur du talent
La brièveté est sous-estimée et même méprisée. Mais si vous regardez dans le cœur des hackers, vous verrez qu’ils aiment vraiment la brièveté. Combien de fois avez-vous entendu des hackers parler avec tendresse de la façon dont, par exemple, dans l'APL, ils peuvent faire des choses incroyables avec seulement quelques lignes de code ? Je suppose que les gens vraiment intelligents aiment prêter attention à cela.
Je crois que presque tout ce qui raccourcit les programmes est une bonne chose. Il devrait y avoir beaucoup de fonctions de bibliothèque, tout ce qui peut être implicite devrait l'être ; la syntaxe devrait être plus concise ; même les noms d’entités doivent être courts.
Et il n’y a pas que les programmes qui doivent être courts. Les manuels doivent également être courts. Une bonne partie des manuels est remplie d'explications, de clauses de non-responsabilité, d'avertissements et de cas particuliers. Si vous devez raccourcir le manuel, la meilleure option est de corriger le langage qui nécessite tant d'explications.
5. Reconnaître ce qu'est le piratage
Beaucoup de gens aimeraient que le hacking soit une question de mathématiques, ou du moins de quelque chose qui s'apparente à de la science. Je pense que le piratage s'apparente davantage à l'architecture. L'architecture est une question de physique dans la mesure où un architecte doit concevoir un bâtiment qui ne tombera 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 adorent, c'est créer de superbes programmes. Et je pense que, au moins dans nos propres pensées, nous devrions nous rappeler qu'écrire de bons programmes est une chose merveilleuse, même lorsque ce travail ne se traduit pas facilement dans le courant intellectuel habituel des articles scientifiques. D'un point de vue intellectuel, il est tout aussi important de concevoir un langage que les programmeurs adoreront que d'en concevoir un terrible qui incarne une idée sur laquelle vous pouvez publier un article.
Questions ouvertes
1. Comment organiser les grandes bibliothèques ?
Les bibliothèques deviennent un élément important des langages de programmation. Ils deviennent si gros que cela peut être dangereux. S'il faut plus de temps pour trouver une fonction dans une bibliothèque qui fait ce dont vous avez besoin que pour écrire cette fonction vous-même, alors tout le code ne fait que rendre votre manuel plus épais. (Les manuels Symbolics en sont un exemple.) Nous devrons donc résoudre le problème d'organisation de la bibliothèque. Idéalement, concevez-les de manière à ce que le programmeur puisse deviner quelle fonction de bibliothèque est appropriée.
2. Les gens ont-ils vraiment peur de la syntaxe des préfixes ?
Il s'agit d'un problème ouvert dans le sens où j'y réfléchis depuis plusieurs années et dont je n'ai toujours pas la réponse. La syntaxe des préfixes me semble tout à fait naturelle, sauf peut-être pour son utilisation en mathématiques. Mais il se peut qu'une grande partie de l'impopularité de Lisp soit simplement due à sa syntaxe peu familière... La question de savoir si nous devrions faire quelque chose à ce sujet, si c'est vrai, est une autre affaire.
3. De quoi avez-vous besoin comme 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 résideront sur un serveur et communiqueront avec vous via un navigateur Web. Et pour écrire de telles applications, nous avons besoin de nouvelles choses.
L'une de ces choses est la prise en charge d'une nouvelle façon de publier des applications serveur. Au lieu d'une ou deux versions majeures par an, comme les logiciels de bureau, les logiciels serveur seront publiés sous forme d'une série de petits changements. Vous pourriez avoir cinq ou dix versions par jour. Et tout le monde disposera toujours de la dernière version.
Savez-vous comment concevoir des programmes maintenables ? Le logiciel serveur doit être conçu pour être modifiable. Vous devriez pouvoir le changer facilement, ou au moins savoir ce que signifie un changement mineur et ce qui est important.
Une autre chose qui peut être utile dans les logiciels serveur est, du coup, la continuité de la livraison. Dans une application Web, vous pouvez utiliser quelque chose comme pour obtenir l'effet des routines dans le monde sans état des sessions Web. La continuité de l'approvisionnement peut en valoir la peine si la fonctionnalité n'est pas trop coûteuse.
4. Quelles nouvelles abstractions restent à découvrir ?
Je ne sais pas si cet espoir est raisonnable, mais personnellement, j'aimerais vraiment découvrir une nouvelle abstraction - quelque chose qui pourrait être aussi significatif que des fonctions de première classe ou une récursivité ou au moins des paramètres par défaut. C'est peut-être un rêve impossible. De telles choses ne sont souvent pas découvertes. Mais je ne perds pas espoir.
Des secrets peu connus
1. Vous pouvez utiliser la langue de votre choix
Auparavant, la création d'applications signifiait la création de logiciels de bureau. Et dans les logiciels de bureau, il existe une forte tendance à écrire des applications dans le même langage que le système d’exploitation. Ainsi, il y a dix ans, écrire des logiciels en général signifiait écrire des logiciels en C. Finalement, la tradition a évolué : les applications ne doivent pas être écrites dans des langages inhabituels. Et cette tradition a évolué depuis si longtemps que des personnes non techniques comme les managers et les investisseurs en capital-risque l'ont également apprise.
Le logiciel serveur détruit complètement ce modèle. Avec le logiciel serveur, vous pouvez utiliser la langue de votre choix. Presque personne ne le comprend encore (surtout les managers et les investisseurs en capital-risque). Mais certains hackers le comprennent, c'est pourquoi nous entendons parler de langages indépendants comme Perl et Python. Nous n'entendons pas parler de Perl et de Python parce que les gens les utilisent pour écrire des applications Windows.
Qu'est-ce que cela signifie pour nous, les personnes intéressées par la conception de langages de programmation, qu'il existe un public potentiel pour notre travail ?
2. La vitesse vient des profileurs
Les développeurs de langage, ou du moins les implémenteurs de langage, aiment écrire des compilateurs qui génèrent du code rapide. Mais je pense que ce n'est pas ce qui rend les langues rapides pour les utilisateurs. Knuth a souligné il y a longtemps que la vitesse ne dépend que de quelques goulots d’étranglement. Et quiconque a essayé d’accélérer un programme sait qu’on ne peut pas deviner où se situe le goulot d’étranglement. Profiler est la réponse.
Les développeurs de langage résolvent le mauvais problème. Les utilisateurs n'ont pas besoin de benchmarks pour fonctionner rapidement. Ils ont besoin d’un langage capable d’indiquer quelles parties de leur programme doivent être réécrites. À ce stade, la rapidité est nécessaire dans la pratique. Alors peut-être qu'il serait préférable que les implémenteurs du langage consacrent la moitié du temps qu'ils consacrent à l'optimisation du compilateur et à l'écriture d'un bon profileur.
3. Vous avez besoin d’une application qui fait évoluer votre langue
Ce n’est peut-être pas la vérité ultime, mais il semble que les meilleurs langages aient évolué en même temps que les applications dans lesquelles ils étaient utilisés. C a été écrit par des personnes qui avaient besoin de programmation système. Lisp a été conçu en partie pour la différenciation symbolique, et McCarthy était si impatient de se lancer qu'il a même commencé à écrire des programmes de différenciation dans le premier article Lisp en 1960.
Ceci est particulièrement utile si votre application résout de nouveaux problèmes. Cela pousse votre langage à avoir de nouvelles fonctionnalités souhaitées par les programmeurs. Personnellement, je souhaite écrire un langage qui conviendra aux applications serveur.
[Au cours de la discussion, Guy Steele a également fait valoir ce point, ajoutant que l'application ne devrait pas consister à écrire un compilateur pour votre langage, à moins que votre langage ne soit conçu pour écrire des compilateurs.]4. Le langage doit être adapté à l'écriture de programmes ponctuels.
Vous savez ce que signifie un programme ponctuel : c'est lorsque vous devez résoudre rapidement un problème limité. Je crois que si vous regardez autour de vous, vous trouverez de nombreux programmes sérieux qui ont commencé comme des programmes ponctuels. Je ne serais pas surpris si la plupart des programmes commençaient comme des programmes ponctuels. Ainsi, si vous souhaitez créer un langage adapté à l’écriture de logiciels en général, il doit également convenir à l’écriture de programmes uniques, car il s’agit de la première étape de nombreux programmes.
5. La syntaxe est liée à la sémantique
On considère traditionnellement que la syntaxe et la sémantique sont des choses très différentes. Cela peut paraître choquant, mais ce n’est pas le cas. Je pense que ce que vous voulez réaliser dans votre programme dépend de la façon dont vous l’exprimez.
J'ai récemment parlé avec Robert Morris, et il a noté que la surcharge des opérateurs est un gros plus pour la victoire des langages à syntaxe infixe. Dans les langages avec syntaxe de préfixe, toute fonction que vous définissez est en fait un opérateur. Si vous souhaitez ajouter un nouveau type de numéro que vous avez composé, vous pouvez simplement définir une nouvelle fonction pour l'ajouter. Si vous faites cela dans un langage avec une syntaxe infixe, vous verrez qu'il y a une grande différence entre utiliser un opérateur surchargé et appeler une fonction.
Des idées qui reviennent avec le temps
1. Nouveaux langages de programmation
Dans les années 1970, il était de bon ton de développer de nouveaux langages de programmation. Ce n’est pas le cas actuellement. Mais je crois que les logiciels serveur ramèneront à nouveau la mode de la création de nouveaux langages. Avec un logiciel serveur, vous pouvez utiliser n'importe quelle langue, donc si quelqu'un crée une langue qui semble meilleure que les autres, il y aura des gens qui décideront de l'utiliser.
2. Temps partagé
Richard Kelsey a eu cette idée dont le moment est à nouveau venu et je la soutiens pleinement. Je suppose (et celle de Microsoft aussi) qu'une grande partie de l'informatique passera du bureau aux serveurs distants. En d’autres termes, le temps partagé est de retour. Je pense que cela nécessitera un soutien au niveau linguistique. Par exemple, Richard et Jonathan Reeves ont effectué beaucoup de travail pour implémenter la planification des processus dans le schéma 48.
3. Efficacité
Récemment, il semblait que les ordinateurs étaient déjà assez rapides. Nous entendons de plus en plus parler de bytecode, ce qui, du moins pour moi, signifie que nous avons une certaine réserve d'énergie. Mais je pense qu’avec les logiciels serveur, nous ne l’avons pas. Quelqu'un devra payer pour les serveurs qui exécutent le logiciel, et le nombre d'utilisateurs que le serveur peut prendre en charge par machine sera un diviseur de ses coûts d'investissement.
Je pense que l’efficacité sera importante, du moins en cas de goulots d’étranglement informatiques. Cela sera particulièrement important pour les opérations d'E/S, car les applications serveur effectuent de nombreuses opérations de ce type.
En fin de compte, il se peut que le bytecode ne soit pas la réponse. Sun et Microsoft semblent actuellement s'affronter dans le domaine du bytecode. Mais ils le font parce que le bytecode est un endroit pratique pour s'intégrer dans un processus, et non parce que le bytecode lui-même est une bonne idée. Il se peut que toute cette bataille passe inaperçue. Ce serait drôle.
Pièges et pièges
1. Clientèle
Ce n’est qu’une supposition, mais les seules applications qui en bénéficieront sont celles qui sont entièrement côté serveur. Concevoir un logiciel qui fonctionne en partant du principe que tout le monde aura un client revient à concevoir une société basée sur le principe que tout le monde sera honnête. Ce serait certainement pratique, mais il faut partir du principe que cela n’arrivera jamais.
Je pense qu'il y aura une augmentation rapide du nombre d'appareils compatibles Web, et nous pouvons supposer qu'ils prendront en charge le HTML et les formulaires de base. Avez-vous un navigateur sur votre téléphone ? Votre PalmPilot aura-t-il un téléphone ? Votre BlackBerry aura-t-il un écran plus grand ? Serez-vous capable d'accéder à Internet depuis votre gameboy ? De ta montre ? Je ne sais pas. Et je n'aurai pas besoin de le savoir si je parie que tout sera sur le serveur. C'est tout simplement beaucoup plus fiable d'avoir tous les cerveaux sur le serveur. .
2. Programmation orientée objet
Je réalise que c'est une déclaration controversée, mais je ne pense pas que la POO soit si importante. Je pense que c'est un paradigme approprié pour des applications spécifiques nécessitant des structures de données spécifiques, comme les systèmes de fenêtrage, les simulations, les systèmes de CAO. Mais je ne comprends pas pourquoi cela devrait convenir à tous les programmes.
Je pense que les gens dans les grandes entreprises aiment la POO, en partie parce que beaucoup de choses qui semblent fonctionner. Ce qui pourrait naturellement être représenté comme, disons, une liste de nombres entiers, peut désormais être représenté comme une salle de classe avec toutes sortes d’échafaudages et d’agitation.
Une autre caractéristique intéressante de la POO est que les méthodes vous donnent certains des effets des fonctions de première classe. Mais ce n’est pas une nouveauté pour les programmeurs Lisp. Lorsque vous disposez de véritables fonctions de première classe, vous pouvez simplement les utiliser de la manière qui convient à la tâche à accomplir, au lieu de tout regrouper dans un passe-partout de classes et de méthodes.
Je pense que cela signifie pour la conception du langage que vous ne devriez pas y intégrer trop profondément la POO. La réponse est peut-être de proposer des éléments plus généraux et fondamentaux et de laisser les gens concevoir n'importe quel système d'objets sous forme de bibliothèques.
3. Conception par comité
Si votre langage est conçu par un comité, alors vous êtes pris au piège, et pas seulement pour des raisons que tout le monde connaît. Tout le monde sait que les comités ont tendance à créer des formulations fragmentaires et incohérentes. Mais je pense que le grand danger est qu’ils ne prennent pas de risques. Lorsqu'un seul responsable est aux commandes, il prend des risques que le comité n'accepterait jamais de prendre.
Faut-il prendre des risques pour créer un bon langage ? Beaucoup de gens pourraient soupçonner que la conception linguistique est un domaine où il faut rester assez proche de la sagesse traditionnelle. Je parie que ce n'est pas le cas. Dans tout ce que font les gens, la récompense est proportionnelle au risque. Alors pourquoi la conception du langage devrait-elle être différente ?
Source: habr.com