Begeleidende filosofie
1. Programmeertalen voor mensen
Programmeertalen zijn de manieren waarop mensen met computers communiceren. De computer spreekt graag elke taal die niet dubbelzinnig is. De reden dat we over hogere talen beschikken, is omdat mensen niet met machinetaal overweg kunnen. Het doel van programmeertalen is om te voorkomen dat onze arme, kwetsbare menselijke hersenen overweldigd worden door een overvloed aan details.
Architecten weten dat sommige ontwerpproblemen alledaagser zijn dan andere. Een van de duidelijkste en meest abstracte ontwerpproblemen is het ontwerp van bruggen. In dit geval is het uw taak om de vereiste afstand af te leggen met zo min mogelijk materiaal. Aan de andere kant van het spectrum staat het stoelontwerp. Stoelontwerpers zouden eens goed moeten nadenken over het menselijk achterwerk.
Bij softwareontwikkeling is er sprake van een soortgelijk verschil. Het ontwerpen van algoritmen voor het routeren van gegevens door een netwerk is een mooi, abstract probleem, net als het ontwerpen van bruggen. Terwijl het ontwerpen van programmeertalen te vergelijken is met het ontwerpen van stoelen: je moet rekening houden met menselijke zwakheden.
De meesten van ons vinden dit moeilijk te accepteren. Het ontwerpen van elegante wiskundige systemen klinkt voor de meesten van ons veel aantrekkelijker dan inspelen op menselijke zwakheden. De rol van wiskundige elegantie is dat een zekere mate van elegantie ervoor zorgt dat programma's gemakkelijker te begrijpen zijn. Maar elegantie houdt daar niet op.
En als ik zeg dat talen zo ontworpen moeten worden dat ze rekening houden met menselijke zwakheden, dan bedoel ik niet dat talen ontworpen moeten worden voor slechte programmeurs. De realiteit is dat je software moet ontwerpen voor de beste programmeurs, maar zelfs de beste programmeurs hebben hun beperkingen. Ik denk niet dat iemand het leuk zou vinden om te programmeren in een taal waarin alle variabelen worden weergegeven door de letter "x" met gehele getallen als indices.
2. Ontwerp voor jezelf en voor je vrienden
Als je naar de geschiedenis van programmeertalen kijkt, zie je dat de beste talen vooral ontworpen zijn om door hun makers gebruikt te worden, terwijl de slechtste talen vooral voor andere mensen ontworpen zijn.
Wanneer talen voor andere mensen worden ontworpen, gaat het altijd om een specifieke groep mensen: mensen die niet zo slim zijn als de taalontwerpers. Je krijgt dus een taal die neerbuigend tegen je spreekt. Cobol is het bekendste voorbeeld, maar de meeste talen zijn doordrongen van deze geest.
Het heeft niets te maken met het hoge niveau van de taal. C is een vrij eenvoudige taal, maar is door de makers ervan speciaal ontwikkeld om te gebruiken. Daarom zijn hackers er zo dol op.
Het argument voor het ontwerpen van talen voor slechte programmeurs is dat er meer slechte programmeurs zijn dan goede. Misschien is dat wel zo. Maar dit kleine aantal goede programmeurs schrijft onevenredig veel meer software.
Ik ben geïnteresseerd in de vraag: hoe kunnen we een taal creëren waar de beste hackers blij mee zijn? Ik denk dat deze vraag identiek is aan de vraag hoe je een goede programmeertaal creëert. En zelfs als dat niet zo is, is het in ieder geval een interessante vraag.
3. Geef de programmeur zoveel mogelijk controle
Veel talen (vooral talen die voor andere mensen bedoeld zijn) fungeren als babysitters: ze proberen je te waarschuwen voor dingen waarvan ze denken dat ze slecht voor je zijn. Ik ben het juist andersom: geef de programmeur zoveel mogelijk controle.
Toen ik Lisp voor het eerst leerde, vond ik het vooral leuk dat we als gelijken met elkaar spraken. In de andere talen die ik tot dan toe had geleerd, bestond een taal en mijn programma in die taal. Ze bestonden echter geheel los van elkaar. Maar in Lisp waren de functies en macro's die ik schreef dezelfde als die waarin de taal zelf was geschreven. Ik kon de taal zelf herschrijven als ik dat wilde. Het had dezelfde aantrekkingskracht als opensourcesoftware.
4. Beknoptheid is de zuster van humor
Beknoptheid wordt onderschat en zelfs veracht. Maar als je in het hart van hackers kijkt, zie je dat ze dol zijn op beknoptheid. Hoe vaak heb je hackers niet met veel enthousiasme horen vertellen over hoe ze in APL met slechts een paar regels code geweldige dingen kunnen doen? Ik denk dat heel intelligente mensen hier graag aandacht aan besteden.
Ik denk dat bijna alles wat programma's korter maakt, een goed iets is. Er zouden veel bibliotheekfuncties moeten zijn, alles wat impliciet kan zijn, zou dat ook moeten zijn; de syntaxis zou beknopter moeten zijn; Zelfs de namen van entiteiten moeten kort zijn.
En het zijn niet alleen programma's die kort moeten zijn. Handleidingen moeten ook kort zijn. Een groot deel van de handleidingen staat vol met uitleg, voorbehouden, waarschuwingen en speciale gevallen. Als u de handleiding wilt inkorten, kunt u het beste de taal aanpassen die zoveel uitleg vereist.
5. Herken wat hacken is
Veel mensen zouden willen dat hacken wiskunde was, of op zijn minst iets dat op wetenschap lijkt. Ik denk dat hacken meer op architectuur lijkt. Architectuur heeft te maken met natuurkunde, in die zin dat de architect een gebouw moet ontwerpen dat niet instort. Het echte doel van de architect is echter om een geweldig gebouw te creëren, niet om ontdekkingen te doen op het gebied van de statica.
Hackers houden ervan om geweldige programma's te maken. En ik denk dat we, in ieder geval in ons eigen hoofd, moeten onthouden dat het schrijven van geweldige programma's geweldig is, zelfs als dat werk niet zo makkelijk te vertalen is naar de gebruikelijke intellectuele waarde van academische artikelen. Vanuit intellectueel oogpunt is het net zo belangrijk om een taal te ontwerpen waar programmeurs dol op zijn, als om een vreselijke taal te ontwerpen die een idee belichaamt waar je een artikel over kunt publiceren.
Openstaande kwesties
1. Hoe organiseer je grote bibliotheken?
Bibliotheken worden een steeds belangrijker onderdeel van programmeertalen. Ze worden zo groot dat het gevaarlijk kan worden. Als het langer duurt om een functie in een bibliotheek te vinden die doet wat u nodig hebt, dan om die functie zelf te schrijven, dan maakt de code uw handleiding alleen maar dikker. (De Symbolics-handleidingen zijn hiervan een voorbeeld.) We zullen dus het probleem van de bibliotheekorganisatie moeten oplossen. Idealiter zouden ze zo ontworpen moeten zijn dat de programmeur kan raden welke bibliotheekfunctie zal werken.
2. Zijn mensen echt bang voor prefix-syntaxis?
Dit is een open probleem in de zin dat ik er al jaren over nadenk en nog steeds het antwoord niet weet. De syntaxis van het voorvoegsel lijkt mij volkomen natuurlijk, behalve misschien voor het gebruik in de wiskunde. Maar het zou ook kunnen dat een groot deel van de impopulariteit van Lisp simpelweg te wijten is aan de onbekende syntaxis... Of er iets aan gedaan moet worden, als dat waar is, is een andere vraag.
3. Wat heb je nodig voor serversoftware?
Ik denk dat de meeste applicaties die de komende twintig jaar geschreven worden, webapplicaties zullen zijn. Dat wil zeggen dat de programma's op een server staan en via een webbrowser met je communiceren. En om zulke applicaties te schrijven, hebben we nieuwe dingen nodig.
Eén daarvan is ondersteuning voor een nieuwe manier om serverapplicaties uit te brengen. In plaats van één of twee grote releases per jaar, zoals bij desktopsoftware, wordt serversoftware uitgebracht in een reeks kleine wijzigingen. Er kunnen vijf tot tien releases per dag zijn. En iedereen heeft altijd de nieuwste versie.
Weet jij hoe je programma's zo ontwerpt dat ze onderhoudbaar zijn? Serversoftware moet zo ontworpen zijn dat deze aanpasbaar is. Je zou het gemakkelijk moeten kunnen veranderen, of in ieder geval moeten weten wat een kleine verandering betekent en wat belangrijk is.
Nog iets dat handig kan zijn bij serversoftware is de continuïteit van de levering. In een webapplicatie zou je zoiets kunnen gebruiken om het effect van routines in de stateloze wereld van websessies te verkrijgen. Het kan de moeite waard zijn om een continue levering te garanderen, als de optie niet te duur is.
4. Welke nieuwe abstracties moeten nog ontdekt worden?
Ik weet niet zeker hoe redelijk deze hoop is, maar ik zou persoonlijk graag een nieuwe abstractie ontdekken - iets dat net zoveel verschil kan maken als first-class functies of recursie, of op zijn minst standaardparameters. Misschien is dit een onmogelijke droom. Vaak blijven zulke brieven ongeopend. Maar ik verlies de hoop niet.
Weinig bekende geheimen
1. U kunt elke gewenste taal gebruiken.
Vroeger betekende het maken van applicaties het maken van desktopsoftware. En bij desktopsoftware bestaat er een grote voorkeur voor het schrijven van applicaties in dezelfde taal als het besturingssysteem. Tien jaar geleden betekende het schrijven van software over het algemeen het schrijven van software in C. Uiteindelijk evolueerde de traditie: applicaties hoeven niet meer in dure talen geschreven te worden. En deze traditie heeft zich in de loop van de tijd zo ontwikkeld dat ook niet-technische mensen, zoals managers en durfkapitalisten, het hebben overgenomen.
Серверный софт уничтожает эту модель полностью. С серверным софтом вы можете взять любой язык, какой пожелаете. Почти никто ещё этого не понимает (особенно менеджеры и венчурные капиталисты). Но некоторые хакеры понимают это, вот почему мы слышали про такие indy-языки как Perl и Python. Мы не слышим про Perl и Python, потому что люди используют их для написания приложений для Windows.
Voor ons, mensen die geïnteresseerd zijn in het ontwerpen van programmeertalen, betekent dit dat er een potentieel publiek is voor ons werk.
2. Snelheid komt van profilers
Taalontwerpers, of in ieder geval taalimplementatoren, schrijven graag compilers die snelle code genereren. Maar ik denk niet dat dat de reden is dat talen zo snel zijn voor gebruikers. Knuth besefte al lang dat snelheid afhankelijk is van slechts een paar knelpunten. En iedereen die ooit heeft geprobeerd een programma te versnellen, weet dat je niet kunt raden waar de bottleneck zit. Profiler is het antwoord.
De taalontwerpers lossen het verkeerde probleem op. Gebruikers hebben geen benchmarks nodig om snel te kunnen werken. Ze hebben een taal nodig die aangeeft welke delen van hun programma herschreven moeten worden. Op dit punt is snelheid in de praktijk geboden. Het zou dus misschien beter zijn als taalimplementatoren de helft van hun tijd aan compileroptimalisatie zouden besteden aan het schrijven van een goede profiler.
3. Je hebt een app nodig die je taalontwikkeling bevordert
Het is misschien niet het laatste woord, maar het lijkt erop dat de beste talen en de toepassingen die ze gebruikten, samen met elkaar zijn geëvolueerd. C is geschreven door mensen die systeemprogrammering wilden. Lisp is deels ontworpen voor symbolische differentiatie en McCarthy wilde er zo graag mee aan de slag dat hij in 1960, in zijn eerste Lisp-artikel, al differentiatieprogramma's begon te schrijven.
Dit is vooral handig als uw app een nieuw probleem oplost. Hiermee wordt uw taal gestimuleerd om nieuwe functies te bieden die programmeurs willen. Persoonlijk ben ik geïnteresseerd in het schrijven van een taal die geschikt is voor servertoepassingen.
[Tijdens de discussie maakte Guy Steele ook dit punt, en voegde eraan toe dat de toepassing niet zou moeten bestaan uit het schrijven van een compiler voor jouw taal, tenzij jouw taal is ontworpen voor het schrijven van compilers.]
4. De taal moet geschikt zijn voor het schrijven van eenmalige programma's.
U weet wat een eenmalig programma inhoudt: dat is wanneer u snel een beperkte taak moet oplossen. Ik denk dat als je om je heen kijkt, je een hoop serieuze programma's zult vinden die ooit als eenmalige actie zijn begonnen. Het zou mij niet verbazen als de meeste programma's als eenmalige acties zijn begonnen. Als je dus een taal wilt creëren die geschikt is voor het schrijven van software in het algemeen, dan moet deze ook geschikt zijn voor het schrijven van eenmalige programma's. Dat is namelijk de beginfase van veel programma's.
5. Syntaxis is gerelateerd aan semantiek
Traditioneel worden syntaxis en semantiek als twee heel verschillende dingen beschouwd. Dit klinkt misschien schokkend, maar dat is het niet. Ik denk dat wat je met je programma wilt bereiken, afhangt van de manier waarop je dat uitdrukt.
Ik sprak onlangs met Robert Morris en hij merkte op dat operatoroverloading een groot voordeel is voor talen met infix-syntaxis. In talen met prefix-syntaxis is elke functie die u definieert in feite een operator. Als u een nieuw type getal wilt toevoegen, kunt u eenvoudig een nieuwe functie definiëren om het toe te voegen. Als je dit doet in een taal met infix-syntaxis, zul je zien dat er een groot verschil is tussen het gebruiken van een overladen operator en het aanroepen van een functie.
Ideeën die in de loop van de tijd terugkomen
1. Nieuwe programmeertalen
Als we terugkijken naar de jaren zeventig, zagen we dat het in de mode was om nieuwe programmeertalen te ontwikkelen. Dat is nu niet meer het geval. Ik geloof echter dat serversoftware de mode voor het creëren van nieuwe talen weer terug zal brengen. Met serversoftware kun je elke gewenste taal gebruiken. Als iemand een taal creëert die beter lijkt dan de rest, zullen er mensen zijn die besluiten die taal te gebruiken.
2. Tijd delen
Richard Kelsey kwam met dit idee, dat nu weer actueel is en ik steun het volledig. Ik vermoed (en dat geldt ook voor Microsoft) dat een groot deel van de computeractiviteiten van de desktop naar externe servers zal verhuizen. Met andere woorden: timesharing is terug. Ik denk dat dit op taalniveau ondersteund moet worden. Richard en Jonathan Reeves hebben bijvoorbeeld hard gewerkt aan de introductie van procesplanning in Schema 48.
3. Efficiëntie
Tot voor kort leek het alsof computers snel genoeg waren. We horen steeds meer over bytecode, wat voor mij in ieder geval betekent dat we rekenkracht in overvloed hebben. Maar ik denk dat dat met serversoftware niet het geval is. Iemand zal daarvoor moeten betalen. severenHet aantal gebruikers waarop de software draait en het aantal gebruikers dat de server per machine kan ondersteunen, zullen de deler zijn van hun investeringskosten.
Ik denk dat efficiëntie belangrijk is, tenminste bij knelpunten in de berekeningen. Dit is vooral belangrijk voor I/O-bewerkingen, omdat servertoepassingen veel van dit soort bewerkingen uitvoeren.
Uiteindelijk kan het zo zijn dat bytecode niet de oplossing is. Sun en Microsoft lijken momenteel lijnrecht tegenover elkaar te staan op het gebied van bytecode. Maar ze doen dit omdat bytecode een handige plek is om zichzelf in een proces te integreren, niet omdat bytecode zelf een goed idee is. Het kan zijn dat deze hele strijd onopgemerkt blijft. Dat zou grappig zijn.
Valkuilen en valkuilen
1. Klanten
Dit is slechts een gok, maar het punt is dat alleen die applicaties die volledig servergebaseerd zijn, er profijt van zullen hebben. Software ontwerpen die ervan uitgaat dat iedereen klant van je is, is te vergelijken met het ontwerpen van een maatschappij die ervan uitgaat dat iedereen eerlijk is. Het zou zeker handig zijn, maar je moet accepteren dat het nooit zal gebeuren.
Ik verwacht dat het aantal apparaten met internettoegang snel zal toenemen. We kunnen er gerust van uitgaan dat deze basis-html en formulieren zullen ondersteunen. Heb je een browser op je telefoon? Heeft uw PalmPilot een telefoon? Krijgt uw Blackberry een groter scherm? Heb je toegang tot internet via je Game Boy? Van je horloge? Ik weet het niet. En ik hoef het niet uit te zoeken als ik erop wed dat alles op de server staat. Het is gewoon veel betrouwbaarder als alle hersenen op de server zitten. .
2. Objectgeoriënteerd programmeren
Ik besef dat dit een controversiële uitspraak is, maar ik denk niet dat OOP een groot probleem is. Ik denk dat dit een geschikt paradigma is voor specifieke toepassingen die specifieke datastructuren nodig hebben, zoals venstersystemen, simulaties en CAD-systemen. Maar ik zie niet in waarom het voor alle programma's geschikt zou moeten zijn.
Ik denk dat mensen bij grote bedrijven OOP vooral leuk vinden omdat het ervoor zorgt dat veel dingen op werk lijken. Wat normaal gesproken zou worden weergegeven als bijvoorbeeld een lijst met gehele getallen, kan nu worden weergegeven als een klasse met allerlei hulpmiddelen, met veel ruis en gedoe.
Een andere aantrekkelijke eigenschap van OOP is dat methoden u een deel van het effect van eersteklasfuncties bieden. Maar voor Lisp-programmeurs is dit geen nieuws. Wanneer u over echte eersteklasfuncties beschikt, kunt u deze op elke gewenste manier gebruiken die past bij de taak die u uitvoert, in plaats van alles in een sjabloon van klassen en methoden te stoppen.
Ik denk dat dit voor taalontwerp betekent dat je OOP er niet te diep in moet integreren. Misschien is het antwoord om meer algemene, fundamentele zaken aan te bieden en mensen objectsystemen als bibliotheken te laten ontwerpen.
3. Ontwerp door commissie
Als uw taal door een commissie is ontworpen, zit u in de val, en niet alleen om redenen die iedereen kent. Het is bekend dat commissies de neiging hebben om onregelmatige, inconsistente taalontwerpen te produceren. Maar ik denk dat het grote gevaar is dat ze geen risico's nemen. Wanneer één persoon de leiding heeft, neemt hij risico's die de commissie nooit zou willen nemen.
Is het nodig om risico's te nemen om een goede taal te creëren? Veel mensen vermoeden dat je bij taalontwerp redelijk dicht bij de gangbare opvattingen moet blijven. Ik wed dat dat niet waar is. Bij alles wat mensen doen, is de beloning evenredig aan het risico. Waarom zou dat bij taalontwerp anders zijn?
Bron: www.habr.com
