Vodeća filozofija
1. Programski jezici za ljude
Programski jezici su način na koji ljudi razgovaraju s računalima. Računalo će rado govoriti svaki jezik koji nije dvosmislen. Razlog zašto imamo jezike visoke razine je taj što se ljudi ne mogu nositi sa strojnim jezikom. Svrha programskih jezika je spriječiti naše jadne, krhke ljudske mozgove da budu preopterećeni previše detalja.
Arhitekti znaju da su neki problemi dizajna svakodnevniji od drugih. Neki od najjasnijih i najapstraktnijih problema projektiranja su projektiranje mostova. U ovom slučaju, vaš zadatak je prijeći traženu udaljenost sa što manje materijala. Na drugom kraju spektra je dizajn stolica. Dizajneri stolica trebali bi provoditi svoje vrijeme razmišljajući o ljudskim stražnjicama.
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 sustava većini nas zvuči mnogo privlačnije od ugađanja ljudskim slabostima. Uloga matematičke elegancije je da određeni stupanj elegancije čini programe lakšim za razumijevanje. Ali nije sve u eleganciji.
I kada kažem da bi jezici trebali biti dizajnirani da udovolje ljudskim slabostima, ne mislim da bi jezici trebali biti dizajnirani za loše programere. U stvarnosti, trebali biste dizajnirati softver za najbolje programere, ali čak i najbolji programeri imaju svoje granice. Mislim da nitko ne bi uživao u programiranju na jeziku u kojem su sve varijable označene slovom "x" s integerima.
2. Dizajnirajte za sebe i svoje prijatelje
Ako pogledate povijest programskih jezika, većina najboljih jezika je dizajnirana 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 tako pametni kao kreatori jezika. Ovako ćete dobiti jezik koji vam govori. Cobol je najistaknutiji primjer, ali većina jezika je prožeta ovim duhom.
To nema nikakve veze s visokom razinom jezika. C je prilično niske razine, ali je stvoren da ga koriste njegovi autori, zbog čega ga hakeri vole.
Argument za dizajniranje jezika za loše programere je da postoji više loših programera 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 sviđa najboljim hakerima? Čini mi se da je ovo pitanje identično pitanju kako napraviti dobar programski jezik?, ali čak i da nije, u najmanju je ruku zanimljivo pitanje.
3. Dajte programeru što je više moguće kontrole
Mnogi se jezici (osobito oni namijenjeni drugim ljudima) ponašaju poput dadilja: pokušavaju vas upozoriti na stvari za koje misle da vam neće biti od koristi. Ja imam suprotno gledište: dajte programeru što više kontrole možete.
Kad sam tek naučio Lisp, najviše mi se svidjelo 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 Lispu, funkcije i makronaredbe koje sam napisao bile su iste one na kojima je napisan sam jezik. Mogao bih prepisati sam jezik da sam htio. Imao je istu privlačnost kao i softver otvorenog koda.
4. Kratkoća je sestra talenta
Sažetost je podcijenjena, pa čak i prezrena. Ali ako pogledate u srca hakera, vidjet ćete da oni jako vole kratkoću. Koliko ste puta čuli hakere kako nježno govore o tome kako, recimo, u APL-u mogu učiniti nevjerojatne stvari sa samo nekoliko redaka koda? Pretpostavljam da stvarno pametni ljudi zapravo vole obratiti pozornost na ovo.
Vjerujem da je gotovo sve što skraćuje programe dobra stvar. Knjižničnih funkcija treba biti puno, sve što može biti implicitno mora biti tako; sintaksa treba biti sažetija; čak i imena entiteta trebaju biti kratka.
I ne samo da programi trebaju biti kratki. Priručnici također trebaju biti kratki. Dobar dio priručnika ispunjen je objašnjenjima, odricanjima od odgovornosti, upozorenjima i posebnim slučajevima. Ako trebate skratiti priručnik, najbolja opcija je ispraviti jezik koji zahtijeva toliko objašnjenja.
5. Prepoznajte što je hakiranje
Mnogi ljudi bi htjeli da je hakiranje matematika ili barem nešto slično znanosti. Mislim da je hakiranje više poput arhitekture. Arhitektura se bavi fizikom utoliko što arhitekt treba projektirati zgradu koja neće pasti, ali pravi cilj arhitekta je stvoriti veliku zgradu, a ne otkrivati na polju statike.
Ono što hakeri vole je stvarati sjajne programe. I mislim da bismo se, barem u vlastitim mislima, trebali sjetiti da je pisanje izvrsnih programa prekrasna stvar, čak i kada se taj rad ne može lako pretočiti u uobičajenu intelektualnu valutu znanstvenih radova. S intelektualnog stajališta, jednako je važno dizajnirati jezik koji će programeri voljeti kao i dizajnirati užasan jezik koji utjelovljuje ideju o kojoj možete objaviti rad.
Otvoreni problemi
1. Kako organizirati velike knjižnice?
Knjižnice postaju važan dio programskih jezika. Postaju toliko veliki da mogu biti opasni. Ako je potrebno više vremena da pronađete funkciju 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 Symbolicsa bili su primjer za to.) Dakle, morat ćemo riješiti problem organizacije knjižnice. U idealnom slučaju, dizajnirajte ih tako da programer može pogoditi koja je funkcija knjižnice prikladna.
2. Boje li se ljudi stvarno sintakse prefiksa?
Ovo je otvoren problem u smislu da o njemu razmišljam već nekoliko godina i još uvijek ne znam odgovor. Sintaksa prefiksa čini mi se potpuno prirodnom, osim možda zbog njezine upotrebe u matematici. Ali može biti da je veliki dio Lispove nepopularnosti jednostavno posljedica nepoznate sintakse... Druga je stvar da li vrijedi išta poduzeti po tom pitanju, ako je to istina.
3. Što vam je potrebno za poslužiteljski softver?
Mislim da će većina aplikacija koje će biti napisane u sljedećih dvadeset godina biti web aplikacije, u smislu da će se programi nalaziti na poslužitelju i komunicirati s vama putem web preglednika. A za pisanje takvih aplikacija trebamo nove stvari.
Jedna od tih stvari je podrška za novi način izdavanja poslužiteljskih aplikacija. Umjesto jednog ili dva velika izdanja godišnje, poput softvera za stolna računala, poslužiteljski softver bit će objavljen u nizu malih izmjena. Možete imati pet ili deset izdanja dnevno. I svi će uvijek imati najnoviju verziju.
Znate li kako dizajnirati programe da ih je moguće održavati? Poslužiteljski softver mora biti dizajniran da bude promjenjiv. Trebali biste ga moći lako promijeniti ili barem znati što manja promjena znači i što je važno.
Još jedna stvar koja može biti korisna u poslužiteljskom softveru je, odjednom, kontinuitet isporuke. U web aplikaciji možete koristiti nešto poput da biste dobili učinak rutina u bezdržavnom svijetu web sesija. Imati kontinuitet opskrbe može se isplatiti ako značajka nije preskupa.
4. Koje nove apstrakcije još treba otkriti?
Nisam siguran koliko je ta nada razumna, ali osobno bih stvarno želio otkriti 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 se stvari često ne otkriju. Ali ne gubim nadu.
Malo poznate tajne
1. Možete koristiti bilo koji jezik koji želite
Prije je stvaranje aplikacija značilo stvaranje softvera za stolna računala. A u softveru za stolna računala postoji velika sklonost pisanju aplikacija na istom jeziku kao i operativni sustav. Tako je prije deset godina pisanje softvera općenito značilo pisanje softvera u C-u. S vremenom se tradicija razvila: aplikacije se ne smiju pisati na neobičnim jezicima. A ova se tradicija toliko dugo razvijala da su je naučili i ljudi koji nisu tehnički, poput menadžera i investitora rizičnog kapitala.
Poslužiteljski softver potpuno uništava ovaj model. S poslužiteljskim softverom možete koristiti bilo koji jezik koji želite. Gotovo nitko to još ne razumije (osobito menadžeri i poduzetnički kapitalisti). Ali neki hakeri to razumiju, zbog čega čujemo o indy jezicima poput Perla i Pythona. Ne čujemo za Perl i Python jer ih ljudi koriste za pisanje Windows aplikacija.
Što to znači za nas, ljude zainteresirane za dizajn programskog jezika, da postoji potencijalna publika za naš rad.
2. Brzina dolazi od profilera
Programeri jezika, ili barem implementatori jezika, vole pisati prevoditelje koji generiraju brz kod. Ali mislim da to nije ono što čini jezike brzima za korisnike. Knuth je davno primijetio da brzina ovisi o samo nekoliko uskih grla. A svatko tko je pokušao ubrzati program zna da ne možete pogoditi gdje je usko grlo. Profiler je odgovor.
Programeri jezika rješavaju krivi problem. Korisnicima nisu potrebna mjerila za brzo pokretanje. Potreban im je jezik koji može pokazati koje dijelove programa treba prepisati. U ovom trenutku potrebna je brzina u praksi. Stoga bi možda bilo bolje da implementatori jezika potroše pola vremena koje potroše na optimiziranje kompajlera i potroše ga na pisanje dobrog profilera.
3. Trebate aplikaciju koja potiče razvoj vašeg jezika
Ovo možda nije konačna istina, ali čini se da su najbolji jezici evoluirali zajedno s aplikacijama u kojima su se koristili. C su napisali ljudi kojima je bilo potrebno sistemsko programiranje. Lisp je djelomično dizajniran za simboličku diferencijaciju, a McCarthy je bio toliko željan započeti da je čak počeo pisati programe diferencijacije u prvom Lispovom dokumentu 1960.
Ovo je posebno dobro ako vaša aplikacija rješava neke nove probleme. To tjera vaš jezik da ima nove značajke koje programeri žele. Osobno sam zainteresiran za pisanje jezika koji će biti dobar za poslužiteljske aplikacije.
[Tijekom rasprave, Guy Steele je također iznio ovu točku, dodajući da se aplikacija ne bi trebala sastojati od pisanja prevoditelja za vaš jezik, osim ako je vaš jezik dizajniran za pisanje prevodilaca.]4. Jezik mora biti prikladan za pisanje jednokratnih programa.
Znate što znači jednokratni program: to je kada trebate brzo riješiti neki ograničeni problem. Vjerujem da ćete, ako pogledate oko sebe, pronaći mnogo ozbiljnih programa koji su započeli kao jednokratni. Ne bih se iznenadio da je većina programa počela kao jednokratni. 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 postići u svom programu ovisi o tome kako to izražavate.
Nedavno sam razgovarao s Robertom Morrisom i on je primijetio da je preopterećenje operatora veliki plus za pobjedu jezika s infiks sintaksom. U jezicima sa sintaksom prefiksa, svaka funkcija koju definirate zapravo je operator. Ako želite dodati novu vrstu broja koju ste sami izmislili, možete jednostavno definirati novu funkciju za njegovo dodavanje. Ako to učinite u jeziku sa sintaksom infiksa, vidjet ćete da postoji velika razlika između korištenja preopterećenog operatora i pozivanja funkcije.
Ideje koje se s vremenom vraćaju
1. Novi programski jezici
Gledajući unatrag u 1970-e, bilo je moderno razvijati nove programske jezike. Sada to nije slučaj. Ali vjerujem da će poslužiteljski softver ponovno vratiti modu stvaranja novih jezika. S poslužiteljskim softverom možete koristiti bilo koji jezik koji želite, pa ako netko stvori jezik koji se čini boljim od ostalih, bit će ljudi koji će ga odlučiti koristiti.
2. Dijeljenje vremena
Richard Kelsey je došao na ovu ideju čije je vrijeme opet došlo i ja je u potpunosti podržavam. Moja pretpostavka (i Microsoftova također) je da će se puno računalstva preseliti sa stolnog računala na udaljene poslužitelje. Drugim riječima, dijeljenje vremena se vratilo. Mislim da će to trebati podršku na razini jezika. Na primjer, Richard i Jonathan Reeves obavili su mnogo posla na implementaciji planiranja procesa u shemi 48.
3. Učinkovitost
Nedavno se činilo da su računala već dovoljno brza. Sve više slušamo o bajt-kodu, što barem meni znači da imamo nešto snage u rezervi. Ali mislim da s poslužiteljskim softverom to nemamo. Netko će morati platiti za poslužitelje koji pokreću softver, a broj korisnika koje poslužitelj može podržati po stroju bit će djelitelj njihovih kapitalnih troškova.
Mislim da će učinkovitost biti važna, barem u računalnim uskim grlima. Ovo će biti posebno važno za I/O operacije, jer poslužiteljske aplikacije izvode mnogo takvih operacija.
Na kraju se može ispostaviti da bytecode nije rješenje. Čini se da se Sun i Microsoft trenutačno bore na polju bajtkoda. Ali oni to čine jer je bajt kod pogodno mjesto za ugradnju u proces, a ne zato što je bajt kod sam po sebi 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 poslužitelja. Dizajnirati softver koji radi na pretpostavci da će svatko imati kupca je kao dizajnirati društvo temeljeno 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 broja uređaja s omogućenom mrežom i možemo pretpostaviti da će podržavati osnovni html i obrasce. Imate li preglednik na 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 svog sata? ne znam I neću morati saznati ako se kladim da će sve biti na serveru. Samo je mnogo pouzdanije imati sav mozak na poslužitelju. .
2. Objektno orijentirano programiranje
Shvaćam da je ovo kontroverzna izjava, ali ne mislim da je OOP toliko važan. Mislim da je ovo prikladna paradigma za specifične aplikacije koje trebaju specifične strukture podataka, kao što su prozorski sustavi, simulacije, CAD sustavi. Ali ne razumijem zašto bi trebao biti prikladan za sve programe.
Mislim da ljudi u velikim tvrtkama vole OOP, djelomično zato što čini mnogo stvari koje izgledaju kao posao. Ono što bi se prirodno moglo predstaviti kao, recimo, popis cijelih brojeva, sada se može predstaviti kao učionica sa svim vrstama skela, gužve i strke.
Još jedna atraktivna značajka OOP-a je da vam metode daju dio učinka prvoklasnih funkcija. Ali to nije novost za Lisp programere. Kada imate istinske prvorazredne funkcije, možete ih jednostavno koristiti na bilo koji način koji odgovara zadatku koji imate, umjesto da sve gurate u šablon klasa i metoda.
Mislim da ovo za dizajn jezika znači da ne biste trebali ugraditi OOP preduboko u njega. Možda je odgovor ponuditi općenitije, temeljnije stvari i dopustiti ljudima da dizajniraju objektne sustave kao knjižnice.
3. Dizajn povjerenstva
Ako je vaš jezik osmislio odbor, onda ste zarobljeni, i to ne samo iz razloga koje svi znaju. Svi znaju da su povjerenstva sklona stvaranju neujednačenih, nedosljednih jezičnih dizajna. Ali mislim da je velika opasnost to što ne riskiraju. Kad je jedna osoba na čelu, preuzima rizike koje povjerenstvo nikada ne bi prihvatilo.
Trebate li riskirati da biste stvorili dobar jezik? Mnogi bi ljudi mogli posumnjati da je dizajn jezika mjesto gdje se morate držati prilično blizu tradicionalne mudrosti. Kladim se da nije tako. U svemu ostalom što ljudi rade, nagrada je proporcionalna riziku. Pa zašto bi jezični dizajn bio drugačiji?
Izvor: www.habr.com