Veiledende filosofi
1. Programmeringsspråk for mennesker
Programmeringsspråk er hvordan folk snakker til datamaskiner. Datamaskinen vil gjerne snakke et hvilket som helst språk som ikke er tvetydig. Grunnen til at vi har høynivåspråk er fordi folk ikke kan håndtere maskinspråk. Poenget med programmeringsspråk er å forhindre at våre fattige, skjøre menneskelige hjerner blir overveldet av for mange detaljer.
Arkitekter vet at noen designproblemer er mer dagligdagse enn andre. Noen av de tydeligste og mest abstrakte designproblemene er utformingen av broer. I dette tilfellet er jobben din å dekke den nødvendige avstanden med så lite materiale som mulig. I den andre enden av spekteret er stoldesign. Stoldesignere bør bruke tiden sin på å tenke på baken til folk.
Programvareutvikling har en lignende forskjell. Å designe algoritmer for å rute data gjennom et nettverk er et fint, abstrakt problem, som å designe broer. Mens å designe programmeringsspråk er som å designe stoler: du må forholde deg til menneskelige svakheter.
Dette er vanskelig for de fleste av oss å innse. Å utforme elegante matematiske systemer høres mye mer attraktivt ut for de fleste av oss enn å ta hensyn til menneskelige svakheter. Rollen til matematisk eleganse er at en viss grad av eleganse gjør programmer lettere å forstå. Men alt handler ikke om eleganse.
Og når jeg sier at språk bør være designet for å imøtekomme menneskelige svakheter, mener jeg ikke at språk skal være designet for dårlige programmerere. I virkeligheten bør du designe programvare for de beste programmererne, men selv de beste programmererne har sine grenser. Jeg tror ikke noen ville like å programmere på et språk der alle variabler ble merket med bokstaven "x" med heltallsabonnement.
2. Design for deg selv og vennene dine
Hvis du ser på historien til programmeringsspråk, var de fleste av de beste språkene designet for å brukes av deres egne forfattere, og de fleste av de verste var designet for andre mennesker å bruke.
Når språk er designet for andre mennesker, er det alltid en spesifikk gruppe mennesker: folk er ikke like smarte som skaperne av språket. Slik får du en tunge som snakker ned til deg. Cobol er det mest fremtredende eksemplet, men de fleste språk er gjennomsyret av denne ånden.
Det har ingenting med hvor høyt nivå språket er. C er ganske lavt nivå, men det ble laget for å brukes av forfatterne, og det er grunnen til at hackere elsker det.
Argumentet for å designe språk for dårlige programmerere er at det er flere dårlige programmerere enn gode. Kanskje er det slik. Men dette lille antallet gode programmerere skriver uforholdsmessig mer programvare.
Spørsmålet mitt er, hvordan lager du et språk som appellerer til de beste hackerne? Det virker for meg som om dette spørsmålet er identisk med spørsmålet om hvordan lage et godt programmeringsspråk?, men selv om det ikke er det, er det i det minste et interessant spørsmål.
3. Gi programmereren så mye kontroll som mulig
Mange språk (spesielt de som er designet for andre) fungerer som barnepiker: de prøver å advare deg bort fra ting de tror ikke vil være nyttige for deg. Jeg har det motsatte synet: gi programmereren så mye kontroll du kan.
Da jeg først lærte Lisp, var det jeg likte best at vi snakket som likeverdige. På de andre språkene jeg hadde lært på det tidspunktet, var det et språk, og det var programmet mitt på det språket, og de eksisterte ganske separat. Men i Lisp var funksjonene og makroene jeg skrev de samme som selve språket ble skrevet i. Jeg kunne skrive om selve språket hvis jeg ville. Den hadde samme appell som åpen kildekode-programvare.
4. Brevity er talentets søster
Korthet er undervurdert og til og med foraktet. Men hvis du ser inn i hjertene til hackere, vil du se at de virkelig liker korthet. Hvor mange ganger har du hørt hackere snakke med glede om hvordan, for eksempel, APL, kan de gjøre fantastiske ting med bare et par linjer med kode? Jeg antar at veldig smarte mennesker faktisk liker å ta hensyn til dette.
Jeg tror at nesten alt som gjør programmer kortere er en god ting. Det skal være mange bibliotekfunksjoner, alt som kan være implisitt skal være det; syntaks bør være mer kortfattet; selv enhetsnavn skal være korte.
Og ikke bare programmer skal være korte. Manualer bør også være korte. En god del av manualene er fylt med forklaringer, ansvarsfraskrivelser, advarsler og spesielle tilfeller. Hvis du trenger å forkorte manualen, er det beste alternativet å korrigere språket som krever så mye forklaring.
5. Gjenkjenne hva hacking er
Mange vil at hacking skal være matematikk, eller i det minste noe som ligner på naturfag. Jeg tror hacking er mer som arkitektur. Arkitektur handler om fysikk ved at en arkitekt trenger å designe en bygning som ikke faller, men det virkelige målet for en arkitekt er å skape en flott bygning, ikke å gjøre funn innen statikk.
Det hackere elsker er å lage gode programmer. Og jeg tror at, i det minste i våre egne tanker, bør vi huske at det å skrive gode programmer er en fantastisk ting, selv når det arbeidet ikke lett oversettes til den vanlige intellektuelle valutaen til vitenskapelige artikler. Fra et intellektuelt synspunkt er det like viktig å designe et språk som programmerere vil elske som det er å designe et forferdelig språk som legemliggjør en idé som du kan publisere en artikkel om.
Åpne problemer
1. Hvordan organisere store biblioteker?
Biblioteker er i ferd med å bli en viktig del av programmeringsspråk. De blir så store at det kan være farlig. Hvis det tar lengre tid å finne en funksjon i et bibliotek som gjør det du trenger enn å skrive den funksjonen selv, så gjør ikke all koden annet enn å gjøre manualen din tykkere. (Symbolikkmanualene var et eksempel på dette.) Så vi må løse problemet med bibliotekorganisasjonen. Ideelt sett design dem slik at programmereren kan gjette hvilken bibliotekfunksjon som passer.
2. Er folk virkelig redde for prefikssyntaks?
Dette er et åpent problem i den forstand at jeg har tenkt på det i flere år og fortsatt ikke vet svaret. Prefikssyntaks virker helt naturlig for meg, bortsett fra kanskje for bruken i matematikk. Men det kan være at mye av Lisps upopularitet rett og slett skyldes den ukjente syntaksen... Om vi skal gjøre noe med det, hvis det stemmer, er en annen sak.
3. Hva trenger du for serverprogramvare?
Jeg tror de fleste applikasjonene som vil bli skrevet i løpet av de neste tjue årene vil være nettapplikasjoner, i den forstand at programmene vil ligge på en server og kommunisere med deg gjennom en nettleser. Og for å skrive slike søknader trenger vi nye ting.
En av disse tingene er støtte for en ny måte å frigjøre serverapplikasjoner på. I stedet for en eller to store utgivelser per år, som desktop programvare, vil serverprogramvare bli utgitt i en rekke små endringer. Du har kanskje fem eller ti utgivelser om dagen. Og alle vil alltid ha den nyeste versjonen.
Vet du hvordan du designer programmer for å være vedlikeholdbare? Serverprogramvare må være utformet for å kunne endres. Du bør enkelt kunne endre det, eller i det minste vite hva en mindre endring betyr og hva som er viktig.
En annen ting som kan være nyttig i serverprogramvare er plutselig kontinuitet i leveringen. I en nettapplikasjon kan du bruke noe som for å få effekten av rutiner i nettøktenes statsløse verden. Å ha kontinuitet i forsyningen kan være verdt det hvis funksjonen ikke er for dyr.
4. Hvilke nye abstraksjoner gjenstår å oppdage?
Jeg er ikke sikker på hvor rimelig det håpet er, men personlig vil jeg virkelig gjerne oppdage en ny abstraksjon - noe som kan være like meningsfullt som førsteklasses funksjoner eller rekursjon eller i det minste standardparametere. Kanskje dette er en umulig drøm. Slike ting blir ofte ikke oppdaget. Men jeg mister ikke håpet.
Lite kjente hemmeligheter
1. Du kan bruke hvilket språk du vil
Tidligere betydde opprettelsen av applikasjoner opprettelsen av skrivebordsprogramvare. Og i stasjonær programvare er det en stor skjevhet mot å skrive applikasjoner på samme språk som operativsystemet. Så for ti år siden betydde det å skrive programvare generelt å skrive programvare i C. Etter hvert utviklet tradisjonen seg: applikasjoner skulle ikke skrives på uvanlige språk. Og denne tradisjonen har utviklet seg så lenge at ikke-tekniske mennesker som ledere og venturekapitalister har lært det også.
Serverprogramvare ødelegger denne modellen fullstendig. Med serverprogramvare kan du bruke hvilket språk du vil. Nesten ingen forstår dette ennå (spesielt ledere og venturekapitalister). Men noen hackere forstår dette, og det er derfor vi hører om indy-språk som Perl og Python. Vi hører ikke om Perl og Python fordi folk bruker dem til å skrive Windows-applikasjoner.
Hva betyr dette for oss, folk som er interessert i programmeringsspråkdesign, at det er et potensielt publikum for arbeidet vårt.
2. Hastighet kommer fra profiler
Språkutviklere, eller i det minste språkimplementere, liker å skrive kompilatorer som genererer rask kode. Men jeg tror ikke det er det som gjør språk raskt for brukere. Knuth bemerket for lenge siden at hastighet avhenger av bare noen få flaskehalser. Og alle som har prøvd å få fart på et program vet at man ikke kan gjette hvor flaskehalsen er. Profiler er svaret.
Språkutviklere løser feil problem. Brukere trenger ikke benchmarks for å kjøre raskt. De trenger et språk som kan vise hvilke deler av programmet deres som må skrives om. På dette tidspunktet er det nødvendig med fart i praksis. Så kanskje det ville vært bedre om språkimplementere brukte halvparten av tiden de bruker på å optimalisere kompilatoren og bruke den på å skrive en god profiler.
3. Du trenger en app som får språket ditt til å utvikle seg
Dette er kanskje ikke den ultimate sannheten, men det ser ut til at de beste språkene utviklet seg sammen med applikasjonene de ble brukt i. C ble skrevet av folk som trengte systemprogrammering. Lisp ble delvis designet for symbolsk differensiering, og McCarthy var så ivrig etter å komme i gang at han til og med begynte å skrive differensieringsprogrammer i den første Lisp-artikkelen i 1960.
Dette er spesielt bra hvis applikasjonen din løser noen nye problemer. Dette presser språket ditt til å ha nye funksjoner som programmerere ønsker. Personlig er jeg interessert i å skrive et språk som vil være bra for serverapplikasjoner.
[Under diskusjonen gjorde Guy Steele også dette poenget, og la til at applikasjonen ikke skulle bestå av å skrive en kompilator for språket ditt, med mindre språket ditt er laget for å skrive kompilatorer.]
4. Språket skal være egnet til å skrive engangsprogrammer.
Du vet hva et one-shot-program betyr: det er når du raskt må løse et begrenset problem. Jeg tror at hvis du ser deg rundt, vil du finne mange seriøse programmer som startet som enkeltstående. Jeg ville ikke bli overrasket om de fleste programmene startet som engangsprogrammer. Dermed, hvis du ønsker å lage et språk som vil være egnet for å skrive programvare generelt, så bør det også være egnet for å skrive engangsprogrammer, fordi dette er startfasen av mange programmer.
5. Syntaks er relatert til semantikk
Det er tradisjonelt antatt at syntaks og semantikk er veldig forskjellige ting. Dette høres kanskje sjokkerende ut, men det er det ikke. Jeg tror det du ønsker å oppnå i programmet ditt har å gjøre med hvordan du uttrykker det.
Jeg snakket nylig med Robert Morris, og han bemerket at operatøroverbelastning er et stort pluss for seieren til språk med infikssyntaks. På språk med prefikssyntaks er enhver funksjon du definerer faktisk en operator. Hvis du vil legge til en ny type tall som du har laget, kan du ganske enkelt definere en ny funksjon for å legge den til. Hvis du gjør dette på et språk med infix-syntaks, vil du se at det er stor forskjell på å bruke en overbelastet operatør og å kalle en funksjon.
Ideer som kommer tilbake over tid
1. Nye programmeringsspråk
Når vi ser tilbake til 1970-tallet, var det mote å utvikle nye programmeringsspråk. Dette er ikke tilfelle nå. Men jeg tror at serverprogramvare igjen vil bringe tilbake moten for å lage nye språk. Med serverprogramvare kan du bruke hvilket språk du vil, så hvis noen lager et språk som virker bedre enn resten, vil det være folk som bestemmer seg for å bruke det.
2. Tidsdeling
Richard Kelsey kom opp med denne ideen hvis tid er kommet igjen, og jeg støtter den fullt ut. Min gjetning (og Microsofts også) er at mye databehandling vil flytte fra skrivebordet til eksterne servere. Tidsdeling er med andre ord tilbake. Jeg tror dette vil trenge støtte på språknivå. For eksempel har Richard og Jonathan Reeves gjort mye arbeid for å implementere prosessplanlegging i Scheme 48.
3. Effektivitet
Nylig så det ut til at datamaskiner allerede var raske nok. Vi hører mer og mer om bytecode, som i det minste for meg betyr at vi har litt strøm i reserve. Men jeg tror at med serverprogramvare har vi det ikke. Noen vil måtte betale for serverne som kjører programvaren, og antall brukere serveren kan støtte per maskin vil være en divisor av kapitalkostnadene deres.
Jeg tror effektivitet vil ha betydning, i det minste når det gjelder dataflaskehalser. Dette vil være spesielt viktig for I/O-operasjoner, fordi serverapplikasjoner utfører mange slike operasjoner.
Til slutt kan det vise seg at bytecode ikke er svaret. Sun og Microsoft ser ut til å gå mot hverandre i bytekodefeltet for øyeblikket. Men de gjør dette fordi bytekode er et praktisk sted å bygge seg inn i en prosess, ikke fordi bytekode i seg selv er en god idé. Det kan vise seg at hele denne kampen vil gå ubemerket hen. Det ville vært morsomt.
Snarer og snarer
1. Kunder
Dette er bare en gjetning, men det er at de eneste applikasjonene som vil ha nytte er de som er helt server-side. Å designe programvare som opererer på antakelsen om at alle vil ha en kunde er som å designe et samfunn basert på antakelsen om at alle vil være ærlige. Det ville definitivt vært praktisk, men du må anta at det aldri vil skje.
Jeg tror det vil være en rask økning av nettaktiverte enheter, og vi kan anta at de vil støtte grunnleggende html og skjemaer. Har du en nettleser på telefonen? Vil din PalmPilot ha en telefon? Vil bjørnebæret ditt ha en større skjerm? Vil du få tilgang til Internett fra gameboyen din? Fra klokken din? Jeg vet ikke. Og jeg slipper å finne ut om jeg satser på at alt vil være på serveren. Det er bare mye mer pålitelig å ha alle hjernene på serveren. .
2. Objektorientert programmering
Jeg skjønner at dette er en kontroversiell uttalelse, men jeg tror ikke OOP er så viktig. Jeg tror dette er et passende paradigme for spesifikke applikasjoner som trenger spesifikke datastrukturer, som vindussystemer, simuleringer, CAD-systemer. Men jeg skjønner ikke hvorfor det skal passe for alle programmer.
Jeg tror folk i store selskaper elsker OOP, delvis fordi det gjør mange ting som ser ut som arbeid. Det som naturlig kan representeres som for eksempel en liste over heltall, kan nå representeres som et klasserom med alle slags stillaser, mas og mas.
En annen attraktiv funksjon ved OOP er at metoder gir deg noe av effekten av førsteklasses funksjoner. Men dette er ikke nyheter for Lisp-programmerere. Når du har ekte førsteklasses funksjoner, kan du ganske enkelt bruke dem på en hvilken som helst måte som passer oppgaven, i stedet for å skyve alt inn i en rekke klasser og metoder.
Jeg tror at dette betyr for språkdesign er at du ikke bør legge OOP for dypt inn i det. Kanskje svaret er å tilby mer generelle, grunnleggende ting, og la folk designe alle objektsystemer som biblioteker.
3. Utforming av utvalg
Hvis språket ditt er utformet av en komité, er du fanget, og ikke bare av grunner som alle kjenner til. Alle vet at komiteer har en tendens til å lage klumpete, inkonsekvente språkdesign. Men jeg tror den store faren er at de ikke tar risiko. Når en person er ansvarlig, tar han risikoer som utvalget aldri ville gå med på å ta på seg.
Trenger du å ta risiko for å skape et godt språk? Mange mennesker kan mistenke at språkdesign er der du må holde deg ganske nær tradisjonell visdom. Jeg vedder på at det ikke er tilfelle. I alt annet folk gjør, er belønningen proporsjonal med risikoen. Så hvorfor skal språkdesign være annerledes?
Kilde: www.habr.com