Fem frågor om design av programmeringsspråk

Ledande filosofi

1. Programmeringsspråk för människor

Programmeringsspråk är sättet som människor pratar med datorer. Datorer är glada över att kommunicera på vilket språk som helst som inte är tvetydigt. Anledningen till att vi har hög-nivåspråk är att människor inte kan hantera maskinspråk. Syftet med programmeringsspråk är att förhindra våra ömtåliga mänskliga hjörnor från att överbelastas med detaljer.

Arkitekter vet att vissa designproblem är mer konkreta än andra. Några av de mest uppenbara och abstrakta designproblemen handlar om att designa broar. I det här fallet är ditt jobb att täcka det nödvändiga avståndet med så lite material som möjligt. I andra änden av spektrumet — att designa stolar. Stoldesigners måste spendera tid på att tänka på mänskliga bakdelar.

Mjukvaruutveckling har en liknande distinktion. Att designa algoritmer för att routa data genom nätverket är ett bra, abstrakt problem, som att designa broar. Medan design av programmeringsspråk liknar designen av stolar: du måste hantera mänskliga svagheter.

För de flesta av oss är det svårt att inse detta. Att designa eleganta matematiska system låter mycket mer tilltalande för de flesta av oss än att ge efter för mänskliga svagheter. Rollen av matematisk elegans är att en viss grad av elegans gör program enklare att förstå. Men elegans är inte allt.

Och när jag säger att språk måste designas med mänskliga svagheter i åtanke, menar jag inte att språk ska designas för dåliga programmerare. Faktiskt bör du designa mjukvara för de bästa programmerarna, men även de bästa programmerarna har sina gränser. Jag tror inte att någon skulle tycka om att programmera i ett språk där alla variabler representerades av bokstaven 'x' med heltalsindex.

2. Designa för dig själv och dina vänner

Om du ser på historien om programmeringsspråk har de flesta av de bästa språken designats för att användas av sina egna skapare, medan de flesta av de sämsta har designats för andra människor.

När språk designas för andra människor så handlar det alltid om en specifik grupp människor: människor är inte lika smarta som skaparna av språket. Så du får ett språk som talar till dig nedlåtande. Cobol är det mest framträdande exemplet, men de flesta språk genomsyras av denna anda.

Det har ingenting att göra med hur hög-nivå ett språk är. C är ganska lågnivå, men det skapades för att användas av dess skapare, vilket förklarar varför hackare älskar det.

Argumentet för att designa språk för dåliga programmerare är att det finns fler dåliga programmerare än bra. Det kanske stämmer. Men en liten mängd bra programmerare skriver oproportionerligt mycket mer mjukvara.

Jag undrar hur man kan skapa ett språk som tilltalar de bästa hackarna? Jag tycker att denna fråga är densamma som frågan om hur man skulle kunna skapa ett bra programmeringsspråk?, men även om det inte är så, så är det åtminstone en intressant fråga.

3. Ge programmeraren så mycket kontroll som möjligt

Många språk (särskilt de som skapats för andra människor) beter sig som barnvakt: de försöker avråda dig från saker som de tycker inte kommer att vara till nytta för dig. Jag har en motsatt åsikt: ge programmeraren så mycket kontroll som möjligt.

När jag först studerade Lisp gillade jag mest att vi kommunicerade på lika villkor. I andra språk som jag hade studerat vid den tidpunkten fanns det ett språk och min programvara på det språket, och de existerade ganska separat. Men i Lisp var funktionerna och makrona som jag skrev desamma som de som språket själv var skrivet i. Jag kunde återskriva själva språket om jag så ville. Det hade samma attraktion som mjukvara med öppen källkod.

4. Korthet är talangens syster

Korthet är undervärderad och till och med föraktad. Men om du tittar in i hackerhjärtan, kommer du att se att de älskar korthet. Hur många gånger har du hört hackare tala med kärlek om hur de i APL kan göra fantastiska saker med bara några rader kod? Jag tror att verkligt kloka människor verkligen uppskattar detta.

Jag anser att nästan allt som gör program kortare är bra. Det bör finnas många bibliotekfunktioner, allt som kan vara implicerat bör vara det; syntaxen bör vara mer kortfattad; till och med namn på entiteter bör vara korta.

Och inte bara program ska vara korta. Manualer ska också vara korta. En stor del av manualerna är fyllda med förklaringar, reservationer, varningar och specialfall. Om du behöver förkorta en manual, är det bästa alternativet att förbättra språket som kräver så många förklaringar.

5. Erkäna vad hacking är

Många människor skulle vilja att hacking var som matematik eller åtminstone något liknande naturvetenskaper. Jag tror att hacking mera liknar arkitektur. Arkitektur är kopplad till fysik, på så sätt att en arkitekt måste designa en byggnad som inte faller, men det verkliga målet för en arkitekt är att skapa en stor byggnad, inte att göra upptäckter inom statik.

Vad hackare älskar är att skapa stora program. Och jag tycker att, åtminstone i våra egna tankar, bör vi komma ihåg att skriva fantastiska program är underbart, även när detta arbete inte lätt översätts till vanlig intellektuell valuta av vetenskapliga publikationer. Ur intellektuell synvinkel är det lika viktigt att utveckla ett språk som programmerare kommer att älska som att skapa något hemskt, som fångar en idé om vilken du kan publicera en artikel.

Öppna problem

1. Hur organiserar man stora bibliotek?

Bibliotek blir en viktig del av programmeringsspråk. De blir så stora att det kan bli farligt. Om det tar längre tid att hitta en funktion i biblioteket som gör det du behöver än att skriva funktionen själv, då gör hela koden inget annat än att tjockna din manual. (Symbolics guider var ett exempel på detta.) Så vi måste lösa problemet med organisationen av bibliotek. Idealiskt skulle vi designa dem så att programmeraren kan gissa vilken bibliotekfunktion som passar.

2. Är folk verkligen skrämda av prefixsyntax?

Det är ett öppet problem i den meningen att jag har tänkt på det i flera år och fortfarande inte vet svaret. Prefixsyntax verkar helt naturligt för mig, kanske förutom dess användning i matematik. Men det kan vara så att den stora delen av den dåliga populariteten för Lisp beror på den ovanliga syntaxen... Är det värt att göra något åt det, om det är sant, är en annan fråga.

3. Vad behöver du för serverprogramvara?

Jag tror att de flesta applikationer som kommer att skrivas under de närmaste tjugo åren kommer att vara webbappar, i den meningen att programmen kommer att ligga på en server och kommunicera med dig via en webbläsare. Och för att skriva sådana applikationer behöver vi nya verktyg.

En av dessa saker är stödet för ett nytt sätt att släppa serverapplikationer. Istället för en eller två stora versioner om året, som skrivbordsmjukvara, kommer servermjukvara att släppas i en serie små förändringar. Du kan ha fem eller tio versioner om dagen. Och alla kommer alltid att ha den senaste versionen.

Vet du hur man designar program så att de är underhållbara? Serverprogramvara måste designas för att vara förändringsbenägen. Du bör kunna ändra den lätt, eller åtminstone veta vad som innebär en liten ändring och vad som är viktigt.

En annan sak som kan vara användbar i serverprogramvara är, plötsligt, kontinuerlig leverans. I en webbapplikation kan du använda något som CPS, för att få effekt av underprogram i en stateless värld av webbsessioner. Det kan vara värt att ha kontinuerlig leverans om denna möjlighet inte blir för kostsam.

4. Vilka nya abstraktioner återstår att upptäcka?

Jag är inte säker på hur rimlig en sådan förhoppning är, men personligen skulle jag verkligen vilja öppna upp för en ny abstraktion — något som skulle kunna ha lika stor betydelse som första klassens funktioner eller rekursion, eller åtminstone standardparametrar. Kanske är det en ouppnåelig dröm. Sådana saker upptäckts sällan. Men jag ger inte upp hoppet.

Lite kända hemligheter

1. Du kan använda vilket språk du vill

Tidigare innebar skapandet av applikationer att man skapade skrivbordsprogram. Och i skrivbordsprogram finns det en stark betoning på att skriva program på samma språk som operativsystemet. För tio år sedan betydde skrivande av program generellt att man skrev program i C. Slutligen har traditionen utvecklats: applikationer behöver inte skrivas på ovanliga språk. Och denna tradition har utvecklats så länge att personer utan teknisk bakgrund, som chefer och riskkapitalister, också har lärt sig detta.

Serverprogramvara krossar helt denna modell. Med serverprogramvara kan du använda vilket språk du vill. Nästan ingen förstår detta ännu (speciellt chefer och riskkapitalister). Men vissa hackare förstår det, därför hör vi om sådana indy-språk som Perl och Python. Vi hör inte om Perl och Python, eftersom folk använder dem för att skriva applikationer för Windows.

Vad detta innebär för oss, människor som är intresserade av att designa programmeringsspråk, är att det finns en potentiell publik för vårt arbete.

2. Hastighet kommer från profilerare

Språkets skapare eller åtminstone dess implementerare älskar att skriva kompilatorer som genererar snabb kod. Men jag tror att det inte är det som gör språk snabba för användare. Knuth påpekade för länge sedan att hastighet beror på endast några få flaskhalsar. Och alla som har försökt att snabba upp ett program vet att man inte kan gissa var flaskhalsen är. Profileraren är svaret.

Språkutvecklarna löser inte rätt problem. Användarna behöver inte att benchmarken ska fungera snabbt. De behöver ett språk som kan visa vilka delar av deras program som behöver skrivas om. I det ögonblicket behövs hastighet i praktiken. Så kanske vore det bättre om språkets implementatörer spenderade hälften av den tid de lägger på att optimera kompilatorn och istället investerade den tiden i att skriva en bra profilerare.

3. Du behöver en applikation som får ditt språk att utvecklas

Kanske är det inte den slutgiltiga sanningen, men det verkar som att de bästa språken har utvecklats tillsammans med de applikationer som använde dem. C skrevs av människor som behövde systemprogrammering. Lisp utvecklades delvis för symbolisk derivering; McCarthy var så ivrig att börja att han började skriva deriveringsprogram redan i det första dokumentet om Lisp 1960.

Detta är särskilt bra om din applikation löser några nya problem. Det pressar ditt språk att ha nya möjligheter som programmerare behöver. Personligen är jag intresserad av att skriva ett språk som skulle vara bra för serverapplikationer.

[Under diskussionen uttryckte Guy Steele också denna tanke och tillade att applikationen inte bör bestå av att skriva en kompilator för ditt språk, såvida inte ditt språk är avsett för att skriva kompilatorer.]

4. Språket bör vara lämpligt för att skriva engångsprogram.

Du vet vad en engångsprogram är: det är när du snabbt behöver lösa ett begränsat problem. Jag antar att om du ser dig omkring så kommer du att upptäcka många seriösa program som började som engångsprogram. Jag skulle inte bli förvånad om de flesta program började som engångsprogram. Så om du vill skapa ett språk som är lämpligt för att skriva mjukvara generellt, bör det också vara lämpligt för att skriva engångsprogram, eftersom det är den inledande fasen för många program.

5. Syntax är kopplad till semantik

Traditionellt anses syntax och semantik vara starkt åtskilda saker. Det kanske låter chockerande, men så är det inte. Jag tror att det du vill få ut av ditt program är kopplat till hur du uttrycker det.

Nyligen pratade jag med Robert Morris, och han påpekade att överbelastning av operatörer är en stor fördel för språk med infixsyntax. I språk med prefixesyntax är varje funktion som du definierar faktiskt en operator. Om du vill lägga till en ny typ av tal som du hittat på, kan du enkelt definiera en ny funktion för att lägga till den. Om du gör det i ett språk med infixsyntax kommer du se att det finns en stor skillnad mellan att använda en överbelastad operator och att anropa en funktion.

Idéer som återkommer med tiden

1. Nya programmeringsspråk

Ser man tillbaka på 1970-talet var det trendigt att utveckla nya programmeringsspråk. Nu är det inte så. Men jag tror att serverprogramvara kommer att återinföra trenden att skapa nya språk. Med serverprogramvara kan du använda vilket språk du vill, och om någon skapar ett språk som verkar bättre än de andra, så kommer det att finnas människor som vågar använda det.

2. Tidsdelning

Richard Kelsey presenterade denna idé, vars tid har kommit igen, och jag stöder den helt. Min gissning (och Microsofts också) är att många beräkningar kommer att flyttas från stationära datorer till avlägsna servrar. Med andra ord har tidsdelningen återvunnit sin plats. Jag tror att det kommer att krävas stöd för detta på språk nivå. Till exempel har Richard och Jonathan Reeve gjort mycket arbete för att införa processplanering i Scheme 48.

3. Effektivitet

Nyligen verkade det som att datorerna redan var tillräckligt snabba. Allt mer hör vi talas om bytekod, vilket åtminstone för mig betyder att vi har kraft i reserv. Men jag tror att med serverprogramvara har vi inte det. Någon måste betala för servrar, som programvaran körs på, och antalet användare som servern kan stödja per maskin kommer att vara en del av deras kapitalutgifter.

Jag tror att effektivitet kommer att spela en roll, åtminstone i beräkningsflaskhalsar. Detta kommer särskilt att vara viktigt för in- och utmatningsoperationer, eftersom serverapplikationer utför många sådana operationer.

I slutändan kan det visa sig att bytekod inte är lösningen. Just nu verkar Sun och Microsoft slåss ansikte mot ansikte på bytekodfältet. Men de gör det för att bytekod är en bekväm plats att integrera sig i processen, inte för att bytekod i sig är en bra idé. Det kan hända att hela denna strid passerar obemärkt. Det skulle vara roligt.

Fällor och hinder

1. Kunder

Detta är bara en hypotetisk idé, men den går ut på att det bara är de applikationer som är helt serverbaserade som kommer att vinna. Att designa mjukvara med antagandet att alla kommer att ha din klient är som att skapa ett samhälle baserat på antagandet att alla kommer att vara ärliga. Det skulle definitivt vara bekvämt, men du måste erkänna att det aldrig kommer att hända.

Jag tror att det kommer att ske en snabb ökning av enheter med webbtillgång, och man kan anta att de kommer att stödja grundläggande HTML och formulär. Har du en webbläsare på din telefon? Kommer din telefon att finnas i din PalmPilot? Kommer din blackberry att ha en större skärm? Kommer du att kunna gå online med din gameboy? Från din klocka? Jag vet inte. Och jag behöver inte få reda på det om jag satsar på att allt kommer att vara på servern. Det är helt enkelt mycket mer pålitligt att ha all intelligens på servern.

2. Objektorienterad programmering

Jag förstår att detta är ett kontroversiellt uttalande, men jag anser inte att OOP är något viktigt. Jag tycker att det är en lämplig paradigm för specifika applikationer som behöver specifika datatyper, som fönstersystem, simuleringar, CAD-system. Men jag förstår inte varför det skulle vara lämpligt för alla program.

Jag tror att människor i stora företag gillar OOP delvis för att det ger mycket av vad som ser ut som arbete. Det som naturligtvis kan representeras som, säg, en lista över heltal, kan nu representeras som en klass med alla möjliga byggnadsställningar, med brus och stress.

En annan lockande aspekt av OOP är att metoder ger dig en slags effekt av förstaklassiga funktioner. Men det är ingen nyhet för programmerare i Lisp. När du har verkliga förstaklassiga funktioner kan du enkelt använda dem på vilket sätt som helst som passar uppgiften istället för att trycka allt in i en mall av klasser och metoder.

Jag tror att detta innebär för språkdesign att man inte ska integrera OOP för djupt. Kanske är svaret att erbjuda mer allmänna, grundläggande saker och låta folk designa vilka objektsystem som helst som bibliotek.

3. Designad av en kommitté

Om ditt språk designas av en kommitté, då är du i en fälla, och inte bara av de skäl som är allmänt kända. Alla vet att kommittéer tenderar att skapa klumpig och inkonsekvent språkdesign. Men jag tror att den största faran är att de inte tar några risker. När en person är ledare, tar de risker som en kommitté aldrig skulle vara överens om att ta.

Måste man ta risker för att skapa ett bra språk? Många människor kanske misstänker att språkdesign är något där man bör hålla sig ganska nära traditionell visdom. Jag vågar påstå att det inte är så. I allt annat människor gör, är belöningen proportionell mot risken. Så varför skulle det vara annorlunda i språkdesign?

Källa: habr.com