Leidende filosofie
1. Programmeertalen voor mensen
Programmeertalen zijn hoe mensen met computers communiceren. De computer is blij met elk tal dat ondubbelzinnig is. De reden dat we high-level talen hebben, is omdat mensen niet kunnen omgaan met machinecode. Het doel van programmeertalen is om onze kwetsbare menselijke hersenen te beschermen tegen een overdaad aan details.
Architecten begrijpen dat sommige ontwerpproblemen minder abstract zijn dan andere. Een van de duidelijkste en meest abstracte ontwerpproblemen is het ontwerpen van bruggen. In dit geval is je taak om de vereiste afstand met zo min mogelijk materiaal te overbruggen. Aan de andere kant van het spectrum ligt het ontwerpen van stoelen. Stoelenontwerpers moeten hun tijd besteden aan overpeinzen over menselijke achterwerken.
Softwareontwikkeling kent een vergelijkbaar onderscheid. Het ontwerpen van algoritmen voor het routeren van gegevens door een netwerk is een goed abstract probleem, zoals het ontwerpen van bruggen. Terwijl het ontwerpen van programmeertalen meer lijkt op het ontwerpen van stoelen: je moet rekening houden met menselijke tekortkomingen.
Voor de meesten van ons is het moeilijk om dit te accepteren. Het ontwerpen van elegante wiskundige systemen lijkt voor velen aantrekkelijker dan het tegemoetkomen aan menselijke tekortkomingen. De rol van wiskundige elegantie is dat een bepaalde mate van elegantie programma's gemakkelijker te begrijpen maakt. Maar elegantie is niet alles.
En als ik zeg dat talen moeten worden ontworpen met het oog op menselijke tekortkomingen, bedoel ik niet dat talen moeten worden ontworpen voor slechte programmeurs. In feite moet je software ontwerpen voor de beste programmeurs, maar zelfs de beste programmeurs hebben hun grenzen. Ik denk niet dat iemand het leuk zou vinden om in een taal te programmeren waarin alle variabelen met de letter 'x' zijn aangeduid met gehele indexen.
2. Ontwerp voor jezelf en je vrienden
Als je naar de geschiedenis van programmeertalen kijkt, zijn de meeste van de beste talen ontworpen voor gebruik door hun eigen makers, terwijl de meeste van de slechtste zijn ontworpen voor andere mensen.
Wanneer talen worden ontworpen voor andere mensen, is het altijd voor een specifieke groep: mensen zijn niet zo slim als de makers van de taal. Zo krijgt u een taal die neerbuigend tegen u spreekt. Cobol is het meest treffende voorbeeld, maar de meeste talen zijn doordrenkt van deze geest.
Dit heeft niets te maken met hoe hoog niveau de taal is. C is vrij laag niveau, maar het is gemaakt voor gebruik door de makers, daarom houden hackers ervan.
Het argument voor het ontwerpen van talen voor slechte programmeurs is dat er meer slechte programmeurs zijn dan goede. Dat mag waar zijn. Maar een klein aantal goede programmeurs schrijft onevenredig veel meer software.
Ik ben benieuwd hoe je een taal maakt die de beste hackers aanspreekt? Ik denk dat deze vraag gelijk is aan de vraag hoe je een goede programmeertaal maakt?, maar zelfs als dit niet zo is, is het in ieder geval een interessante vraag.
3. Geef de programmeur zoveel mogelijk controle
Veel talen (vooral die voor andere mensen zijn gemaakt) gedragen zich als oppassers: ze proberen je te waarschuwen voor dingen waarvan ze denken dat ze niet nuttig voor je zijn. Ik houd van het tegenovergestelde: geef de programmeur zoveel controle als je kunt.
Toen ik voor het eerst Lisp leerde, hield ik het meest van het feit dat we op gelijke voet spraken. In andere talen die ik tot dat moment had geleerd, was er de taal, en mijn programma in die taal, en ze bestonden behoorlijk apart. Maar in Lisp waren de functies en macro's die ik schreef dezelfde als die waarop de taal zelf was geschreven. Ik kon de taal zelf herschrijven als ik dat wilde. Het had dezelfde aantrekkingskracht als open source software.
4. Beknoptheid is de zus van talent
Korteheid wordt vaak onderschat en zelfs veracht. Maar als je in de harten van hackers kijkt, zie je dat ze dol zijn op kortheid. Hoe vaak heb je gehoord dat hackers met liefde zeggen dat ze in APL verbazingwekkende dingen kunnen doen met slechts een paar regels code? Ik denk dat echt slimme mensen dat eigenlijk altijd opmerken.
Ik geloof dat bijna alles wat programma's korter maakt, goed is. Er zouden talloze bibliotheekfuncties moeten zijn, alles wat impliciet kan zijn, moet dat zijn; de syntaxis moet overwegend beknopt zijn; zelfs de namen van entiteiten moeten kort zijn.
En niet alleen programma's moeten kort zijn. Handleidingen moeten ook kort zijn. Een groot deel van handleidingen is gevuld met verduidelijkingen, voorbehouden, waarschuwingen en speciale gevallen. Als je een handleiding moet inkorten, is de beste optie de taal aan te passen die zoveel uitleg vereist.
5. Erken wat hacken is
Veel mensen zouden willen dat hacken wiskunde was of op zijn minst iets dat lijkt op de natuurwetenschappen. Ik denk dat hacken meer lijkt op architectuur. Architectuur is gerelateerd aan fysica, in die zin dat een architect een gebouw moet ontwerpen dat niet instort, maar het echte doel van de architect is om een geweldig gebouw te creƫren, niet om ontdekkingen te doen op het gebied van statica.
Wat hackers leuk vinden, is het creƫren van geweldige programma's. En ik denk dat we, althans in onze eigen gedachten, moeten onthouden dat het schrijven van prachtige programma's geweldig is, zelfs als dat werk zich moeilijk vertaalt in de gebruikelijke intellectuele valuta van wetenschappelijke artikelen. Vanuit intellectueel perspectief is het net zo belangrijk om een taal te ontwikkelen die programmeurs zullen waarderen, alswel om een afschuwelijke, maar conceptueel relevante creatie te maken waarvan je een artikel kunt publiceren.
Openstaande problemen
1. Hoe organiseer je grote bibliotheken?
Bibliotheken worden een belangrijk onderdeel van programmeertalen. Ze worden zo omvangrijk dat dit gevaarlijk kan zijn. Als het meer tijd kost om een functie in een bibliotheek te vinden die doet wat je nodig hebt dan het zelf schrijven van die functie, dan voegt de gehele code niets toe behalve dat het je handleiding dikker maakt. (De handleidingen van Symbolics zijn daar een voorbeeld van.) We moeten dus het probleem van bibliotheekorganisatie aanpakken. Idealiter zouden ze zo ontworpen moeten worden dat een programmeur kan raden welke functie van de bibliotheek geschikt is.
2. Zijn mensen echt bang voor prefix-syntaxis?
Dit is een open probleem in die zin dat ik er al een paar jaar over nadenk en nog steeds het antwoord niet weet. Prefix-syntaxis lijkt me absoluut natuurlijk, mogelijk met uitzondering van het gebruik ervan in de wiskunde. Maar het is mogelijk dat het grootste deel van de onpopulariteit van Lisp gewoon te danken is aan de onbekende syntaxisā¦ Is het de moeite waard om hier iets mee te doen, als dat waar is, is een andere vraag.
3. Wat heb je nodig voor server-software?
Ik denk dat de meeste applicaties die in de komende twintig jaar worden geschreven webapplicaties zullen zijn, in die zin dat programma's zich op een server bevinden en met jou communiceren via een webbrowser. En om zulke applicaties te schrijven, hebben we nieuwe dingen nodig.
Een van die dingen is ondersteuning voor een nieuwe manier om serverapplicaties vrij te geven. In plaats van Ć©Ć©n of twee grote releases per jaar, zoals desktopsoftware, zal serversoftware worden vrijgegeven in een reeks kleine wijzigingen. Je kunt vijf of tien releases per dag hebben. En iedereen heeft altijd de laatste versie.
Weet je hoe je programma's moet ontwerpen zodat ze onderhoudbaar zijn? Server-software moet zo worden ontworpen dat deze wijzigbaar is. Je moet de mogelijkheid hebben om deze gemakkelijk te wijzigen, of in ieder geval te begrijpen wat een kleine wijziging betekent en wat belangrijk is.
Een andere nuttige functie voor serversoftware kan plotseling zijn, continue levering. In een webapplicatie kun je iets gebruiken zoals , om het effect van subroutines in de stateless wereld van websessies te krijgen. Continue levering kan de moeite waard zijn als deze mogelijkheid niet te duur is.
4. Welke nieuwe abstracties moeten nog ontdekt worden?
Ik weet niet hoe redelijk die hoop is, maar persoonlijk zou ik erg graag een nieuwe abstractie willen openen ā iets dat net zo'n grote betekenis zou kunnen hebben als first-class functies of recursie, of op zijn minst standaardparameters. Misschien is dit een onhaalbare droom. Dergelijke dingen worden vaak niet ontdekt. Maar ik geef de hoop niet op.
Weinig bekende geheimen
1. Je kunt elke taal gebruiken die je wilt
Vroeger betekende het creƫren van applicaties het maken van desktopsoftware. En in desktopsoftware ligt een grote nadruk op het schrijven van applicaties in dezelfde taal als het besturingssysteem. Tien jaar geleden betekende software schrijven in het algemeen dat je software in C schreef. Uiteindelijk is de traditie geƫvolueerd: applicaties hoeven niet in ongebruikelijke talen geschreven te zijn. En deze traditie is zo lang doorontwikkeld dat niet-technische mensen, zoals managers en durfkapitalisten, het ook hebben geleerd.
Serversoftware vernietigt dit model volledig. Met serversoftware kun je elke taal gebruiken die je wilt. Bijna niemand begrijpt dit nog (vooral managers en durfkapitalisten). Maar sommige hackers begrijpen dit, daarom hebben we gehoord van dergelijke indie-talen als Perl en Python. We horen niet over Perl en Python omdat mensen ze gebruiken om applicaties voor Windows te schrijven.
Wat betekent dit voor ons, mensen die geĆÆnteresseerd zijn in het ontwerpen van programmeertalen, dat er een potentieel publiek voor ons werk is.
2. Snelheid komt van profilers
Taalontwikkelaars of tenminste de implementatoren houden ervan om compilers te schrijven die snelle code genereren. Maar ik denk niet dat dat is wat talen snel maakt voor gebruikers. Knuth merkte al lang geleden op dat snelheid slechts van enkele knelpunten afhangt. En iedereen die heeft geprobeerd een programma te versnellen, weet dat je niet kunt raden waar het knelpunt zit. Profiler is het antwoord.
De ontwikkelaars van de taal pakken het probleem niet aan. Gebruikers hebben niet nodig dat benchmarks snel werken. Ze hebben een taal nodig die kan laten zien welke delen van hun programma herschreven moeten worden. Op dat moment is snelheid in de praktijk nodig. Misschien is het beter als de implementators van de taal de helft van hun tijd die ze besteden aan het optimaliseren van de compiler, gebruiken om een goede profiler te schrijven.
3. U heeft een applicatie nodig die uw taal laat evolueren.
Misschien is dit niet de ultieme waarheid, maar het lijkt erop dat de beste talen zich hebben ontwikkeld samen met de applicaties waarin ze werden gebruikt. C werd geschreven door mensen die systeemprogrammering nodig hadden. Lisp werd gedeeltelijk ontwikkeld voor symbolische differentiatie; McCarthy kon niet wachten om te beginnen, dus hij begon zelfs in het eerste document over Lisp in 1960 met het schrijven van differentiatieprogramma's.
Dit is vooral goed als uw applicatie enkele nieuwe problemen oplost. Dit duwt uw taal om nieuwe mogelijkheden te hebben die programmeurs nodig hebben. Persoonlijk ben ik geĆÆnteresseerd in het schrijven van een taal die goed is voor serverapplicaties.
[Tijdens de discussie bracht Guy Steele ook deze gedachte naar voren, toevoegend dat een applicatie niet mag bestaan uit het schrijven van een compiler voor uw taal, tenzij uw taal bedoeld is voor het schrijven van compilers.]
4. De taal moet geschikt zijn voor het schrijven van eenmalige programma's.
U weet wat een eenmalig programma betekent: het is wanneer u snel een beperkte taak moet oplossen. Ik geloof dat als u om u heen kijkt, u veel serieuze programma's zult ontdekken die als eenmalige programma's zijn begonnen. Het zou me niet verbazen als de meeste programma's als eenmalige programma's zijn begonnen. Dus als u een taal wilt creƫren die geschikt is voor het schrijven van software in het algemeen, moet deze ook geschikt zijn voor het schrijven van eenmalige programma's, omdat dit de initiƫle fase van veel programma's is.
5. De syntaxis is verbonden met de semantiek.
Traditioneel wordt aangenomen dat syntaxis en semantiek sterk verschillende zaken zijn. Dit klinkt misschien schokkend, maar dat is niet het geval. Ik denk dat wat u in uw programma wilt krijgen, verband houdt met hoe u het uitdrukt.
Onlangs sprak ik met Robert Morris, en hij merkte op dat operatoroverbelasting een groot voordeel is bij het winnen van talen met infix-syntaxis. In talen met prefix-syntaxis is elke functie die je definieert in feite een operator. Als je een nieuw type getal wilt optellen dat je hebt bedacht, kun je eenvoudig een nieuwe functie definiƫren om het toe te voegen. Als je dit doet in een taal met infix-syntaxis, zul je merken dat er een groot verschil is tussen het gebruiken van de overbelaste operator en het aanroepen van de functie.
Ideeƫn die in de loop van de tijd terugkeren
1. Nieuwe programmeertalen
Terugkijkend naar de jaren '70 was het een trend om nieuwe programmeertalen te ontwikkelen. Dat is nu niet meer het geval. Maar ik denk dat serversoftware de trend voor het maken van nieuwe talen weer terugbrengt. Met serversoftware kun je elke taal gebruiken die je wilt, dus als iemand een taal creƫert die beter lijkt dan de anderen, zullen er mensen zijn die bereid zijn deze te gebruiken.
2. Tijddeling
Richard Kelsey heeft dit idee naar voren gebracht, en ik steun het volledig. Mijn vermoeden (en dat van Microsoft ook) is dat veel berekeningen van desktop- naar remote servers zullen verschuiven. Met andere woorden, tijddeling is terug. Ik denk dat er ondersteuning voor nodig zal zijn op taalniveau. Bijvoorbeeld, Richard en Jonathan Rees hebben veel werk verzet om procesplanning in Scheme 48 te implementeren.
3. Efficiƫntie
Het leek onlangs dat computers al snel genoeg zijn. Steeds vaker horen we over bytecode, wat voor mij betekent dat we rekenkracht over hebben. Maar ik denk dat we die niet hebben met serversoftware. Iemand zal moeten betalen voor servers, waarop de software draait, en het aantal gebruikers dat de server kan ondersteunen per machine zal het deel van hun kapitaalkosten zijn.
Ik denk dat efficiƫntie belangrijk zal zijn, vooral in knelpunten van berekeningen. Dit zal vooral belangrijk zijn voor invoer- en uitvoeroperaties, omdat serverapplicaties veel van dergelijke operaties genereren.
Uiteindelijk kan het blijken dat bytecode geen oplossing biedt. Sun en Microsoft lijken momenteel letterlijk strijd te leveren op het gebied van bytecode. Maar ze doen dit omdat bytecode een handige plaats is om zichzelf in het proces in te bedden, en niet omdat bytecode op zichzelf een goed idee is. Het kan zijn dat deze strijd geheel onopgemerkt voorbij gaat. Het zou grappig zijn.
Valstrikken en hindernissen
1. Klanten
Het is slechts een veronderstelling, maar ik denk dat alleen die applicaties zullen winnen die volledig server-gebaseerd zijn. Het ontwerpen van software die ervan uitgaat dat iedereen jouw client heeft, lijkt op het creƫren van een samenleving die uitgaat van de veronderstelling dat iedereen eerlijk is. Dat zou zeker handig zijn, maar je zult moeten accepteren dat dit nooit het geval zal zijn.
Ik denk dat er een snelle toename zal zijn van apparaten met webtoegang, en we kunnen veronderstellen dat ze basis-html en formulieren zullen ondersteunen. Heb je een browser op je telefoon? Zal je telefoon in je PalmPilot zitten? Heeft je Blackberry een groter scherm? Kun je internetten vanaf je Gameboy? Van je horloge? Ik weet het niet. En ik hoef het niet te weten, als ik er op wed dat alles op de server zal draaien. Het is gewoon veel betrouwbaarder om alle intelligentie op de server te hebben.
2. Objectgeoriƫnteerd programmeren
Ik begrijp dat dit een controversiƫle uitspraak is, maar ik geloof niet dat OOP iets belangrijks is. Ik denk dat het een geschikte paradigma is voor specifieke toepassingen die specifieke datastructuren nodig hebben, zoals venstersystemen, simulaties en CAD-systemen. Maar ik begrijp niet waarom het geschikt zou moeten zijn voor alle programma's.
Ik denk dat mensen in grote bedrijven een voorkeur hebben voor OOP, deels omdat het veel biedt dat eruitziet als werk. Wat natuurlijk kan worden gepresenteerd als, laten we zeggen, een lijst van gehele getallen, kan nu worden gepresenteerd als een klasse met allerlei soorten steigers, met lawaai en drukte.
Een andere aantrekkelijke eigenschap van OOP is dat methoden je een soort effect van first-class functies geven. Maar dat is geen nieuws voor programmeurs in Lisp. Wanneer je echte first-class functies hebt, kun je ze gewoon gebruiken op elke manier die past bij de taak, in plaats van alles in een sjabloon van klassen en methoden te duwen.
Ik denk dat dit voor taaldesign betekent dat je objectgeoriƫnteerd programmeren niet te diep erin moet verweven. Misschien ligt het antwoord in het aanbieden van algemenere, fundamentele elementen en het toestaan voor mensen om objectsystemen te ontwerpen in de vorm van bibliotheken.
3. Ontwerp door een comitƩ
Als je taal door een comitƩ wordt ontworpen, dan zit je gevangen, en niet alleen om de redenen die algemeen bekend zijn. Het is algemeen bekend dat commissies de neiging hebben om een krom, inconsistent taaldesign te creƫren. Maar ik denk dat een groter gevaar is dat ze geen risico's nemen. Wanneer er ƩƩn persoon aan het roer staat, neemt die risico's die een comitƩ nooit zou durven nemen.
Moet je risico's nemen om een goede taal te creƫren? Veel mensen vermoeden misschien dat het ontwerpen van een taal iets is waar je je redelijk dicht bij de traditionele wijsheid moet houden. Ik durf te wedden dat dit niet zo is. In alles wat mensen doen, is de beloning evenredig aan het risico. Waarom zou dat in het ontwerpen van talen anders moeten zijn?
Bron: habr.com
