Vlákno názorů k článku
František Fuka: 95 procent všeho dělám v jazyce Lua

Za 5 let udelejte rozhovor s nekym kdo tyhle programy bude muset udrzovat :-))

To je sice pravda, ale ne celá pravda. Každý program existuje v nějakém svém ekosystému – v nějaké své nice. A podle toho je také tvořen (v lepším případě).

Věci jako hry, redakční systémy pro blogování a různé agregátory googlových služeb, to není věc, která by vůbec měla předpokládanou dobu života pět let.

A naopak, věci jako enterprise systémy, bankovní systémy, databázové servery a tak, ty se nepíšou ani v Pythonu ani v lua ani v ničem podobném; resp. jejich základy se v nich nepíšou – je možné samozřejmě do nich lua integrovat a konkrétní business procesy už v lua skriptovat. Předpokládaná životnost toho konkrétního scénáře (toho lua skriptu) je typicky několik málo let, zatímco předpokládaná životnost toho systému jsou desítky let.

Lua potřebuje v podstatě jediný ekosystém: podmnožinu ANSI C. Je záměrně napsaná tak, aby šla zkompilovat i kompilátorem C++, a neznám moc implementací programovacích jazyků (psaných v C), které by šly zkompilovat nejen „hosted“ implementacemi jazyka C, ale i „freestanding“ implementacemi céčka. Lua to umí.

Její autoři jsou navíc docela silně konzervativní, a i když je Lua (jako současná implementace) záměrně napsaná tak, aby byla co nejvíc hackovatelná a tweakovatelná (a existuje spousta zajímavých patchů), tak sami provádějí pouze ty změny, které projdou docela náročným sítem. Docela pěkné je shlédnout přednášku Evolution of Lua, kde se k tomu Roberto vyjadřuje docela podrobně.

Myslím, že dnes napsaný program v jazyku Lua bude možné za čtyřicet let spustit s mnohem menší námahou než program v Pythonu nebo v Ruby.

Takhle dopředu věštit si u počítačů může dovolit jen Sibyla.

„I don't know which programming language I will use [in the year 2000], but I know its name will be Fortran.“

 – Anonymní citát z 60. let. No v čempak že se to počítají dnes ty černé díry? :-)))

Myslíte, že udržovat desetikilobajtový program je složitější, než udržovat desetimegabajtový? Skutečně?

desetikilobajtový program znamená, že veškerá logika je schována uvnitř samotného runtimu programu. takže kromě vlastního zdrojáku ještě budete muset debugovat tenhle.

Netuším, čemu přesně říkáte „samotný runtime programu“ a čím se to liší od „programu“ a co s tím má společného fakt, jak daný jazyk zachází se zdrojáky, ale že logika těžko může být mimo program, to je mi celkem jasné.

Spis mi jde o to ze tenhle ‚super duper programmer‘ si vsechno bastli sam. Persistenci, webserver, xml parser. Dokonce se chlubi ze si dela vlastni dedicnost apod… Pritom i Lua ma dobre knihovny.

Ted delam na projektu kde vetsina kodu je z 1999/2000 + udrzba a nove featury, nastesti dobre zdokumentovana Ja­va.

No tak vzhledem k tomu, že se svět ještě neshodl na tom, jaký objektový model že je vlastně nejlepší (či „nejlepší“? :-)) – na rozdíl třeba od scopingu, kde statický lexikální nakonec vyhrál na celé čáře – mi přijde, že přístup „udělám si objektový model na míru“ není až tak úplně mimo mísu. Ono to není až tak těžké a neliší se to od programování v jazycích, které mají sice objektový model, ale k němu také MOP. Pokud jde o perzistenci, je kupa projektů, které ji buď prostě musí mít vlastní (postavil byste Google search engine nad MySQL?), nebo je to jednodušší než to roubovat nad něco jiného. Taky by asi byla chyba si myslet, že František neustále všechno zbůhdarma přepisuje. Tomu nevěřím.

Me prijde ze „udělám si objektový model na míru“ je uplne mimo misu. Nejde o to si jen neco nabastlit, ale otestovat a zdokumentovat. Pro Lua existuje nekolik objektovych systemu, proc psat vlastni a nevzit uz existujici? Protoze muj program bude o 0.05% rychlejsi?

BTW a vite na cem google search engine bezi? Schvalne si zjistete proc google do mySQL dopsal clustering :-)))))

Hlavne si zjistete, proc vubec vytvoril BigTable, a k cemu je technika MapReduce. Opravdu naivni clovek si muze myslet, ze Google bezi na MySQL.

Nejde o existenci knihoven, ale o to, ze neexistuji knihovny, ktere by se nejak vyrazne kryly s tim, co pri svem programovani potrebuju. A za druhe, pri kazdem projektu ty veci vetsinou potrebuju trochu jinak. A ty projekty delam treba dva za mesic. Napsani potrebnych knihoven a jejich upravu provadim v prubehu programovani celeho toho projektu. Nestalo se vam nikdy, ze zjistite, ze nejaka knihovna neco dela jinak, nez byste chtel? Mne jo. Takze si ji v takovem pripade upravim. A velmi snadno, protoze ma maximalne par kilo (nebot dela presne to co potrebuju) a napsal jsem ji ja pred par dny…

Napriklad misto XML parseru mi vetsinou staci napsat nejake 2–3 regulerni vyrazy (respektive to co misto nich ma Lua). Vyhoda je, ze vetsinou delam na vecech, u kterych se nemusim starat o validaci vstupu.

Základní pravidlo pro klasické OOP a knihovny zní – knihovny jsou uzavřené pro změny, ovšem otevřené pro rozšiřování. Pokud není knihovna přesně ušitá na míru mým potřebám, tak ji neupravuju, ale udělám odvozenou třídu, která modifikuje chování knihovní třídy. Díky tomu vývojáři prohlubují své znalosti jednotlivých knihoven, aniž by se báli, že se ty knihovny budou měnit… knihovny tvoří hierarchickou strukturu, no a u těch méně používaných se holt musí kouknout do dokumentace. Obávám se, že lepší systém na vývoj velkých systémů zatím nebyl vynalezen.

Nějak si nejsem jistý, jestli „klasické OOP“ vůbec mělo třebas i podobná pravidla, natožpak tahle. Podívejte se do Smalltalku 80 a jeho potomků (Cincom Smalltalk, Squeak…). Zjistíte, že byl vyvinut způsobem nikoli nepodobným tomu, jaký František popisuje. :-) A to je, prosím pěkně, to „nejklasičtější“ OOP, jaké snad může být. To, co popisujete, sedí spíš na Modulu (nebo další podobné Wirthovy vynálezy) a modulární programování.

Tak možná jsem špatně použil pojem „klasické OOP“. Prostě tou zásadou, co píšu, dnes začíná každá učebnice objektového programování a design patternů. Byla to reakce na Františkův dotaz, co děláme, když zjistíme, že nějaká knihovna nedělá přesně to, co potřebujeme. Alfou a omegou dnešního programování je dělat takové knihovny, které se snadno rozšiřují a kombinují. Nikoliv modifikují.

Co to je „dnešní programování“? Máte na mysli dnešní lepení kódu? Kdo si nemůže dovolit zaplatit programátora, ten se holt musí spokojit s lepičem. Ale jejich metody bych neztotožňoval s metodami programování. Hlavním cílem programování nikdy nebylo, aby i imbecil zvládnul nějak něco vyřešit, ale danou věc vyřešit co nejefektivněji a nejelegantněji. A jestli to vyžaduje modifikaci existujícího kódu… Účel světí prostředky.

Ano, dnešní programování je z největší části o tom, mít přehled, co existuje za knihovny, frameworky, design patterny, zkrátka, co už někdo řešil přede mnou a co se stává v nějaké oblasti průmyslovým standardem. A samozřejmě také o tom, že když chci přispět vlastní knihovnou, tak jak ji tvořit (pravidlo uzavřenosti k modifikacím, otevřenosti k rozšiřování). Zásadně protestuju, abyste špičkového vývojáře, který má tyto znalosti, o kterých píšu, i když vlastního kódu za pracovní den napíše jen pár řádků, označoval za „lepiče“. Ani on se nevysmívá tomu druhému (generačně staršímu) druhu programátora, který je spíše geniálním algoritmizátorem a v jeho kódu není jediná zbytečná řádka. Oba představují vysoce náročný typ práce a oba jsou potřební, aby šel vývoj dopředu. Těch prvních je dnes ale prostě víc a je to v pořádku.

To není vysmívání se. To je konstatování faktu. Programování JE v první řadě algoritmizace, NE lepení knihoven dohromady. Ale i kdyby to mělo být bráno jako výsměch – on se totiž ten „dnešní špičkový vývojář“ nemá komu vysmívat. Kvalita toho, co on plodí, velmi silně zaostává za tím, co vzešlo od toho „generačně staršího“ druhu programátorů. Už jsem narazil na tvrzení, že „co nenajdu googlem, to jako by nebylo“. Na dnešní vývojáře se to dá parafrázovat slovy „nač není knihovna, to nejde udělat“. Takovým lidem bych se měl co vysmívat (jak jedněm, tak druhým), protože jde o evidentní atrofii jejich intelektu.

Dobrý programátor v tom pojetí, jak ho chápu já, ví, že neplatí „nač není knihovna, to nejde udělat“, ale „nač není knihovna, to bude dražší“. Mě se zkrátka líbí myšlenka, že programátoři chápou svou práci tak, že produkují především knihovny a ty pak sdílí s ostatními, ideálně s celým světem. Jednotlivé projekty jsou pak průsečíky těch knihoven, klidně za cenu částečné ztráty jejich efektivnosti. Musíte se na „efektivnost“ dívat globálně. Tvořit software dnes může „každý blbec“, jak si asi myslíte, ovšem díky tomuto kvantitativnímu skoku zase vzrostla konkurence a koncový uživatel z toho nakonec profituje. Jak je nejlépe vidět na internetových aplikacích. Uživatele nezajímá, jak efektivně pracuje programový kód, který mu něco poskytuje. Ale v této debatě nemá smysl pokračovat, začíná připomínat debatu s ševcem z 19. století o dnešní globální ekonomice. Samozřejmě, že ten švec dělal poctivé bytelné boty, které vydrží dvacet let, o tom žádná. :) Ale to je jen naprosto dílčí fakt.

A já mám kamaráda, který má tak velkou nohu, že si ty boty prostě musí nechat šít od ševce na míru. Ale možná by se měl podvolit dnešní globální ekonomice a začít chodit bos. :)

Jo, dobrý příměr. A František Fuka je prostě ten švec, co šije ty atypické programy. Našel si mezírku na trhu, která je dnes už hodně malá, a ostatní ševci, co se učili šít na osmibitech, mu můžou jen závidět. Buď mrzoutsky mumlat něco o starých zlatých časech nebo si najít prostor pro kreativitu i v tom novém systému…

Teď je otázka, jestli zadavatel potřebuje OPIMÁLNĚ VYŘEŠIT svůj problém (klasicky vyjádřeno funkcí 3 nebo 4 proměnných – čas, cena, kvalita, resp. funkcionalita), nebo zda má zájem brousit léta nějaký kód jako vzácný drahokam, což bylo možná představitelné v době, kdy se psaly programy daleko menšího rozsahu, než jsou některé dnešní.

Zaplatit si geniálního solitéra sice může být lákavé, ale jenom do té doby, než nastane potřeba projekt rozšířit nebo daného člověka z jakéhokoliv důvodu nahradit. A nejhorší situace z hlediska firmy nastává v okamžiku, kdy se takovému géniovi nechají zcela volné ruce. Sice možná zná nazpaměť každý svůj napsaný řádek, ale pokud nemá dostatek sebedisciplíny, nebude s velkou pravděpodobností existovat časem jiné řešení, než celý systém nahradit něčím jiným nebo ho kompletně přepsat. V takovém případě si géniův nadřízený zcela přirozeně položí otázku, zda neměl raději zaměstnat nějakého „lepiče“.

Myslíš LPeg? Jako „to, co místo nich má Lua“? Mně to přijde o něco (nebo o hodně?) udržovatelnější než „perlí regexpy“ přes půl řádku, a přitom člověk nemusí čekat na Perl 6 Grammars (ano, i autoři Perlu uznali, že současná syntaxe regulárních výrazů v Perlu nebyl až tak dobrý nápad :-)).

Desetimegabajtový program taky může znamenat, že je samodokumentující, protože je ukecanější. Proto ano, jeho přečtením pochopím jeho architekturu a algoritmy rychleji než louskáním desetikilového programu od matematického ge­nia.

Samodokumentující programy jsou samozřejmě fajn, ale napsáním dokumentace k desetikilobaj­tovému programu z něj těžko udělám desetimegabajtový. To by ke každé řádce kódu muselo ve zdrojovém kódu existovat tisíc řádků dokumentace! To by už možná bylo až nepřehledné. :-) TeX má, pokud se nepletu, poměr dokumentace ke kódu asi tak čtyři ku jedné (zjištěno z jeho jediného zdrojového souboru), a to je přitom docela obsáhlá.

A jaká část kódu toho desetimegabajtového programu je z klávesnice jeho vývojáře? Řekl bych, že optimistický odhad je asi tak promile. Zbytek je automaticky generovaný kód a kód knihoven. Troufám si tvrdit, že jakýkoliv autonomní problém se dá popsat strojovým kódem desítky, v krajním případě stovky kilobajtů dlouhém.

„Troufám si tvrdit, že jakýkoliv autonomní problém se dá popsat strojovým kódem desítky, v krajním případě stovky kilobajtů dlouhém.“

V tom máte nepochybně pravdu. Proto také věřím Chucku Moorovi, který říká, že dáte-li mu libovolný megabajtový program řešící nějaký problém, napíše obdobný program desetikilobajtový, který bude dělat přesně to, co potřebujete. Pokud jde o automatické generování kódu, nezapomeňte, že forthisté, lispeři a další podobná verbež (zřejmě včetně luistů) ho sice používají taky, a to v mohem dokonalejší formě (koneckonců ji vynalezli), ale nemají tu drzost započítávat generovaný kód do „zdrojového“, neboť očividně zdrojový není (a jelikož se u nich generování kódu odehrává při kompilaci, tak leckdy není ani vidět, takže není moc co měřit a započítávat).

A co tedy máte na mysli vy, když řeknete „desetimegabajtový program“ a porovnáváte ho s tím „desetikilovým“? Porovnáváme snad výsledný kód, ne? Zdrojáky se obvykle měří na řádky (my forthisté ho měříme na „skriny“ ;-).

Já? Já měl na mysli právě 10 MB ručně napsaných. To až Vy jste mě upozornil na možnost, že by někdo počítal henerovaný kód. Zdrojáky se měří na řádky, ale u projektů, které kód generují, osobně za zdroják počítám pouze velikost zdrojáků generátoru + velikost jeho vstupních dat. Generované Cčko ignoruji úplně stejně, jako meziprodukty Scheme-to-C kompilátorů a GAS assembleru uvnitř GCC.

Na mainframech existuji programy napsane v CLISTu a REXXu, ktere funguji stejne od 80.let (pokud nevite, oba jsou dynamicke skriptovaci jazyky). I kdyz je pravda, ze IBM uzkostlive dodrzuje zpetnou kompatibilitu, coz u OSS zdaleka tak dobre neplati.

Kazdopadne, pokud pointou vaseho prispevku melo byt, ze programy napsane ve skriptovacich jazycich jsou neudrzovatelne (nebo hure udrzovatelne nez C++), tak to neni pravda. Muj osobni nazor je, ze udrzovatelnost jazyka je dana v podstate jen a jen zpetnou kompatibilitou jeho implementace, to ostatni na to nema zasadni vliv.

„Na mainframech existuji programy napsane v CLISTu a REXXu, ktere funguji stejne od 80.let (pokud nevite, oba jsou dynamicke skriptovaci jazyky) I kdyz je pravda, ze IBM uzkostlive dodrzuje zpetnou kompatibilitu, coz u OSS zdaleka tak dobre neplati.“

Zase takový ignorant historie nejsem, dokonce znám i SNOBOL. :-p ;-) A pánové kolem Lua si na takovýchhle věcech dávají docela záležet, linkoval jsem už i video.

„Kazdopadne, pokud pointou vaseho prispevku melo byt, ze programy napsane ve skriptovacich jazycich jsou neudrzovatelne (nebo hure udrzovatelne nez C++), tak to neni pravda. I kdyz je pravda, ze IBM uzkostlive dodrzuje zpetnou kompatibilitu, coz u OSS zdaleka tak dobre neplati.“

Já jsem napsal pouze to, že deset kilobajtů se udržuje lépe, než deset megabajtů. Pokud tam vidíte cokoli o jazycích, tak si to tam dosazujete sám. :-) S poslední větou bezvýhradně souhlasím.

Šmarjá, ta poslední věta, se kterou souhlasím, měla být „Muj osobni nazor je, ze udrzovatelnost jazyka je dana v podstate jen a jen zpetnou kompatibilitou jeho implementace, to ostatni na to nema zasadni vliv.“ Vlepil jsem tam něco, co nedává v kontextu smysl. :D

Reagoval jsem na Bubaka, ne na vas. :-) Myslim, ze se shodneme.