Vägledande filosofi
1. Programmeringsspråk för människor
Programmeringsspråk är hur människor pratar med datorer. Datorn talar gärna alla språk som inte är tvetydiga. Anledningen till att vi har högnivåspråk är för att människor inte kan hantera maskinspråk. Poängen med programmeringsspråk är att förhindra att våra stackars, ömtåliga mänskliga hjärnor blir överväldigade av för många detaljer.
Arkitekter vet att vissa designproblem är mer vardagliga än andra. Några av de tydligaste och mest abstrakta designproblemen är designen av broar. I det här fallet är ditt jobb att täcka det avstånd som krävs med så lite material som möjligt. I andra änden av spektrumet finns stoldesign. Stolsdesigners bör ägna sin tid åt att tänka på folks rumpor.
Mjukvaruutveckling har en liknande skillnad. Att designa algoritmer för att dirigera data genom ett nätverk är ett trevligt, abstrakt problem, som att designa broar. Medan att designa programmeringsspråk är som att designa stolar: du måste hantera mänskliga svagheter.
Detta är svårt för de flesta av oss att inse. Att designa eleganta matematiska system låter mycket mer attraktivt för de flesta av oss än att ta hand om mänskliga svagheter. Rollen för matematisk elegans är att en viss grad av elegans gör program lättare att förstå. Men allt handlar inte om elegans.
Och när jag säger att språk ska utformas för att tillgodose mänskliga svagheter, menar jag inte att språk ska vara designade för dåliga programmerare. I verkligheten borde 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 på ett språk där alla variabler betecknades med bokstaven "x" med heltalsuppteckningar.
2. Designa för dig själv och dina vänner
Om du tittar på programmeringsspråkens historia, var de flesta av de bästa språken designade för att användas av deras egna författare, och de flesta av de värsta var designade för andra människor att använda.
När språk är designade för andra människor är det alltid en specifik grupp människor: människor är inte lika smarta som skaparna av språket. Det är så du får en tunga som talar ner till dig. Cobol är det mest framträdande exemplet, men de flesta språk är genomsyrade av denna anda.
Det har ingenting att göra med hur hög nivå språket är. C är ganska låg nivå, men det skapades för att användas av dess författare, vilket är anledningen till att 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. Kanske är det så. Men det här lilla antalet bra programmerare skriver oproportionerligt mycket mer mjukvara.
Min fråga är, hur skapar man ett språk som tilltalar de bästa hackarna? Det verkar för mig att denna fråga är identisk med frågan om hur man skapar ett bra programmeringsspråk?, men även om det inte är det, 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 är utformade för andra) fungerar som barnskötare: de försöker varna dig från saker som de tror inte kommer att vara användbara för dig. Jag har den motsatta uppfattningen: ge programmeraren så mycket kontroll du kan.
När jag först lärde mig Lisp var det jag gillade mest att vi pratade som jämlikar. På de andra språken som jag hade lärt mig vid den tidpunkten fanns det ett språk, och det fanns mitt program på det språket, och de fanns helt separat. Men i Lisp var funktionerna och makron som jag skrev samma som själva språket skrevs på. Jag kunde skriva om själva språket om jag ville. Den hade samma överklagande som programvara med öppen källkod.
4. Brevity är talangens syster
Korthet är underskattat och till och med föraktat. Men om du tittar in i hackares hjärtan kommer du att se att de verkligen gillar korthet. Hur många gånger har du hört hackare prata med glädje om hur, säg, APL, de kan göra fantastiska saker med bara ett par rader kod? Jag antar att riktigt smarta människor faktiskt gillar att uppmärksamma detta.
Jag tror att nästan allt som gör programmen kortare är bra. Det ska finnas många biblioteksfunktioner, allt som kan vara implicit ska vara så; syntax bör vara mer koncis; även entitetsnamn ska vara korta.
Och inte bara program ska vara korta. Manualer bör också vara korta. En stor del av manualerna är fyllda med förklaringar, ansvarsfriskrivningar, varningar och specialfall. Om du behöver förkorta manualen är det bästa alternativet att korrigera språket som kräver så mycket förklaring.
5. Inse vad hacking är
Många människor vill att hacking ska vara matematik, eller åtminstone något som liknar naturvetenskap. Jag tror att hacking är mer som arkitektur. Arkitektur handlar om fysik genom att en arkitekt behöver designa en byggnad som inte faller, men det verkliga målet för en arkitekt är att skapa en fantastisk byggnad, inte att göra upptäckter inom området statik.
Vad hackare älskar är att skapa bra program. Och jag tror att vi åtminstone i våra egna tankar bör komma ihåg att det är en underbar sak att skriva fantastiska program, även när det arbetet inte lätt översätts till den vanliga intellektuella valutan för vetenskapliga artiklar. Ur en intellektuell synvinkel är det lika viktigt att designa ett språk som programmerare kommer att älska som det är att designa ett hemskt språk som förkroppsligar en idé som du kan publicera en tidning om.
Öppna frågor
1. Hur organiserar man stora bibliotek?
Bibliotek blir en viktig del av programmeringsspråk. De blir så stora att det kan vara farligt. Om det tar längre tid att hitta en funktion i ett bibliotek som gör det du behöver än att skriva den funktionen själv, så gör all kod inget annat än att göra din manual tjockare. (Symbolikmanualerna var ett exempel på detta.) Så vi måste lösa problemet med biblioteksorganisationen. Designa dem helst så att programmeraren kan gissa vilken biblioteksfunktion som är lämplig.
2. Är folk verkligen rädda för prefixsyntax?
Detta är ett öppet problem i den meningen att jag har funderat på det i flera år och fortfarande inte vet svaret. Prefixsyntax verkar helt naturligt för mig, förutom kanske för dess användning i matematik. Men det kan vara så att mycket av Lisps impopularitet helt enkelt beror på den okända syntaxen... Om vi ska göra något åt det, om det stämmer, är en annan sak.
3. Vad behöver du för serverprogramvara?
Jag tror att de flesta applikationer som kommer att skrivas under de kommande tjugo åren kommer att vara webbapplikationer, i den meningen att program kommer att ligga på en server och kommunicera med dig via en webbläsare. Och för att skriva sådana ansökningar behöver vi nya saker.
En av dessa saker är stöd för ett nytt sätt att släppa serverapplikationer. Istället för en eller två stora utgåvor per år, som skrivbordsmjukvara, kommer serverprogramvara att släppas i en serie små förändringar. Du kanske har fem eller tio släpp om dagen. Och alla kommer alltid att ha den senaste versionen.
Vet du hur man designar program för att vara underhållbara? Serverprogramvara måste vara designad för att kunna ändras. Du bör lätt kunna ändra det, eller åtminstone veta vad en mindre förändring innebär och vad som är viktigt.
En annan sak som kan vara användbar i serverprogramvara är plötsligt kontinuitet i leveransen. I en webbapplikation kan du använda något liknande för att få effekten av rutiner i webbsessionernas statslösa värld. Att ha kontinuitet i utbudet kan vara värt det om funktionen inte är för dyr.
4. Vilka nya abstraktioner återstår att upptäcka?
Jag är inte säker på hur rimligt det hoppet är, men personligen skulle jag verkligen vilja upptäcka en ny abstraktion - något som kan vara lika meningsfullt som förstklassiga funktioner eller rekursion eller åtminstone standardparametrar. Kanske är detta en omöjlig dröm. Sådana saker upptäcks ofta inte. Men jag tappar inte hoppet.
Lite kända hemligheter
1. Du kan använda vilket språk du vill
Tidigare innebar skapandet av applikationer skapandet av skrivbordsprogramvara. Och i stationär programvara finns det en stor fördom mot att skriva applikationer på samma språk som operativsystemet. Så för tio år sedan innebar att skriva programvara i allmänhet att skriva programvara i C. Så småningom utvecklades traditionen: applikationer ska inte skrivas på ovanliga språk. Och denna tradition har utvecklats så länge att icke-tekniska människor som chefer och riskkapitalister också har lärt sig den.
Serverprogramvara förstör denna modell fullständigt. Med serverprogramvara kan du använda vilket språk du vill. Nästan ingen förstår detta ännu (särskilt chefer och riskkapitalister). Men vissa hackare förstår detta, och det är därför vi hör om indyspråk som Perl och Python. Vi hör inte talas om Perl och Python eftersom folk använder dem för att skriva Windows-program.
Vad betyder detta för oss, människor som är intresserade av programmeringsspråksdesign, att det finns en potentiell publik för vårt arbete.
2. Hastigheten kommer från profilerare
Språkutvecklare, eller åtminstone språkimplementerare, gillar att skriva kompilatorer som genererar snabb kod. Men jag tror inte att det är det som gör språken snabba för användarna. Knuth noterade för länge sedan att hastigheten bara beror på några få flaskhalsar. Och alla som har försökt få fart på ett program vet att man inte kan gissa var flaskhalsen är. Profiler är svaret.
Språkutvecklare löser fel problem. Användare behöver inte riktmärken för att köra snabbt. De behöver ett språk som kan visa vilka delar av deras program som behöver skrivas om. Vid det här laget behövs snabbhet i praktiken. Så det kanske vore bättre om språkimplementerare ägnade hälften av den tid de lägger ner på att optimera kompilatorn och spendera den på att skriva en bra profilerare.
3. Du behöver en app som får ditt språk att utvecklas
Detta kanske inte är den ultimata sanningen, men det verkar som att de bästa språken utvecklades tillsammans med applikationerna där de användes. C skrevs av människor som behövde systemprogrammering. Lisp designades delvis för symbolisk differentiering, och McCarthy var så ivrig att komma igång att han till och med började skriva differentieringsprogram i den första Lisp-tidningen 1960.
Detta är särskilt bra om din applikation löser några nya problem. Detta driver ditt språk att ha nya funktioner som programmerare vill ha. Själv är jag intresserad av att skriva ett språk som är bra för serverapplikationer.
[Under diskussionen påpekade Guy Steele också detta och tillade att applikationen inte bör bestå av att skriva en kompilator för ditt språk, om inte ditt språk är utformat för att skriva kompilatorer.]4. Språket ska vara lämpligt för att skriva engångsprogram.
Du vet vad ett engångsprogram betyder: det är när du snabbt behöver lösa ett begränsat problem. Jag tror att om du tittar dig omkring kommer du att hitta många seriösa program som började som engångsföreteelser. Jag skulle inte bli förvånad om de flesta program började som engångsföreteelser. Således, om du vill skapa ett språk som är lämpligt för att skriva mjukvara i allmänhet, bör det också vara lämpligt för att skriva enstaka program, eftersom detta är inledningsskedet av många program.
5. Syntax är relaterad till semantik
Man tror traditionellt att syntax och semantik är väldigt olika saker. Detta kan låta chockerande, men det är det inte. Jag tror att det du vill uppnå i ditt program har att göra med hur du uttrycker det.
Jag pratade nyligen med Robert Morris, och han noterade att operatörsöverbelastning är ett stort plus för segern för språk med infixsyntax. På språk med prefixsyntax är alla funktioner du definierar faktiskt en operator. Om du vill lägga till en ny typ av nummer som du skapat kan du helt enkelt definiera en ny funktion för att lägga till den. Om du gör detta på ett språk med infix-syntax ser du att det är stor skillnad mellan att använda en överbelastad operatör och att anropa en funktion.
Idéer som kommer tillbaka med tiden
1. Nya programmeringsspråk
När man ser tillbaka på 1970-talet var det på modet att utveckla nya programmeringsspråk. Så är inte fallet nu. Men jag tror att servermjukvaran återigen kommer att ta tillbaka modet för att skapa nya språk. Med serverprogramvara kan du använda vilket språk du vill, så om någon skapar ett språk som verkar bättre än resten, kommer det att finnas folk som kommer att bestämma sig för att använda det.
2. Tidsdelning
Richard Kelsey kom på denna idé vars tid har kommit igen och jag stöder den fullt ut. Min gissning (och även Microsofts) är att mycket datoranvändning kommer att flyttas från skrivbordet till fjärrservrar. Tidsdelning är med andra ord tillbaka. Jag tror att detta kommer att behöva stöd på språknivå. Till exempel har Richard och Jonathan Reeves gjort mycket arbete för att implementera processschemaläggning i Schema 48.
3. Effektivitet
Nyligen verkade det som att datorer redan var tillräckligt snabba. Vi hör mer och mer om bytecode, vilket åtminstone för mig betyder att vi har lite kraft i reserv. Men jag tror att vi inte har det med servermjukvara. Någon kommer att behöva betala för servrarna som kör programvaran, och antalet användare servern kan stödja per maskin kommer att vara en divisor för deras kapitalkostnader.
Jag tror att effektivitet kommer att ha betydelse, åtminstone när det gäller datorflaskhalsar. Detta kommer att vara särskilt viktigt för I/O-operationer, eftersom serverapplikationer utför många sådana operationer.
I slutändan kan det visa sig att bytecode inte är svaret. Sun och Microsoft verkar gå head to head i bytekodfältet för tillfället. Men de gör detta för att bytekod är ett bekvämt ställe att bädda in sig själv i en process, inte för att bytekod i sig är en bra idé. Det kan visa sig att hela denna strid kommer att gå obemärkt förbi. Det skulle vara roligt.
Snaror och snaror
1. Kunder
Detta är bara en gissning, men det är att de enda applikationer som kommer att gynnas är de som är helt server-side. Att designa mjukvara som arbetar utifrån antagandet att alla kommer att ha en kund är som att designa ett samhälle baserat på antagandet att alla kommer att vara ärliga. Det skulle definitivt vara bekvämt, men du måste anta att det aldrig kommer att hända.
Jag tror att det kommer att ske en snabb ökning av webbaktiverade enheter, och vi kan anta att de kommer att stödja grundläggande html och formulär. Har du en webbläsare på din telefon? Kommer din PalmPilot att ha en telefon? Kommer din björnbär att ha en större skärm? Kommer du att kunna komma åt Internet från din gameboy? Från din klocka? jag vet inte. Och jag behöver inte ta reda på om jag slår vad om att allt kommer att finnas på servern. Det är bara mycket mer tillförlitligt att ha alla hjärnor på servern. .
2. Objektorienterad programmering
Jag inser att detta är ett kontroversiellt uttalande, men jag tror inte att OOP är så viktigt. Jag tror att detta är ett lämpligt paradigm för specifika applikationer som behöver specifika datastrukturer, som fönstersystem, simuleringar, CAD-system. Men jag förstår inte varför det skulle passa alla program.
Jag tror att människor i stora företag älskar OOP, delvis, eftersom det gör att många saker ser ut som arbete. Det som naturligt kan representeras som, säg, en lista med heltal, kan nu representeras som ett klassrum med alla möjliga ställningar, liv och rörelse.
En annan attraktiv egenskap hos OOP är att metoder ger dig en del av effekten av förstklassiga funktioner. Men detta är inga nyheter för Lisp-programmerare. När du har riktiga förstklassiga funktioner kan du helt enkelt använda dem på vilket sätt som helst som passar den aktuella uppgiften, istället för att trycka in allt i en samling klasser och metoder.
Jag tror att vad detta betyder för språkdesign är att du inte ska bädda in OOP för djupt i det. Kanske är svaret att erbjuda mer allmänna, grundläggande saker och låta människor designa vilka objektsystem som helst som bibliotek.
3. Design av kommitté
Om ditt språk är designat av en kommitté, då är du instängd, och inte bara av skäl som alla känner till. Alla vet att kommittéer tenderar att skapa klumpiga, inkonsekventa språkdesigner. Men jag tror att den stora faran är att de inte tar risker. När en person är ansvarig tar han risker som nämnden aldrig skulle gå med på att ta.
Behöver du ta risker för att skapa ett bra språk? Många kanske misstänker att språkdesign är där man måste hålla sig ganska nära traditionell visdom. Jag slår vad om att så inte är fallet. I allt annat som människor gör är belöningen proportionell mot risken. Så varför skulle språkdesign vara annorlunda?
Källa: will.com