Řídící filozofie
1. Programovací jazyky pro lidi
Programovací jazyky jsou způsob, jakým lidé komunikují s počítači. Počítač bude rád komunikovat v jakémkoli jazyce, který není nejednoznačný. Důvodem, proč máme vysoce úrovňové jazyky, je to, že lidé si nemohou poradit s jazykem strojů. Podstatou programovacích jazyků je ochránit náš křehký lidský mozek před přetížením obrovským množstvím detailů.
Architekti vědí, že některé návrhářské problémy jsou více praktické než jiné. Některé z nejjasnějších a nejobecnějších návrhářských problémů jsou návrh mostů. V tomto případě spočívá vaše práce v pokrytí požadované vzdálenosti co nejmenším množstvím materiálu. Na druhém konci spektra je návrh židlí. Návrháři židlí musí trávit svůj čas přemýšlením o lidských pozadích.
Vývoj softwaru má podobné odlišení. Návrh algoritmů pro směrování dat v síti je dobrý, abstraktní problém, stejně jako návrh mostů. Naproti tomu návrh programovacích jazyků je podobný návrhu židlí: musíte se vyrovnávat s lidskými slabostmi.
Většině z nás je těžké to přijmout. Návrh elegantních matematických systémů zní mnohem přitažlivěji pro většinu z nás, než pokoušet se vyhovět lidským slabostem. Role matematické elegance spočívá v tom, že určitý stupeň elegance činí programy snáze pochopitelnými. Ale elegance není jediným faktorem.
A když říkám, že jazyky by měly být navrženy s ohledem na lidské slabosti, nemyslím tím, že jazyky by měly být navrženy pro špatné programátory. Ve skutečnosti byste měli navrhovat software pro nejlepší programátory, ale i ti nejlepší programátoři mají své meze. Nemyslím si, že by si kdokoli užíval programování v jazyce, kde by všechny proměnné byly označovány písmenem „x“ s celočíselnými indexy.
2. Navrhujte pro sebe a pro své přátele
Pokud se podíváte na historii programovacích jazyků, většina z nejlepších jazyků byla navržena pro použití svými autory, zatímco většina těch nejhorších byla navržena pro jiné lidi.
Když jsou jazyky navrhovány pro jiné lidi, vždy to bývá specifická skupina lidí: lidé nejsou tak chytří jako tvůrci jazyka. Takže dostáváte jazyk, který s vámi mluví povzneseně. Cobol je nejvýraznějším příkladem, ale většina jazyků je tímto duchem prostoupena.
To nemá nic společného s tím, jak vysoce úrovňový jazyk je. C je dost nízkoúrovňový, ale byl vytvořen pro použití jeho autory, což je důvod, proč ho hackeři milují.
Argument pro navrhování jazyků pro špatné programátory je, že špatných programátorů je více než dobrých. Možná je to pravda. Ale malé množství dobrých programátorů píše nepoměrně více softwaru.
Zajímá mě otázka, jak vytvořit jazyk, který se bude líbit těm nejlepším hackerům? Myslím, že tato otázka je totožná s otázkou, jak vytvořit dobrý programovací jazyk?, ale i když to není tak docela, alespoň je to zajímavá otázka.
3. Dejte programátorovi tolik kontroly, kolik je možné.
Mnohé jazyky (zejména ty, které byly vytvořeny pro jiné lidi) se chovají jako chůvy: snaží se vás varovat před věcmi, které podle jejich názoru nebudou pro vás prospěšné. Jsem proti tomu: dejte programátorovi tolik kontroly, kolik můžete.
Když jsem poprvé studoval Lisp, nejvíce se mi líbilo, že jsme si povídali jako rovný s rovným. V jiných jazycích, které jsem do té doby studoval, byl jazyk a má program v tomto jazyce a tyto dvě věci existovaly docela odděleně. Ale v Lispu byly funkce a makra, které jsem napsal, stejně jako ty, na kterých byl samotný jazyk napsán. Mohl jsem přepsat samotný jazyk, pokud bych chtěl. Měl stejnou přitažlivost jako software s otevřeným kódem.
4. Stručnost je sestra talentu.
Stručnost je podceňována a dokonce opovrhována. Ale pokud nakouknete do srdcí hackerů, uvidíte, že mají stručnost velmi rádi. Kolikrát jste slyšeli, jak hackeři s láskou hovoří o tom, že například v APL mohou dělat úžasné věci s pouhými pár řádky kódu? Myslím, že skutečně chytrí lidé si to ve skutečnosti uvědomují.
Myslím, že téměř všechno, co umožňuje zkracovat programy, je dobré. Mělo by existovat mnoho knihovních funkcí, vše neexplicitní by mělo takové být; syntaxe by měla být většinou stručná; dokonce i názvy entit by měly být krátké.
A nejen programy by měly být krátké. Manuály by také měly být stručné. Velká část manuálů je zaplněna vysvětlivkami, upozorněními, varováními a zvláštními případy. Pokud potřebujete zkrátit manuál, nejlepší volbou je opravit jazyk, který vyžaduje tolik vysvětlení.
5. Přiznejte si, co je to hacking.
Mnoha lidem by se líbilo, kdyby hacking byl matematikou nebo alespoň něčím, co se podobalo přírodním vědám. Myslím, že hacking je spíše jako architektura. Architektura souvisí s fyzikou v tom smyslu, že architekt musí navrhnout budovu, která nespadne, ale skutečným cílem architekta je vytvořit skvělou budovu, nikoli objevovat v oblasti statiky.
Co hackeři milují, je vytváření skvělých programů. A myslím, že alespoň ve svých vlastních myšlenkách bychom měli mít na paměti, že psaní úžasných programů je skvělé i při tom, že tato práce se těžko přetváří do běžné intelektuální měny vědeckých prací. Z intelektuálního hlediska je neméně důležité jak vyvíjet jazyk, který programátoři zamilují, tak i vytvářet hrůzostrašný, hmatatelný koncept, o kterém můžete publikovat článek.
Otevřené problémy
1. Jak organizovat velké knihovny?
Knihovny se stávají důležitou součástí programovacích jazyků. Stávají se natolik rozsáhlými, že to může být riskantní. Pokud trvá déle najít v knihovně funkci, která splňuje vaše potřeby, než napsat tuto funkci samostatně, pak celý kód pouze rozšiřuje váš manuál. (Případ Symbolics byl toho příkladem.) Budeme tedy muset vyřešit problém s organizací knihoven. Ideálně by měly být navrženy tak, aby programátor mohl snadno uhodnout, která funkce knihovny je vhodná.
2. Jsou lidé skutečně vystrašeni prefixovou syntaxi?
Je to otevřený problém v tom smyslu, že jsem o něm přemýšlel několik let a stále neznám odpověď. Prefixová syntaxe se mi zdá naprosto přirozená, možná s výjimkou jejího použití v matematice. Ale může být, že většina nepopularity Lispu je prostě kvůli neznámé syntaxi... Měli bychom s tím něco dělat, pokud je to pravda, to je jiná otázka.
3. Co potřebujete pro serverový software?
Myslím, že většina aplikací, které budou napsány v příštích dvaceti letech, budou webovými aplikacemi, v tom smyslu, že programy budou umístěny na serveru a budou s vámi komunikovat prostřednictvím webového prohlížeče. A abychom napsali takové aplikace, potřebujeme nové věci.
Jedna z těchto věcí je podpora nového způsobu vydávání serverových aplikací. Místo jednoho nebo dvou velkých vydání ročně, jako u desktopového softwaru, bude serverový software vydáván sérií drobných změn. Můžete mít pět nebo deset vydání denně. A všichni budou mít vždy poslední verzi.
Víte, jak navrhovat programy, aby byly udržovatelné? Serverový software by měl být navržen tak, aby byl adaptabilní. Měli byste mít možnost snadno jej měnit, nebo alespoň vědět, co znamená drobná změna a co je důležité.
Další věc, která může být užitečná v serverovém softwaru, je, překvapivě, nepřetržitost dodávky. Ve webové aplikaci můžete použít něco jako , abyste získali efekt podprogramů v beztížném světě webových relací. Možná, že nepřetržitost dodávky stojí za to, pokud tato možnost nebude příliš nákladná.
4. Jaké nové abstrakce zbývá objevit?
Nejsem si jistý, jak rozumná je taková naděje, ale osobně bych velmi chtěl otevřít novou abstrakci — něco, co by mohlo mít stejně velký význam jako funkce prvního řádu, rekurze, nebo alespoň výchozí parametry. Možná je to nesplnitelný sen. Takové věci se často neobjevují. Ale neztrácím naději.
Málo známá tajemství
1. Můžete použít jakýkoli jazyk, jaký chcete
Dříve se pod vytvářením aplikací rozuměl vývoj desktopového softwaru. A u desktopového softwaru je velký důraz kladen na psaní aplikací ve stejném jazyce, jaký používá operační systém. Před deseti lety znamenal vývoj softwaru obecně psaní softwaru v jazyce C. Nakonec se tradice vyvinula: aplikace nemusí být psány v neobvyklých jazycích. A tato tradice se vyvíjela tak dlouho, že to začali chápat i netechnické osoby, jako jsou manažeři a rizikoví investoři.
Serverový software tuto model úplně ničí. Se serverovým softwarem můžete použít jakýkoli jazyk, jaký chcete. Téměř nikdo to ještě nechápe (zejména manažeři a rizikoví investoři). Ale někteří hackeři to chápou, proto slyšíme o takových indie jazycích jako Perl a Python. Neslyšíme o Perlu a Pythonu, protože lidé je používají k psaní aplikací pro Windows.
Co to znamená pro nás, lidi zajímající se o návrh programovacích jazyků, je, že existuje potenciální publikum pro naši práci.
2. Rychlost přichází z profilerů
Vývojáři jazyků nebo alespoň jeho implementátoři rádi píší kompilátory, které generují rychlý kód. Ale myslím si, že to není to, co činí jazyky rychlé pro uživatele. Knuth už dávno poznamenal, že rychlost závisí pouze na několika úzkých místech. A každý, kdo se snažil zrychlit program, ví, že nemůžeš uhádnout, kde to úzké místo je. Profiler je odpověď.
Vývojáři jazyka neřeší ten správný problém. Uživatelé nepotřebují, aby benchmarky pracovaly rychle. Potřebují jazyk, který může ukázat, které části jejich programu je třeba přepsat. V tuto chvíli je rychlost potřebná v praxi. Možná by bylo lepší, kdyby vykonavatelé jazyka strávili polovinu času, který věnují optimalizaci kompilátoru, jehož psaním a místo toho se zaměřili na psaní dobrého profileru.
3. Potřebujete aplikaci, která posune váš jazyk vpřed
Možná to není konečné pravda, ale zdá se, že nejlepší jazyky se vyvíjely spolu s aplikacemi, ve kterých byly použity. C byl napsán lidmi, kteří potřebovali systémové programování. Lisp byl částečně vyvinut pro symbolické diferenciace, McCarthy byl tak netrpělivý, že začal psát diferenciální programy dokonce v prvním dokumentu o Lispu v roce 1960.
To je obzvlášť dobré, pokud vaše aplikace řeší nějaké nové problémy. To nutí váš jazyk mít nové schopnosti, které programátoři potřebují. Osobně mě zajímá psát jazyk, který bude dobrý pro serverové aplikace.
[Během diskuze také Guy Steele vyjádřil tuto myšlenku, přičemž dodal, že aplikace by neměla zahrnovat pouze psaní kompilátoru pro váš jazyk, pokud váš jazyk není určen pro psaní kompilátorů.]
4. Jazyk by měl být vhodný pro psaní jednorázových programů.
Víte, co znamená jednorázový program: je to, když potřebujete rychle vyřešit nějaký omezený úkol. Domnívám se, že pokud se rozhlédnete, najdete mnoho vážných programů, které začínaly jako jednorázové. Nebudu se divit, pokud většina programů začínala jako jednorázové. Takže, pokud chcete vytvořit jazyk, který bude vhodný pro psaní softwaru obecně, měl by být také vhodný pro psaní jednorázových programů, protože to je počáteční fáze mnoha programů.
5. Syntaktika souvisí se sémantikou
Tradičně se považuje, že syntaxe a sémantika jsou silně odlišné věci. Možná to zní šokující, ale není tomu tak. Myslím, že to, co chcete dosáhnout ve vaší aplikaci, souvisí s tím, jak to vyjadřujete.
Nedávno jsem hovořil s Robertem Morrisem a on poznamenal, že přetížení operátorů je velkým plusem pro jazyky s infixní syntaxí. V jazycích s prefixní syntaxí je jakákoliv funkce, kterou definujete, v podstatě operátorem. Pokud chcete sečíst nový typ čísla, které jste vymysleli, můžete jednoduše definovat novou funkci pro jeho přidání. Pokud to uděláte ve jazyce s infixní syntaxí, uvidíte, že mezi použitím přetíženého operátoru a voláním funkce existuje velký rozdíl.
Nápady, které se v průběhu času vracejí
1. Nové programovací jazyky
Když se ohlédnu do 70. let, bylo trendy vyvíjet nové programovací jazyky. Dnes už to tak není. Ale domnívám se, že serverový software znovu vrátí módu vytváření nových jazyků. S serverovým softwarem můžete použít jakýkoliv jazyk, jaký chcete, takže pokud někdo vytvoří jazyk, který se bude zdát lepší než ostatní, najdou se lidé, kteří se rozhodnou ho použít.
2. Časové sdílení
Richard Kelsey přišel s touto myšlenkou, jejíž čas se opět vrátil, a já ji plně podporuji. Myslím (a také Microsoft), že se mnoho výpočtů přesune z desktopů na vzdálené servery. Jinými slovy, časové sdílení se vrátilo. Myslím, že bude potřeba to podpořit na úrovni jazyka. Například Richard a Jonathan Reeves udělali mnoho práce na implementaci plánování procesů v Scheme 48.
3. Efektivita
Nedávno se zdálo, že jsou počítače dostatečně rychlé. Čím dál tím více slýcháme o bajtovém kódu, což pro mě alespoň znamená, že máme výkon v záloze. Ale myslím, že s serverovým softwarem už ho nemáme. Někdo bude muset zaplatit za servery, na kterých software běží, a počet uživatelů, které server může unést na jedno zařízení, bude děličem jejich kapitálových nákladů.
Myslím, že efektivita bude mít význam, alespoň v úzkých místech výpočtů. To bude zvlášť důležité pro operace vstupu-výstupu, protože serverové aplikace produkují mnoho takových operací.
Nakonec se může ukázat, že bytecode není řešení. Sun a Microsoft v současnosti vypadají, že se navzájem potkávají na poli bytecode. Dělají to však proto, že bytecode je pohodlné místo pro jeho integraci do procesu, a ne proto, že bytecode je sám o sobě dobrý nápad. Může se ukázat, že celá tato bitva proběhne nepozorovaně. Bylo by to vtipné.
Past a nástrahy
1. Klienti
To je jen domněnka, ale ta, že vyhrají pouze ty aplikace, které budou zcela serverové. Navrhovat software, který vychází z předpokladu, že každý bude mít vašeho klienta, je jako vytvářet společnost založenou na předpokladu, že všichni budou čestní. Bylo by to určitě pohodlné, ale musíte připustit, že to nikdy nebude.
Myslím, že dojde k rychlému nárůstu zařízení s přístupem na web, a dá se předpokládat, že budou podporovat základní HTML a formuláře. Máte prohlížeč na svém telefonu? Bude telefon v vašem PalmPilotu? Bude mít váš Blackberry větší obrazovku? Budete mít možnost připojit se k internetu ze svého gameboye? Z vašich hodin? Nevím. A nebudu se to muset dozvědět, pokud vsaďím na to, že všechno bude na serveru. Je jednoduše mnohem spolehlivější mít veškerý výkon na serveru.
2. Objektově orientované programování
Chápu, že to je kontroverzní tvrzení, ale nemyslím si, že OOP je něco důležitého. Myslím, že je to vhodná paradigma pro specifické aplikace, které potřebují konkrétní datové struktury, jako jsou okenní systémy, simulace, CAD systémy. Ale nerozumím, proč by měla být vhodná pro všechny programy.
Myslím, že lidé ve velkých firmách mají rádi OOP, částečně proto, že poskytuje mnoho toho, co vypadá jako práce. To, co může být přirozeně reprezentováno jako, řekněme, seznam celých čísel, může nyní být reprezentováno jako třída se všemi druhy stavebních lešení, se šumem a ruchy.
Další atraktivní rys OOP je, že metody poskytují jakýsi efekt funkcí prvního stupně. Ale to není novinka pro programátory v Lispu. Když máte skutečné funkce prvního stupně, můžete je prostě použít jakýmkoli způsobem, který odpovídá úkolu, místo abyste všechno vnucovali do šablony tříd a metod.
Myslím, že to znamená pro jazykový design, že do něj nemusíte příliš hluboce zabudovávat OOP. Možná je odpovědí nabízet obecnější, základní věci a nechat lidi navrhovat libovolné objektové systémy jako knihovny.
3. Navrhování výborem
Pokud váš jazyk navrhuje výbor, pak jste v pasti, a to nejen z důvodů, které jsou všem známé. Je známo, že výbory mají tendenci vytvářet hrubý, nekonzistentní jazykový design. Ale myslím, že větší nebezpečí spočívá v tom, že nepřebírají rizika. Když je v čele jedna osoba, tak přebírá rizika, které by výbor nikdy nebyl ochoten přijmout.
Musíte riskovat, abyste vytvořili dobrý jazyk? Mnoho lidí může mít podezření, že navrhování jazyků je něco, kde byste se měli držet poměrně blízko tradiční moudrosti. Mohu se hádat, že to tak není. Ve všem, co lidé dělají, je odměna úměrná riziku. Tak proč by to mělo být u navrhování jazyků jinak?
Zdroj: habr.com
