Guiding Philosophy
1. Programski jezici za ljude
Programski jezici su način na koji ljudi razgovaraju sa računarima. Računar će rado govoriti bilo koji jezik koji nije dvosmislen. Razlog zašto imamo jezike visokog nivoa je taj što ljudi ne mogu da rukuju mašinskim jezikom. Smisao programskih jezika je spriječiti da naš jadni, krhki ljudski mozak bude preopterećen previše detalja.
Arhitekte znaju da su neki problemi dizajna svakodnevniji od drugih. Neki od najjasnijih i najapstraktnijih problema dizajna su projektiranje mostova. U ovom slučaju, vaš posao je da pređete potrebnu udaljenost sa što manje materijala. Na drugom kraju spektra je dizajn stolica. Dizajneri stolica trebali bi provoditi svoje vrijeme razmišljajući o ljudskim guzicima.
Razvoj softvera ima sličnu razliku. Dizajniranje algoritama za usmjeravanje podataka kroz mrežu je lijep, apstraktan problem, poput projektiranja mostova. Dok je dizajniranje programskih jezika poput dizajniranja stolica: morate se nositi s ljudskim slabostima.
To je većini nas teško shvatiti. Dizajniranje elegantnih matematičkih sistema većini nas zvuči mnogo privlačnije od povlađivanja ljudskim slabostima. Uloga matematičke elegancije je da određeni stepen elegancije čini programe lakšim za razumevanje. Ali elegancija se tu ne zaustavlja.
I kada kažem da jezici treba da budu dizajnirani da udovolje ljudskim slabostima, ne mislim da jezici treba da budu dizajnirani za loše programere. U stvarnosti, trebali biste dizajnirati softver za najbolje programere, ali čak i najbolji programeri imaju svoja ograničenja. Mislim da niko ne bi uživao u programiranju na jeziku gde su sve varijable označene slovom "x" sa celim indeksima.
2. Dizajnirajte za sebe i svoje prijatelje
Ako pogledate istoriju programskih jezika, većina najboljih jezika su dizajnirani da ih koriste njihovi autori, a većina najgorih je dizajnirana da ih koriste drugi ljudi.
Kada su jezici dizajnirani za druge ljude, to je uvijek određena grupa ljudi: ljudi nisu toliko pametni kao tvorci jezika. Ovako ćete dobiti jezik koji vam govori dolje. Cobol je najistaknutiji primjer, ali većina jezika je prožeta tim duhom.
To nema nikakve veze sa nivoom jezika. C je dosta nizak nivo, ali je kreiran da ga koriste njegovi autori, zbog čega ga hakeri vole.
Argument za dizajniranje jezika za loše programere je da ima više loših nego dobrih. Možda je to tako. Ali ovaj mali broj dobrih programera piše nesrazmjerno više softvera.
Moje pitanje je, kako stvoriti jezik koji se dopada najboljim hakerima? Čini mi se da je ovo pitanje identično pitanju kako napraviti dobar programski jezik?, ali čak i ako nije, u najmanju je ruku zanimljivo pitanje.
3. Dajte programeru što je više moguće kontrole
Mnogi jezici (posebno oni dizajnirani za druge ljude) se ponašaju kao dadilje: pokušavaju da vas upozore od stvari za koje misle da vam neće koristiti. Zauzimam suprotan stav: dajte programeru što više kontrole.
Kada sam prvi put naučio Lisp, najviše mi se dopalo to što smo razgovarali kao jednaki. U drugim jezicima koje sam do tada naučio, postojao je jezik, i postojao je moj program na tom jeziku, i postojali su sasvim odvojeno. Ali u Lisp-u, funkcije i makroi koje sam napisao bile su iste na kojima je napisan i sam jezik. Mogao bih da prepišem sam jezik da sam hteo. Imao je istu privlačnost kao softver otvorenog koda.
4. Kratkoća je sestra talenta
Kratkoća je potcijenjena, pa čak i prezrena. Ali ako pogledate u srca hakera, vidjet ćete da oni zaista vole kratkoću. Koliko puta ste čuli da hakeri s ljubavlju pričaju o tome kako, recimo, u APL-u mogu da urade neverovatne stvari sa samo nekoliko linija koda? Pretpostavljam da zaista pametni ljudi vole da obrate pažnju na ovo.
Vjerujem da je skoro sve što skraćuje programe dobra stvar. Trebalo bi da postoji mnogo bibliotečkih funkcija, sve što može biti implicitno treba da bude tako; sintaksa bi trebala biti sažetija; čak i nazivi entiteta trebaju biti kratki.
I ne samo da programi treba da budu kratki. Priručnici takođe treba da budu kratki. Dobar dio priručnika prepun je objašnjenja, odricanja odgovornosti, upozorenja i posebnih slučajeva. Ako trebate skratiti priručnik, najbolja opcija je ispraviti jezik koji zahtijeva toliko objašnjenja.
5. Prepoznajte šta je hakovanje
Mnogi ljudi bi željeli da hakiranje bude matematika, ili barem nešto slično nauci. Mislim da hakiranje više liči na arhitekturu. Arhitektura se bavi fizikom u tome što arhitekta treba da dizajnira zgradu koja neće pasti, ali pravi cilj arhitekte je da stvori veliku zgradu, a ne da pravi otkrića u polju statike.
Ono što hakeri vole je stvaranje sjajnih programa. I mislim da bismo, barem u našim mislima, trebali zapamtiti da je pisanje sjajnih programa divna stvar, čak i kada se taj rad ne može lako prevesti u uobičajenu intelektualnu valutu naučnih radova. Sa intelektualnog stanovišta, jednako je važno dizajnirati jezik koji će se svidjeti programerima kao i dizajnirati užasan jezik koji utjelovljuje ideju o kojoj možete objaviti rad.
Otvorena pitanja
1. Kako organizirati velike biblioteke?
Biblioteke postaju važan dio programskih jezika. Oni postaju toliko veliki da mogu biti opasni. Ako je potrebno više vremena da se pronađe funkcija u biblioteci koja radi ono što vam je potrebno nego da sami napišete tu funkciju, onda sav kod ne čini ništa osim što vaš priručnik čini debljim. (Priručnici za simboliku su bili primjer ovoga.) Dakle, morat ćemo riješiti problem organiziranja biblioteka. U idealnom slučaju, dizajnirajte ih tako da programer može pogoditi koja funkcija biblioteke je prikladna.
2. Da li se ljudi zaista plaše sintakse prefiksa?
Ovo je otvoren problem u smislu da o njemu razmišljam već nekoliko godina i još uvijek ne znam odgovor. Sintaksa prefiksa mi se čini potpuno prirodnom, osim možda njene upotrebe u matematici. Ali može biti da je veliki dio Lispove nepopularnosti jednostavno zbog nepoznate sintakse... Da li bismo trebali nešto učiniti po tom pitanju, ako je istina, to je druga stvar.
3. Šta vam je potrebno za serverski softver?
Mislim da će većina aplikacija koje će biti napisane u narednih dvadeset godina biti web aplikacije, u smislu da će programi boraviti na serveru i komunicirati s vama preko web pretraživača. A da bismo napisali takve aplikacije, potrebne su nam nove stvari.
Jedna od tih stvari je podrška za novi način izdavanja serverskih aplikacija. Umjesto jednog ili dva velika izdanja godišnje, poput desktop softvera, serverski softver će biti objavljen u nizu malih promjena. Možda imate pet ili deset izdanja dnevno. I svi će uvijek imati najnoviju verziju.
Znate li kako dizajnirati programe da budu održavani? Serverski softver mora biti dizajniran tako da se može mijenjati. Trebali biste biti u mogućnosti to lako promijeniti, ili barem znati šta mala promjena znači i šta je važno.
Još jedna stvar koja može biti korisna u serverskom softveru je, iznenada, kontinuitet isporuke. U web aplikaciji možete koristiti nešto poput da biste dobili efekat rutina u svijetu web sesija bez stanja. Imati kontinuitet isporuke može se isplatiti ako funkcija nije preskupa.
4. Koje nove apstrakcije još treba otkriti?
Nisam siguran koliko je ta nada razumna, ali lično bih zaista volio da otkrijem novu apstrakciju - nešto što bi moglo imati smisla poput prvoklasnih funkcija ili rekurzije ili barem zadanih parametara. Možda je ovo nemoguć san. Takve stvari se često ne otkrivaju. Ali ne gubim nadu.
Malo poznate tajne
1. Možete koristiti bilo koji jezik koji želite
Ranije je kreiranje aplikacija značilo kreiranje desktop softvera. A kod desktop softvera postoji velika predrasuda prema pisanju aplikacija na istom jeziku kao i operativni sistem. Dakle, prije deset godina, pisanje softvera općenito je značilo pisanje softvera na C. Na kraju je tradicija evoluirala: aplikacije ne bi trebale biti pisane na neobičnim jezicima. I ova tradicija je evoluirala toliko dugo da su je naučili i ljudi koji nisu tehnički kao menadžeri i rizični kapitalisti.
Serverski softver potpuno uništava ovaj model. Sa serverskim softverom možete koristiti bilo koji jezik koji želite. Gotovo niko to još ne razumije (posebno menadžeri i investitori rizičnog kapitala). Ali neki hakeri to razumiju, zbog čega čujemo za nezavisne jezike poput Perla i Pythona. Ne čujemo za Perl i Python jer ih ljudi koriste za pisanje aplikacija za... Windows.
Šta to znači za nas, ljude zainteresovane za dizajn programskog jezika, da postoji potencijalna publika za naš rad.
2. Brzina dolazi od profilera
Programeri jezika, ili barem implementatori jezika, vole pisati kompajlere koji generiraju brzi kod. Ali mislim da to nije ono što jezike čini brzim za korisnike. Knuth je davno primijetio da brzina ovisi o samo nekoliko uskih grla. I svako ko je pokušao da ubrza program zna da ne možete pogoditi gde je usko grlo. Profiler je odgovor.
Programeri jezika rješavaju pogrešan problem. Korisnicima nisu potrebni benčmarkovi za brzo pokretanje. Potreban im je jezik koji može pokazati koje dijelove njihovog programa treba prepisati. U ovom trenutku, brzina je potrebna u praksi. Dakle, možda bi bilo bolje kada bi implementatori jezika potrošili pola vremena koje provode na optimizaciju kompajlera i potrošili ga na pisanje dobrog profilera.
3. Potrebna vam je aplikacija koja omogućava da vaš jezik evoluira
Ovo možda nije konačna istina, ali čini se da su najbolji jezici evoluirali zajedno s aplikacijama u kojima su korišteni. C su napisali ljudi kojima je bilo potrebno sistemsko programiranje. Lisp je dijelom dizajniran za simboličku diferencijaciju, a McCarthy je bio toliko nestrpljiv da započne da je čak počeo pisati programe diferencijacije u prvom Lisp radu 1960. godine.
Ovo je posebno dobro ako vaša aplikacija rješava neke nove probleme. Ovo gura vaš jezik da ima nove funkcije koje programeri žele. Lično, zainteresovan sam za pisanje jezika koji će biti dobar za serverske aplikacije.
[Tokom diskusije, Guy Steele je također rekao ovo, dodajući da se aplikacija ne bi trebala sastojati od pisanja kompajlera za vaš jezik, osim ako vaš jezik nije dizajniran za pisanje kompajlera.]
4. Jezik mora biti prikladan za pisanje jednokratnih programa.
Znate šta znači jednokratni program: to je kada trebate brzo riješiti neki ograničeni problem. Vjerujem da ćete, ako pogledate okolo, pronaći mnogo ozbiljnih programa koji su počeli kao jednokratni. Ne bih se iznenadio da je većina programa počela kao jednokratna. Dakle, ako želite stvoriti jezik koji će biti prikladan za pisanje softvera općenito, onda bi trebao biti prikladan i za pisanje jednokratnih programa, jer je to početna faza mnogih programa.
5. Sintaksa je povezana sa semantikom
Tradicionalno se vjeruje da su sintaksa i semantika vrlo različite stvari. Ovo možda zvuči šokantno, ali nije. Mislim da ono što želite da postignete u svom programu ima veze sa načinom na koji to izražavate.
Nedavno sam razgovarao sa Robertom Morrisom i on je primetio da je preopterećenje operatora veliki plus za pobedu jezika sa infiksnom sintaksom. U jezicima sa sintaksom prefiksa, svaka funkcija koju definirate je zapravo operator. Ako želite da dodate novi tip broja koji ste izmislili, možete jednostavno definirati novu funkciju da biste ga dodali. Ako to učinite na jeziku sa infiksnom sintaksom, vidjet ćete da postoji velika razlika između korištenja preopterećenog operatora i pozivanja funkcije.
Ideje koje se vremenom vraćaju
1. Novi programski jezici
Gledajući unazad u 1970-te, bilo je moderno razvijati nove programske jezike. To sada nije slučaj. Ali vjerujem da će serverski softver ponovo vratiti modu za kreiranje novih jezika. Sa serverskim softverom možete koristiti bilo koji jezik koji želite, pa ako neko stvori jezik koji se čini boljim od ostalih, naći će se ljudi koji će odlučiti da ga koriste.
2. Podjela vremena
Richard Kelsey je došao na ovu ideju čije je vrijeme ponovo došlo i ja je u potpunosti podržavam. Moja pretpostavka (i Microsoft-ova) je da će se mnogo računarstva preseliti sa desktopa na udaljene servere. Drugim riječima, podjela vremena se vratila. Mislim da će za ovo trebati podrška na nivou jezika. Na primjer, Richard i Jonathan Reeves su uradili dosta posla na implementaciji planiranja procesa u shemi 48.
3. Efikasnost
Nedavno se činilo da su računari dovoljno brzi. Sve više čujemo o bajtkodu, što, barem za mene, znači da imamo snage na pretek. Ali mislim da sa serverskim softverom nemamo. Neko će morati da plati za to. serveri, na kojem softver radi, a broj korisnika koje server može podržati po mašini bit će djelitelj njihovih kapitalnih troškova.
Mislim da će efikasnost biti važna, barem u računarskim uskim grlima. Ovo će biti posebno važno za I/O operacije, jer serverske aplikacije izvode mnogo takvih operacija.
Na kraju se može ispostaviti da bajt kod nije odgovor. Čini se da se Sun i Microsoft trenutno međusobno bore u polju bajtkoda. Ali oni to rade zato što je bajtkod pogodno mesto za ugradnju u proces, a ne zato što je sam bajtkod dobra ideja. Može se ispostaviti da će cijela ova bitka proći nezapaženo. Bilo bi smiješno.
Zamke i zamke
1. Klijenti
Ovo je samo nagađanje, ali jedine aplikacije koje će imati koristi su one koje su u potpunosti na strani servera. Dizajniranje softvera koji radi na pretpostavci da će svi imati kupca je poput dizajniranja društva zasnovanog na pretpostavci da će svi biti pošteni. To bi svakako bilo zgodno, ali morate pretpostaviti da se to nikada neće dogoditi.
Mislim da će doći do naglog porasta uređaja koji podržavaju web, i možemo pretpostaviti da će podržavati osnovni html i forme. Da li imate pretraživač na svom telefonu? Hoće li vaš PalmPilot imati telefon? Hoće li vaš blackberry imati veći ekran? Hoćete li moći pristupiti internetu sa svog gameboya? Sa tvog sata? Ne znam. I neću morati da saznam ako se kladim da će sve biti na serveru. Mnogo je pouzdanije imati sav mozak na serveru. .
2. Objektno orijentirano programiranje
Shvaćam da je ovo kontroverzna izjava, ali mislim da OOP nije toliko važan. Mislim da je ovo prikladna paradigma za specifične aplikacije kojima su potrebne specifične strukture podataka, kao što su prozorski sistemi, simulacije, CAD sistemi. Ali ne razumijem zašto bi trebao biti prikladan za sve programe.
Mislim da ljudi u velikim kompanijama vole OOP, djelimično, zato što čini mnoge stvari koje izgledaju kao da rade. Ono što bi se prirodno moglo predstaviti kao, recimo, lista cijelih brojeva, sada se može predstaviti kao učionica sa svim vrstama skela, gužve i gužve.
Još jedna atraktivna karakteristika OOP-a je da vam metode daju dio efekta prvoklasnih funkcija. Ali ovo nije vijest za Lisp programere. Kada imate prave prvoklasne funkcije, možete ih jednostavno koristiti na bilo koji način koji odgovara zadatku, umjesto da sve gurate u šablon klasa i metoda.
Mislim da ovo znači za dizajn jezika je da ne biste trebali previše duboko ugrađivati OOP u njega. Možda je odgovor ponuditi opštije, temeljne stvari i dozvoliti ljudima da dizajniraju bilo koji objektni sistem kao biblioteke.
3. Dizajn od strane komisije
Ako je vaš jezik dizajniran od strane komisije, onda ste u zamci, i to ne samo iz razloga koje svi znaju. Svi znaju da komiteti imaju tendenciju da kreiraju neujednačene, nedosledne jezičke dizajne. Ali mislim da je velika opasnost u tome što ne rizikuju. Kada je jedna osoba zadužena, ona preuzima rizik na koji komisija nikada ne bi pristala da preuzme.
Da li morate da rizikujete da biste stvorili dobar jezik? Mnogi ljudi mogu posumnjati da je jezički dizajn mjesto gdje morate ostati prilično blizu tradicionalnoj mudrosti. Kladim se da to nije slučaj. U svemu ostalom što ljudi rade, nagrada je proporcionalna riziku. Pa zašto bi dizajn jezika trebao biti drugačiji?
izvor: www.habr.com
