Fem spørsmål om design av programmeringsspråk

Ledelsesfilosofi

1. Programmeringssprog for mennesker

Programmeringssprog er den måde, hvorpå mennesker taler med computere. Computeren vil med glæde tale på ethvert sprog, der ikke er tvetydigt. Årsagen til, at vi har høj-niveau sprog, er, at mennesker ikke kan klare maskinsprog. Essensen af programmeringssprog er at forhindre vores skrøbelige menneskelige hjerner i at blive overbelastet med en masse detalje.

Arkitekter ved, at nogle designproblemer er mere jordnære end andre. Nogle af de mest klare og abstrakte designproblemer er design af broer. I dette tilfælde er dit job at overskride den krævede afstand med så lidt materiale som muligt. I den anden ende af spektret er design af stole. Stolendesignere skal bruge deres tid på at tænke på menneskelige bagdele.

Softwareudvikling har en lignende forskel. At designe algoritmer til at rute data gennem et netværk er et godt, abstrakt problem, ligesom design af broer. Mens design af programmeringssprog minder om design af stole: det handler om at håndtere menneskelige svagheder.

For de fleste af os er det svært at indse. At designe elegante matematiske systemer lyder meget mere tiltalende for de fleste af os end at imødekomme menneskelige svagheder. Den rolle, matematisk elegance spiller, er, at en vis grad af elegance gør programmer mere forståelige. Men elegance er ikke det eneste.

Og når jeg siger, at sprog skal designes med menneskelige svagheder in mente, 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 mener ikke, at nogen ville finde det behageligt at programmere i et sprog, hvor alle variabler blev angivet med bogstavet "x" med heltalsindeks.

2. Design til dig selv og dine venner

Når du ser på historien til programmeringsspråk, ble de fleste av de beste språkene designet for å bli brukt av sine egne skapere, mens de fleste av de dårligste ble designet for andre mennesker.

Når språk designes for andre mennesker, er det alltid en spesifikk gruppe mennesker: folk er ikke så smarte som skaperne av språket. Så du ender opp med et språk som snakker til deg nedlatende. Cobol er det mest fremtredende eksempelet, men de fleste språk er gjennomsyret av denne ånden.

Dette har ingenting å gjøre med hvor høynivått språket er. C er ganske lavnivått, men det ble laget for å bli brukt av dets skapere, derfor elsker hackere det.

Argumentet for å designe språk for dårlige programmerere er at det er flere dårlige programmerere enn gode. Kanskje det er sant. Men dette lille antallet gode programmerere skriver uforholdsmessig mer programvare.

Jeg er interessert i spørsmålet om hvordan man skaper et språk som appellerer til de beste hackerne? Jeg føler at dette spørsmålet er identisk med spørsmålet om hvordan man lager et godt programmeringsspråk?, men selv om det ikke er slik, 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 laget for andre mennesker) oppfører seg som barnevakter: de prøver å advare deg mot ting de mener ikke vil være nyttige for deg. Jeg er uenig: gi programmereren så mye kontroll som mulig.

Da jeg først studerte Lisp, likte jeg mest at vi snakket som likeverdige. I andre språk jeg hadde lært på det tidspunktet, var det et språk, og det var programmet mitt skrevet i det språket, og de eksisterte ganske separat. Men i Lisp var funksjonene og makroene jeg skrev de samme som de som var skrevet av selve språket. Jeg kunne omprogrammere språket selv om jeg ønsket det. Det hadde den samme tiltrekkingskraften som programvare med åpen kildekode.

4. Korthet er talentets søster

Kortehet er undervurdert og til og med foraktet. Men hvis du ser inn i hjertene til hackere, vil du se at de elsker korthet. Hvor mange ganger har du hørt hackere snakke kjærlighetsfullt om hvor de kan gjøre fantastiske ting med bare et par linjer kode i APL? Jeg tror de virkelig smarte folkene liker å fokusere på dette.

Jeg mener at nesten alt som lar programmer bli kortere er bra. Det må finnes mange biblioteksfunksjoner, alt som kan være implisitt bør være det; syntaksen bør være mer kortfattet; til og med navnene på entiteter bør være korte.

Og ikke bare programmer bør være korte. Manualer bør også være korte. En stor del av manualene er fylt med forklaringer, forbehold, advarsler og spesielle tilfeller. Hvis du må forkorte en manual, er den beste måten å korrigere språket som krever så mye forklaring.

5. Erkjenn hva hacking er

Mange mennesker ønsker at hacking skulle være matematikk, eller i det minste noe som ligner på naturvitenskapene. Jeg tror hacking ligner mer på arkitektur. Arkitektur har en tilknytning til fysikk, i den forstand at arkitekten mådesigne en bygning som ikke faller, men den virkelige målet for arkitekten er å skape en stor bygning, ikke å gjøre oppdagelser innen statikk.

Det hackere elsker er å lage store programmer. Og jeg tror, i det minste i våre egne tanker, at vi må huske at det å skrive fantastisk programvare er fantastisk, selv når dette arbeidet vanskelig kan oversettes til vanlig intellektuell valuta av vitenskapelige arbeider. Intellektuelt sett er det like viktig å utvikle et språk som programmerere vil elske, som det er å lage noe forferdelig, som ideen som du kan publisere en artikkel om.

Åpne problemer

1. Hvordan organisere store biblioteker?

Bibliotekene blir en viktig del av programmeringsspråk. De blir så store at det kan bli farlig. Hvis det tar mer tid å finne en funksjon i biblioteket som gjør det du trenger, enn å skrive den funksjonen selv, så gjør ikke koden annet enn å tykne manualen din. (Symbolics-håndbøkene var et eksempel på dette.) Så vi må finne en løsning for organisering av biblioteker. Ideelt sett bør de designes slik at programmereren kan gjette hvilken funksjon i biblioteket 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, kanskje bortsett fra bruken av den i matematikk. Men det kan være slik at mye av upopulariteten til Lisp'er skyldes den uvante syntaksen... Er det verdt å gjøre noe med dette, hvis det er tilfelle, er et annet spørsmål.

3. Hva trenger du for serverprogramvare?

Jeg tror at de fleste applikasjonene som vil bli skrevet de neste tyve årene, vil være nettapplikasjoner, i den forstand at programmene vil ligge på en server og kommunisere med deg gjennom nettleseren. Og for å skrive slike applikasjoner trenger vi nye verktøy.

En slik ting er støtte for en ny måte å slippe serverapplikasjoner på. I stedet for ett eller to store utgivelser i året, slik som desktopprogramvare, vil serverprogramvare bli utgitt i serien av små endringer. Du kan ha fem eller ti utgivelser per dag. Og alle vil alltid ha den nyeste versjonen.

Vet du hvordan man designer programmer slik at de er vedlikeholdbare? Serverprogramvare må designes for å være endringsdyktig. Du må kunne endre den enkelt, eller i det minste vite hva et lite endring betyr og hva som er viktig.

En annen ting som kan være nyttig i serverprogramvaren, er, overraskende nok, kontinuerlighet i leveransen. I en webapplikasjon kan du bruke noe som CPS, for å oppnå effekten av delprogrammer i en stateless verden av webøkter. Kontinuerlighet i leveransen kan være verdt det, hvis denne muligheten ikke er for kostbar.

4. Hvilke nye abstraksjoner gjenstår å oppdage?

Eg er ikkje sikker på korfor det er så fornuftig å ha slike håp, men sjølv har eg eit sterkt ønske om å opne ei ny abstraksjon — noko som kunne ha like mykje å seie som førsteklasses funksjonar eller rekursjon, eller iallfall standardparameter. Kanskje det er ein utopisk draum. Slike ting kjem sjeldan fram. Men eg gir ikkje opp håpet.

Lite kjente hemmeligheiter

1. Du kan bruke kva som helst språk du ønskjer

Tidlegare betydde det å lage applikasjonar å lage programvare for skrivebordet. Og i skrivebordsprogramvare var det ein stor tendens til å skrive applikasjonar på same språk som operativsystemet. Så for ti år sidan betydde det å skrive programvare generelt å skrive programvare i C. Tradisjonen utvikla seg til slutt: applikasjonar treng ikkje å vere skrivne i uvanlege språk. Og denne tradisjonen har utvikla seg så lenge at ikkje-tekniske folk, som leiarar og venturekapitalistar, også har lært det.

Serverprogramvare øydelegg denne modellen fullstendig. Med serverprogramvare kan du bruke kva språk du ønskjer. Nesten ingen forstår dette enno (spesielt leiarar og venturekapitalistar). Men nokre hackarar forstår det, og det er derfor vi har høyrt om slike indie-språk som Perl og Python. Vi høyrer ikkje om Perl og Python, fordi folk bruker dei til å skrive applikasjonar for Windows.

Kva betyr dette for oss som er interesserte i å designe programmeringsspråk? Det finst eit potensiell publikum for arbeidet vårt.

2. Hastighet kjem frå profilerar

Språkdevarar eller, iallfall, implementatorane av det, elskar å skrive kompilatorar som genererer rask kode. Men eg trur ikkje det er dette som gjer språk raske for brukarane. Knuth påpeika for lenge sidan at hastigheten avhenger av berre nokre få flaskehalsar. Og kven som helst som har prøvd å gjere eit program raskare veit at du ikkje kan gjette kva flaskehalsen er. Profilerar er svaret.

Språkutviklarane løysar ikkje det rette problemet. Brukarane treng ikkje at benkmarkeringane går raskt. Dei treng eit språk som kan vise kva delar av programmet deira som må skrivast om. På det tidspunktet er hastighet praktisk viktig. Kanskje det ville vore betre om implementørane av språket brukte halvparten av tida deira på å optimalisere kompilatoren og heller brukte den tida til å skrive ein god profiler.

3. Du treng ein applikasjon som tvingar språket ditt til å utvikle seg

Kanskje dette ikkje er den endelige sannheita, men det verkar som om dei beste språka utvikla seg saman med applikasjonane der dei blei brukte. C blei skriven av folk som trengte systemprogrammering. Lisp blei utvikla delvis for symbolsk diferensiering; McCarthy var så ivrig etter å starte at han begynte å skrive differensieringsprogrammer allereie i det første dokumentet om Lisp i 1960.

Dette er spesielt bra om applikasjonen di løysar nokre nye problem. Det pressar språket ditt til å ha nye funksjonar som programmørar treng. Personleg er eg interessert i å skrive eit språk som er bra for serverapplikasjonar.

[Under diskusjonen uttrykte Guy Steele også denne tanken, og la til at applikasjonen ikkje skal bestå av å skrive ein kompilator for språket ditt, med mindre språket ditt er meint for å skrive kompilatorar.]

4. Språket må vere eigna for å skrive éngangsprogram.

Du veit kva ein éngangsprogram er: det er når du raskt treng å løysa eit avgrensa problem. Eg tru det er mange seriøse program som starta som éngangsprogram. Eg ville ikkje bli overraska over om dei fleste program starta som éngangsprogram. Så om du vil lage eit språk som er eigna for å skrive program i det heile, så må det også vere eigna for å skrive éngangsprogram, fordi det er det tidlege stadiet for mange program.

5. Syntaksen er knytt til semantikken

Tradisjonelt er det blitt ansett at syntaks og semantikk er to sterkt forskjellige ting. Dette kan høyrest sjokkerande ut, men det er ikkje tilfelle. Eg trur det du vil oppnå i programmet ditt, er knytt til korleis du uttrykker det.

Nyleg snakka eg við Robert Morris, og hann merkaði at operator overloading er ein stór fyrimunur í samband við at vinna yvir mál við infix syntaks. Í mál við prefix syntaks er hvør einstakur funktion, tú definera, í veruleikanum ein operator. Um tú vilt leggja til nýggjan talgildan tølu, sum tú hevur funnir uppá, kanst tú einfalt definera eina nýggja funktion til at leggja tað saman. Um tú ger tað í eini mál við infix syntaks, sær tú at millum at brúka ein ovarløgd operator og at kalla ein funktion er stórur munur.

Idear, sum koma aftur við tíðum

1. Nýggj mál fyri programming

Havandi sítt í 1970-unum var tað í tíðarandanum at menna nýggj mál fyri programming. Nú er hetta ikki so. Men eg heldur, at server software fer at skapa aftur nýggj mál. Við server software kanst tú brúka eitthvørt mál, tú ynskir, so um onkur skapar mál, sum følist betur enn hini, so verða fólk, sum treysta til at brúka tað.

2. Tíðarsplit

Richard Kelsey setti hesa tankan fram, tíð hansara er komin aftur, og eg stuðli henni heilt. Mín antin (og Microsoft eisini) er at nógv útreiðslur flyta seg frá desktopinum til fjargøtt serverar. Í aðra orðum, tíðarsplit er komið aftur. Eg haldi, at tað fer at krevja stuðul á málnivónum. Til dømis hava Richard og Jonathan Reeves gjørt nógv arbeiði við at innleiða prosess scheduling í Scheme 48.

3. Effektivitet

Nyleg var tað sum um datahálvandi maskinir vóru nóg nógv skjótir. Allar fleiri og fleiri hoyra vit um byte-code, sum í min elvugøtton meint at vit hafa orku í dýrum. Men eg haldi, at við server software, hava vit ikki tað. Nøkur skulu borga fyri servere, har softwareið arbeiðir, og talið av brúkarum, sum servarin kann halda í miðal fyri hvørja maskinu, munar í hesum kapitalútreiðslum.

Eg heldur, at effektivitet fer at spilla ein stóran leik, í allaru førda í útreiðslum. Særs týdningarmikið fer hetta at verða fyri input-output viðurskifti, tí at server applikatiónir framleiða nógv av slíkum viðurskifti.

Til slutt kan det vise seg at bytekode ikke er løsningen. Sun og Microsoft ser ut til å kjempe ansikt til ansikt på bytekodefeltet nå. Men de gjør dette fordi bytekode er et praktisk sted for å bygge seg inn i prosessen, og ikke fordi bytekode i seg selv er en god idé. Det kan hende at hele denne kampen vil gå ubemerket hen. Det ville vært morsomt.

Feller og feller

1. Kunder

Dette er bare en antakelse, men det er at bare de programmene som er helt serverbaserte vil vinne. Å designe programvare med antakelsen om at alle vil ha din klient, minner om å skape et samfunn basert på antakelsen om at alle vil være ærlige. Det ville absolutt vært praktisk, men du må anta at dette aldri vil skje.

Jeg tror vi vil se en rask økning av enheter med tilgang til nettet, og det er rimelig å anta at de vil støtte grunnleggende HTML og skjemaer. Har du en nettleser på telefonen? Vil telefonen være i din PalmPilot? Vil din Blackberry ha en større skjerm? Vil du kunne gå på internett fra din Gameboy? Fra klokken din? Jeg vet ikke. Og jeg trenger ikke å finne ut av det hvis jeg satser på at alt vil være på serveren. Det er bare mye mer pålitelig å ha all intelligens på serveren.

2. Objektstående programmering

Jeg forstår at dette er en kontroversiell påstand, men jeg mener at OOP ikke er så viktig. Jeg tror det er et passende paradigme for spesifikke applikasjoner som trenger spesifikke datastrukturer, som vindussystemer, simuleringer, CAD-systemer. Men jeg forstår ikke hvorfor det burde være passende for alle programmer.

Jeg tror folk i store selskaper liker OOP, delvis fordi det gir mye som ser ut som arbeid. Det som naturlig kan representeres som en liste med heltall, kan nå representeres som en klasse med all slags stillaser, med støy og mas.

En annen tiltalende egenskap ved OOP er at metodene gir deg en slags effekt av førsteklasses funksjoner. Men dette er ikke noe nytt for programmerere som bruker Lisp. Når du har ekte førsteklasses funksjoner, kan du bare bruke dem på hvilken som helst måte som passer oppgaven, i stedet for å presse alt inn i en mal av klasser og metoder.

Eg trur at dette betyr for språkdesign at ein ikkje bør djupt integrere OOP i det. Kanskje svaret ligg i å tilby meir generelle, grunnleggjande ting, og la folk designe eigne objektsystem som bibliotek.

3. Designa av eit utvalg

Dersom språket ditt vert designa av eit utval, så er du i ei felle, ikkje berre av dei kjende grunnane. Det er allment kjent at utvalg har ein tendens til å skape klumpete, usamanhengande språkdesign. Men eg trur at den største faren er at dei ikkje tar risiko. Når ein person står fremst, tar han risikoene som eit utval aldri vil bli einige om.

Må ein ta risiko for å lage eit godt språk? Mange kan mistenka at språkdine design er eit område der ein må halde seg nær tradisjonell visdom. Eg kan påstå at det ikkje er slik. I alt anna folk gjer, er belønninga i proporsjon med risikoen. Så kvifor skulle det vere annleis i språkdesign?

Kilde: habr.com