Ledende filosofi
1. Programmeringssprog til mennesker
Programmeringssprog er den måde, mennesker taler med computere. Computeren vil gerne kommunikere på ethvert sprog, der ikke er tvetydigt. Årsagen til, at vi har højniveau programmeringssprog, er, at mennesker har svært ved at håndtere maskinsprog. Essensen af programmeringssprog er at forhindre vores skrøbelige menneskelige hjerner i at blive overbelastet af en overflod af detaljer.
Arkitekter ved, at nogle designproblemer er mere jordnære end andre. Nogle af de mest tydelige og abstrakte designproblemer er brodesign. Her er dit mål at spænde over den krævede afstand med så lidt materiale som muligt. I den anden ende af spektret er design af stole. Stoledesignere skal bruge tid på at tænke over menneskelige bagdele.
Softwareudvikling har en lignende forskel. At designe algoritmer til at rute data gennem et netværk er et godt, abstrakt problem, ligesom at designe broer. Mens design af programmeringssprog er som at designe stole: det handler om at håndtere menneskelige svagheder.
For de fleste af os er det svært at erkende. At designe elegante matematiske systemer lyder langt mere tiltalende for de fleste af os end at bøje os for menneskelige svagheder. Den matematiske elegancens rolle er, at en vis grad af elegance gør programmer lettere at forstå. Men elegance er ikke det eneste.
Og når jeg siger, at sprog skal designes med menneskelige svagheder i tankerne, mener jeg ikke, at sprog skal designes til dårlige programmører. Faktisk skal du designe software til de bedste programmører, men selv de bedste programmører har deres grænser. Jeg tror ikke, at nogen ville finde det behageligt at programmere på et sprog, hvor alle variabler blev betegnet med bogstavet «x» med heltalsindekser.
2. Design til dig selv og dine venner
Hvis du ser på historien om programmeringssprog, blev de fleste af de bedste sprog designet til brug af deres egne skabere, mens mange af de dårligste blev designet til andre mennesker.
Når sprog er designet til andre mennesker, er det altid en bestemt gruppe mennesker: folk er ikke så kloge som skaberne af sproget. Så får du et sprog, der taler til dig nedladende. Cobol er det mest markante eksempel, men de fleste sprog er gennemsyret af denne ånd.
Det har intet at gøre med, hvor højniveauet sproget er. C er ret lavniveau, men det blev skabt til brug af dets skabere, og derfor elsker hackere det.
Argumentet for at designe sprog til dårlige programmører er, at der er flere dårlige programmører end gode. Det kan være sandt. Men en lille gruppe dygtige programmører skriver uforholdsmæssigt meget software.
Jeg stiller mig selv spørgsmålet, hvordan man skaber et sprog, der vil appellere til de bedste hackere? Jeg mener, dette spørgsmål er det samme som spørgsmålet, hvordan man skaber et godt programmeringssprog?, men selv hvis det ikke er tilfældet, så er det i det mindste et interessant spørgsmål.
3. Giv programmører så meget kontrol som muligt
Mange sprog (især dem, der er skabt til andre mennesker) opfører sig som barnepiger: de prøver at advare dig om ting, de mener, ikke vil være nyttige for dig. Jeg har den modsatte holdning: giv programmører så meget kontrol som muligt.
Da jeg først studerede Lisp, kunne jeg bedst lide, at vi talte på lige fod. I andre sprog, som jeg på det tidspunkt havde lært, var der et sprog, og så var der mit program i dette sprog, og de eksisterede ret adskilt. Men i Lisp var de funktioner og makroer, jeg skrev, de samme som dem, sproget selv var skrevet med. Jeg kunne genopbygge sproget selv, hvis jeg ønskede det. Det havde samme tiltrækning som open source-software.
4. Kortfattethed er talentets søster
Kortfattethed undervurderes og endda foragtes. Men hvis du kigger ind i hjerterne på hackere, vil du se, at de virkelig elsker kortfattethed. Hvor mange gange har du hørt hackere tale med kærlighed om, hvordan de for eksempel kan gøre fantastiske ting i APL med blot et par linjer kode? Jeg mener, at de virkelig smarte mennesker i virkeligheden elsker at fokusere på dette.
Jeg mener, at næsten alt, der gør programmer kortere, er godt. Der må være mange biblioteksfunktioner, alt der kan være implicit, bør være det; syntaksen skal være mere kortfattet; selv navne på enheder skal være korte.
Og ikke kun programmer skal være korte. Manualer skal også være korte. En god del af manualerne er fyldt med forklaringer, forbehold, advarsler og særlige tilfælde. Hvis du skal forkorte en manual, er den bedste løsning at forbedre sproget, som kræver så mange forklaringer.
5. Accepter hvad hacking er
Mange mennesker ville ønske, at hacking var matematik eller i det mindste noget, der lignede naturvidenskaberne. Jeg mener, hacking ligner mere arkitektur. Arkitektur er relateret til fysik, i den forstand at en arkitekt skal designe en bygning, der ikke falder ned, men den sande mål for en arkitekt er at skabe en stor bygning, ikke at lave opdagelser inden for statik.
Hvad hackere elsker, er at skabe store programmer. Og jeg mener, at vi i det mindste i vores egne tanker skal huske, at det er fantastisk at skrive vidunderlige programmer, selv når dette arbejde er svært at oversætte til almindelig intellektuel valuta for videnskabelige arbejder. Fra et intellektuelt synspunkt er det lige så vigtigt at udvikle et sprog, som programmører vil elske, som det er at skabe noget skrækkeligt, der inkorporerer en idé, hvorom du kan publicere en artikel.
Åbne problemer
1. Hvordan organiserer man store biblioteker?
Biblioteker bliver en vigtig del af programmeringssprog. De bliver så store, at det kan være farligt. Hvis det tager længere tid at finde en funktion i biblioteket, der gør det, du har brug for, end at skrive denne funktion selv, så bidrager koden kun til at gøre din manual tykkere. (Symbolics-manualerne var et eksempel på dette.) Så vi bliver nødt til at løse problemet med organiseringen af biblioteker. Ideelt set bør de designes, så programmøren kan gætte, hvilken funktion i biblioteket der vil passe.
2. Er folk virkelig skræmte af præfikssyntaks?
Det er et åbent spørgsmål, i den forstand at jeg har tænkt over det i flere år og stadig ikke kender svaret. Præfikssyntaks virker helt naturligt for mig, muligvis undtagen i matematik. Men det kan være, at en stor del af Lisp'ernes upopularitet bare skyldes den ukendte syntaks... Er det værd at gøre noget ved, hvis det er sandt, er et andet spørgsmål.
3. Hvad har du brug for til serversoftware?
Jeg tror, at de fleste applikationer, der vil blive skrevet i de næste tyve år, vil være webapplikationer, i den forstand at programmerne vil være placeret på serveren og kommunikere med dig gennem en webbrowser. Og for at skrive sådanne applikationer har vi brug for nye ting.
En af disse ting er støtte til en ny måde at udgive serverapplikationer på. I stedet for én eller to store udgivelser om året, som med desktopsoftware, vil serversoftware blive udgivet i en serie af små ændringer. Du kan have fem eller ti udgivelser om dagen. Og alle vil altid have den nyeste version.
Ved du, hvordan man designer programmer, så de er vedligeholdelige? Serversoftware skal designes til at være foranderligt. Du skal have mulighed for nemt at ændre det, eller i det mindste vide, hvad en lille ændring betyder, og hvad der er vigtigt.
En anden ting, der kan være nyttig i serversoftware, er pludselig kontinuitet i leveringen. I en webapplikation kan du bruge noget som , for at opnå effekt fra underprogrammer i et stateless websessionsmiljø. Kontinuitet i leveringen kan være værd at have, hvis denne mulighed ikke er for dyr.
4. Hvilke nye abstraktioner er der tilbage at opdage?
Jeg er ikke sikker på, hvor rimelig et håb det er, men personligt ville jeg meget gerne åbne for en ny abstraktion - noget, der kunne have lige så stor betydning som førsteklasses funktioner eller rekursion eller i det mindste standardparametre. Måske er det en uopnåelig drøm. Sådanne ting bliver ofte ikke opdaget. Men jeg mister ikke håbet.
Lille kendte hemmeligheder
1. Du kan bruge hvilket som helst sprog, du ønsker
Tidligere betød oprettelse af applikationer at lave desktop-software. Og i desktop-software er der en stor tendens til at skrive applikationer på samme sprog som operativsystemet. For ti år siden betød softwareudvikling i det hele taget at skrive software i C. Til sidst har traditionen udviklet sig: applikationer behøver ikke at være skrevet i usædvanlige sprog. Og denne tradition har udviklet sig så længe, at ikke-tekniske mennesker, som ledere og venturekapitalister, også har lært dette.
Serversoftware nedlægger denne model helt. Med serversoftware kan du tage hvilket som helst sprog, du ønsker. Næsten ingen forstår det endnu (især ledere og venturekapitalister). Men nogle hackere forstår det, hvilket er grunden til, at vi har hørt om sådanne indie-sprog som Perl og Python. Vi hører ikke om Perl og Python, fordi folk bruger dem til at skrive applikationer til Windows.
Hvad betyder det for os, der er interesserede i at designe programmeringssprog, at der er et potentielt publikum for vores arbejde.
2. Hastighed kommer fra profileringsværktøjer
Sprogudviklere eller i det mindste dem, der implementerer det, kan godt lide at skrive kompilerere, der genererer hurtig kode. Men jeg tror ikke, at det er det, der gør sprog hurtige for brugerne. Knuth bemærkede længe før, at hastighed kun afhænger af et par flaskehalse. Og enhver, der har prøvet at optimere et program, ved, at du ikke er i stand til at gætte, hvor flaskehalsen er. Profilering er svaret.
Sproget udviklere adresserer ikke det rigtige problem. Brugerne behøver ikke, at benchmarks kører hurtigt. De har brug for et sprog, der kan vise, hvilke dele af deres program der skal skrives om. I det øjeblik er hastighed vigtig i praksis. Så måske ville det være bedre, hvis sprogets implementatorer brugte halvdelen af den tid, de bruger på at optimere compileren, på at skrive en god profiler.
3. Du har brug for en applikation, der får dit sprog til at udvikle sig.
Det er måske ikke den ultimative sandhed, men det ser ud til, at de bedste sprog har udviklet sig sammen med de applikationer, hvori de blev brugt. C blev skrevet af folk, der havde brug for systemprogrammering. Lisp blev delvist udviklet til symbolsk differentiering; McCarthy kunne ikke vente med at komme i gang, så han begyndte at skrive differentieringsprogrammer selv i det første dokument om Lisp i 1960.
Dette er særligt godt, hvis din applikation løser nogle nye problemer. Det presser dit sprog til at have nye muligheder, som programmørerne har brug for. Personligt er jeg interesseret i at skrive et sprog, der er godt til serverapplikationer.
[Under diskussionen nævnte Guy Steele også denne tanke og tilføjede, at applikationen ikke bør bestå i at skrive en compiler til dit sprog, medmindre dit sprog er designet til at skrive compilere.]
4. Sproget skal være egnet til at skrive engangsprogrammer.
Du ved, hvad en engangsprogram er: det er når du hurtigt skal løse en begrænset opgave. Jeg formoder, at hvis du ser dig omkring, vil du opdage mange seriøse programmer, der startede som engangsprogrammer. Jeg ville ikke blive overrasket, hvis de fleste programmer startede som engangsprogrammer. Så hvis du vil skabe et sprog, der er egnet til at skrive software generelt, skal det også være egnet til at skrive engangsprogrammer, fordi det er startfasen for mange programmer.
5. Syntax er relateret til semantik.
Det betragtes traditionelt, at syntax og semantik er vidt forskellige ting. Det kan lyde chokerende, men det er ikke tilfældet. Jeg mener, at det, du ønsker at opnå i dit program, er relateret til, hvordan du udtrykker det.
For nylig talte jeg med Robert Morris, og han nævnte, at operatoroverbelastning er en stor fordel ved at vinde over sprog med infiks syntaks. I sprog med præfiks syntaks er enhver funktion, du definerer, faktisk en operator. Hvis du ønsker at tilføje en ny type tal, som du har opfundet, kan du blot definere en ny funktion til at tilføje det. Hvis du gør det i et sprog med infiks syntaks, vil du se, at der er en stor forskel mellem at bruge en overbelastet operator og at kalde en funktion.
Ideer, der vender tilbage over tid
1. Nye programmeringssprog
Når man ser tilbage på 1970'erne, var det populært at udvikle nye programmeringssprog. Det er ikke længere tilfældet. Men jeg tror, at serversoftware igen vil bringe trenden med skabelse af nye sprog tilbage. Med serversoftware kan du bruge hvilket som helst sprog du ønsker, så hvis nogen skaber et sprog, der virker bedre end de andre, vil der være folk, der tør bruge det.
2. Tidsdeling
Richard Kelsey fremlagde denne idé, hvis tid er kommet tilbage, og jeg støtter den fuldt ud. Mit gæt (og Microsofts også) er, at mange beregninger vil flytte fra desktop til remote servere. Med andre ord, tidsdeling er tilbage. Jeg tror, det vil kræve støtte på sprogniveau. For eksempel har Richard og Jonathan Reeves gjort meget arbejde for at implementere procesplanlægning i Scheme 48.
3. Effektivitet
For nylig syntes det, at computere allerede er hurtige nok. Mere og mere hører vi om bytekode, hvilket for mig betyder, at vi har overskud af kapacitet. Men jeg tror, at med serversoftware har vi ikke det. Nogen skal betale for servere, som softwaren kører på, og antallet af brugere, som serveren kan håndtere pr. maskine, vil være en divisor af deres kapitalomkostninger.
Jeg mener, at effektivitet vil være vigtig, især i flaskehalse i beregninger. Dette vil være særligt vigtigt for input-output operationer, fordi serverapplikationer genererer mange af sådanne operationer.
I sidste ende kan det vise sig, at bytecode ikke er løsningen. Sun og Microsoft ser i øjeblikket ud til at kæmpe ansigt til ansigt på bytecode-området. Men de gør det, fordi bytecode er et praktisk sted at integrere sig i processen, ikke fordi bytecode i sig selv er en god idé. Det kan vise sig, at hele denne kamp vil gå ubemærket hen. Det ville være sjovt.
Fælder og faldgruber
1. Kunder
Det er kun en formodning, men den går på, at kun de applikationer, der er helt serverbaserede, vil vinde. At designe software, der fungerer under forudsætningen af, at alle vil have din klient, ligner at skabe et samfund baseret på den antagelse, at alle vil være ærlige. Det ville bestemt være bekvemt, men du må acceptere, at det aldrig vil ske.
Jeg tror, der vil være en hurtig stigning i enheder med webadgang, og det kan antages, at de vil støtte grundlæggende html og former. Har du en browser på din telefon? Vil din telefon være i din PalmPilot? Vil din Blackberry have en større skærm? Får du mulighed for at gå online fra din Game Boy? Fra dit ur? Jeg ved det ikke. Og jeg behøver ikke at finde det ud, hvis jeg satser på, at alt er på serveren. Det er bare meget mere pålideligt at have al intelligens på serveren.
2. Objektorienteret programmering
Jeg forstår, at det er en kontroversiel udtalelse, men jeg anser ikke OOP for at være noget vigtigt. Jeg mener, det er en passende paradigme for specifikke applikationer, der kræver specifikke datastrukturer, som f.eks. vinduessystemer, simulationer, CAD-systemer. Men jeg forstår ikke, hvorfor det skulle være passende for alle programmer.
Jeg tror, at folk i store virksomheder elsker OOP, delvis fordi det giver meget af det, der ligner arbejde. Det, der naturligt kan præsenteres som f.eks. en liste af heltal, kan nu præsenteres som en klasse med alle mulige byggeri, med støj og travlhed.
En anden tiltalende egenskab ved OOP er, at metoder giver dig en slags effekt af førsteklasses funktioner. Men det er ikke noget nyt for programmører i Lisp. Når du har rigtige førsteklasses funktioner, kan du bare bruge dem på enhver måde, der passer til opgaven, i stedet for at presse alt ind i en skabelon af klasser og metoder.
Jeg tror, det betyder for sprogdesign, at man ikke bør indlejre OOP for dybt i det. Måske er svaret at tilbyde mere generelle, grundlæggende koncepter og lade folk designe enhver objektsystem som biblioteker.
3. Designet af et udvalg
Hvis dit sprog er designet af et udvalg, så er du fanget, og ikke kun af de grunde, som alle kender. Alle ved, at udvalg har en tendens til at skabe klodset, inkonsekvent sprogdesign. Men jeg tror, at den største fare er, at de ikke påtager sig risici. Når én person står i spidsen, påtager de sig de risici, som et udvalg aldrig vil være enige om.
Skal man tage risici for at skabe et godt sprog? Mange mennesker vil muligvis mistænke, at sprogdesign er et område, hvor man skal holde sig tæt på den traditionelle visdom. Jeg vil argumentere for, at det ikke er tilfældet. I alt andet, hvad folk gør, er belønningen proportional med risikoen. Så hvorfor skulle det være anderledes i sprogdesign?
Kilde: habr.com
