Vůdčí filozofie
1. Programovací jazyky pro lidi
Programovací jazyky jsou způsob, jakým lidé mluví s počítači. Počítač bude rád mluvit jakýmkoli jazykem, který není dvojsmyslný. Důvod, proč máme jazyky na vysoké úrovni, je ten, že lidé nezvládají strojový jazyk. Smyslem programovacích jazyků je zabránit tomu, aby naše ubohé, křehké lidské mozky nebyly zahlceny příliš mnoha detaily.
Architekti vědí, že některé konstrukční problémy jsou světštější než jiné. Některé z nejjasnějších a nejabstraktnějších konstrukčních problémů jsou konstrukce mostů. V tomto případě je vaším úkolem urazit požadovanou vzdálenost s co nejmenším množstvím materiálu. Na druhém konci spektra je design židlí. Návrháři židlí by měli trávit čas přemýšlením o zadku lidí.
Vývoj softwaru má podobný rozdíl. Navrhování algoritmů pro směrování dat přes síť je pěkný, abstraktní problém, jako navrhování mostů. Zatímco navrhování programovacích jazyků je jako navrhování židlí: musíte se vypořádat s lidskými slabostmi.
Pro většinu z nás je těžké si to uvědomit. Navrhování elegantních matematických systémů zní pro většinu z nás mnohem atraktivněji než podbízení se lidským slabostem. Úloha matematické elegance spočívá v tom, že určitý stupeň elegance usnadňuje pochopení programů. Vše ale není jen o eleganci.
A když říkám, že jazyky by měly být navrženy tak, aby vyhovovaly lidským slabostem, nemyslím tím, že by jazyky 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é limity. Nemyslím si, že by někoho bavilo programovat v jazyce, kde byly všechny proměnné značeny písmenem „x“ s celočíselnými indexy.
2. Navrhněte pro sebe a své přátele
Když se podíváte na historii programovacích jazyků, většina nejlepších jazyků byla navržena tak, aby je používali jejich vlastní autoři, a většina nejhorších byla navržena pro použití jinými lidmi.
Když jsou jazyky navrženy pro jiné lidi, je to vždy specifická skupina lidí: lidé nejsou tak chytří jako tvůrci jazyka. Takto získáte jazyk, který k vám mluví. Cobol je nejvýraznějším příkladem, ale většina jazyků je prodchnuta tímto duchem.
Nemá to nic společného s tím, jak je jazyk na vysoké úrovni. C je poměrně nízká úroveň, ale byla vytvořena pro použití jejími autory, a proto ji hackeři milují.
Argumentem pro navrhování jazyků pro špatné programátory je, že existuje více špatných programátorů než dobrých. Možná je to tak. Ale tento malý počet dobrých programátorů píše nepoměrně více softwaru.
Moje otázka zní, jak vytvoříte jazyk, který osloví ty nejlepší hackery? Zdá se mi, že tato otázka je totožná s otázkou, jak vytvořit dobrý programovací jazyk?, ale i kdyby tomu tak nebylo, je to přinejmenším zajímavá otázka.
3. Poskytněte programátorovi co největší kontrolu
Mnoho jazyků (zejména těch, které jsou určeny pro jiné lidi) se chová jako chůvy: snaží se vás varovat před věcmi, o kterých si myslí, že pro vás nebudou užitečné. Zastávám opačný názor: dejte programátorovi co největší kontrolu.
Když jsem se poprvé naučil Lisp, nejvíc se mi líbilo, že jsme mluvili jako rovnocenní. V ostatních jazycích, které jsem se do té doby naučil, existoval jazyk a v tomto jazyce byl můj program a existovaly zcela odděleně. Ale v Lisp byly funkce a makra, které jsem napsal, stejné, ve kterých byl napsán samotný jazyk. Mohl bych přepsat samotný jazyk, kdybych chtěl. Měl stejnou přitažlivost jako open source software.
4. Stručnost je sestrou talentu
Stručnost je podceňována a dokonce opovrhována. Když se ale podíváte do srdcí hackerů, uvidíte, že mají opravdu rádi stručnost. Kolikrát jste slyšeli hackery mluvit laskavě o tom, jak, řekněme, APL, mohou dělat úžasné věci s pouhými několika řádky kódu? Myslím, že opravdu chytří lidé tomu rádi věnují pozornost.
Věřím, že téměř vše, co zkracuje programy, je dobrá věc. Knihovních funkcí by mělo být hodně, mělo by tomu tak být vše, co může být implicitní; syntaxe by měla být stručnější; 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 krátké. Velká část příruček je plná vysvětlení, vyloučení odpovědnosti, varování a zvláštních případů. Pokud potřebujete manuál zkrátit, nejlepší možností je opravit jazyk, který vyžaduje tolik vysvětlování.
5. Rozpoznejte, co je hackování
Mnoho lidí by si přálo, aby hackování bylo matematikou nebo alespoň něčím podobným vědě. Myslím, že hackování je spíše architektura. Architektura je o fyzice v tom, že architekt potřebuje navrhnout budovu, která nespadne, ale skutečným cílem architekta je vytvořit velkou budovu, ne dělat objevy v oblasti statiky.
Co hackeři milují, je vytvářet skvělé programy. A myslím, že alespoň v našich myšlenkách bychom měli pamatovat na to, že psaní skvělých programů je skvělá věc, i když se tato práce nedá snadno převést do obvyklé intelektuální měny vědeckých prací. Z intelektuálního hlediska je stejně důležité navrhnout jazyk, který si programátoři zamilují, jako navrhnout hrozný jazyk, který ztělesňuje myšlenku, o které 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ů. Jsou tak velké, že to může být nebezpečné. Pokud nalezení funkce v knihovně, která dělá to, co potřebujete, trvá déle, než abyste tuto funkci napsali sami, pak veškerý kód nedělá nic jiného, než že váš manuál bude tlustší. (Příkladem toho byly příručky Symbolics.) Takže budeme muset vyřešit problém organizace knihovny. Ideálně je navrhněte tak, aby programátor odhadl, která funkce knihovny je vhodná.
2. Opravdu se lidé bojí syntaxe prefixů?
Toto je otevřený problém v tom smyslu, že o něm přemýšlím několik let a stále neznám odpověď. Syntaxe předpon mi připadá naprosto přirozená, snad až na její použití v matematice. Ale může to být tak, že velká část neoblíbenosti Lisp je jednoduše způsobena neznámou syntaxí... Jestli s tím máme něco dělat, je-li to pravda, je jiná věc.
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é aplikace 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 mohli psát takové aplikace, potřebujeme nové věci.
Jednou z těchto věcí je podpora nového způsobu uvolňování serverových aplikací. Místo jednoho nebo dvou velkých vydání ročně, jako je software pro stolní počítače, bude serverový software vydán v sérii malých změn. Můžete mít pět nebo deset vydání denně. A každý bude mít vždy nejnovější verzi.
Víte, jak navrhnout programy tak, aby byly udržovatelné? Serverový software musí být navržen tak, aby byl měnitelný. Měli byste to umět snadno změnit, nebo alespoň vědět, co drobná změna znamená a co je důležité.
Další věc, která může být užitečná v serverovém softwaru, je náhle kontinuita doručování. Ve webové aplikaci můžete použít něco jako získat efekt rutin v bezstavovém světě webových relací. Mít kontinuitu dodávek se může vyplatit, pokud tato funkce není příliš drahá.
4. Jaké nové abstrakce je třeba ještě objevit?
Nejsem si jistý, jak rozumná je ta naděje, ale osobně bych opravdu rád objevil novou abstrakci – něco, co by mohlo mít stejný význam jako prvotřídní funkce nebo rekurze nebo alespoň výchozí parametry. Možná je to nesplnitelný sen. Takové věci se často neodhalí. Ale neztrácím naději.
Málo známá tajemství
1. Můžete použít libovolný jazyk
Dříve tvorba aplikací znamenala tvorbu desktopového softwaru. A v desktopovém softwaru je velká zaujatost vůči psaní aplikací ve stejném jazyce jako operační systém. Před deseti lety tedy psaní softwaru obecně znamenalo psaní softwaru v jazyce C. Tradice se nakonec vyvinula: aplikace by neměly být psány v neobvyklých jazycích. A tato tradice se vyvíjela tak dlouho, že se ji naučili i netechnickí lidé, jako jsou manažeři a investoři rizikového kapitálu.
Serverový software tento model zcela zničí. Se serverovým softwarem můžete používat libovolný jazyk. Tomu zatím skoro nikdo nerozumí (zejména manažeři a venture kapitalisté). Ale někteří hackeři to chápou, a proto slyšíme o indy jazycích jako Perl a Python. O Perlu a Pythonu neslyšíme, protože je lidé používají k psaní aplikací pro Windows.
Co to znamená pro nás, lidi se zájmem o návrh programovacích jazyků, že existuje potenciální publikum pro naši práci.
2. Rychlost pochází od profilerů
Vývojáři jazyků nebo alespoň implementátoři jazyků rádi píší kompilátory, které generují rychlý kód. Ale myslím, že to není to, co dělá jazyky pro uživatele rychlými. Knuth již dávno poznamenal, že rychlost závisí jen na několika úzkých hrdlech. A každý, kdo se pokusil zrychlit program, ví, že nemůžete odhadnout, kde je úzké hrdlo. Profiler je odpověď.
Vývojáři jazyků řeší špatný problém. Uživatelé nepotřebují benchmarky, aby běželi rychle. Potřebují jazyk, který dokáže ukázat, které části jejich programu je třeba přepsat. V tomto okamžiku je v praxi potřeba rychlost. Možná by tedy bylo lepší, kdyby implementátoři jazyků strávili polovinu času, který stráví optimalizací kompilátoru, a strávili jej psaním dobrého profilovače.
3. Potřebujete aplikaci, díky které se bude váš jazyk vyvíjet
To nemusí být konečná pravda, ale zdá se, že nejlepší jazyky se vyvinuly spolu s aplikacemi, ve kterých byly použity. C bylo napsáno lidmi, kteří potřebovali systémové programování. Lisp byl navržen částečně pro symbolickou diferenciaci a McCarthy byl tak dychtivý začít, že dokonce začal psát rozlišovací programy v prvním článku Lisp v roce 1960.
To je zvláště dobré, pokud vaše aplikace řeší nějaké nové problémy. To tlačí váš jazyk k tomu, aby měl nové funkce, které programátoři chtějí. Osobně mám zájem napsat jazyk, který bude dobrý pro serverové aplikace.
[Během diskuze Guy Steele také uvedl, že aplikace by neměla spočívat v psaní kompilátoru pro váš jazyk, pokud váš jazyk není navržen pro psaní kompilátorů.]4. Jazyk musí 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ý problém. Věřím, že když se podíváte kolem sebe, najdete mnoho seriózních programů, které začaly jako jednorázové. Nedivil bych se, kdyby většina programů začínala jako jednorázové. Pokud tedy chcete vytvořit jazyk, který bude vhodný pro psaní softwaru obecně, pak by měl být vhodný i pro psaní jednorázových programů, protože to je počáteční fáze mnoha programů.
5. Syntaxe souvisí se sémantikou
Tradičně se věří, že syntaxe a sémantika jsou velmi odlišné věci. Může to znít šokovaně, ale není. Myslím, že to, čeho chcete ve svém programu dosáhnout, souvisí s tím, jak to vyjádříte.
Nedávno jsem mluvil s Robertem Morrisem a ten poznamenal, že přetížení operátorů je velkým plusem pro vítězství jazyků se syntaxí infix. V jazycích se syntaxí předpon je jakákoli funkce, kterou definujete, ve skutečnosti operátorem. Pokud chcete přidat nový typ čísla, které jste si vymysleli, můžete jednoduše definovat novou funkci pro jeho přidání. Pokud to uděláte v jazyce se syntaxí infix, uvidíte, že je velký rozdíl mezi použitím přetíženého operátoru a voláním funkce.
Nápady, které se časem vracejí
1. Nové programovací jazyky
Když se podíváme zpět do 1970. let minulého století, bylo módní vyvíjet nové programovací jazyky. Nyní tomu tak není. Ale věřím, že serverový software opět vrátí módu pro vytváření nových jazyků. Se serverovým softwarem můžete používat jakýkoli jazyk, který chcete, takže pokud někdo vytvoří jazyk, který se zdá lepší než ostatní, najdou se lidé, kteří se ho rozhodnou použít.
2. Sdílení času
S tímto nápadem přišel Richard Kelsey, jehož čas opět nadešel a já ho plně podporuji. Můj odhad (a také Microsoft) je, že hodně výpočetní techniky se přesune z desktopu na vzdálené servery. Jinými slovy, sdílení času je zpět. Myslím, že to bude vyžadovat podporu na jazykové úrovni. Například Richard a Jonathan Reeves odvedli spoustu práce na implementaci plánování procesů ve schématu 48.
3. Účinnost
Nedávno se zdálo, že počítače jsou již dostatečně rychlé. Stále častěji slyšíme o bytecode, což alespoň pro mě znamená, že máme v záloze nějakou energii. Ale myslím, že se serverovým softwarem ho nemáme. Někdo bude muset zaplatit za servery, na kterých běží software, a počet uživatelů, které může server podporovat na jeden stroj, bude dělitelem jejich kapitálových nákladů.
Myslím, že na účinnosti bude záležet, alespoň v problémech s výpočetní technikou. To bude zvláště důležité pro I/O operace, protože serverové aplikace provádějí mnoho takových operací.
Nakonec se může ukázat, že bytecode není řešení. Zdá se, že Sun a Microsoft v tuto chvíli jdou proti sobě v oblasti bajtového kódu. Ale dělají to proto, že bajtkód je vhodné místo pro vložení do procesu, ne proto, že samotný bajtkód je dobrý nápad. Může se ukázat, že celá tato bitva zůstane bez povšimnutí. Bylo by to vtipné.
Nástrahy a nástrahy
1. Klienti
To je jen odhad, ale je to tak, že jediné aplikace, které budou mít prospěch, jsou ty, které jsou zcela na straně serveru. Navrhování softwaru, který funguje na základě předpokladu, že každý bude mít zákazníka, je jako navrhování společnosti založené na předpokladu, že každý bude čestný. Určitě by to bylo pohodlné, ale musíte počítat s tím, že se to nikdy nestane.
Myslím, že bude rapidně přibývat zařízení s podporou webu a můžeme předpokládat, že budou podporovat základní html a formuláře. Máte v telefonu prohlížeč? Bude mít váš PalmPilot telefon? Bude mít vaše ostružina větší displej? Budete mít přístup k internetu ze svého gameboye? Z vašich hodinek? Nevím. A nebudu muset zjišťovat, jestli vsadím, že všechno bude na serveru. Je prostě mnohem spolehlivější mít všechny mozky na serveru. .
2. Objektově orientované programování
Uvědomuji si, že je to kontroverzní prohlášení, ale nemyslím si, že OOP je tak důležité. Myslím, že toto je vhodné paradigma pro specifické aplikace, které potřebují specifické datové struktury, jako jsou okenní systémy, simulace, CAD systémy. Ale nechápu, proč by to mělo být vhodné pro všechny programy.
Myslím, že lidé ve velkých společnostech milují OOP, částečně proto, že díky němu spousta věcí vypadá jako práce. To, co by přirozeně mohlo být reprezentováno jako, řekněme, seznam celých čísel, může být nyní reprezentováno jako třída s nejrůznějšími lešeními, shonem a shonem.
Dalším atraktivním rysem OOP je, že vám metody poskytují určitý efekt prvotřídních funkcí. Pro programátory Lisp to ale není žádná novinka. Máte-li skutečně prvotřídní funkce, můžete je jednoduše používat jakýmkoli způsobem, který vyhovuje danému úkolu, namísto toho, abyste vše tlačili do kotle tříd a metod.
Myslím, že to pro jazykový design znamená, že byste do něj neměli OOP vkládat příliš hluboko. Možná je odpovědí nabídnout obecnější, základní věci a nechat lidi navrhnout jakékoli objektové systémy jako knihovny.
3. Návrh komise
Pokud je váš jazyk navržen komisí, jste v pasti, a to nejen z důvodů, které každý zná. Každý ví, že komise mají tendenci vytvářet hrudkovité, nekonzistentní jazykové návrhy. Ale myslím, že velké nebezpečí je v tom, že neriskují. Když je ve vedení jedna osoba, podstupuje rizika, s jejichž převzetím by výbor nikdy nesouhlasil.
Potřebujete riskovat, abyste vytvořili dobrý jazyk? Mnoho lidí může mít podezření, že jazykový design je místo, kde musíte zůstat blízko tradiční moudrosti. Vsadím se, že tomu tak není. Ve všem ostatním, co lidé dělají, je odměna úměrná riziku. Proč by tedy měl být jazykový design jiný?
Zdroj: www.habr.com