Gvida Filozofio
1. Programlingvoj por homoj
Programlingvoj estas kiel homoj parolas al komputiloj. La komputilo volonte parolos iun ajn lingvon, kiu ne estas ambigua. La kialo, ke ni havas altnivelajn lingvojn, estas ĉar homoj ne povas trakti maŝinlingvon. La celo de programlingvoj estas malhelpi, ke niaj malriĉaj, delikataj homaj cerboj estu superfortitaj de tro da detaloj.
Arkitektoj scias, ke iuj projektproblemoj estas pli banalaj ol aliaj. Kelkaj el la plej klaraj kaj plej abstraktaj dezajnoproblemoj estas la dezajno de pontoj. En ĉi tiu kazo, via laboro estas kovri la postulatan distancon per kiel eble plej malmulte da materialo. Ĉe la alia fino de la spektro estas seĝdezajno. Seĝdezajnistoj devus pasigi sian tempon pensante pri la pugoj de homoj.
La disvolviĝo de programaro havas similan diferencon. Dezajni algoritmojn por direkti datumojn tra reto estas bela, abstrakta problemo, kiel desegni pontojn. Dum desegni programlingvojn estas kiel desegni seĝojn: vi devas trakti homajn malfortojn.
Ĉi tio estas malfacile por la plej multaj el ni konscii. Dezajni elegantajn matematikajn sistemojn sonas multe pli alloga por la plimulto de ni ol kompati homajn malfortojn. La rolo de matematika eleganteco estas, ke iom da eleganteco faras programojn pli facile kompreneblaj. Sed ne ĉio temas pri eleganteco.
Kaj kiam mi diras, ke lingvoj devus esti dezajnitaj por akomodi homajn malfortojn, mi ne volas diri, ke lingvoj devus esti dezajnitaj por malbonaj programistoj. En realeco, vi devus desegni programaron por la plej bonaj programistoj, sed eĉ la plej bonaj programistoj havas siajn limojn. Mi pensas, ke neniu ĝuus programi en lingvo, kie ĉiuj variabloj estis signitaj per la litero "x" kun entjeraj asignoj.
2. Desegni por vi mem kaj viaj amikoj
Se vi rigardas la historion de programlingvoj, la plej multaj el la plej bonaj lingvoj estis dezajnitaj por esti uzataj de siaj propraj aŭtoroj, kaj la plej multaj el la plej malbonaj estis desegnitaj por aliaj homoj.
Kiam lingvoj estas desegnitaj por aliaj homoj, ĝi ĉiam estas specifa grupo de homoj: homoj ne estas tiel inteligentaj kiel la kreintoj de la lingvo. Jen kiel vi ricevas langon, kiu parolas al vi. Cobol estas la plej elstara ekzemplo, sed la plej multaj lingvoj estas trempitaj de ĉi tiu spirito.
Ĝi neniel rilatas al kiom alta nivelo estas la lingvo. C estas sufiĉe malalta nivelo, sed ĝi estis kreita por esti uzata de ĝiaj aŭtoroj, tial hackers amas ĝin.
La argumento por desegni lingvojn por malbonaj programistoj estas, ke ekzistas pli da malbonaj programistoj ol bonaj. Eble ĉi tio estas tiel. Sed ĉi tiu malgranda nombro da bonaj programistoj verkas misproporcie pli da programaro.
Mia demando estas, kiel vi kreas lingvon kiu plaĉas al la plej bonaj hackers? Ŝajnas al mi, ke ĉi tiu demando estas identa al la demando kiel krei bonan programlingvon?, sed eĉ se ĝi ne estas, ĝi estas almenaŭ interesa demando.
3. Donu al la programisto kiel eble plej multe da kontrolo
Multaj lingvoj (precipe tiuj destinitaj por aliaj homoj) agas kiel vartistinoj: ili provas averti vin pri aferoj, kiujn ili opinias, ke ili ne utilos al vi. Mi prenas la malan vidon: donu al la programisto tiom da kontrolo kiel vi povas.
Kiam mi unue lernis Lisp, kion mi plej ŝatis estis ke ni parolis kiel egaluloj. En la aliaj lingvoj, kiujn mi lernis ĝis tiam, estis lingvo, kaj estis mia programo en tiu lingvo, kaj ili ekzistis tute aparte. Sed en Lisp, la funkcioj kaj makrooj, kiujn mi skribis, estis la samaj, en kiuj la lingvo mem estis skribita. Mi povus reverki la lingvon mem, se mi volus. Ĝi havis la saman alogon kiel malfermkoda programaro.
4. Mallongeco estas la fratino de talento
Koncizeco estas subtaksata kaj eĉ malestimata. Sed se vi rigardas en la korojn de piratoj, vi vidos, ke ili vere ŝatas koncizecon. Kiom da fojoj vi aŭdis, ke piratoj paroli ame pri kiel, ekzemple, en APL, ili povas fari mirindajn aferojn per nur kelkaj linioj de kodo? Mi supozas, ke vere inteligentaj homoj vere ŝatas atenti ĉi tion.
Mi kredas, ke preskaŭ ĉio, kio mallongigas programojn, estas bona. Devus ekzisti multe da bibliotekaj funkcioj, ĉio, kio povas esti implicita, estu tiel; sintakso estu pli konciza; eĉ entaj nomoj estu mallongaj.
Kaj ne nur programoj estu mallongaj. Manlibroj ankaŭ devus esti mallongaj. Bona parto de la manlibroj estas plena de klarigoj, malgarantioj, avertoj kaj specialaj kazoj. Se vi bezonas mallongigi la manlibron, la plej bona elekto estas korekti la lingvon, kiu postulas tiom da klarigo.
5. Rekonu kio estas hakado
Multaj homoj ŝatus, ke hakado estu matematiko, aŭ almenaŭ io simila al scienco. Mi pensas, ke hakado estas pli kiel arkitekturo. Arkitekturo temas pri fiziko en tio, ke arkitekto bezonas projekti konstruaĵon, kiu ne falos, sed la vera celo de arkitekto estas krei bonegan konstruaĵon, ne fari malkovrojn en la kampo de statiko.
Kion amas piratoj estas krei bonegajn programojn. Kaj mi pensas ke, almenaŭ en niaj propraj pensoj, ni memoru, ke verki bonegajn programojn estas mirinda afero, eĉ kiam tiu laboro ne facile tradukiĝas en la kutiman intelektan valuton de sciencaj artikoloj. De intelekta vidpunkto, estas same grave desegni lingvon, kiun programistoj amos, kiel desegni teruran, kiu enkorpigas ideon pri kiu vi povas eldoni artikolon.
Malfermaj Problemoj
1. Kiel organizi grandajn bibliotekojn?
Bibliotekoj fariĝas grava parto de programlingvoj. Ili fariĝas tiel grandaj, ke ĝi povas esti danĝera. Se necesas pli longe trovi funkcion en biblioteko, kiu faras tion, kion vi bezonas, ol skribi tiun funkcion mem, tiam la tuta kodo faras nenion krom fari vian manlibron pli dika. (La manlibroj de Symbolics estis ekzemplo de tio.) Do ni devos solvi la bibliotekan organizan problemon. Ideale, desegni ilin por ke la programisto povu diveni, kiu biblioteka funkcio taŭgas.
2. Ĉu homoj vere timas prefiksan sintakson?
Ĉi tio estas malferma problemo en la senco, ke mi pensas pri ĝi dum pluraj jaroj kaj ankoraŭ ne konas la respondon. Prefiksa sintakso ŝajnas al mi tute natura, krom eble pro ĝia uzo en matematiko. Sed povas esti, ke granda parto de la malpopulareco de Lisp estas simple pro la nekonata sintakso... Ĉu ni faru ion pri tio, se vere, estas alia afero.
3. Kion vi bezonas por servila programaro?
Mi pensas, ke la plej multaj aplikaĵoj, kiuj estos skribitaj en la venontaj dudek jaroj, estos ret-aplikoj, en la senco, ke programoj loĝos sur servilo kaj komunikiĝos kun vi per tTT-legilo. Kaj por skribi tiajn aplikojn ni bezonas novajn aferojn.
Unu el tiuj aferoj estas subteno por nova maniero liberigi servilaplikojn. Anstataŭ unu aŭ du grandaj eldonoj jare, kiel labortabla programaro, servila programaro estos liberigita en serio de malgrandaj ŝanĝoj. Vi eble havas kvin aŭ dek eldonojn tage. Kaj ĉiuj ĉiam havos la lastan version.
Ĉu vi scias kiel desegni programojn por esti konserveblaj? Servila programaro devas esti desegnita por esti ŝanĝebla. Vi devus povi ŝanĝi ĝin facile, aŭ almenaŭ scii kion signifas eta ŝanĝo kaj kio estas grava.
Alia afero kiu povas esti utila en servila programaro estas, subite, kontinueco de livero. En TTT-apliko oni povas uzi ion similan akiri la efikon de rutinoj en la sennacia mondo de interretaj kunsidoj. Havi kontinuecon de provizo povas valori ĝin se la funkcio ne estas tro multekosta.
4. Kiuj novaj abstraktaĵoj restas por malkovri?
Mi ne certas kiom racia estas tiu espero, sed persone mi tre ŝatus malkovri novan abstraktadon - ion kiu povus esti same signifoplena kiel unuaklasaj funkcioj aŭ rekurso aŭ almenaŭ defaŭltaj parametroj. Eble ĉi tio estas neebla sonĝo. Tiaj aferoj ofte ne estas malkovritaj. Sed mi ne perdas esperon.
Malmulte konataj sekretoj
1. Vi povas uzi ajnan lingvon, kiun vi volas
Antaŭe, la kreado de aplikoj signifis la kreadon de labortabla programaro. Kaj en labortabla programaro estas granda antaŭjuĝo al verkado de aplikoj en la sama lingvo kiel la operaciumo. Do antaŭ dek jaroj, verki programaron ĝenerale signifis verki programaron en C. Eventuale evoluis la tradicio: aplikaĵoj ne estu skribitaj en nekutimaj lingvoj. Kaj ĉi tiu tradicio evoluis tiel longe, ke ankaŭ ne-teknikaj homoj kiel administrantoj kaj riskkapitalistoj lernis ĝin.
Servila programaro tute detruas ĉi tiun modelon. Per servila programaro vi povas uzi ajnan lingvon, kiun vi volas. Preskaŭ neniu ankoraŭ komprenas ĉi tion (precipe administrantoj kaj riskkapitalistoj). Sed iuj piratoj komprenas ĉi tion, tial ni aŭdas pri indiaj lingvoj kiel Perl kaj Python. Ni ne aŭdas pri Perl kaj Python ĉar homoj uzas ilin por verki Vindozajn aplikaĵojn.
Kion tio signifas por ni, homoj interesitaj pri programlingvodezajno, ke ekzistas ebla publiko por nia laboro.
2. Rapido venas de profilistoj
Lingvoprogramistoj, aŭ almenaŭ lingvo-efektivistoj, ŝatas skribi kompililojn kiuj generas rapidan kodon. Sed mi pensas, ke tio ne estas kio igas lingvojn rapidaj por uzantoj. Knuth notis antaŭ longe, ke rapideco dependas de nur kelkaj proplempunktoj. Kaj ĉiu, kiu provis plirapidigi programon, scias, ke oni ne povas diveni, kie estas la botelkolo. Profiler estas la respondo.
Lingvoprogramistoj solvas la malĝustan problemon. Uzantoj ne bezonas komparnormojn por funkcii rapide. Ili bezonas lingvon, kiu povas montri, kiujn partojn de ilia programo oni devas reverki. Je ĉi tiu punkto, rapideco estas necesa en la praktiko. Do eble estus pli bone, se lingvo-efektivigantoj elspezus duonon de la tempo, kiun ili pasigas optimumigante la kompililon kaj elspezus ĝin por verki bonan profililon.
3. Vi bezonas apon, kiu evoluigas vian lingvon
Ĉi tio eble ne estas la finfina vero, sed ŝajnas, ke la plej bonaj lingvoj evoluis kune kun la aplikoj en kiuj ili estis uzataj. C estis skribita de homoj kiuj bezonis sistemajn programadon. Lisp estis dizajnita delvis por simbola diferencigo, kaj McCarthy estis tiel fervora komenci ke li eĉ komencis verki diferencigajn programojn en la unua Lisp-artikolo en 1960.
Ĉi tio estas precipe bona se via aplikaĵo solvas iujn novajn problemojn. Ĉi tio puŝas vian lingvon havi novajn funkciojn, kiujn deziras programistoj. Persone, mi interesiĝas verki lingvon kiu estos bona por servilaj aplikaĵoj.
[Dum la diskuto, Guy Steele ankaŭ esprimis ĉi tiun punkton, aldonante ke la aplikaĵo ne devus konsisti el verkado de kompililo por via lingvo, krom se via lingvo estas desegnita por skribi kompililojn.]4. La lingvo devas esti taŭga por verki unufojajn programojn.
Vi scias, kion signifas unufoja programo: estas kiam vi bezonas rapide solvi iun limigitan problemon. Mi kredas, ke se vi ĉirkaŭrigardos, vi trovos multajn seriozajn programojn, kiuj komenciĝis kiel unufojaj. Mi ne surprizus se la plej multaj programoj komenciĝus kiel unufojaj. Tiel, se vi volas krei lingvon, kiu taŭgos por verki programaron ĝenerale, tiam ĝi ankaŭ taŭgu por verki unufojajn programojn, ĉar ĉi tiu estas la komenca etapo de multaj programoj.
5. Sintakso rilatas al semantiko
Tradicie oni kredas, ke sintakso kaj semantiko estas tre malsamaj aferoj. Ĉi tio povas soni ŝoka, sed ĝi ne estas. Mi pensas, kion vi volas atingi en via programo, rilatas al kiel vi esprimas ĝin.
Mi lastatempe parolis kun Robert Morris, kaj li rimarkis, ke operacianto superŝarĝado estas granda pluso por la venko de lingvoj kun infiksa sintakso. En lingvoj kun prefiksa sintakso, iu ajn funkcio, kiun vi difinas, estas fakte operatoro. Se vi volas aldoni novan tipon de nombro, kiun vi kreis, vi povas simple difini novan funkcion por aldoni ĝin. Se vi faras tion en lingvo kun infiksa sintakso, vi vidos, ke estas granda diferenco inter uzi troŝarĝitan operatoron kaj voki funkcion.
Ideoj kiuj revenas kun la tempo
1. Novaj programlingvoj
Rerigardante al la 1970-aj jaroj, estis mode evoluigi novajn programlingvojn. Ĉi tio ne estas la kazo nun. Sed mi kredas, ke servila programaro denove revenigos la modon por krei novajn lingvojn. Per servila programaro vi povas uzi ajnan lingvon, kiun vi volas, do se iu kreas lingvon, kiu ŝajnas pli bona ol la ceteraj, estos homoj, kiuj decidos uzi ĝin.
2. Tempo kundivido
Richard Kelsey elpensis ĉi tiun ideon, kies tempo denove venis kaj mi plene subtenas ĝin. Mia supozo (kaj ankaŭ tiu de Mikrosofto) estas, ke multe da komputado moviĝos de la labortablo al foraj serviloj. Alivorte, tempodividado revenis. Mi pensas, ke tio bezonos subtenon je la lingva nivelo. Ekzemple, Richard kaj Jonathan Reeves faris multe da laboro por efektivigi procezplanadon en Skemo 48.
3. Efikeco
Lastatempe ŝajnis, ke komputiloj jam estas sufiĉe rapidaj. Ni aŭdas pli kaj pli pri bajtkodo, kio almenaŭ por mi signifas, ke ni havas iom da potenco en rezervo. Sed mi pensas, ke kun servila programaro, ni ne havas ĝin. Iu devos pagi por la serviloj, kiuj funkcias la programaron, kaj la nombro da uzantoj, kiujn la servilo povas subteni per maŝino, estos dividanto de iliaj kapitalkostoj.
Mi pensas, ke efikeco gravos, almenaŭ en komputado de proplempunktoj. Ĉi tio estos speciale grava por I/O-operacioj, ĉar servilaj aplikaĵoj plenumas multajn tiajn operaciojn.
Fine, povas rezulti, ke bajtkodo ne estas la respondo. Sun kaj Mikrosofto ŝajnas iri kapon al kapo en la bajtekskoda kampo nuntempe. Sed ili faras tion ĉar bajtkodo estas oportuna loko por enigi sin en procezon, ne ĉar bajtkodo mem estas bona ideo. Povas rezulti, ke ĉi tiu tuta batalo restos nerimarkita. Estus amuze.
Kaptiloj kaj kaptiloj
1. Klientoj
Ĉi tio estas nur supozo, sed la solaj aplikoj kiuj profitos estas tiuj, kiuj estas tute servilaj. Desegni programaron, kiu funkcias laŭ la supozo, ke ĉiuj havos klienton, estas kiel desegni socion bazitan sur la supozo, ke ĉiuj estos honestaj. Nepre estus oportune, sed vi devas supozi, ke ĝi neniam okazos.
Mi pensas, ke estos rapida kresko de ret-ebligitaj aparatoj, kaj ni povas supozi, ke ili subtenos bazajn html-ojn kaj formojn. Ĉu vi havas retumilon en via telefono? Ĉu via PalmPilot havos telefonon? Ĉu via rubusujo havos pli grandan ekranon? Ĉu vi povos aliri la Interreton de via gameboy? De via horloĝo? Mi ne scias. Kaj mi ne devos ekscii, ĉu mi vetas, ke ĉio estos sur la servilo. Estas nur multe pli fidinda havi ĉiujn cerbojn sur la servilo. .
2. Objekt-orientita programado
Mi rimarkas, ke ĉi tio estas polemika deklaro, sed mi ne pensas, ke OOP estas tiom grava. Mi pensas, ke ĉi tio estas taŭga paradigmo por specifaj aplikoj, kiuj bezonas specifajn datumstrukturojn, kiel fenestraj sistemoj, simulaĵoj, CAD-sistemoj. Sed mi ne komprenas kial ĝi taŭgu por ĉiuj programoj.
Mi pensas, ke homoj en grandaj kompanioj amas OOP, parte, ĉar ĝi faras multajn aferojn, kiuj aspektas kiel laboro. Kio nature povus esti reprezentita kiel, ekzemple, listo de entjeroj, nun povas esti reprezentita kiel klasĉambro kun ĉiaj skafaldoj, tumulto.
Alia alloga trajto de OOP estas, ke metodoj donas al vi iom da efiko de unuaklasaj funkcioj. Sed ĉi tio ne estas novaĵo por Lisp-programistoj. Kiam vi havas verajn unuaklasajn funkciojn, vi povas simple uzi ilin en ajna maniero, kiu konvenas al la tasko, anstataŭ puŝi ĉion en kaldronon de klasoj kaj metodoj.
Mi pensas, kion tio signifas por lingvodezajno, ke vi ne devus enigi OOP tro profunde en ĝin. Eble la respondo estas proponi pli ĝeneralajn, fundamentajn aferojn, kaj lasi homojn desegni iujn ajn objektosistemojn kiel bibliotekojn.
3. Dezajno de komitato
Se via lingvo estas desegnita de komitato, tiam vi estas kaptita, kaj ne nur pro kialoj, kiujn ĉiuj konas. Ĉiuj scias, ke komitatoj emas krei malplenajn, malkonsekvencajn lingvajn dezajnojn. Sed mi pensas, ke la granda danĝero estas, ke ili ne riskas. Kiam unu persono respondecas, li riskas, kiujn la komitato neniam konsentus preni.
Ĉu vi bezonas riski por krei bonan lingvon? Multaj homoj povus suspekti, ke lingvodezajno estas kie vi devas resti sufiĉe proksime al tradicia saĝo. Mi vetas, ke tio ne estas la kazo. En ĉio alia, homoj faras, la rekompenco estas proporcia al la risko. Do kial lingvodezajno estu malsama?
fonto: www.habr.com