Vedúca filozofia
1. Programovacie jazyky pre ľudí
Programovacie jazyky sú spôsob, akým komunikujú ľudia s počítačmi. Počítač bude rád komunikovať v akomkoľvek jazyku, ktorý nie je nejasný. Dôvod, prečo máme vysokú úroveň jazykov, je ten, že ľudia sa nedokážu vyrovnať s jazykmi strojov. Podstata programovacích jazykov spočíva v tom, aby sme ochránili naše krehké ľudské mozgy pred zahltením množstvom detailov.
Architekti vedia, že niektoré problémové navrhovania sú viac praktické ako iné. Jedným z najjasnejších a najabstraktnejších problémov dizajnu je navrhovanie mostov. V tomto prípade je vašou úlohou preklenúť požadovanú vzdialenosť s čo najmenším množstvom materiálu. Na opačnom konci spektra je navrhovanie stoličiek. Návrhári stoličiek musia tráviť svoj čas premýšľaním o ľudských pozadiach.
Vývoj softvéru má podobné rozlíšenie. Navrhovanie algoritmov na smerovanie dát cez sieť je dobrý, abstraktný problém, ako navrhovanie mostov. Zatiaľ čo navrhovanie programovacích jazykov je podobné navrhovaniu stoličiek: musíte sa vyrovnať s ľudskými slabosťami.
Väčšina z nás to ťažko chápe. Navrhovanie elegantných matematických systémov znie pre väčšinu z nás oveľa atraktívnejšie ako ustupovanie ľudským slabostiam. Úloha matematickej elegancie spočíva v tom, že určitý stupeň elegancie robí programy jednoduchšími na pochopenie. Ale elegancia nie je všetko.
A keď hovorím, že jazyky by mali byť navrhnuté s ohľadom na ľudské slabosti, nemám na mysli, že jazyky by mali byť navrhnuté pre zlých programátorov. V skutočnosti by ste mali navrhovať softvér pre najlepších programátorov, ale aj najlepší programátori majú svoje hranice. Nemyslím si, že by sa niekto rád programoval v jazyku, kde by všetky premenné boli označené písmenom „x“ s celými indexmi.
2. Navrhujte pre seba a pre svojich priateľov
Ak sa pozriete na históriu programovacích jazykov, väčšina najlepších jazykov bola navrhnutá na používanie ich autormi, zatiaľ čo väčšina najhorších bola navrhnutá pre iných ľudí.
Keď sú jazyky navrhnuté pre iných, vždy ide o konkrétnu skupinu ľudí: ľudia nie sú takí múdri ako autori jazyka. Takže dostanete jazyk, ktorý s vami hovorí zvrchnene. Cobol je najlepší príklad, ale väčšina jazykov je preniknutá týmto duchom.
Nie je to nič spoločné s tým, aký vysokoúrovňový jazyk je. C je dosť nízkoúrovňový, no bol vytvorený na používanie jeho autormi, a preto ho hackeri milujú.
Argument pre navrhovanie jazykov pre slabých programátorov je ten, že slabých programátorov je viac ako dobrých. Možno je to pravda. Ale malé množstvo dobrých programátorov píše neúmerne viac softvéru.
Zaujíma ma otázka, ako vytvoriť jazyk, ktorý sa bude páčiť najlepším hackerom? Zdá sa mi, že táto otázka je rovnaká ako otázka, ako vytvoriť dobrý programovací jazyk?, ale aj keby to nebolo tak, je to aspoň zaujímavá otázka.
3. Dajte programátorom toľko kontroly, koľko je možné
Mnohé jazyky (najmä tie, ktoré sú vytvorené pre iných) sa správajú ako pestúni: snažia sa vás varovať pred vecami, ktoré podľa nich pre vás nebudú prospešné. Ja zastávam opačný názor: dajte programátorom toľko kontroly, koľko môžete.
Keď som sa prvýkrát učil Lisp, najviac sa mi páčilo, že sme sa rozprávali ako rovní. V iných jazykoch, ktoré som sa dovtedy naučil, existoval jazyk a moja programácia v tomto jazyku, ktoré existovali celkom oddelene. Ale v Lispe funkcie a makrá, ktoré som napísal, boli také isté ako tie, na ktorých bol napísaný samotný jazyk. Mohol som preprogramovať samotný jazyk, keby som chcel. Mal rovnakú príťažlivosť ako softvér s otvoreným kódom.
4. Krátkosť je sestra talentu
Stručnosť je nedocenená a dokonca opovrhovaná. Ale ak nazriete do sŕdc hackerov, uvidíte, že veľmi milujú stručnosť. Koľkokrát ste počuli, ako hackeri s láskou hovoria o tom, že v APL môžu robiť úžasné veci s len pár riadkami kódu? Myslím, že naozaj inteligentní ľudia si to všimnú.
Myslím, že takmer všetko, čo umožňuje programy skrátiť, je dobré. Musí existovať množstvo knižničných funkcií, všetko, čo môže byť implicitné, by malo byť; syntax by mala byť väčšmi stručná; dokonca aj názvy entít by mali byť krátke.
A nie len programy by mali byť krátke. Manuály by mali byť taktiež stručné. Dobrá časť manuálov je plná vysvetlení, výhrad, varovaní a špeciálnych prípadov. Ak potrebujete skrátiť manuál, najlepšou voľbou je opraviť jazyk, ktorý vyžaduje toľko vysvetlení.
5. Uznať, čo je hackovanie
Mnohí by si priali, aby hackovanie bola matematika alebo aspoň niečo podobné prírodným vedám. Myslím, že hackovanie viac pripomína architektúru. Architektúra je spojená s fyzikou, v tom zmysle, že architekt musí navrhnúť budovu, ktorá nespadne, ale skutočným cieľom architekta je vytvoriť veľkú budovu, nie robiť objavy v oblasti statiky.
Čo hackeri milujú, je vytvárať veľké programy. A myslím si, že aspoň vo vlastných myšlienkach by sme si mali pamätať, že písať výnimočné programy je výnimočné, aj keď táto práca sa ťažko prevádza na bežnú intelektuálnu menu vedomostí. Z intelektuálneho hľadiska je rovnako dôležité vyvíjať jazyk, ktorý programátori zbožňujú, ako vytvárať zlý projekt, ktorého myšlienku môžete publikovať.
Otvorené problémy
1. Ako organizovať veľké knižnice?
Knižnice sa stávajú dôležitou súčasťou programovacích jazykov. Stávajú sa tak veľkými, že to môže byť nebezpečné. Ak trvá dlhšie nájsť funkciu v knižnici, ktorá robí to, čo potrebujete, ako napísať túto funkciu sami, potom celý kód nerobí nič iné, len zahusťuje váš manuál. (Príručky Symbolics boli tomu príkladom.) Musíme sa teda vysporiadať s problémom organizácie knižníc. Ideálne by sa mali navrhnúť tak, aby programátor mohol uhádnuť, ktorá funkcia knižnice bude vyhovovať.
2. Boja sa ľudia skutočne prefixovej syntaxe?
Je to otvorený problém v tom zmysle, že som o ňom rozmýšľal niekoľko rokov a stále neviem odpoveď. Prefixová syntaxa sa mi zdá úplne prirodzená, možno s výnimkou jej použitia v matematike. Ale môže to byť tak, že veľká časť nepopularity Lispov je len kvôli neznámej syntaxe... Je potrebné s tým niečo robiť, ak je to pravda, to je iná otázka.
3. Čo potrebujete pre serverový softvér?
Myslím, že väčšina aplikácií, ktoré budú napísané v nasledujúcich dvadsiatich rokoch, budú webovými aplikáciami, v tom zmysle, že programy budú umiestnené na serveri a budú komunikovať s vami cez webový prehliadač. A na to, aby sme napísali také aplikácie, potrebujeme nové veci.
Jednou z takých vecí je podpora nového spôsobu vydávania serverových aplikácií. Namiesto jedného alebo dvoch veľkých vydaní ročne, ako pri desktopovom softvéri, serverový softvér bude vydávaný sériou drobných zmien. Môžete mať päť alebo desať vydaní za deň. A všetci budú mať vždy najnovšiu verziu.
Viete, ako navrhovať programy tak, aby boli udržiavateľné? Serverový softvér by mal byť navrhnutý tak, aby bol schopný zmien. Musíte mať možnosť ho ľahko zmeniť, alebo aspoň vedieť, čo znamená drobná zmena a čo je dôležité.
Ešte jedna vec, ktorá môže byť užitočná v serverovom softvéri, je, prekvapivo, kontinuálnosť dodávky. V webovej aplikácii môžete použiť niečo ako , aby ste dosiahli efekt podprogramov v bezstavovom svete webových relácií. Možno stojí za to mať kontinuálnosť dodávky, ak táto možnosť nie je príliš nákladná.
4. Aké nové abstrakcie zostáva objaviť?
Nie som si istý, ako rozumná je takáto nádej, ale osobne by som veľmi chcel objaviť novú abstrakciu — niečo, čo by mohlo mať rovnaký význam ako funkcie prvej triedy alebo rekurzia, alebo aspoň predvolené argumenty. Možno je to nedosiahnuteľný sen. Takéto veci sa často neobjavujú. Ale nestrácam nádej.
Malo známe tajomstvá
1. Môžete použiť akýkoľvek jazyk, aký chcete
Kedysi sa pod tvorbou aplikácií rozumelo vytváranie desktopového softvéru. A v desktopovom softvéri je veľký dôraz na písanie aplikácií v tom istom jazyku, aký má operačný systém. Pred desiatimi rokmi písanie softvéru vo všeobecnosti znamenalo písanie softvéru v C. Nakoniec sa tradícia vyvinula: aplikácie nemusia byť napísané v nezvyčajných jazykoch. A táto tradícia sa vyvíjala tak dlho, že aj netechnickí ľudia, ako sú manažéri a rizikoví kapitalisti, sa to naučili.
Serverový softvér úplne ničí tento model. So serverovým softvérom môžete vziať akýkoľvek jazyk, aký chcete. Takmer nikto to ešte nechápe (najmä manažéri a rizikoví kapitalisti). Ale niektorí hackeri to chápu, a preto sme počuli o takých indie jazykoch ako Perl a Python. Nezaznamenávame Perl a Python, pretože ich ľudia používajú na písanie aplikácií pre Windows.
Čo to znamená pre nás, ľudí, ktorých zaujíma návrh programovacích jazykov, že existuje potenciálna verejnosť pre našu prácu.
2. Rýchlosť prichádza z profilerov
Vývojári jazyka alebo aspoň jeho realizátori radi píšu kompilátory, ktoré generujú rýchly kód. Ale myslím, že to nie je to, čo robí jazyky rýchlymi pre používateľov. Knuth dávno poznamenal, že rýchlosť závisí len od niekoľkých úzkych miest. A každý, kto sa snažil urýchliť program, vie, že nemôže uhádnuť, kde je úzke miesto. Profiler je odpoveď.
Vývojári jazyka sa nezaoberajú tou správnou problematikou. Používateľom nezáleží na tom, aby benchmarky fungovali rýchlo. Potrebujú jazyk, ktorý dokáže ukázať, ktoré časti ich programu by sa mali prepisovať. V túto chvíľu je rýchlosť praktická. Možno by bolo lepšie, keby implementátori jazyka strávili polovicu času, ktorý venujú optimalizácii kompilátora, jeho písaním dobrého profilovača.
3. Potrebujete aplikáciu, ktorá posunie váš jazyk dopredu
Možno to nie je konečná pravda, ale zdá sa, že najlepšie jazyky sa vyvíjali spolu s aplikáciami, v ktorých boli použité. C bol vytvorený ľuďmi, ktorí potrebovali systémové programovanie. Lisp bol vyvinutý čiastočne na symbolické diferenciovanie; McCarthy sa nemohol dočkať a začal písať programy na diferenciovanie už v prvom dokumente o Lisp zo roku 1960.
Je to obzvlášť dobré, ak vaša aplikácia rieši niektoré nové problémy. To podnecuje váš jazyk k tomu, aby mal nové funkcie, ktoré programátori potrebujú. Osobne ma zaujíma, písať jazyk, ktorý bude dobrý pre serverové aplikácie.
[Počas diskusie Guy Steele vyjadril tento pocit, dodávajúc, že aplikácia by sa nemala obmedzovať na písanie kompilátora pre váš jazyk, pokiaľ váš jazyk nie je určený na písanie kompilátorov.]
4. Jazyk by mal byť vhodný na písanie jednorazových programov.
Viete, čo znamená jednorazový program: je to, keď musíte rýchlo vyriešiť nejakú konkrétnu úlohu. Predpokladám, že ak sa pozriete okolo seba, nájdete množstvo závažných programov, ktoré začínali ako jednorazové. Nebol by som prekvapený, ak by väčšina programov začínala ako jednorazové. Takže, ak chcete vytvoriť jazyk, ktorý bude vhodný na písanie softvéru všeobecne, mal by byť aj vhodný na písanie jednorazových programov, pretože to je počiatočná fáza mnohých programov.
5. Syntax je spojená so sémantikou
Tradične sa považuje, že syntax a sémantika sú veľmi odlišné veci. Možno to znie šokujúco, ale nie je to tak. Myslím, že to, čo chcete získať vo vašom programe, súvisí s tým, ako to vyjadrujete.
Nedávno som hovoril s Robertom Morrisom a poznamenal, že preťažovanie operátorov je veľkým plusom pre víťazstvo jazykov s infixovým syntaktickým rámcom. V jazykoch s prefixovým syntaktickým rámcom je akákoľvek funkcia, ktorú definujete, vlastne operátorom. Ak chcete pridať nový typ čísla, ktorý ste vymysleli, jednoducho môžete definovať novú funkciu na jeho pripojenie. Ak to urobíte v jazyku s infixovým syntaktickým rámcom, uvidíte, že medzi použitím preťaženého operátora a volaním funkcie je obrovský rozdiel.
Nápady, ktoré sa časom vracajú
1. Nové programovacie jazyky
Pohľadom do 70. rokov bolo moderné vyvíjať nové programovacie jazyky. Teraz to už nie je tak. Ale myslím si, že serverový softvér opäť prinesie módu vytvárania nových jazykov. So serverovým softvérom môžete používať akýkoľvek jazyk, ktorý chcete, takže ak niekto vytvorí jazyk, ktorý sa javí lepší ako ostatné, budú ľudia, ktorí sa rozhodnú ho používať.
2. Rozdelenie času
Richard Kelsey predstavil túto myšlienku, ktorej čas sa opäť dostavil, a ja ju plne podporujem. Môj predpoklad (a Microsoft tiež) je, že mnoho výpočtov sa presunie z desktopov na vzdialené servery. Inými slovami, rozdelenie času sa vrátilo. Myslím, že na úrovni jazyka bude potrebná jeho podpora. Napríklad Richard a Jonathan Reeves vykonali veľa práce na implementácii plánovania procesov v Schemove 48.
3. Efektívnosť
Nedávno sa zdalo, že počítače sú už dosť rýchle. Čoraz častejšie počujeme o bajtovom kóde, čo pre mňa znamená, že máme výkon v zásobe. Ale myslím, že so serverovým softvérom tento výkon nemáme. Niekto bude musieť zaplatiť za servery, na ktorých beží softvér, a počet používateľov, ktorých server môže udržať na jednu mašinu, bude deliteľom ich kapitálových nákladov.
Myslím, že efektívnosť bude mať význam, aspoň v úzkych miestach výpočtov. Osobitne dôležité to bude pre operácie vstupu-výstupu, pretože serverové aplikácie vykonávajú množstvo takýchto operácií.
Nakoniec sa môže ukázať, že bytecode nie je východisko. Sun a Microsoft sa momentálne zdá, že zápasia tvárou v tvár na poli bytecode. Ale robia to, pretože bytecode je pohodlné miesto na vtesnanie sa do procesu, nie preto, že by bytecode bol sám osebe dobrý nápad. Môže sa ukázať, že celá táto bitka prejde bez povšimnutia. Bolo by to zábavné.
Pasce a nástrahy
1. Klienti
Toto je len domnienka, ale predpokladám, že vyhrajú iba tie aplikácie, ktoré budú úplne serverové. Navrhnúť softvér, ktorý funguje na predpoklade, že každý bude mať váš klient, je ako vytvárať spoločnosť založenú na predpoklade, že všetci budú čestní. To by určite bolo pohodlné, ale musíte uznať, že to sa nikdy nestane.
Myslím, že sa rýchlo zvýši počet zariadení s prístupom na web a je rozumné predpokladať, že budú podporovať základný HTML a formuláre. Máte prehliadač na telefóne? Bude telefon vo vašom PalmPilote? Bude mať váš blackberry väčší displej? Budete mať možnosť pripojiť sa na internet zo svojho gameboya? Z vašich hodiniek? Neviem. A nemusím to vedieť, ak tipujem, že všetko bude na serveri. Je jednoducho oveľa spoľahlivejšie mať všetku inteligenciu na serveri.
2. Objektovo orientované programovanie
Chápem, že ide o kontroverzné tvrdenie, ale nemyslím si, že OOP je niečo dôležité. Myslím, že je to vhodná paradigma pre konkrétne aplikácie, ktoré potrebujú špecifické dátové štruktúry, ako sú systémové okná, simulácie, CAD systémy. Ale nerozumiem, prečo by mala byť vhodná pre všetky programy.
Myslím, že ľudia vo veľkých spoločnostiach majú OOP radi, čiastočne preto, že to poskytuje množstvo toho, čo vyzerá ako práca. To, čo sa prirodzene môže predstaviť ako napríklad zoznam celých čísel, sa teraz môže predstaviť ako trieda so všetkými druhmi konštrukcií, s hlukom a zhonom.
Ďalšou atraktívnou vlastnosťou OOP je, že metódy vám dávajú určitý efekt funkcií prvého rádu. Ale to nie je novinka pre programátorov v Lispe. Keď máte skutočné funkcie prvého rádu, môžete ich jednoducho používať akýmkoľvek spôsobom, ktorý zodpovedá danej úlohe, namiesto toho, aby ste všetko tlačili do šablóny tried a metód.
Myslím si, že to pre jazykový dizajn znamená, že by ste nemali príliš hlboko vkladať OOP do neho. Možno je odpoveďou ponúknuť viac všeobecné, základné veci a nechať ľudí projektovať akékoľvek objektové systémy v podobe knižníc.
3. Návrh výborom
Ak váš jazyk navrhuje výbor, ste v pasci, a to nie len z dôvodov, ktoré sú všetkým známe. Je známe, že výbory majú tendenciu vytvárať hrbatý, nekonzistentný dizajn jazyka. Ale myslím, že väčšie nebezpečenstvo spočíva v tom, že nemenia riziká. Keď je v čele jedna osoba, preberá riziká, ktoré by výbor nikdy neprijal.
Je potrebné riskovať, aby sa vytvoril dobrý jazyk? Mnohí ľudia môžu podozrievať, že návrh jazyka je to, kde by ste sa mali držať dosť blízko k tradičnej múdrosti. Môžem sa hádať, že to nie je pravda. Vo všetkom ostatnom, čo robia ľudia, je odmena proporcionálna riziku. Tak prečo by to malo byť iné pri návrhu jazykov?
Zdroj: habr.com
