Philosophie directrice
1. Langages de programmation pour les personnes
Les langages de programmation sont la façon dont les gens parlent avec les ordinateurs. L'ordinateur sera heureux de parler 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 surchargé d'une masse de détails.
Les architectes savent que certains problèmes de conception sont plus banals que d'autres. La conception des ponts est l'un des problèmes de conception les plus clairs et les plus abstraits. Dans ce cas, votre travail consiste à couvrir la distance requise avec le moins de matériel possible. À l'autre extrémité du spectre se trouve la conception des chaises. Les concepteurs de chaises devraient passer leur temps à penser aux ânes humains.
Le développement de logiciels a une différence similaire. La conception d'algorithmes pour le routage de données sur un réseau est un bon problème abstrait, 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.
La plupart d'entre nous ont du mal à s'en rendre compte. Concevoir des systèmes mathématiques élégants semble beaucoup plus attrayant pour la plupart d'entre nous que de se livrer à des 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 tout ne se limite pas à l'élégance.
Et quand je dis que les langues doivent être conçues pour tenir compte des faiblesses humaines, je ne veux pas dire que les langues doivent être conçues pour les mauvais programmeurs. En fait, vous devez concevoir des logiciels pour les meilleurs programmeurs, mais même les meilleurs programmeurs ont leurs limites. Je ne pense pas qu'au moins quelqu'un aimerait programmer dans une langue où toutes les variables seraient désignées par la lettre "x" avec des indices entiers.
2. Concevez pour vous et pour 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 d'autres personnes.
Lorsque les langues sont conçues pour d'autres personnes, il s'agit toujours d'un groupe spécifique de personnes: les personnes ne sont pas aussi intelligentes que les créateurs de la langue. Vous obtenez donc une langue qui vous parle avec condescendance. Cobol est l'exemple le plus clair, mais la plupart des langues sont imprégnées de cet esprit.
Cela n'a rien à voir avec le niveau élevé de la langue. C est assez bas niveau, mais il a été créé pour être utilisé par ses auteurs, c'est pourquoi les pirates 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.
Je m'intéresse à la question de savoir comment créer un langage qui plaira 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 nombreuses langues (en particulier celles créées pour d'autres personnes) se comportent comme des nounous: elles essaient de vous mettre en garde contre des choses qui, à leur avis, ne vous seront pas utiles. J'ai l'opinion contraire: donnez au programmeur autant de contrôle que possible.
Lorsque j'ai étudié le lisp pour la première fois, ce que j'ai le plus aimé, c'est que nous parlions sur un pied d'égalité. Dans d'autres langues que j'avais étudiées à l'époque, il y avait une langue, et il y avait mon programme dans cette langue, et elles existaient tout à fait séparément. Mais en Lisp, les fonctions et les macros que j'ai écrites étaient les mêmes dans lesquelles la langue elle-même était écrite. 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. Brevity - 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 pirates, vous verrez qu'ils aiment beaucoup la brièveté. Combien de fois avez-vous entendu des pirates dire avec amour que, par exemple, dans l'APL, ils peuvent faire des choses incroyables avec seulement quelques lignes de code? Je crois que les gens vraiment intelligents aiment vraiment y prêter attention.
Je crois que presque tout ce qui raccourcit les programmes est bon. 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 non seulement les programmes doivent être courts. Les manuels doivent également être courts. Une bonne partie des manuels est remplie d'explications, d'exonérations de responsabilité, d'avertissements et de cas particuliers. Si vous avez besoin de raccourcir le manuel, la meilleure option est de corriger la langue, ce qui nécessite tant d'explications.
5. Reconnaissez ce qu'est le piratage.
Beaucoup de gens aimeraient que le piratage soit mathématique, ou du moins quelque chose de similaire aux sciences naturelles. Je pense que le piratage ressemble plus à l'architecture. L'architecture est liée à la physique, en ce sens que l'architecte doit concevoir un bâtiment qui ne tombera pas, mais le véritable objectif de l'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 super programmes. Et je pense que, du moins dans nos propres pensées, nous devons nous rappeler que l'écriture de merveilleux programmes est merveilleuse, même lorsque ce travail n'est pas facilement traduit dans la monnaie intellectuelle ordinaire des travaux scientifiques. D'un point de vue intellectuel, il est tout aussi important de développer un langage que les programmeurs vont adorer et d'en créer un terrible qui incarne l'idée sur laquelle vous pouvez publier un article.
Problèmes ouverts
1. Comment organiser de grandes bibliothèques?
Les bibliothèques deviennent une partie importante des langages de programmation. Ils deviennent si gros que cela peut être dangereux. S'il faut plus de temps pour trouver une fonction dans la bibliothèque qui fait ce dont vous avez besoin que d'écrire cette fonction vous-même, alors tout le code ne fait qu'épaissir votre manuel. (Les manuels symboliques en sont un exemple.) Nous devons donc résoudre le problème de l'organisation des bibliothèques. Idéalement, concevez-les de sorte que le programmeur puisse deviner quelle fonction de bibliothèque convient.
2. Les gens ont-ils vraiment peur de la syntaxe des préfixes?
C'est un problème ouvert dans le sens où j'y pense depuis plusieurs années et je ne connais toujours pas la réponse. La syntaxe du préfixe me semble tout à fait naturelle, peut-être en plus de l'utiliser en mathématiques. Mais il se peut que la plupart de l'impopularité de Lisp soit simplement due à une syntaxe inconnue ... Y a-t-il quelque chose à voir avec cela, si c'est vrai, c'est une autre question.
3. De quoi avez-vous besoin pour le logiciel serveur?
Je pense que la plupart des applications qui seront écrites dans les vingt prochaines années seront des applications web, dans le sens où les programmes seront situés sur le 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 prend en charge une nouvelle façon de publier des applications serveur. Au lieu d'une ou deux versions majeures par an, comme le logiciel de bureau, le logiciel serveur sera publié dans une série de petits changements. Vous pouvez avoir cinq ou dix versions par jour. Et tout le monde aura toujours la dernière version.
Savez-vous comment concevoir des programmes à soutenir? Le logiciel serveur doit être conçu pour être adaptable. 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 un logiciel serveur est, tout à coup, la continuité de livraison. Dans une application Web, vous pouvez utiliser quelque chose comme
CPS pour obtenir l'effet des routines dans le monde sans état des sessions Web. Peut avoir une continuité de livraison en vaut la peine si cette opportunité n'est pas trop chère.
4. Quelles nouvelles abstractions restent à ouvrir?
Je ne sais pas dans quelle mesure cet espoir est raisonnable, mais personnellement, je voudrais vraiment découvrir une nouvelle abstraction - quelque chose qui pourrait être aussi important que les fonctions de première classe ou la récursivité, ou au moins les paramètres par défaut. C'est peut-être un rêve impossible. Ces choses ne s'ouvrent souvent pas. Mais je ne perds pas espoir.
Des secrets mé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 un grand parti pris pour l'écriture d'applications dans la même langue que le système d'exploitation. Il y a dix ans, écrire un logiciel dans son ensemble signifiait donc écrire un logiciel en C. Finalement, la tradition a évolué: les applications ne doivent pas être écrites dans des langages inhabituels. Et cette tradition se développe depuis si longtemps que les personnes non techniques, telles que les gestionnaires et les investisseurs en capital-risque, ont également appris cela.
Le logiciel serveur détruit complètement ce modèle. Avec le logiciel serveur, vous pouvez utiliser la langue de votre choix. Presque personne d'autre ne le comprend (en particulier les gestionnaires et les investisseurs en capital-risque). Mais certains pirates comprennent cela, c'est pourquoi nous avons entendu parler de langages indy comme Perl et Python. Nous n'entendons pas parler de Perl et Python car 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 ses implémenteurs, adorent é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. Knut a depuis longtemps remarqué que la vitesse ne dépend que de quelques goulots d'étranglement. Et quiconque a essayé d'accélérer le programme sait que vous ne pouvez pas deviner où se trouve le goulot d'étranglement. Le profileur est la réponse.
Les développeurs de langage résolvent le mauvais problème. Les utilisateurs n'ont pas besoin de repères pour travailler rapidement. Ils ont besoin d'un langage qui peut montrer quelles parties de leur programme doivent être réécrites. À ce stade, la vitesse est nécessaire dans la pratique. Il serait donc préférable que les implémenteurs de langage passent la moitié du temps à optimiser le compilateur et à l'écrire un bon profileur.
3. Vous avez besoin d'une application qui fait évoluer votre langage
Ce n'est peut-être pas la vérité ultime, mais il semble que les meilleurs langages se soient développés avec les applications dans lesquelles ils ont été utilisés. C a été écrit par des personnes qui avaient besoin d'une programmation système. Lisp a été conçu en partie pour la différenciation symbolique; McCarthy était si désireux de commencer qu'il a commencé à écrire des programmes de différenciation même dans le premier document Lisp en 1960.
Cela est particulièrement utile si votre application résout de nouveaux problèmes. Cela encourage votre langage à disposer de nouvelles fonctionnalités dont les programmeurs ont besoin. Personnellement, je suis intéressé par l'écriture d'un langage adapté aux applications serveur.
[Au cours de la discussion, Guy Steele a également exprimé cette idée, ajoutant que l'application ne devrait pas consister à écrire un compilateur pour votre langue, à moins que votre langue ne soit destinée à l'écriture de compilateurs.]
4. La langue doit convenir à la rédaction de programmes uniques.Vous savez ce que signifie un programme unique: c'est à ce moment que 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 ponctuels. Ainsi, si vous souhaitez créer un langage adapté à l'écriture de logiciels en général, il devrait convenir à l'écriture de programmes ponctuels, car il s'agit de la phase initiale de nombreux programmes.
5. Syntaxe liée à la sémantique
On croit traditionnellement 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.
J'ai récemment parlé avec Robert Morris, et il a remarqué que la surcharge de l'opérateur est un gros plus dans les langues gagnantes avec la syntaxe infixe. Dans les langues avec syntaxe de préfixe, toute fonction que vous définissez est en fait un opérateur. Si vous souhaitez ajouter le 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 à la mode de développer de nouveaux langages de programmation. Ce n'est plus le cas. Mais je crois que le logiciel serveur reviendra à la mode pour créer de nouveaux langages. Avec le logiciel serveur, vous pouvez utiliser n'importe quelle langue que vous souhaitez, 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. Partage de temps
Richard Kelsey a proposé cette idée, dont le temps est venu, et je la soutiens pleinement. Je suppose (et Microsoft aussi) que de nombreux calculs passeront du bureau aux serveurs distants. En d'autres termes, la division du temps est revenue. Je pense que vous aurez besoin de soutien au niveau linguistique. Par exemple, Richard et Jonathan Reeves ont fait beaucoup de travail pour mettre en œuvre la planification des processus dans le schéma 48.
3. Efficacité
Récemment, il semblait que les ordinateurs étaient déjà assez rapides. De plus en plus, nous entendons parler de bytecode, ce qui signifie au moins pour moi que nous avons le pouvoir en stock. Mais je pense qu'avec le logiciel serveur, nous ne l'avons pas. Quelqu'un devra payer pour les serveurs exécutant le logiciel, et le nombre d'utilisateurs que le serveur peut supporter par machine sera un diviseur de leurs coûts d'investissement.
Je pense que l'efficacité aura de l'importance, au moins dans les goulots d'étranglement de l'informatique. 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 pourrait s'avérer que le bytecode n'est pas une option. Sun et Microsoft semblent actuellement se battre face à face sur le champ du bytecode. Mais ils le font parce que le bytecode est un endroit pratique pour s'impliquer dans le processus, et non parce que le bytecode seul 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. Clients
Ce n'est qu'une hypothèse, mais c'est que seules les applications qui seront entièrement côté serveur en bénéficieront. Concevoir un logiciel qui fonctionne sur l'hypothèse que tout le monde aura votre client, c'est comme créer une société basée sur l'hypothèse que tout le monde sera honnête. Ce serait certainement pratique, mais vous devez supposer que cela ne se produira jamais.
Je pense qu'il y aura une augmentation rapide des appareils avec accès au 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? Y aura-t-il un téléphone dans votre PalmPilot? Votre mûre aura-t-elle un écran plus grand? Aurez-vous la possibilité d'aller en ligne depuis votre gameboy? De votre montre? Je ne sais pas. Et je n'ai pas besoin de savoir si je parie que tout sera sur le serveur. Il est tout simplement beaucoup plus fiable d'avoir tous les cerveaux sur le serveur. .
2. Programmation orientée objet
Je comprends qu'il s'agit d'une déclaration 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 spécifiques, telles que des systèmes de fenêtres, des simulations, des systèmes de CAO. Mais je ne comprends pas pourquoi il devrait convenir à tous les programmes.
Je pense que les gens des grandes entreprises aiment la POO, en partie parce que cela fournit beaucoup de ce qui ressemble à du travail. Ce qui, bien sûr, peut être représenté comme, disons, une liste d'entiers, peut maintenant être représenté comme une classe avec toutes sortes d'échafaudages, avec du bruit et de l'agitation.
Une autre caractéristique intéressante de la POO est que les méthodes vous donnent un certain effet des fonctions de première classe. Mais ce n'est pas nouveau pour les programmeurs Lisp. Lorsque vous disposez de fonctions réelles de la première classe, vous pouvez simplement les utiliser de la manière qui correspond à la tâche, au lieu de tout insérer dans un modèle à partir des classes et des 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.
Peut-être que la réponse est d'offrir des choses plus générales et fondamentales et de permettre aux gens de concevoir tout type de systèmes d'objets sous forme de bibliothèques.3. Conception par le comité
Si votre langue est rédigée 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 un langage grossier et incohérent. Mais je pense que le grand danger est qu'ils ne prennent pas de risques. Lorsqu'une personne est à la tête, elle prend des risques que le comité n'acceptera jamais de prendre.Dois-je prendre des risques pour créer une bonne langue? Beaucoup de gens peuvent soupçonner que la conception d'une langue est l'endroit où vous devriez rester assez proche de la sagesse traditionnelle. Je parie que non. 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?