Vejledende filosofi
1. Programmeringssprog for mennesker
Programmeringssprog er, hvordan folk taler til computere. Computeren vil med glæde tale ethvert sprog, der ikke er tvetydigt. Grunden til, at vi har sprog på højt niveau, er fordi folk ikke kan håndtere maskinsprog. Pointen med programmeringssprog er at forhindre vores stakkels, skrøbelige menneskelige hjerner i at blive overvældet af for mange detaljer.
Arkitekter ved, at nogle designproblemer er mere banale end andre. Nogle af de klareste og mest abstrakte designproblemer er design af broer. I dette tilfælde er din opgave at tilbagelægge den nødvendige afstand med så lidt materiale som muligt. I den anden ende af spektret er stoledesign. Stoledesignere bør bruge deres tid på at tænke på folks numse.
Softwareudvikling har en lignende forskel. At designe algoritmer til at dirigere data gennem et netværk er et godt, abstrakt problem, ligesom at designe broer. Mens design af programmeringssprog er som at designe stole: du skal håndtere menneskelige svagheder.
Det er svært for de fleste af os at indse. At designe elegante matematiske systemer lyder meget mere attraktivt for de fleste af os end at lægge mærke til menneskelige svagheder. Rollen af matematisk elegance er, at en vis grad af elegance gør programmer lettere at forstå. Men det handler ikke kun om elegance.
Og når jeg siger, at sprog skal være designet til at imødekomme menneskelige svagheder, mener jeg ikke, at sprog skal være designet til dårlige programmører. I virkeligheden burde du designe software til de bedste programmører, men selv de bedste programmører har deres grænser. Jeg tror ikke, at nogen ville nyde at programmere på et sprog, hvor alle variabler blev angivet med bogstavet "x" med heltalstilslutninger.
2. Design til dig selv og dine venner
Hvis du ser på programmeringssprogs historie, var de fleste af de bedste sprog designet til at blive brugt af deres egne forfattere, og de fleste af de værste var designet til andre mennesker at bruge.
Når sprog er designet til andre mennesker, er det altid en bestemt gruppe mennesker: folk er ikke så smarte som skaberne af sproget. Sådan får du en tunge, der taler ned til dig. Cobol er det mest fremtrædende eksempel, men de fleste sprog er gennemsyret af denne ånd.
Det har intet at gøre med, hvor højt sproget er. C er et ret lavt niveau, men det blev skabt til at blive brugt af dets forfattere, hvorfor hackere elsker det.
Argumentet for at designe sprog til dårlige programmører er, at der er flere dårlige programmører end gode. Måske er det sådan. Men dette lille antal gode programmører skriver uforholdsmæssigt mere software.
Mit spørgsmål er, hvordan skaber man et sprog, der appellerer til de bedste hackere? Det forekommer mig, at dette spørgsmål er identisk med spørgsmålet om, hvordan man laver et godt programmeringssprog?, men selvom det ikke er det, er det i hvert fald et interessant spørgsmål.
3. Giv programmøren så meget kontrol som muligt
Mange sprog (især dem, der er designet til andre mennesker) fungerer som barnepiger: de forsøger at advare dig væk fra ting, de ikke tror vil gavne dig. Jeg har det modsatte synspunkt: giv programmøren så meget kontrol, som du kan.
Da jeg først lærte Lisp, kunne jeg bedst lide, at vi talte som ligeværdige. På de andre sprog, som jeg havde lært på det tidspunkt, var der et sprog, og der var mit program på det sprog, og de eksisterede helt adskilt. Men i Lisp var de funktioner og makroer, jeg skrev, de samme, som selve sproget var skrevet i. Jeg kunne omskrive selve sproget, hvis jeg ville. Det havde samme appel som open source-software.
4. Brevity er talentets søster
Korthed er undervurderet og endda foragtet. Men hvis du ser ind i hackernes hjerter, vil du se, at de virkelig kan lide korthed. Hvor mange gange har du hørt hackere tale kærligt om, hvordan de i f.eks. APL kan gøre fantastiske ting med blot et par linjer kode? Jeg gætter på, at virkelig kloge mennesker faktisk kan lide at være opmærksomme på dette.
Jeg tror, at næsten alt, der gør programmer kortere, er en god ting. Der skal være en masse biblioteksfunktioner, alt hvad der kan være implicit bør være det; syntaks bør være mere kortfattet; selv enhedsnavne 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, ansvarsfraskrivelser, advarsler og særlige tilfælde. Hvis du har brug for at forkorte manualen, er den bedste mulighed at rette det sprog, der kræver så meget forklaring.
5. Erkend, hvad hacking er
Mange mennesker vil gerne have, at hacking er matematik, eller i det mindste noget, der ligner videnskab. Jeg tror, at hacking er mere som arkitektur. Arkitektur handler om fysik, idet en arkitekt skal designe en bygning, der ikke falder, men det egentlige mål for en arkitekt er at skabe en fantastisk bygning, ikke at gøre opdagelser inden for statik.
Hvad hackere elsker, er at skabe fantastiske programmer. Og jeg tror, at vi, i det mindste i vores egne tanker, bør huske, at det er en vidunderlig ting at skrive gode programmer, selv når det arbejde ikke let kan omsættes til den sædvanlige intellektuelle valuta for videnskabelige artikler. Fra et intellektuelt synspunkt er det lige så vigtigt at designe et sprog, som programmører vil elske, som det er at designe et forfærdeligt sprog, der legemliggør en idé, som du kan udgive et papir om.
Åbne numre
1. Hvordan organiserer man store biblioteker?
Biblioteker er ved at blive 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 et bibliotek, der gør det, du har brug for, end at skrive den funktion selv, så gør al koden ikke andet end at gøre din manual tykkere. (Symbolikmanualerne var et eksempel på dette.) Så vi bliver nødt til at løse problemet med bibliotekets organisation. Ideelt set design dem, så programmøren kan gætte, hvilken biblioteksfunktion der er egnet.
2. Er folk virkelig bange for præfikssyntaks?
Dette er et åbent problem i den forstand, at jeg har tænkt over det i flere år og stadig ikke kender svaret. Præfikssyntaks forekommer mig helt naturligt, måske bortset fra dens brug i matematik. Men det kan være, at meget af Lisps upopularitet simpelthen skyldes den ukendte syntaks... Om det er værd at gøre noget ved det, hvis det er sandt, er en anden sag.
3. Hvad skal du bruge 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 programmer vil ligge på en server og kommunikere med dig gennem en webbrowser. Og for at skrive sådanne ansøgninger har vi brug for nye ting.
En af disse ting er understøttelse af en ny måde at frigive serverapplikationer på. I stedet for en eller to store udgivelser om året, som desktop-software, vil serversoftware blive frigivet i en række små ændringer. Du har måske fem eller ti udgivelser om dagen. Og alle vil altid have den nyeste version.
Ved du, hvordan man designer programmer, så de kan vedligeholdes? Serversoftware skal være designet til at kunne ændres. Du skal nemt kunne ændre det, eller i det mindste vide, hvad en mindre æ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 f.eks at få effekten af rutiner i websessionernes statsløse verden. At have kontinuitet i forsyningen kan være det værd, hvis funktionen ikke er for dyr.
4. Hvilke nye abstraktioner mangler at blive opdaget?
Jeg er ikke sikker på, hvor rimeligt det håb er, men personligt ville jeg virkelig gerne opdage en ny abstraktion - noget, der kunne være lige så meningsfuldt som førsteklasses funktioner eller rekursion eller i det mindste standardparametre. Måske er dette en umulig drøm. Sådan noget bliver ofte ikke opdaget. Men jeg mister ikke håbet.
Lidt kendte hemmeligheder
1. Du kan bruge et hvilket som helst sprog, du ønsker
Tidligere betød oprettelsen af applikationer skabelsen af desktop-software. Og i desktop-software er der en stor skævhed mod at skrive applikationer på samme sprog som operativsystemet. Så for ti år siden betød det at skrive software generelt at skrive software i C. Til sidst udviklede traditionen sig: applikationer skulle ikke skrives på usædvanlige sprog. Og denne tradition har udviklet sig så længe, at ikke-tekniske mennesker som ledere og venturekapitalister også har lært det.
Serversoftware ødelægger denne model fuldstændigt. Med serversoftware kan du bruge et hvilket som helst sprog, du ønsker. Næsten ingen forstår dette endnu (især ledere og venturekapitalister). Men nogle hackere forstår dette, og derfor hører vi om indy-sprog som Perl og Python. Vi hører ikke om Perl og Python, fordi folk bruger dem til at skrive Windows-applikationer.
Hvad betyder det for os, folk, der er interesseret i programmeringssprogsdesign, at der er et potentielt publikum til vores arbejde.
2. Hastighed kommer fra profiler
Sprogudviklere, eller i det mindste sprogimplementere, kan godt lide at skrive compilere, der genererer hurtig kode. Men jeg tror ikke, det er det, der gør sprog hurtigt for brugerne. Knuth bemærkede for længe siden, at hastigheden kun afhænger af nogle få flaskehalse. Og enhver, der har forsøgt at fremskynde et program, ved, at man ikke kan gætte, hvor flaskehalsen er. Profiler er svaret.
Sprogudviklere løser det forkerte problem. Brugere behøver ikke benchmarks for at køre hurtigt. De har brug for et sprog, der kan vise, hvilke dele af deres program, der skal omskrives. På dette tidspunkt er der brug for fart i praksis. Så måske ville det være bedre, hvis sprogimplementere brugte halvdelen af den tid, de bruger på at optimere compileren og bruge den på at skrive en god profiler.
3. Du har brug for en app, der får dit sprog til at udvikle sig
Dette er måske ikke den ultimative sandhed, men det ser ud til, at de bedste sprog udviklede sig sammen med de applikationer, de blev brugt i. C blev skrevet af folk, der havde brug for systemprogrammering. Lisp var til dels designet til symbolsk differentiering, og McCarthy var så ivrig efter at komme i gang, at han endda begyndte at skrive differentieringsprogrammer i det første Lisp-blad i 1960.
Dette er især godt, hvis din applikation løser nogle nye problemer. Dette presser dit sprog til at have nye funktioner, som programmører ønsker. Personligt er jeg interesseret i at skrive et sprog, der vil være godt til serverapplikationer.
[Under diskussionen gjorde Guy Steele også dette punkt og tilføjede, at applikationen ikke skulle 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 et one-shot-program betyder: det er, når du hurtigt skal løse et begrænset problem. Jeg tror, at hvis man ser sig omkring, vil man finde mange seriøse programmer, der startede som enkeltstående. Jeg ville ikke blive overrasket, hvis de fleste af programmerne startede som engangsprogrammer. Hvis du vil skabe et sprog, der vil være egnet til at skrive software generelt, så bør det også være velegnet til at skrive enkeltstående programmer, fordi dette er den indledende fase af mange programmer.
5. Syntaks er relateret til semantik
Det er traditionelt antaget, at syntaks og semantik er meget forskellige ting. Det lyder måske chokerende, men det er det ikke. Jeg tror, hvad du vil opnå i dit program, har at gøre med, hvordan du udtrykker det.
Jeg talte for nylig med Robert Morris, og han bemærkede, at operatøroverbelastning er et stort plus for sprogs sejr med infix-syntaks. På sprog med præfikssyntaks er enhver funktion, du definerer, faktisk en operator. Hvis du ønsker at tilføje en ny type tal, som du har lavet, kan du blot definere en ny funktion for at tilføje den. Hvis du gør dette i et sprog med infix-syntaks, vil du se, at der er stor forskel på at bruge en overbelastet operatør og at kalde en funktion.
Idéer, der kommer tilbage over tid
1. Nye programmeringssprog
Når vi ser tilbage til 1970'erne, var det moderne at udvikle nye programmeringssprog. Dette er ikke tilfældet nu. Men jeg tror på, at serversoftware igen vil bringe mode tilbage til at skabe nye sprog. Med serversoftware kan du bruge et hvilket som helst sprog, du vil, så hvis nogen skaber et sprog, der virker bedre end resten, vil der være folk, der vil beslutte at bruge det.
2. Tidsdeling
Richard Kelsey kom op med denne idé, hvis tid er kommet igen, og jeg støtter den fuldt ud. Mit gæt (og også Microsofts) er, at en masse computere vil flytte fra skrivebordet til fjernservere. Tidsdeling er med andre ord 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 så det ud til, at computere allerede var hurtige nok. Vi hører mere og mere om bytecode, hvilket i hvert fald for mig betyder, at vi har noget strøm i reserve. Men jeg tror, at med serversoftware har vi det ikke. Nogen skal betale for de servere, der kører softwaren, og antallet af brugere, serveren kan understøtte pr. maskine, vil være en divisor af deres kapitalomkostninger.
Jeg tror, effektivitet vil betyde noget, i det mindste i computerflaskehalse. Dette vil især være vigtigt for I/O-operationer, fordi serverapplikationer udfører mange af sådanne operationer.
I sidste ende kan det vise sig, at bytecode ikke er svaret. Sun og Microsoft ser ud til at gå hinanden i bytekodefeltet i øjeblikket. Men de gør dette, fordi bytekode er et praktisk sted at integrere sig selv i en proces, ikke fordi bytekode 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.
Snarer og snarer
1. Kunder
Dette er kun et gæt, men det er, at de eneste applikationer, der vil gavne, er dem, der er fuldstændig server-side. At designe software, der opererer ud fra den antagelse, at alle vil have en kunde, er som at designe et samfund baseret på den antagelse, at alle vil være ærlige. Det ville helt sikkert være praktisk, men du må gå ud fra, at det aldrig vil ske.
Jeg tror, der vil ske en hurtig stigning i web-aktiverede enheder, og vi kan antage, at de vil understøtte grundlæggende html og formularer. Har du en browser på din telefon? Vil din PalmPilot have en telefon? Vil din blackberry have en større skærm? Vil du være i stand til at få adgang til internettet fra din gameboy? Fra dit ur? Jeg ved ikke. Og jeg skal ikke finde ud af, om jeg satser på, at alt vil være på serveren. Det er bare meget mere pålideligt at have alle hjernerne på serveren. .
2. Objektorienteret programmering
Jeg er klar over, at dette er en kontroversiel udtalelse, men jeg tror ikke, OOP er så vigtigt. Jeg tror, dette er et passende paradigme for specifikke applikationer, der har brug for specifikke datastrukturer, såsom vinduessystemer, simuleringer, CAD-systemer. Men jeg forstår ikke hvorfor det skulle være egnet til alle programmer.
Jeg tror, at folk i store virksomheder til dels elsker OOP, fordi det får mange ting til at ligne arbejde. Hvad der naturligt kan repræsenteres som f.eks. en liste over heltal, kan nu repræsenteres som et klasseværelse med alskens stilladser, travlhed.
Et andet attraktivt træk ved OOP er, at metoder giver dig noget af effekten af førsteklasses funktioner. Men dette er ikke nyheder for Lisp-programmører. Når du har ægte førsteklasses funktioner, kan du blot bruge dem på enhver måde, der passer til opgaven, i stedet for at skubbe alt ind i en kedelplade af klasser og metoder.
Jeg tror, at det betyder for sprogdesign, at du ikke skal indlejre OOP for dybt i det. Måske er svaret at tilbyde mere generelle, grundlæggende ting og lade folk designe alle objektsystemer som biblioteker.
3. Udformning af udvalg
Hvis dit sprog er designet af et udvalg, så er du fanget, og ikke kun af årsager, som alle kender. Alle ved, at udvalg har en tendens til at skabe klumpede, inkonsekvente sprogdesigns. Men jeg tror, den store fare er, at de ikke tager risici. Når én person er ansvarlig, tager han risici, som udvalget aldrig ville gå med til at påtage sig.
Skal du løbe risici for at skabe et godt sprog? Mange mennesker har måske mistanke om, at sprogdesign er det sted, hvor du skal holde dig temmelig tæt på traditionel visdom. Jeg vil vædde på, at det ikke er tilfældet. I alt andet folk gør, er belønningen proportional med risikoen. Så hvorfor skulle sprogdesign være anderledes?
Kilde: www.habr.com