Begeleidende filosofie
1. Programmeertalen voor mensen
Programmeertalen zijn de manier waarop mensen met computers praten. De computer spreekt graag elke taal die niet dubbelzinnig is. De reden dat we talen op hoog niveau hebben, is omdat mensen niet overweg kunnen met machinetaal. Het doel van programmeertalen is om te voorkomen dat onze arme, kwetsbare menselijke hersenen overweldigd raken door te veel details.
Architecten weten dat sommige ontwerpproblemen alledaagser zijn dan andere. Enkele van de duidelijkste en meest abstracte ontwerpproblemen zijn het ontwerp van bruggen. In dit geval is het jouw taak om de vereiste afstand met zo min mogelijk materiaal af te leggen. Aan de andere kant van het spectrum staat het stoelontwerp. Stoelontwerpers moeten hun tijd besteden aan het nadenken over de konten van mensen.
Softwareontwikkeling heeft een soortgelijk verschil. Het ontwerpen van algoritmen om gegevens door een netwerk te routeren is een mooi, abstract probleem, net als het ontwerpen van bruggen. Terwijl het ontwerpen van programmeertalen hetzelfde is als het ontwerpen van stoelen: je hebt te maken met menselijke zwakheden.
Dit is voor de meesten van ons moeilijk te beseffen. Het ontwerpen van elegante wiskundige systemen klinkt voor de meesten van ons veel aantrekkelijker dan toegeven aan menselijke zwakheden. De rol van wiskundige elegantie is dat een zekere mate van elegantie programma's gemakkelijker te begrijpen maakt. Maar het gaat niet alleen om elegantie.
En als ik zeg dat talen moeten worden ontworpen om tegemoet te komen aan menselijke zwakheden, bedoel ik niet dat talen moeten worden ontworpen voor slechte programmeurs. In werkelijkheid zou je software moeten ontwerpen voor de beste programmeurs, maar zelfs de beste programmeurs hebben hun grenzen. Ik denk niet dat iemand het leuk zou vinden om te programmeren in een taal waarin alle variabelen worden aangegeven met de letter "x" met gehele subscripts.
2. Ontwerp voor jezelf en je vrienden
Als je naar de geschiedenis van programmeertalen kijkt, zijn de meeste van de beste talen ontworpen om door hun eigen auteurs te worden gebruikt, en de meeste van de slechtste talen zijn ontworpen om door andere mensen te worden gebruikt.
Als talen voor andere mensen worden ontworpen, gaat het altijd om een specifieke groep mensen: mensen zijn niet zo slim als de makers van de taal. Zo krijg je een tong die tegen je praat. Cobol is het meest prominente voorbeeld, maar de meeste talen zijn doordrenkt van deze geest.
Het heeft niets te maken met het niveau van de taal. C is van een vrij laag niveau, maar is gemaakt om door de auteurs ervan te worden gebruikt, en daarom zijn hackers er dol op.
Het argument voor het ontwerpen van talen voor slechte programmeurs is dat er meer slechte programmeurs zijn dan goede. Misschien is dit zo. Maar dit kleine aantal goede programmeurs schrijft onevenredig veel meer software.
Mijn vraag is: hoe creëer je een taal die de beste hackers aanspreekt? Het lijkt mij dat deze vraag identiek is aan de vraag hoe je een goede programmeertaal maakt?, maar zelfs als dat niet zo is, is het op zijn minst een interessante vraag.
3. Geef de programmeur zoveel mogelijk controle
Veel talen (vooral talen die voor andere mensen zijn ontworpen) gedragen zich als kindermeisjes: ze proberen je te waarschuwen voor dingen waarvan ze denken dat ze niet nuttig voor je zullen zijn. Ik ben het tegenovergestelde standpunt ingenomen: geef de programmeur zoveel mogelijk controle.
Toen ik Lisp voor het eerst leerde, vond ik het leukste dat we als gelijken praatten. In de andere talen die ik op dat moment had geleerd, was er een taal, en er was mijn programma in die taal, en ze bestonden heel afzonderlijk. Maar in Lisp waren de functies en macro's die ik schreef dezelfde als waarin de taal zelf was geschreven. Ik zou de taal zelf kunnen herschrijven als ik dat wilde. Het had dezelfde aantrekkingskracht als open source-software.
4. Beknoptheid is de zus van talent
Beknoptheid wordt onderschat en zelfs veracht. Maar als je in de harten van hackers kijkt, zul je zien dat ze erg van beknoptheid houden. Hoe vaak heb je hackers niet liefdevol horen praten over hoe ze, bijvoorbeeld in APL, verbazingwekkende dingen kunnen doen met slechts een paar regels code? Ik denk dat heel slimme mensen hier graag aandacht aan besteden.
Ik geloof dat bijna alles dat programma's korter maakt, een goede zaak is. Er zouden veel bibliotheekfuncties moeten zijn, alles wat impliciet kan zijn, zou dat ook moeten zijn; de syntaxis zou beknopter moeten zijn; zelfs namen van entiteiten moeten kort zijn.
En niet alleen programma's moeten kort zijn. Handleidingen moeten ook kort zijn. Een groot deel van de handleidingen is gevuld met uitleg, disclaimers, waarschuwingen en speciale gevallen. Als u de handleiding moet inkorten, kunt u het beste de taal corrigeren die zoveel uitleg vereist.
5. Herken wat hacken is
Veel mensen willen dat hacken wiskunde is, of op zijn minst iets dat lijkt op wetenschap. Ik denk dat hacken meer op architectuur lijkt. Architectuur gaat over natuurkunde in die zin dat een architect een gebouw moet ontwerpen dat niet zal vallen, maar het echte doel van een architect is om een geweldig gebouw te creëren, niet om ontdekkingen te doen op het gebied van de statica.
Waar hackers van houden, is het maken van geweldige programma's. En ik denk dat we, tenminste in onze eigen gedachten, moeten onthouden dat het schrijven van geweldige programma's iets geweldigs is, zelfs als dat werk zich niet gemakkelijk laat vertalen in de gebruikelijke intellectuele valuta van wetenschappelijke artikelen. Vanuit intellectueel oogpunt is het net zo belangrijk om een taal te ontwerpen waar programmeurs dol op zullen zijn, als om een vreselijke taal te ontwerpen die een idee belichaamt waarover je een artikel kunt publiceren.
Openstaande problemen
1. Hoe grote bibliotheken organiseren?
Bibliotheken worden een belangrijk onderdeel van programmeertalen. Ze worden zo groot dat het gevaarlijk kan zijn. Als het langer duurt om een functie in een bibliotheek te vinden die doet wat je nodig hebt dan om die functie zelf te schrijven, dan doet alle code niets anders dan je handleiding dikker maken. (De Symboliek-handleidingen waren hier een voorbeeld van.) We zullen dus het probleem van de bibliotheekorganisatie moeten oplossen. Ontwerp ze idealiter zo dat de programmeur kan raden welke bibliotheekfunctie geschikt is.
2. Zijn mensen echt bang voor de syntaxis van voorvoegsels?
Dit is een open probleem in de zin dat ik er al enkele jaren over nadenk en nog steeds het antwoord niet weet. De syntaxis van voorvoegsels lijkt mij volkomen natuurlijk, behalve misschien vanwege het gebruik ervan in de wiskunde. Maar het kan zijn dat een groot deel van Lisp's impopulariteit eenvoudigweg te wijten is aan de onbekende syntaxis... Of we er iets aan moeten doen, als dat waar is, is een andere zaak.
3. Wat heb je nodig voor serversoftware?
Ik denk dat de meeste applicaties die de komende twintig jaar zullen worden geschreven webapplicaties zullen zijn, in de zin dat programma's op een server zullen staan en met je zullen communiceren via een webbrowser. En om zulke applicaties te schrijven hebben we nieuwe dingen nodig.
Eén van die dingen is ondersteuning voor een nieuwe manier om serverapplicaties uit te brengen. In plaats van één of twee grote releases per jaar, zoals desktopsoftware, zal serversoftware met een reeks kleine wijzigingen worden uitgebracht. Je hebt misschien vijf of tien releases per dag. En iedereen beschikt altijd over de nieuwste versie.
Weet jij hoe je programma's zo ontwerpt dat ze onderhoudbaar zijn? Serversoftware moet zo zijn ontworpen dat deze veranderlijk is. Je zou het gemakkelijk moeten kunnen veranderen, of in ieder geval weten wat een kleine verandering betekent en wat belangrijk is.
Iets anders dat nuttig kan zijn bij serversoftware is plotseling de continuïteit van de levering. In een webapplicatie kun je zoiets gebruiken als om het effect van routines in de staatloze wereld van websessies te krijgen. Het hebben van continuïteit van het aanbod kan de moeite waard zijn als de functie niet te duur is.
4. Welke nieuwe abstracties moeten nog ontdekt worden?
Ik weet niet zeker hoe redelijk die hoop is, maar persoonlijk zou ik heel graag een nieuwe abstractie willen ontdekken - iets dat net zo betekenisvol zou kunnen zijn als eersteklas functies of recursie of op zijn minst standaardparameters. Misschien is dit een onmogelijke droom. Zulke dingen worden vaak niet ontdekt. 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. Dus tien jaar geleden betekende het schrijven van software in het algemeen het schrijven van software in C. Uiteindelijk evolueerde de traditie: applicaties mogen niet in ongebruikelijke talen worden geschreven. En deze traditie is al zo lang geëvolueerd dat niet-technische mensen zoals managers en durfkapitalisten deze ook hebben geleerd.
Serversoftware vernietigt dit model volledig. Met serversoftware kunt u elke gewenste taal gebruiken. Bijna niemand begrijpt dit nog (vooral managers en durfkapitalisten). Maar sommige hackers begrijpen dit, daarom horen we over indy-talen als Perl en Python. We horen niets over Perl en Python omdat mensen ze gebruiken om Windows-applicaties te schrijven.
Wat betekent dit voor ons, mensen die geïnteresseerd zijn in het ontwerpen van programmeertalen, dat er een potentieel publiek is voor ons werk.
2. Snelheid komt van profilers
Taalontwikkelaars, of in ieder geval taalimplementeerders, schrijven graag compilers die snelle code genereren. Maar ik denk dat dat niet is wat talen snel maakt voor gebruikers. Knuth merkte lang geleden op dat snelheid afhankelijk is van slechts een paar knelpunten. En iedereen die wel eens heeft geprobeerd een programma te versnellen, weet dat je niet kunt raden waar het knelpunt zit. Profiler is het antwoord.
Taalontwikkelaars lossen het verkeerde probleem op. Gebruikers hebben geen benchmarks nodig om snel te kunnen werken. Ze hebben een taal nodig die kan laten zien welke delen van hun programma herschreven moeten worden. Op dit punt is in de praktijk snelheid nodig. Dus misschien zou het beter zijn als taalimplementeerders de helft van de tijd die ze besteden aan het optimaliseren van de compiler besteden aan het schrijven van een goede profiler.
3. Je hebt een app nodig die je taal laat evolueren
Dit is misschien niet de ultieme waarheid, maar het lijkt erop dat de beste talen evolueerden samen met de toepassingen waarin ze werden gebruikt. C is geschreven door mensen die systeemprogrammering nodig hadden. Lisp was gedeeltelijk ontworpen voor symbolische differentiatie, en McCarthy wilde zo graag aan de slag dat hij in 1960 zelfs begon met het schrijven van differentiatieprogramma's in het eerste Lisp-artikel.
Dit is vooral goed als uw toepassing enkele nieuwe problemen oplost. Dit zorgt ervoor dat uw taal nieuwe functies krijgt die programmeurs willen. Persoonlijk ben ik geïnteresseerd in het schrijven van een taal die goed is voor servertoepassingen.
[Tijdens de discussie maakte Guy Steele dit punt ook naar voren, eraan toevoegend dat de applicatie niet mag bestaan uit het schrijven van een compiler voor jouw taal, tenzij je taal ontworpen is om compilers te schrijven.]4. De taal moet geschikt zijn voor het schrijven van eenmalige programma's.
Je weet wat een one-shot-programma betekent: het is wanneer je snel een beperkt probleem moet oplossen. Ik geloof dat als je rondkijkt, je veel serieuze programma's zult vinden die als eenmalige programma's zijn begonnen. Het zou mij niet verbazen als de meeste programma's als eenmalige programma's 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, omdat dit de beginfase is van veel programma's.
5. Syntaxis houdt verband met semantiek
Traditioneel wordt aangenomen dat syntaxis en semantiek heel verschillende dingen zijn. Dit klinkt misschien schokkend, maar dat is het niet. Ik denk dat wat je met je programma wilt bereiken, te maken heeft met de manier waarop je het uitdrukt.
Ik sprak onlangs met Robert Morris en hij merkte op dat overbelasting door operators een groot pluspunt is voor de overwinning van talen met infix-syntaxis. In talen met een prefixsyntaxis is elke functie die u definieert feitelijk een operator. Als u een nieuw type nummer wilt toevoegen dat u zelf heeft bedacht, 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 gebruik van een overbelaste operator en het aanroepen van een functie.
Ideeën die in de loop van de tijd terugkomen
1. Nieuwe programmeertalen
Terugkijkend op de jaren zeventig was het in de mode om nieuwe programmeertalen te ontwikkelen. Dit is nu niet het geval. Maar ik geloof dat serversoftware opnieuw de mode voor het creëren van nieuwe talen zal terugbrengen. Met serversoftware kun je elke gewenste taal gebruiken, dus als iemand een taal maakt die beter lijkt dan de rest, zullen er mensen zijn die besluiten deze te gebruiken.
2. Tijd delen
Richard Kelsey kwam met dit idee, waarvoor de tijd weer is aangebroken en ik sta er volledig achter. Mijn inschatting (en die van Microsoft) is dat veel computergebruik van de desktop naar externe servers zal verhuizen. Met andere woorden, time-sharing is terug. Ik denk dat dit ondersteuning op taalniveau nodig heeft. Richard en Jonathan Reeves hebben bijvoorbeeld veel werk verzet om procesplanning in Schema 48 te implementeren.
3. Efficiëntie
Onlangs leek het erop dat computers al snel genoeg waren. We horen steeds meer over bytecode, wat voor mij in ieder geval betekent dat we wat reservevermogen hebben. Maar ik denk dat we het met serversoftware niet hebben. Iemand zal moeten betalen voor de servers waarop de software draait, en het aantal gebruikers dat de server per machine kan ondersteunen zal een deler zijn van hun kapitaalkosten.
Ik denk dat efficiëntie er toe zal doen, tenminste als het gaat om computerknelpunten. Dit zal vooral belangrijk zijn voor I/O-bewerkingen, omdat serverapplicaties veel van dergelijke bewerkingen uitvoeren.
Uiteindelijk kan blijken dat bytecode niet het antwoord is. Het lijkt erop dat Sun en Microsoft het momenteel tegen elkaar opnemen op het gebied van bytecodes. Maar ze doen dit omdat bytecode een handige plek is om zichzelf in een proces in te bedden, niet omdat bytecode zelf een goed idee is. Het kan blijken dat deze hele strijd onopgemerkt zal blijven. Het zou grappig zijn.
Snaren en strikken
1. Klanten
Dit is slechts een gok, maar de enige applicaties die hiervan zullen profiteren zijn applicaties die volledig server-side zijn. Het ontwerpen van software die ervan uitgaat dat iedereen een klant zal hebben, is hetzelfde als het ontwerpen van een samenleving die gebaseerd is op de veronderstelling dat iedereen eerlijk zal zijn. Het zou zeker handig zijn, maar je moet ervan uitgaan dat het nooit zal gebeuren.
Ik denk dat er een snelle toename zal zijn van apparaten met internettoegang, en we kunnen ervan uitgaan dat ze eenvoudige html en formulieren zullen ondersteunen. Heb je een browser op je telefoon? Heeft uw PalmPilot een telefoon? Heeft jouw BlackBerry een groter scherm? Kun je vanaf je Gameboy toegang krijgen tot internet? Van je horloge? Ik weet het niet. En ik hoef er niet achter te komen of ik wed dat alles op de server staat. Het is gewoon veel betrouwbaarder om alle hersenen op de server te hebben. .
2. Objectgeoriënteerd programmeren
Ik realiseer me dat dit een controversiële verklaring is, maar ik denk niet dat OOP zo belangrijk 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 begrijp niet waarom het voor alle programma's geschikt zou moeten zijn.
Ik denk dat mensen in grote bedrijven deels van OOP houden, omdat het veel dingen maakt die op werk lijken. Wat natuurlijk zou kunnen worden weergegeven als bijvoorbeeld een lijst met gehele getallen, kan nu worden weergegeven als een klaslokaal met allerlei steigers, drukte en drukte.
Een ander aantrekkelijk kenmerk van OOP is dat methoden je een deel van het effect van eersteklas functies geven. Maar dit is geen nieuws voor Lisp-programmeurs. Als je over echte eersteklas functies beschikt, kun je ze eenvoudigweg op elke manier gebruiken die bij de taak past, in plaats van alles in een standaardpakket van klassen en methoden te stoppen.
Ik denk dat dit voor taalontwerp betekent dat je OOP er niet te diep in moet inbedden. Misschien is het antwoord om algemenere, fundamentelere zaken aan te bieden, en mensen alle objectsystemen als bibliotheken te laten ontwerpen.
3. Ontwerp door commissie
Als je taalgebruik door een commissie is ontworpen, zit je in de val, en niet alleen om redenen die iedereen kent. Iedereen weet dat commissies de neiging hebben om klonterige, inconsistente taalontwerpen te creëren. 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.
Moet je risico's nemen om een goede taal te creëren? Veel mensen vermoeden misschien dat je bij taalontwerp redelijk dicht bij de traditionele wijsheid moet blijven. Ik wed dat dat niet het geval is. Bij al het andere dat mensen doen, is de beloning evenredig aan het risico. Dus waarom zou taalontwerp anders zijn?
Bron: www.habr.com