Pitanja o projektovanju programskih jezika

Vodstvena filozofija

1. Programski jezici za ljude

Programsko jezike su način na koji ljudi komuniciraju sa računarima. Računar će rado komunicirati na svakom jeziku koji nije dvosmislen. Razlog zašto imamo jezike visokog nivoa je taj što se ljudi ne mogu nositi s mašinskim jezikom. Suština programskih jezika je da spreči naš slabi, krhki ljudski um od preopterećenja mnoštvom detalja.

Arhitekte znaju da su neki problemi dizajna prizemljeniji od drugih. Neki od najslikovitijih i apstraktnih problema dizajna uključuju dizajn mostova. U ovom slučaju, vaš posao je da premostite potrebnu udaljenost s što manje materijala. Na drugom kraju spektra je dizajn stolica. Dizajneri stolica moraju provesti vreme razmišljajući o ljudskim stražnjicama.

Razvoj softvera ima slične razlike. Dizajniranje algoritama za usmeravanje podataka kroz mrežu je dobar, apstraktan problem, poput dizajniranja mostova. Dok je dizajn programskih jezika sličan dizajnu stolica: potrebno je nositi se sa ljudskim slabostima.

Većini od nas je teško to shvatiti. Dizajn elegantnih matematičkih sistema zvuči mnogo privlačnije za većinu od nas nego popuštanje ljudskim slabostima. Uloga matematičke elegancije je u tome da neka stepenica elegancije čini programe lakše razumljivim. Ali elegancija nije sve.

I kada kažem da jezici treba da budu dizajnirani s obzirom na ljudske slabosti, ne mislim da jezici treba da budu dizajnirani za loše programere. Ustvari, trebate dizajnirati softver za najbolje programere, ali čak i najbolji programeri imaju svoje granice. Ne mislim da bi ikome bilo drago programirati na jeziku gde bi sve promenljive bile označene slovom "x" s celobrojnim indeksima.

2. Dizajnirajte za sebe i svoje prijatelje

Če pogledamo zgodovino programskih jezikov, so bili najboljši jeziki zasnovani predvsem za uporabo svojih avtorjev, medtem ko so bili najslabši jeziki ustvarjeni za druge ljudi.

Ko so jeziki zasnovani za druge ljudi, je to običajno neka specifična skupina ljudi: ljudje niso tako pametni kot ustvarjalci jezika. Tako dobimo jezik, ki se s tabo pogovarja s preziranjem. Cobol je najbolj oprijemljiv primer, toda večina jezikov je prežeta s tem duhom.

To nima zveze s tem, kako visok nivo ima jezik. C je dovolj nizkonivojski, vendar je bil ustvarjen za uporabo njegovih avtorjev, zato ga imajo hekerji radi.

Argument za zasnovo jezikov za slabe programerje je, da je slabih programerjev več kot dobrih. Morda je to res. Toda to malo dobrih programerjev ustvari nenavadno več programske opreme.

Zanima me vprašanje, kako ustvariti jezik, ki bi bil všeč najboljšim hekerjem? Zdi se mi, da je to vprašanje identično vprašanju, kako ustvariti dober programski jezik?, vendar, tudi če ni, je vsaj zanimivo vprašanje.

3. Dajte programerju čim več nadzora.

Mnogi jeziki (zlasti tisti, ki so ustvarjeni za druge ljudi) delujejo kot varuhi: trudijo se, da vas opozorijo na stvari, za katere menijo, da vam ne bodo v pomoč. Jaz pa se strinjam z nasprotnim: dajte programerju čim več nadzora, kolikor je le mogoče.

Ko sem prvič učil Lisp, me je najbolj pritegnilo to, da smo se pogovarjali kot enakovredni. V drugih jezikih, ki sem jih takrat že spoznal, je bil jezik in moja programa v tem jeziku, ki sta obstajala kar ločeno. Toda v Lispu so bile funkcije in makroji, ki sem jih napisal, enaki tistim, s katerimi je bil napisan sam jezik. Lahko sem prepisal sam jezik, če bi hotel. Imel je enako privlačnost kot programska oprema z odprto kodo.

4. Kratkost je sestra talenta.

Kratkost je podcenjena i čak prezrena. Ali ako zagledate u srca hakera, videćete da veoma vole kratkoću. Koliko puta ste čuli kako hakeri s ljubavlju govore o tome kako, recimo, u APL-u mogu da postignu neverovatne stvari sa samo nekoliko redova koda? Smatram da pravi pametni ljudi zapravo vole da obrate pažnju na to.

Smatram da je gotovo sve što omogućava da programi budu kraći — dobro. Trebalo bi da postoji mnoštvo funkcija u bibliotekama, sve što može biti implicitno — trebalo bi da bude takvo; sintaksa bi trebala da bude što konciznija; čak i imena entiteta trebala bi biti kratka.

I ne samo da programi treba da budu kratki. Uputstva takođe treba da budu sažeta. Veliki deo uputstava ispunjen je objašnjenjima, izuzecima, upozorenjima i posebim slučajevima. Ako vam zatreba da skratite uputstvo, najbolja opcija je da ispravite jezik koji zahteva toliko objašnjenja.

5. Priznajte šta je hakerstvo

Mnogim ljudima bi se svidelo da hakerstvo bude matematika ili, bar, nešto što podseća na prirodne nauke. Smatram da je hakerstvo mnogo bliže arhitekturi. Arhitektura je povezana sa fizikom, u smislu da arhitekta treba da dizajnira zgradu koja neće pasti, ali prava svrha arhitekte je da stvara veličanstvene zgrade, a ne da otkriva u oblasti statike.

Ono što hakeri vole jeste da stvaraju velike programe. I mislim da, barem u našim mislima, treba da se setimo da je pisanje divnih programa divno, čak i kada se taj rad teško prevodi u uobičajenu intelektualnu valutu naučnih radova. Sa intelektualnog stanovišta, jednako je važno razvijati jezik koji će programerima biti drag, kao i stvarati strašan, predstavljajući ideju, o kojoj možete objaviti članak.

Otvoreni problemi

1. Kako organizovati velike biblioteke?

Knjižnice postajajo pomemben del programskih jezikov. Postajajo tako velike, da je to lahko nevarno. Če porabite več časa za iskanje funkcije v knjižnici, ki dela tisto, kar potrebujete, kot pa za pisanje te funkcije sami, potemtakem ves koda ne dela drugega, kot da povečuje vašo dokumentacijo. (Dokumenti Symbolics so bili dober primer.) Tako bomo morali reševati težave z organizacijo knjižnic. Idealno bi jih bilo zasnovati tako, da bi programer lahko ugotovil, katera funkcija knjižnice je primerna.

2. Ali so ljudje resnično prestrašeni zaradi prefiksne sintakse?

To je odprta težava v tem smislu, da sem o njej razmišljal že nekaj let in še vedno ne poznam odgovora. Prefiksna sintaksa se mi zdi povsem naravna, morda razen pri njeni uporabi v matematiki. Morda je tako, da je večina nepriljubljenosti Lispov preprosto posledica nenavadne sintakse... Ali je smiselno kaj storiti glede tega, če je to res, je drugo vprašanje.

3. Kaj potrebujete za strežniško programsko opremo?

Mislim, da bodo večina aplikacij, ki bodo napisane v naslednjih dvajsetih letih, spletne aplikacije, v tem smislu, da bodo programi nameščeni na strežniku in se bodo z vami povezali preko spletnega brskalnika. In da bi napisali takšne aplikacije, potrebujemo nove stvari.

Ena od takih stvari je podpora novemu načinu izvajanja strežniških aplikacij. Namesto enega ali dveh večjih izdaj na leto, kot pri namizni programski opremi, bo strežniška programska oprema izhajala v seriji manjših sprememb. Lahko imate pet ali deset izdaj na dan. In vsi vedno uporabljajo najnovejšo različico.

Ali veste, kako oblikovati programe, da bodo vzdržni? Strežniška programska oprema mora biti zasnovana tako, da je sposobna sprememb. Imate morali imeti možnost, da jo zlahka spremenite, ali vsaj vedeti, kaj pomeni majhna sprememba in kaj je pomembno.

Še ena stvar, ki je lahko koristna v strežniški programski opremi, je, nenadoma, kontinuirana dobava. V spletni aplikaciji lahko uporabite nekaj takega kot CPS, da dosežete učinek podprogramov v brezdržavnem svetu spletnih sej. Morda ima kontinuirana dobava smisel, če ta možnost ni predraga.

4. Katere nove abstrakcije so še ostale za odkrivanje?

Nisem prepričan, kako pametna je takšna nadanja, toda osebno si zelo želim odkriti novo abstrakcijo – nekaj, kar bi imelo enako veliko vrednost kot funkcije prvega razreda, rekurzija ali vsaj privzeti parametri. Morda je to neizvedljiva sanja. Takšne stvari se pogosto ne odkrijejo. A ne izgubljam upanja.

Manj znane skrivnosti

1. Lahko uporabite poljubni jezik, ki ga želite

V preteklosti je bilo pod ustvarjanjem aplikacij mišljeno ustvarjanje namizne programske opreme. V namizni programski opremi je bil velik poudarek na pisanju aplikacij v istem jeziku kot operacijski sistem. Pred desetimi leti je pisanje programske opreme na splošno pomenilo pisanje programske opreme v C. Na koncu se je tradicija razvila: aplikacije ne bi smele biti napisane v nenavadnih jezikih. In ta tradicija se je razvijala tako dolgo, da so tudi nenoznačni ljudje, kot so menedžerji in tveganjski kapitalisti, to spoznali.

Strežniška programska oprema popolnoma uničuje ta model. Pri strežniški programski opremi lahko vzamete kateri koli jezik, ki ga želite. Skoraj nihče tega še ne razume (zlasti menedžerji in tveganjski kapitalisti). Toda nekateri hekerji to razumejo, zato smo slišali za tako imenovane indy jezike, kot sta Perl in Python. Ne slišimo o Perlu in Pythonu, ker jih ljudje uporabljajo za pisanje aplikacij za Windows.

Kaj to pomeni za nas, ljudi, ki nas zanima oblikovanje programskih jezikov, je, da obstaja potencialna publika za naše delo.

2. Hitrost prihaja iz profilov

Razvijalci jezika ali vsaj njegovi izvajalci radi pišejo prevajalnike, ki generirajo hitro kodo. Ampak mislim, da to ni tisto, kar jezike naredi hitre za uporabnike. Knuth je pred davnimi časi opazil, da hitrost odvisna le od nekaterih ozkih grl. In vsak, ki je poskusil pospešiti program, ve, da ne morete uganiti, kje je ozko grlo. Profiler je odgovor.

Razvijalci jezika ne rešavaju pravi problem. Korisnicima nije potrebno da benchmark testovi rade brzo. Potreban im je jezik koji može pokazati koje delove njihovih programa treba prepisati. U tom trenutku, brzina je važna u praksi. Možda bi bilo bolje da implementatori jezika potroše polovinu vremena koje troše na optimizaciju kompajlera na pisanje dobrog profajlera.

3. Potrebna vam je aplikacija koja će vaš jezik razvijati

Možda to nije konačna istina, ali čini se da su se najbolji jezici razvijali zajedno sa aplikacijama u kojima su korišćeni. C je napisan od strane ljudi kojima je bilo potrebno sistemsko programiranje. Lisp je delimično razvijen za simboličku derivaciju, a Makarti je bio toliko nestrpljiv da počne da piše programe za derivaciju čak i u prvom dokumentu o Lisp-u iz 1960. godine.

To je posebno važno ako vaša aplikacija rešava nove probleme. To podstiče vaš jezik da ima nove mogućnosti koje programerima trebaju. Lično, zanimljivo mi je pisati jezik koji će biti dobar za server aplikacije.

[Tokom diskusije, Gaj Stil je takođe izrazio ovu misao, dodajući da aplikacija ne bi trebala da se sastoji u pisanju kompajlera za vaš jezik, osim ako vaš jezik nije namenjen pisanju kompajlera.]

4. Jezik bi trebao biti prikladan za pisanje jednokratnih programa.

Znate šta znači jednokratni program: to je kada trebate brzo rešiti neki ograničen zadatak. Pretpostavljam da ako pogledate oko sebe, otkrićete mnogo ozbiljnih programa koji su počeli kao jednokratni. Ne bih se iznenadio ako je većina programa počela kao jednokratni. Dakle, ako želite da stvorite jezik koji će biti prikladan za pisanje softvera uopšte, on takođe treba biti prikladan za pisanje jednokratnih programa, jer je to početna faza mnogih programa.

5. Sintaksa je povezana sa semantikom

Tradicionalno se smatra da su sintaksa i semantika veoma različite stvari. Možda to zvuči šokantno, ali nije tako. Mislim da je ono što želite da postignete u vašem programu povezano s tim kako to izražavate.

Nedavno sem govoril z Robertom Morrisom, ki je opazil, da je preobremenitev operatorjev velik plus za zmago jezikov z infiksno sintakso. V jezikih s prefiksno sintakso je vsaka funkcija, ki jo definirate, dejansko operator. Če želite sešteti novo vrsto števila, ki ste ga izumili, lahko preprosto definirate novo funkcijo za dodajanje. Če to storite v jeziku z infiksno sintakso, boste opazili, da obstaja velika razlika med uporabo preobremenjenega operatorja in klicem funkcije.

Ideje, ki se sčasoma vračajo

1. Novi programerski jeziki

Ko gledamo nazaj v sedemdeseta leta, je bilo priljubljeno razvijati nove programerske jezike. Zdaj to ni več tako. Ampak mislim, da bo strežniška programska oprema ponovno povrnila modo za ustvarjanje novih jezikov. S strežniško programsko opremo lahko uporabite kateri koli jezik želite, zato, če kdo ustvari jezik, ki se zdi boljši od ostalih, bodo ljudje, ki se bodo odločili, da ga uporabijo.

2. Časovna delitev

Richard Kelsey je predstavil to idejo, katere čas je ponovno prišel, in jo popolnoma podpiram. Moje domneve (in tudi Microsoftove) so, da se bo veliko izračunov preselilo z namiznih računalnikov na oddane strežnike. Z drugimi besedami, časovna delitev se je vrnila. Mislim, da bo potrebno to podpreti na ravni jezika. Na primer, Richard in Jonathan Reeves sta opravila veliko dela za uvedbo načrtovanja procesov v Scheme 48.

3. Učinkovitost

Nedavno se je zdelo, da so računalniki že dovolj hitri. Vsak dan večkrat slišimo o bajtnih kodah, kar vsaj zame pomeni, da imamo moč v rezervo. Ampak mislim, da zdaj s strežniško programsko opremo tega nimamo. Nekdo bo moral plačati za servere, na katerih deluje programska oprema, in število uporabnikov, ki jih strežnik lahko prenese na eno napravo, bo delilo njihove kapitalske stroške.

Mislim, da bo učinkovitost pomembna, vsaj v ozkih grlih izračunov. Še posebej pomembna bo za operacije vnosa-izdaja, ker strežniške aplikacije producirajo številne takšne operacije.

Na koncu se lahko izkaže, da bytecode ni rešitev. Sun in Microsoft se trenutno zdita, da se spopadata na področju bytecode-a. Toda to počneta, ker je bytecode priročno mesto za integracijo v proces, ne zato, ker bi bil bytecode sam po sebi dobra ideja. Morda se bo izkazalo, da se bo ta bitka odvijala neopažena. Bilo bi zabavno.

Zadnje pasti in pasti

1. Stranke

To je le domneva, a predvidevam, da bodo zmagala le tista uporabniška orodja, ki bodo v celoti strežniška. Načrtovati programsko opremo, ki deluje pod predpostavko, da bo vsakdo imel vaš odjemalec, je podobno ustvarjanju družbe, ki temelji na predpostavki, da bodo vsi pošteni. To bi bilo zagotovo priročno, a morali bi sprejeti, da tega nikoli ne bo.

Mislim, da bo hitro povečanje naprav z dostopom do spleta, in lahko domnevamo, da bodo podpirale osnovni HTML in oblike. Imate brskalnik na telefonu? Bo telefon v vašem PalmPilotu? Ali bo vaš blackberry imel večji zaslon? Ali boste imeli možnost dostopa do interneta s svojega gameboy-a? S svojih ur? Ne vem. In ne bom moral to ugotoviti, če stavim, da bo vse na strežniku. Preprosto je veliko bolj zanesljivo imeti vse umske sposobnosti na strežniku.

2. Objektno usmerjeno programiranje

Razumem, da je to sporno stališče, a ne menim, da je OOP kaj pomembnega. Mislim, da je to ustrezna paradigma za specifične aplikacije, ki potrebujejo specifične podatkovne strukture, kot so sistemski okni, simulacije, CAD sistemi. A ne razumem, zakaj bi morala biti primerna za vse programe.

Mislim, da ljudem v velikih podjetjih OOP deloma ustreza, ker daje občutek dela. To, kar je naravno mogoče predstaviti kot, recimo, seznam celih števil, je zdaj mogoče predstaviti kot razred z vsemi vrstami gradbenih strukture, s hrupom in neredom.

Druga privlačna lastnost OOP je, da metode dajejo nek učinek funkcij prvega razreda. A to ni novost za programerje v Lispu. Ko imate prave funkcije prvega razreda, lahko preprosto uporabite na kateri koli način, ki ustreza nalogi, namesto da bi vse potisnili v predlogo razredov in metod.

Men arvan, et see tähendab, et keeltekavandi jaoks ei pea te objektorienteeritud programmeerimist liiga sügavale sisse viima. Vastus võib olla pakkuda rohkem üldisi, põhialuseid ja lasta inimestel kujundada üksusesüsteeme teekide kaudu.

3. Komitee disain

Kui teie keel on komitee poolt kavandatud, siis olete lõksus, mitte ainult kõigist tuntud põhjustest. Kõigile on teada, et komiteed kipuvad looma tuhmilt, järjepidevamalt keelekujundust. Kuid nagu ma arvan, on suurem oht see, et nad ei võtaks riske. Kui eesotsas on üks inimene, siis ta võtab riske, mida komitee kunagi nõustuda ei taha.

Kas on vaja riske võtta, et luua hea keel? Paljud inimesed võivad kahtlustada, et keelekujundamine on valdkond, kus peaksite kinni pidama traditsioonilisest targutamisest. Ma võiksin vaielda, et see nii ei ole. Kõiges muus, mida inimesed teevad, on tasu proportsionaalne riskiga. Miks peaks keelekujundamine olema erand?

Izvor: habr.com