Vodilna filozofija
1. Programski jeziki za ljudi
S programskimi jeziki se ljudje pogovarjamo z računalniki. Računalnik bo z veseljem govoril kateri koli jezik, ki ni dvoumen. Razlog, da imamo jezike na visoki ravni, je, ker ljudje ne znajo obvladati strojnega jezika. Bistvo programskih jezikov je preprečiti, da bi naši ubogi, krhki človeški možgani postali preobremenjeni s preveč podrobnostmi.
Arhitekti vedo, da so nekateri problemi načrtovanja bolj vsakdanji kot drugi. Nekateri najbolj jasni in abstraktni projektni problemi so projektiranje mostov. V tem primeru je vaša naloga premagati zahtevano razdaljo s čim manj materiala. Na drugem koncu spektra je oblikovanje stolov. Oblikovalci stolov bi morali porabiti čas za razmišljanje o riti ljudi.
Razvoj programske opreme ima podobno razliko. Oblikovanje algoritmov za usmerjanje podatkov skozi omrežje je lep, abstrakten problem, kot je načrtovanje mostov. Medtem ko je oblikovanje programskih jezikov podobno oblikovanju stolov: ukvarjati se morate s človeškimi slabostmi.
To se večina od nas težko zaveda. Oblikovanje elegantnih matematičnih sistemov se večini od nas zdi veliko bolj privlačno kot ugajanje človeškim slabostim. Vloga matematične elegance je, da določena stopnja elegance naredi programe lažje razumljive. Vendar ni vse v eleganci.
In ko rečem, da bi morali biti jeziki oblikovani tako, da ustrezajo človeškim slabostim, ne mislim, da bi morali biti jeziki zasnovani za slabe programerje. V resnici bi morali načrtovati programsko opremo za najboljše programerje, vendar imajo tudi najboljši programerji svoje meje. Mislim, da nihče ne bi užival v programiranju v jeziku, kjer so bile vse spremenljivke označene s črko "x" s celimi indeksi.
2. Oblikujte zase in za svoje prijatelje
Če pogledate zgodovino programskih jezikov, je bila večina najboljših jezikov zasnovana tako, da jih uporabljajo njihovi avtorji, večina najslabših pa je bila zasnovana za uporabo drugih ljudi.
Ko so jeziki oblikovani za druge ljudi, je to vedno določena skupina ljudi: ljudje niso tako pametni kot ustvarjalci jezika. Tako dobiš jezik, ki govori navzdol. Cobol je najvidnejši primer, vendar je večina jezikov prežeta s tem duhom.
To nima nobene zveze s tem, kako visoka je raven jezika. C je precej nizka raven, vendar je bil ustvarjen, da ga uporabljajo njegovi avtorji, zato ga imajo hekerji radi.
Argument za oblikovanje jezikov za slabe programerje je, da je več slabih programerjev kot dobrih. Morda je temu tako. Toda to majhno število dobrih programerjev napiše nesorazmerno več programske opreme.
Moje vprašanje je, kako ustvariti jezik, ki je všeč najboljšim hekerjem? Zdi se mi, da je to vprašanje identično vprašanju, kako ustvariti dober programski jezik?, a tudi če ni, je vsaj zanimivo vprašanje.
3. Dajte programerju čim večji nadzor
Mnogi jeziki (zlasti tisti, ki so namenjeni drugim ljudem) delujejo kot varuške: poskušajo vas odvrniti od stvari, za katere menijo, da vam ne bodo koristile. Jaz imam nasprotno stališče: dajte programerju čim več nadzora.
Ko sem se prvič učil Lisp, mi je bilo najbolj všeč, da smo se pogovarjali kot enakovredni. V drugih jezikih, ki sem se jih do takrat naučil, je obstajal jezik in v tem jeziku je bil moj program, ki sta obstajala povsem ločeno. Toda v Lispu so bile funkcije in makri, ki sem jih napisal, enaki tistim, v katerih je bil napisan sam jezik. Sam jezik bi lahko prepisal, če bi hotel. Imel je enako privlačnost kot odprtokodna programska oprema.
4. Kratkost je sestra talenta
Kratkost je podcenjena in celo prezirana. Toda če pogledate v srca hekerjev, boste videli, da imajo zelo radi kratkost. Kolikokrat ste slišali, kako hekerji ljubeče govorijo o tem, kako lahko, recimo, v APL naredijo neverjetne stvari s samo nekaj vrsticami kode? Mislim, da so res pametni ljudje radi pozorni na to.
Verjamem, da je skoraj vse, kar skrajša programe, dobro. Knjižničnih funkcij bi moralo biti veliko, vse, kar je lahko implicitno, bi moralo biti tako; sintaksa naj bo bolj jedrnata; tudi imena entitet naj bodo kratka.
In ne le programi naj bodo kratki. Tudi priročniki naj bodo kratki. Dobršen del priročnikov je poln razlag, omejitev odgovornosti, opozoril in posebnih primerov. Če morate priročnik skrajšati, je najboljša možnost, da popravite jezik, ki zahteva toliko razlage.
5. Prepoznajte, kaj je hekanje
Marsikdo bi želel, da bi bilo hekanje matematika ali vsaj nekaj podobnega znanosti. Mislim, da je hekanje bolj podobno arhitekturi. Pri arhitekturi gre za fiziko, saj mora arhitekt zasnovati zgradbo, ki ne bo padla, toda pravi cilj arhitekta je ustvariti veliko zgradbo, ne pa delati odkritij na področju statike.
Hekerji radi ustvarjajo odlične programe. In mislim, da bi se vsaj v svojih mislih morali spomniti, da je pisanje odličnih programov čudovita stvar, tudi če tega dela ni zlahka prevesti v običajno intelektualno valuto znanstvenih člankov. Z intelektualnega vidika je prav tako pomembno oblikovati jezik, ki ga bodo imeli radi programerji, kot je oblikovati grozen jezik, ki uteleša idejo, o kateri lahko objavite članek.
Odprta vprašanja
1. Kako organizirati velike knjižnice?
Knjižnice postajajo pomemben del programskih jezikov. Postanejo tako veliki, da so lahko nevarni. Če potrebujete dlje, da v knjižnici najdete funkcijo, ki dela tisto, kar potrebujete, kot da to funkcijo napišete sami, potem vsa koda ne naredi nič drugega kot naredi vaš priročnik debelejši. (Priročniki Symbolics so bili primer tega.) Torej bomo morali rešiti problem organizacije knjižnice. V idealnem primeru jih oblikujte tako, da lahko programer ugane, katera funkcija knjižnice je primerna.
2. Ali se ljudje res bojijo sintakse predpon?
To je odprt problem v smislu, da o tem razmišljam že več let in še vedno ne vem odgovora. Sintaksa predpon se mi zdi povsem naravna, razen morda za njeno uporabo v matematiki. Vendar se lahko zgodi, da je velik del nepriljubljenosti Lispa preprosto posledica neznane sintakse ... Druga stvar je, ali bi morali glede tega kaj storiti, če je res.
3. Kaj potrebujete za strežniško programsko opremo?
Mislim, da bo večina aplikacij, ki bodo napisane v naslednjih dvajsetih letih, spletne aplikacije, v smislu, da bodo programi nameščeni na strežniku in bodo z vami komunicirali prek spletnega brskalnika. In za pisanje takih aplikacij potrebujemo nove stvari.
Ena od teh stvari je podpora za nov način izdaje strežniških aplikacij. Namesto ene ali dveh velikih izdaj na leto, kot je namizna programska oprema, bo strežniška programska oprema izdana v nizu majhnih sprememb. Morda imate pet ali deset izdaj na dan. In vsi bodo vedno imeli najnovejšo različico.
Ali veste, kako načrtovati programe, da jih je mogoče vzdrževati? Strežniška programska oprema mora biti zasnovana tako, da jo je mogoče spreminjati. Morali bi ga imeti možnost enostavno spremeniti ali vsaj vedeti, kaj manjša sprememba pomeni in kaj je pomembno.
Druga stvar, ki je lahko uporabna pri strežniški programski opremi, je nenadoma kontinuiteta dostave. V spletni aplikaciji lahko uporabite nekaj podobnega da bi dobili učinek rutine v brezdržavnem svetu spletnih sej. Neprekinjena dobava se morda splača, če funkcija ni predraga.
4. Katere nove abstrakcije je treba še odkriti?
Nisem prepričan, kako razumno je to upanje, a osebno bi res rad odkril novo abstrakcijo - nekaj, kar bi lahko bilo tako pomembno kot prvorazredne funkcije ali rekurzija ali vsaj privzeti parametri. Mogoče so to nemogoče sanje. Takih stvari pogosto ne odkrijemo. Ampak ne izgubim upanja.
Malo znane skrivnosti
1. Uporabite lahko kateri koli jezik, ki ga želite
Prej je ustvarjanje aplikacij pomenilo ustvarjanje namizne programske opreme. In v programski opremi za namizne računalnike obstaja velika pristranskost glede pisanja aplikacij v istem jeziku kot operacijski sistem. Pred desetimi leti je torej pisanje programske opreme na splošno pomenilo pisanje programske opreme v C. Sčasoma se je tradicija razvila: aplikacije ne bi smele biti napisane v nenavadnih jezikih. In ta tradicija se je razvijala tako dolgo, da so se je naučili tudi netehnični ljudje, kot so menedžerji in vlagatelji tveganega kapitala.
Strežniška programska oprema popolnoma uniči ta model. S strežniško programsko opremo lahko uporabljate kateri koli jezik. Tega še skoraj nihče ne razume (predvsem menedžerji in tvegani kapitalisti). Toda nekateri hekerji to razumejo, zato slišimo o indijskih jezikih, kot sta Perl in Python. Ne slišimo o Perlu in Pythonu, ker ju ljudje uporabljajo za pisanje aplikacij za Windows.
Kaj to pomeni za nas, ljudi, ki jih zanima oblikovanje programskih jezikov, da obstaja potencialna publika za naše delo.
2. Hitrost prihaja iz profilov
Razvijalci jezikov ali vsaj izvajalci jezikov radi pišejo prevajalnike, ki ustvarjajo hitro kodo. Ampak mislim, da to ni tisto, zaradi česar so jeziki hitri za uporabnike. Knuth je že zdavnaj opazil, da je hitrost odvisna le od nekaj ozkih grl. In vsakdo, ki je poskušal pospešiti program, ve, da ne morete uganiti, kje je ozko grlo. Profiler je odgovor.
Razvijalci jezikov rešujejo napačen problem. Uporabniki za hitro delovanje ne potrebujejo meril uspešnosti. Potrebujejo jezik, ki lahko pokaže, katere dele njihovega programa je treba prepisati. Na tej točki je v praksi potrebna hitrost. Zato bi bilo morda bolje, če bi izvajalci jezika polovico časa, ki ga porabijo za optimizacijo prevajalnika, porabili za pisanje dobrega profilerja.
3. Potrebujete aplikacijo, s katero se vaš jezik razvija
To morda ni popolna resnica, vendar se zdi, da so se najboljši jeziki razvijali skupaj z aplikacijami, v katerih so bili uporabljeni. C so napisali ljudje, ki so potrebovali sistemsko programiranje. Lisp je bil delno zasnovan za simbolno diferenciacijo in McCarthy je bil tako nestrpen, da bi začel, da je celo začel pisati diferenciacijske programe v prvem dokumentu Lisp leta 1960.
To je še posebej dobro, če vaša aplikacija rešuje nove težave. To spodbuja vaš jezik k novim funkcijam, ki jih programerji želijo. Osebno me zanima pisanje jezika, ki bo dober za strežniške aplikacije.
[Med razpravo je to poudaril tudi Guy Steele in dodal, da aplikacija ne bi smela vsebovati pisanja prevajalnika za vaš jezik, razen če je vaš jezik zasnovan za pisanje prevajalnikov.]4. Jezik mora biti primeren za pisanje enkratnih programov.
Veste, kaj pomeni enkratni program: ko morate hitro rešiti omejen problem. Verjamem, da če se ozrete okoli sebe, boste našli veliko resnih programov, ki so se začeli kot enkratni. Ne bi me presenetilo, če bi se večina programov začela kot enkratni. Če torej želite ustvariti jezik, ki bo primeren za pisanje programske opreme na splošno, potem mora biti primeren tudi za pisanje enkratnih programov, ker je to začetna faza mnogih programov.
5. Sintaksa je povezana s semantiko
Tradicionalno velja, da sta sintaksa in semantika zelo različni stvari. Morda se to sliši šokantno, vendar ni. Mislim, da je tisto, kar želite doseči v svojem programu, odvisno od tega, kako to izražate.
Pred kratkim sem govoril z Robertom Morrisom in ugotovil je, da je preobremenitev operaterja velik plus za zmago jezikov s sintakso infiksa. V jezikih s sintakso predpone je vsaka funkcija, ki jo definirate, pravzaprav operator. Če želite dodati novo vrsto številke, ki ste jo izmislili, lahko preprosto definirate novo funkcijo, da jo dodate. Če to storite v jeziku s sintakso infiksa, boste videli, da obstaja velika razlika med uporabo preobremenjenega operatorja in klicanjem funkcije.
Ideje, ki se čez čas vračajo
1. Novi programski jeziki
Če pogledamo nazaj v sedemdeseta leta, je bilo moderno razvijati nove programske jezike. Zdaj temu ni tako. Vendar verjamem, da bo strežniška programska oprema spet vrnila modo za ustvarjanje novih jezikov. S strežniško programsko opremo lahko uporabljate kateri koli jezik, tako da, če nekdo ustvari jezik, ki se zdi boljši od ostalih, se bodo ljudje odločili, da ga bodo uporabljali.
2. Delitev časa
Richard Kelsey je prišel na to idejo, čigar čas je spet prišel, in popolnoma jo podpiram. Moja domneva (in tudi Microsoftova) je, da se bo veliko računalništva preselilo z namizja na oddaljene strežnike. Z drugimi besedami, delitev časa se vrača. Mislim, da bo to potrebovalo podporo na jezikovni ravni. Na primer, Richard in Jonathan Reeves sta opravila veliko dela za implementacijo načrtovanja procesov v shemi 48.
3. Učinkovitost
Nedavno se je zdelo, da so računalniki že dovolj hitri. Vedno več slišimo o bajtni kodi, kar vsaj zame pomeni, da imamo nekaj moči v rezervi. Ampak mislim, da s strežniško programsko opremo tega nimamo. Nekdo bo moral plačati za strežnike, ki poganjajo programsko opremo, in število uporabnikov, ki jih strežnik lahko podpira na stroj, bo delitelj njihovih kapitalskih stroškov.
Mislim, da bo učinkovitost pomembna, vsaj pri računalniških ozkih grlih. To bo še posebej pomembno za V/I operacije, ker strežniške aplikacije izvajajo veliko takih operacij.
Na koncu se lahko izkaže, da bajtna koda ni rešitev. Zdi se, da si Sun in Microsoft trenutno nasprotujeta na področju bajtne kode. Toda to počnejo, ker je bajtna koda priročno mesto za vdelavo v proces, ne zato, ker je bajtna koda sama po sebi dobra ideja. Lahko se izkaže, da bo celotna bitka ostala neopažena. Bilo bi smešno.
Zanke in zanke
1. Stranke
To je le ugibanje, vendar bodo imele koristi le tiste aplikacije, ki so v celoti na strani strežnika. Oblikovanje programske opreme, ki deluje na predpostavki, da bo vsakdo imel stranko, je kot načrtovanje družbe, ki temelji na predpostavki, da bodo vsi pošteni. Vsekakor bi bilo priročno, vendar morate domnevati, da se to ne bo nikoli zgodilo.
Mislim, da se bo hitro povečalo število naprav, ki podpirajo splet, in domnevamo lahko, da bodo podpirale osnovni html in obrazce. Ali imate v telefonu brskalnik? Bo imel vaš PalmPilot telefon? Bo imel vaš blackberry večji zaslon? Boste lahko dostopali do interneta s svojim gameboyem? Iz vaše ure? Nevem. In ne bo mi treba izvedeti, če stavim, da bo vse na strežniku. Samo veliko bolj zanesljivo je imeti vse možgane na strežniku. .
2. Objektno orientirano programiranje
Zavedam se, da je to sporna izjava, vendar mislim, da OOP ni tako pomemben. Mislim, da je to primerna paradigma za posebne aplikacije, ki potrebujejo specifične podatkovne strukture, kot so okenski sistemi, simulacije, sistemi CAD. Ne razumem pa, zakaj bi moral biti primeren za vse programe.
Mislim, da imajo ljudje v velikih podjetjih radi OOP, delno zato, ker naredi veliko stvari, ki izgledajo kot delo. Kar bi lahko naravno predstavili kot, recimo, seznam celih števil, je zdaj mogoče predstaviti kot učilnico z najrazličnejšimi odri, vrvežem in vrvežem.
Druga privlačna značilnost OOP je, da vam metode dajo nekaj učinka prvovrstnih funkcij. Vendar to ni novica za programerje Lisp. Ko imate resnično prvorazredne funkcije, jih lahko preprosto uporabite na kakršen koli način, ki ustreza nalogi, ki jo imate pri roki, namesto da vse potisnete v kotlino razredov in metod.
Mislim, da to za oblikovanje jezika pomeni, da OOP ne bi smeli pregloboko vdelati vanj. Mogoče je odgovor v tem, da ponudimo bolj splošne, temeljne stvari in pustimo ljudem, da oblikujejo katere koli objektne sisteme kot knjižnice.
3. Oblikovanje komisije
Če vaš jezik oblikuje odbor, potem ste ujeti, in to ne le zaradi razlogov, ki jih vsi poznajo. Vsi vedo, da odbori ponavadi ustvarjajo grudaste, nedosledne jezikovne zasnove. Ampak mislim, da je velika nevarnost, da ne tvegajo. Ko je ena oseba odgovorna, prevzema tveganja, ki jih komisija nikoli ne bi sprejela.
Ali morate tvegati, da ustvarite dober jezik? Mnogi ljudje morda sumijo, da je jezikovno oblikovanje tisto, kjer se morate precej približati tradicionalni modrosti. Stavim, da ni tako. Pri vsem drugem, kar ljudje počnejo, je nagrada sorazmerna s tveganjem. Zakaj bi torej moralo biti oblikovanje jezika drugačno?
Vir: www.habr.com