Pet pitanja o dizajnu programskih jezika

Vodilačka filozofija

1. Programske jezike za ljude

Programsko jezike su način na koji ljudi komuniciraju s računalima. Računalo će rado razgovarati na svakom jeziku koji ne stvara dvosmislenosti. Razlog zbog kojeg imamo visoko razine jezike je to što ljudi ne mogu da se nose s mašinskim jezikom. Suština programskih jezika je u tome da spriječe naš slabi, krhki ljudski um od preopterećenja mnoštvom detalja.

Arhitekti znaju da su neki problemi dizajniranja prizemniji od drugih. Jedan od najjasnijih i najapstraktnijih problema dizajniranja je projektiranje mostova. U tom slučaju, vaš zadatak je da pokrijete potrebnu udaljenost s što manjom količinom materijala. S druge strane spektra — projektiranje stolica. Dizajneri stolica moraju trošiti svoje vrijeme razmišljajući o ljudskim stražnjicama.

Razvoj softvera ima slično razlikovanje. Projektiranje algoritama za usmjeravanje podataka kroz mrežu — dobar, apstraktan problem, poput projektiranja mostova. Dok je projektiranje programskih jezika slično projektiranju stolica: treba se nositi s ljudskim slabostima.

Većini od nas teško je to shvatiti. Projektiranje elegantnih matematičkih sustava zvuči daleko privlačnije za većinu od nas nego popuštanje ljudskim slabostima. Uloga matematičke elegancije je u tome što određena stupanj elegancije čini programe jednostavnijima za razumijevanje. Međutim, elegancija nije jedina stvar.

I kada kažem da jezici trebaju biti projektirani kako bi uzeli u obzir ljudske slabosti, ne mislim da jezici trebaju biti projektirani za loše programere. U stvari, trebali biste dizajnirati softver za bolje programere, ali čak i najbolji programeri imaju svoje granice. Ne mislim da bi se itko veselio programiranju na jeziku gdje bi sve varijable bile označene slovom „x“ s cjelobrojnim indeksima.

2. Dizajnirajte za sebe i za svoje prijatelje

Ako pogledate povijest programskih jezika, većina najboljih jezika je dizajnirana za korištenje od strane njihovih autora, dok je većina najgorih dizajnirana za druge ljude.

Kada se jezici dizajniraju za druge ljude, to je uvijek neka određena grupa: ljudi nisu tako pametni kao stvaratelji jezika. Tako dobivate jezik koji s vama razgovara s preziru.

To nema nikakve veze s tim koliko je jezik visoko nivojski. C je dovoljno niskonivojski, ali je stvoren za korištenje od strane njegovih autora, zbog čega ga hakeri vole.

Argument u korist dizajniranja jezika za loše programere je taj da je loših programera više nego dobrih. Možda je to tako. No, malo je dobrih programera koji pišu nerazmjerno više softvera.

Zanima me pitanje kako stvoriti jezik koji će se svidjeti najboljim hakerima? Čini mi se da je ovo pitanje identično pitanju kako stvoriti dobar programski jezik?, ali čak i ako nije, to je barem zanimljivo pitanje.

3. Dajte programeru koliko god kontrole možete

Mnogi jezici (osobito oni koji su stvoreni za druge ljude) ponašaju se kao dadilje: pokušavaju vas upozoriti na stvari za koje misle da vam neće koristiti. Ja se zalažem za suprotno mišljenje: dajte programeru koliko god kontrole možete.

Kada sam prvi put učio Lisp, najviše mi se svidjelo to što smo razgovarali kao ravnopravan. U drugim jezicima koje sam tada učio, postojali su jezik i moja programa na tom jeziku, koji su postojali prilično odvojeno. No u Lisp-u, funkcije i makroi koje sam napisao bili su isti oni na kojima je napisan sam jezik. Mogao sam prepisati sam jezik ako sam to želio. Imao je istu privlačnost kao i softver s otvorenim kodom.

4. Sažetost je sestra talenta

Kratkost je često nedovoljno cijenjena i čak prezrena. No, ako zavirite u srca hakera, vidjet ćete da vrlo cijene kratkoću. Koliko ste puta čuli da hakeri s ljubavlju govore o tome kako, recimo, u APL-u mogu raditi neverovatne stvari s pomoću samo nekoliko redaka koda? Smatram da pravi pametni ljudi zapravo vole skrenuti pažnju na to.

Smatram da je gotovo sve što omogućava skraćivanje programa – dobro. Trebalo bi postojati mnoštvo bibliotečkih funkcija, sve što može biti implicitno – treba biti takvo; sintaksa bi trebala biti u većoj mjeri kratka; čak i imena entiteta trebala bi biti kratka.

I ne samo da programi trebaju biti kratki. Upute također trebaju biti kratke. Dobar dio uputa ispunjen je objašnjenjima, iznimkama, upozorenjima i posebnim slučajevima. Ako trebate skratiti upute, najbolja opcija je ispraviti jezik koji zahtijeva toliko mnogo objašnjenja.

5. Priznajte što je hakerstvo

Mnogim ljudima bi voljeli da hakerstvo bude matematika ili, barem, nešto slično prirodnim znanostima. Mislim da hakerstvo više nalikuje arhitekturi. Arhitektura je povezana s fizikom, u smislu da arhitekt mora dizajnirati zgradu koja se neće srušiti, ali prava svrha arhitekta je stvoriti sjajnu zgradu, a ne otkrivati stvari iz statike.

Ono što hakeri vole je stvarati sjajne programe. I mislim da, barem u našim vlastitim mislima, trebamo zapamtiti da pisanje izvanrednih programa - to je izvanredno, čak i kada se taj rad teško prevodi u uobičajenu intelektualnu valutu znanstvenih radova. Iz intelektualne perspektive, jednako je važno razvijati jezik koji će programeri obožavati, kao i stvarati nešto strašno, što utjelovljuje ideju o kojoj možete objaviti članak.

Otvoreni problemi

1. Kako organizirati velike biblioteke?

Biblioteke postaju važan dio programskih jezika. Postaju toliko velike da to može biti opasno. Ako treba više vremena da pronađete funkciju u biblioteci koja radi ono što vam treba nego da sami napišete tu funkciju, tada sav vaš kod ne čini ništa osim što zgušnjava vaš priručnik. (Priručnici Symbolics su bili primjer.) Tako da ćemo morati riješiti problem s organizacijom biblioteka. Idealno bi ih trebalo dizajnirati tako da programer može pogoditi koja funkcija biblioteke bi odgovarala.

2. Da li su ljudi zaista uplašeni prefiksnom sintaksom?

To je otvoreni problem u smislu da sam razmišljao o njemu nekoliko godina i još uvijek ne znam odgovor. Prefiksna sintaksa mi se čini apsolutno prirodnom, možda osim korištenja u matematici. No, može biti da je velika većina nepopularnosti Lisp-a jednostavno zbog nepoznate sintakse... Da li nešto trebamo učiniti povodom toga, ako je to istina, to je drugo pitanje.

3. Što vam je potrebno za serverski softver?

Mislim da će većina aplikacija koje će biti napisane u sljedećih dvadeset godina biti web aplikacije, u smislu da će programi biti smješteni na serveru i komunicirati s vama putem web preglednika. A da bismo napisali takve aplikacije potrebne su nam nove stvari.

Jedna od tih stvari je podrška novom načinu izdavanja serverskih aplikacija. Umjesto jednog ili dva velika izdanja godišnje, kao kod desktop softvera, serverski softver će se izdavati nizom manjih promjena. Možete imati pet ili deset izdanja dnevno. I svi će uvijek imati najnoviju verziju.

Znate li kako dizajnirati programe da budu održivi? Serverski softver treba biti dizajniran sposobnim za promjene. Trebali biste imati mogućnost lako ga mijenjati, ili barem znati što znači mala promjena i što je važno.

Još jedna stvar koja može biti korisna u serverskom softveru je, iznenada, kontinuitet opskrbe. U web aplikaciji možete koristiti nešto poput CPS, kako biste postigli efekt od podprograma u stateless svijetu web sesija. Možda kontinuitet opskrbe vrijedi, ako ta mogućnost nije preskupa.

4. Koje nove apstrakcije je ostalo otkriti?

Nisam siguran koliko je razumna takva nada, ali osobno bih volio otvoriti novu apstrakciju — nešto što bi moglo imati isto tako veliko značenje kao funkcije prvog razreda ili rekurzija ili barem parametri prema zadanim postavkama. Možda je to nedostižan san. Takve stvari često ne dolaze do izražaja. Ali ne gubim nadu.

Malo poznate tajne

1. Možete koristiti bilo koji jezik koji želite

Ranije se pod izradom aplikacija podrazumijevala izrada desktop softvera. A u desktop softveru postoji veliki naglasak na pisanju aplikacija na istom jeziku kao i operativni sustav. Prije deset godina, izrada softvera u cjelini značila je izradu softvera na C-u. Na kraju, tradicija se razvila: aplikacije ne moraju biti napisane na neobičnim jezicima. I ta se tradicija razvijala toliko dugo da su je naučili čak i netehnički ljudi, poput menadžera i kapitalista.

Serverski softver potpuno uništava ovaj model. Sa serverskim softverom možete uzeti bilo koji jezik koji želite. Gotovo nitko to još ne razumije (osobito menadžeri i kapitalisti). Ali neki hakeri to razumiju, zato smo čuli za takve indie jezike kao Perl i Python. Ne čujemo za Perl i Python jer ljudi koriste te jezike za pisanje aplikacija za Windows.

Što to znači za nas, ljude zainteresirane za dizajn programskih jezika, jest da postoji potencijalna publika za naš rad.

2. Brzina dolazi od profajlera

Razvijači jezika ili, barem, njegovi realizatori vole pisati kompajlere koji generiraju brzi kod. No mislim da to nije ono što jezike čini brzim za korisnike. Knuth je davno primijetio da brzina ovisi o samo nekoliko uskih grla. A bilo tko tko je pokušao ubrzati program zna da ne možete pogoditi gdje je usko grlo. Profajler je odgovor.

Programeri jezika ne rješavaju pravi problem. Korisnicima nije potrebno da benchmarkovi rade brzo. Njima je potreban jezik koji može pokazati koji dijelovi njihovog programa trebaju biti prepisani. U tom trenutku, brzina je potrebna u praksi. Možda bi bilo bolje da implementatori jezika provedu polovicu vremena koje troše na optimizaciju kompajlera, posvećujući ga pisanju dobrog profajlera.

3. Trebate aplikaciju koja tjerati vaš jezik da se razvija

Možda to nije konačna istina, ali izgleda da su se najbolji jezici razvijali uz aplikacije u kojima su korišteni. C je napisan od strane ljudi kojima je bilo potrebno sistemsko programiranje. Lisp je djelomično razvijen za simbolsku diferencijaciju; McCarthy je bio toliko uzbuđen da je počeo pisati programe za diferencijaciju čak i u prvom dokumentu o Lisp-u 1960. godine.

To je posebno dobro ako vaša aplikacija rješava neke nove probleme. To potiče vaš jezik da ima nove mogućnosti koje programerima trebaju. Osobno, zanima me pisati jezik koji će biti dobar za serverne aplikacije.

[Tijekom rasprave, Guy Steele je također iznio ovu misao, dodajući da aplikacija ne bi trebala uključivati pisanje kompajlera za vaš jezik, osim ako vaš jezik nije namijenjen za pisanje kompajlera.]

4. Jezik treba biti prikladan za pisanje jednokratnih programa.

Znate što znači jednokratni program: to je kada trebate brzo riješiti neki ograničen problem. Mislim da ako pogledate oko sebe, naći ćete mnoge ozbiljne programe koji su počeli kao jednokratni. Ne bih se iznenadio da je većina programa počela kao jednokratni. Tako da, ako želite stvoriti jezik koji će biti prikladan za pisanje softvera u cjelini, mora biti i 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 stvari koje se jako razlikuju. Možda ovo zvuči šokantno, ali nije tako. Mislim da je ono što želite postići u vašem programu povezano s tim kako to izražavate.

Nedavno sam razgovarao s Robertom Morrisom, i on je primijetio da je preopterećenje operatora velika prednost za jezike s infiksnom sintaksom. U jezicima s prefiksnom sintaksom svaka funkcija koju definirate zapravo je operator. Ako želite zbrojiti novi tip broja koji ste izmislili, jednostavno možete definirati novu funkciju za njegovo zbrajanje. Ako to učinite u jeziku s infiksnom sintaksom, primijetit ćete veliku razliku između korištenja preopterećenog operatora i poziva funkcije.

Ideje koje se s vremenom vraćaju

1. Novi programski jezici

Gledajući unazad u 1970-e, bilo je modernizirati razvoj novih programskih jezika. Danas to nije slučaj. No mislim da će softver poslužitelja ponovno dovesti do stvaranja novih jezika. S poslužiteljskim softverom možete koristiti bilo koji jezik koji odaberete, pa će, ako netko stvori jezik koji se čini boljim od ostalih, biti ljudi koji će se odlučiti koristiti ga.

2. Dijeljenje vremena

Richard Kelsey je iznio ovu ideju, čije je vrijeme ponovno došlo, i potpuno je podržavam. Moje pretpostavke (kao i Microsoftove) su da će se mnogi proračuni premjestiti s radne površine na udaljene poslužitelje. Drugim riječima, dijeljenje vremena se vratilo. Mislim da će trebati podrška za to na razini jezika. Na primjer, Richard i Jonathan Riews su uložili puno truda u uvođenje rasporeda procesa u Scheme 48.

3. Učinkovitost

Nedavno se činilo da su računala već dovoljno brza. Sve više i više čujemo o bajt-kodu, što za mene znači da imamo snage u rezervi. No mislim da s poslužiteljskim softverom, nemamo je. Netko će morati platiti za servere, na kojima radi softver, a broj korisnika koje server može podnijeti po jednom stroju bit će djelitelj njihovih kapitalnih troškova.

Mislim da će učinkovitost biti važna, barem u uskim grlima proračuna. Ovo će biti posebno važno za operacije ulaza-izlaza, jer poslužiteljske aplikacije generiraju mnogo takvih operacija.

Na kraju se možda pokaže da bytecode nije rješenje. Sun i Microsoft trenutno se čine kao da se suočavaju licem u lice na polju bytecode-a. Ali to rade zato što je bytecode zgodno mjesto za ugrađivanje u proces, a ne zato što je bytecode sama po sebi dobra ideja. Može se pokazati da će ova borba proći nezapaženo. Bilo bi smiješno.

Zamke i zamke

1. Klijenti

To je samo pretpostavka, ali ona sugerira da će pobijediti samo one aplikacije koje će biti potpuno serverne. Projektirati softver koji funkcionira pod pretpostavkom da će svaki imati vaš klijent, sliči stvaranju društva temeljenog na pretpostavci da će svi biti pošteni. Bilo bi to zasigurno prikladno, ali morate priznati da to nikada neće biti.

Mislim da će doći do brze ekspanzije uređaja s pristupom na web, i može se pretpostaviti da će podržavati osnovni HTML i forme. Imate li preglednik na svom telefonu? Hoće li telefon biti u vašem PalmPilotu? Hoće li vaš blackberry imati veći ekran? Hoće li moći pristupiti internetu s vašeg gameboya? S vaših satova? Ne znam. I neću morati to saznati ako se kladim da će sve biti na serveru. Jednostavno je mnogo pouzdanije imati sve umove na serveru.

2. Objektno orijentirano programiranje

Razumijem da je ovo kontroverzno, ali ne smatram da je OOP nešto važno. Mislim da je to odgovarajuća paradigma za određene aplikacije kojima su potrebne specifične strukture podataka, poput prozorskih sustava, simulacija, CAD sustava. Ali ne razumijem zašto bi trebala biti prikladna za sve programe.

Mislim da ljudi u velikim kompanijama vole OOP, djelomično zato što pruža mnogo onoga što izgleda kao rad. Ono što se prirodno može predstaviti kao, recimo, lista cijelih brojeva, sada se može predstaviti kao klasa sa svim vrstama građevinskih skela, uz sva šum i užurbanost.

Druga privlačna osobina OOP-a je ta što vam metode daju neki učinak funkcija prvog reda. No, to nije novost za programere koji koriste Lisp. Kada imate prave funkcije prvog reda, možete ih koristiti na bilo koji način koji odgovara zadatku umjesto da sve naguravate u šablon klasa i metoda.

Mislim da to za jezični dizajn znači da se ne smije previše duboko integrirati OOP. Možda je odgovor u tome da se nude općenitije, osnovne stvari i da se ljudima omogući da dizajniraju bilo kakve objektne sustave u obliku biblioteka.

3. Dizajniranje od strane odbora

Ako vaš jezik dizajnira odbor, tada ste u zamci, i to ne samo zbog razloga koji su svima poznati. Svi znaju da odbori imaju tendenciju stvarati nesuvisle, nekonzistentne jezične dizajne. No, mislim da je veća opasnost u tome što ne preuzimaju rizike. Kada je na čelu jedna osoba, ona preuzima rizike koje odbor nikada ne bi pristao preuzeti.

Mora li se riskirati da bi se stvorio dobar jezik? Mnogi ljudi mogu sumnjati da je dizajn jezika ono gdje morate ostati prilično blizu tradicionalnoj mudrosti. Mogao bih se posvađati da to nije slučaj. U svemu ostalom što ljudi rade, nagrada je proporcionalna riziku. Zašto bi u dizajnu jezika to trebalo biti drugačije?

Izvor: habr.com