Vlákno názorů k článku Omezuje prastaré ASCII dnešní programátory? od belzebub - Opravdu stupidni clanek plny nesmyslu: Nikdy sem si nevsiml...

Mně přijde jazyk bez typové kontroly jako docela nebezpečný. Mnohokrát jsem v C napsal něco jako:

if (chyba) {
        fprintf("chyba cislo %d\n", chyba);
        exit(1);
}

No, a kompilátor C je tak hodný, že dá warning. Bez typové kontroly by v tom programu vznikl latentní bug, který dlouho nikdo neodhalí ... až do chvíle, kdy daná chyba opravdu nastane.

Ti lidi, co zde píšou, jak nové programovací jazyky jsou blbost a jak všechno bylo vymyšleno v LISPu či Forthu ... jak oni vlastně řeší tento příklad --- kdy dojde k nesouladu typů na větvi programu, co se běžně nevykonává?

To píšou unit testy na všechny větve? Nebo mají tak bystrý mozek, že takovouhle chybu nikdy neudělají? (nebo v tom jejich jazyce píšou tak malé programy, že na tento problém nenarážejí? :) )

C++ templates jsou dost komplikované, ale nenapadá mě, jak ten problém statické typové kontroly řešit lépe a elegantně. Napadá to tebe?

Milý BLEK.u, zkus se někdy přemoci a zkus se třeba na ten Lisp pořádně podívat - ber to jako výzvu, zkus se vykašlat na všemožné předsudky, zkus nesrovnávat s jinými jazyky, prostě zkus ho pochopit coby matematik - kterým jakožto matfyzák aspoň trochu musíš být. Nepřemýšlej, jak bys takový a takový konstrukt jazyka C udělal v Lispu - zamysli se nad tím, jak bys daný problém řešil prostředky Lispu. Já vím, je to těžké, zvlášť když má člověk za sebou tisíce a tisíce řádků v C... Jazyky jako Lisp a Forth jsou skutečně značně odlišné od C - a to říkám jako člověk, který začal BASICem, prošel Assemblerem (v němž dělám dodnes), přes Pascal se dostal k C a C++, s nimiž jsem se potýkal minimálně 15 let (dnes už tolik ne) a jakýmsi řízením osudu se dostal k Lispu i k Forthu, kteréžto jazyky jsem z počátku nenáviděl - až do té doby, než jsem se naladil na myšlenkové pochody jejich tvůrců. A přesně u tebe vidím ty samé problémy, jaké jsem nastiňoval já kdysi - co když budu potřebovat do takového a takového kontejneru... co když budu chtít zkontrolovat typ toho a toho... No jasně - pokud k tomu člověk přistupuje takto... ale to je špatně! Člověk se u takovýchto jazyků musí dostat do situace, kdy si řekne "ale já nepotřebuji matlat se s nějakými kontejnery, já nepotřebuji matlat se s typovou kontrolou. Protože já celý ten problém můžu rozlousknout z úplně jiné strany a úplně jinými prostředky." K opravdovému pochopení jazyků jako je Lisp či Forth musí člověk zvyklý na algolské jazyky totálně překopat své myšlení, totálně překopat svůj pohled na to, jak má vypadat program, na to, co jsou data, co jsou algoritmy a na jakých úrovních spolu mají interagovat. Objektové programování je jen slaboučký odvar toho všeho - čehož důkazem mimo jiné je i to, že do obou zmíněných jazyků se dá OOP doprogramovat čistě jen prostředky těch jazyků - a tím nemyslím našvindlovat, jako třeba u C, ale skutečně doprogramovat, tj. vytvořit ideální syntaktické prostředky pro tento styl programování.
Běžný postup třeba u Pascalu nebo C při návrhu programu je analýza, návrh datových struktur a návrh operací nad těmito strukturami. To platí jak u strukturovaného, tak u objektového návrhu. U Lispu nebo u Forthu to tak ale není - tam po analýze následuje návrh lexikálních prostředků vhodných k řešení daného problému. A teprve v rámci těchto lexikálních prostředků se navrhují datové a algoritmické vazby. Jsou to vlastně metajazyky. Jestliže chci udělat databázi, nejsem omezen jen na záznam v kombinaci s polem nebo ukazatelem na tento záznam a standardní typovou kontrolou jazyka. Dotvořím si k tomu kus jazyka, kde k vlastnímu záznamu složitých dat bude použita úplně elementární entita - jako třeba spojový seznam nebo spojový seznam spojových seznamů, ale to, aby se s tím dalo elegantně pracovat, mi zajistí potřebná makra a funkce nad těmi makry už s tím budou operovat jako s elementy jazyka.

No a k těm dotazům - v podstatě jsi ty odpovědi trefil. Když píšeš v Lispu makro nebo funkci, ve Forthu slovo - tak hned jak ji napíšeš, tak si vyzkoušíš, jak funguje. Ty entity co vytváříš jsou tak jednoduché, že se to dá dělat - několikastránková funkce v C není neobvyklá - v Lispu nebo ve Forthu je to nesmysl, autor by se v tom začal ztrácet ještě v průběhu jejího psaní. Když dostaneš za úkol napsat algoritmus na výpočet determinantu matice řádu 3 Sarrusovým pravidlem, uděláš to v C jedním polem 3x3 a jednou funkcí. Ve Forthu to jedním slovem zaručeně dělat nebudeš - budeš si muset nějak syntakticky ztvárnit tu matici a nějak si elegantně zpřístupnit její obsah. Nakonec zjistíš, že tvoje myšlení je takovýmito jazyky tak z(de)formované, že až budeš dělat zase v C, tak tu chybu fakt neuděláš nikdy. A do třetice - opravdu děláš programy (nebo spíše komponenty) tak malé, že na tyto problémy nenarážíš, jelikož ten problém řešíš v těchto jazycích inkrementálně - asi jako bys někomu vysvětloval matematiku: neřekneš mu, co má udělat, aby spočetl to a to; vystvětlíš mu, co je to a to, jak se s tím pracuje, na základě této znalosti vysvětliš další věci atd. až dotyčný získá znalosti k výpočtu.
Tyhle jazyky tě nutí řešený problém nejdřív perfektně poznat. Jsou jako bystří studenti - když jsi mimo, tak tě dostanou a donutí pěkně si nabít hubu; když víš o co jde, tak ti dokážou pomoci při nalezení správného řešení.

To by mě dost zajímalo, ukaž mi někde příklady, které se dají špatně řešit procedurálními jazyky a dají se dobře řešit LISPem? V neprocedurálním programování ve škole jsem se totiž nenaučil nic (úlohy typu: "napište tento algoritmus v tomto neprocedurálním jazyce", což ovšem trvá dýl než bych ho psal v procedurálním).

Na internetu člověk o LISPu najde spoustu chvalozpěvů (nějaké dokonce přirovnávají LISP k Maxwellovým rovnicím: http://www.arcfn.com/2008/07/maxwells-equations-of-software-examined ), ovšem nepodepřených nějakými reálnými argumenty, proč by v tom bylo programovat lepší.

A programy těchto jazycích prakticky nejsou vidět (napadá mě leda Sparc konzole ve Forthu a psycholog v LISPu v Emacsu).

ten odkaz jsem dal špatně, správně má být http://www.arcfn.com/2008/07/maxwells-equations-of-software-examined.html

"Když dostaneš za úkol napsat algoritmus na výpočet determinantu matice řádu 3 Sarrusovým pravidlem, uděláš to v C jedním polem 3x3 a jednou funkcí" .....
Vím, že se to do této debaty nehodí, ale Jak se ten algoritmus zapíše v C++? Dík

Dal jsem si cas na rozmyslenou (a tajne doufal, ze odpovi nekdo za me, jak to pekne udelal Biktop), a uznavam, ze staticka typova kontrola muze nekomu chybet. Slo by trivialne namitnout, ze ten problem ale stejne neresi, protoze i kdybychom tam ten file handle meli, nemuzeme mit jistotu, ze ten soubor bude napr. otevreny.

V Common Lispu by tohle ale nebyl az takovy problem, protoze tento kratky kus kodu bychom zabalili do funkce (nebo do makra, pokuc bychom nechteli z duvodu vykonu pokazde vyhodnocovat argumenty), takze bychom ho snadno odladili zvlast. Ah, moment, ono uz to vlastne funkce je - jmenuje se error. A druha vec je, ze Common Lisp ma restarty a REPL, coz by usnadnilo reseni takoveho problemu.

Nicmene, vzpomnel jsem si na poznamku v knize Paula Grahama ANSI Common Lisp, kde srovnava Cckove a Lispove funkce. Tim, ze Lisp ma uzavery a funkce s obecnymi argumenty (tj. bez typove kontroly) dovoluje psat funkce ktere pracuji s funkcemi. Je IMHO zatim nevyresena otazka, zda takove veci vubec ve staticky typovanem jazyce jdou. A podobne problemy jeste vetsiho rozsahu maji typovane kontejnery.

Ptas se, proc to zkusit. Me presvedcila prednaska Practical Common Lisp, zejmena pak restarty. Precetl jsem si pak stejnojmennou knizku, a bylo to podnetne. Pro priklady veci, ktere nejde dobre udelat v C doporucuji knizku On Lisp a pripadne Let Over Lambda.

Hm, jeste nad tim premyslim, a skutecne, je to problem.

Filozofie C je, ze promenne maji typ, kdezto filozofie Lispu je, ze hodnoty maji typ.

To prvni prinasi moznost staticke typove kontroly, ale zabiji to moznost existence obecnych operatoru, protoze jak vypocitate vysledny typ? Ve finale se podle me nekde nemuzete vyhnout pretypovani.

To druhe sice bere moznost urcite staticke typove kontroly, ale zaroven vam to dava do ruky metaprogramatorske techniky.

Takze asi to bude, co si vybrat. Samozrejme, ten kdo metaprogramovani nezkusil, tomu asi nechybi, ale soude podle tvrzeni lidi, co znaji oboji, ozelite radeji to prvni.

Co jsem do té knihy koukal ... mně LISP přijde spíš jako write-only jazyk určený pro snadné řešení problémů, a ne jako jazyk určený pro psaní aplikací.

Silný makrojazyk ... nepřijde mi to jako výhoda pro psaní aplikací. Příklad: v Linuxu třeba najdeš volání funkce outb_p. Nicméně definici té funkce tam v arch/x86 nenajdeš. Nenajdeš ji proto, že je generovaná makrem a i její jméno je také poskládáno makrem. Někdo zjistil, že outb_p, outw_p a outl_p mají podobnou implementaci a vygeneroval ty funkce z jedné šablony makrem --- sice můžeme říct, jak to krásně faktorizoval, a jak sdílel podobný kód --- ovšem má to i podstatnou nevýhodu --- když se jako nováček neznalý Linuxového kernelu podíváš na nějaký kód volající outb_p a zeptáš se "co to volání dělá?", tak se to nedozvíš.

Pokud někdo bude do důsledků používat to metaprogramování (makra nebo eval), jak to po něm přečteš? On sám to přečte, ale jak to přečte někdo jiný?

Když chceš něco změnit v programu v C, tak to tam najdeš, snadno zjistíš jak to funguje (až na pár extrémních případů, jako výše popsaný identifikátor skládaný makrem) a změníš to. Nemusíš vůbec zkoumat, jak celý program funguje ani jakou má strukturu.

Když chceš něco změnit v programu v C++, už je to horší, už to tak snadno nepochopíš, operátory mohou být přetížené (a nevíš na co, dokud neprozkoumáš celou objektovou hierarchii), u virtuálních metod také nevíš, co se volá.

A v případě jazyků ve kterých programátor definuje vlastní lexikální strukturu, jak zjistíš, co některá část dělá? ... leda přečtením a pochopením celého toho makrosystému, co si programátor nadefinoval.

Další otázka je, jak budeš takový meta-generovaný program ověřovat. U normálních jazyků, když chceš ověřit zda o proměnných X, Y a Z platí predikát P(X,Y,Z), tak je to jednoduché --- ověříš, že P(X,Y,Z) platí na začátku, a pak si grepem najdeš všechna místa, kde se X, Y nebo Z přiřazuje, a lokálně pro každé místo ověříš, že pokud platilo P(X,Y,Z) před přiřazením, pak musí platit i po přiřazení. V momentě kdy začneš ten kód dynamicky generovat, tak už to ověříš o hodně hůř --- musíš najít všechna místa, co generují nějaký kód, zjistit, zda se náhodou nesnaží vygenerovat kód, co přiřadí do X, Y nebo Z, a pokud ano, dokázat, že všechny možné varianty kódu, co vygenerují, zachovávají predikát P.

Jiný příklad --- u normálního jazyka můžeš jednoduchou flow-control analýzou dokázat, že funkce F nesahá na proměnnou X, funkce F nebere zámek Z, atd. V momentě, kdy funkce F pouští něco, co bylo někde vygenerováno, tak to už flow-control analýzou nedokážeš.

No, je pravda, ze jsem nikdy zadny slozitejsi program v Lispu cist nemusel, tak nevim. Ale nemyslim, ze by to co pises bylo az takovy rozdil od jinych jazyku.

Predne, volani makra je uplne stejne, jako volani funkce; a vlastne ten zakladni rozdil je v tom, ze makro nevyhodnocuje argumenty. Takze podivat se, co dela dany kus kodu je stejny problem jako u funkci - staci najit definici. Vetsina maker je rozumna, takze jejich efekt je jen lokalni.

Samozrejme, jdou tam pak delat i dalsi kouzla, a i treba pomoci eval. Ale pokud se to nezneuziva, tak je to stejne komplikovane jako v C/C++.

Je to vlastne paradox, ze davas za vzor zrovna jadro, ktere pouziva dost komplikovanou (co vim) C makrologii.

Když budeš používat makra pouze k expanzi symbolů, pak to máš stejné jako C preprocesor. Vyznáš se v tom stejně jako v C programu, ale ani ti to nepřinese víc možností než C preprocesor.

Jádro Linuxu jde zkoumat takovým způsobem, že když je tam něco, co nevíš co dělá, tak si definici najdeš grepem (možná takhle projdeš několik úrovní expanzí, ale je to mechanická práce a nakonec najdeš to co chceš). Pokud ta makra pouze expandují symboly, tak to jde, když začnou dělat něco složitějšího (tvořit jména symbolů), tak už to pak takhle analyzovat nejde.

Proto se toho, co psal Biktop o návrhu lexikálních prostředků, trochu děsím. Když si 10 programátorů navrhne každý svoje lexikální prostředky a pomocí nich snadno a elegantně vyřeší svůj problém --- tak je pak otázka, jak to pak jeden po druhém bude číst?

Neni to stejne jako C preprocesor, protoze narozdil od C preprocesoru je mozne v ramci expanzi maker pouzit cely aparat Lispu, kdezto v C je preprocesor separatni a velmi slaby jazyk. A take, makra maji pri expanzi fakticky k dispozici syntakticky strom, narozdil od C preprocesoru, kde jsou to proste jen retezce.

Je pravda, ze makra muzou tvorit jmena symbolu, ale vetsina z nich to nedela.

Co se tyce te otazky, ja myslim, ze jsou to prehnane obavy. Stejne se da argumentovat i v pripade obycejnych funkci - kdyz kazdy si napise vlastni knihovnu funkci, jak to po sobe programatori budou cist? A vidis, zvladaji to docela dobre. Podle me nejvetsi problem s makry je, ze se blbe pisou a ladi; citelnost (snazsi zapis) je naopak jejich vyhoda.

"je mozne v ramci expanzi maker pouzit cely aparat Lispu"

Právě to může být i nevýhoda. V C když nevím, co něco dělá, tak si ta makra expanduju sám --- ovšem čím je ten makrosystém silnější, tím hůř se ta makra v hlavě expandují. To, že C má slabý makrojazyk je výhoda --- snáze se to čte (a IMHO by mohl být ještě slabší, operátor ## na spojování tokenů v tom dokáže nadělat bordel).

Je otázka, kdyby ti někdo ukázal velký program v Lispu, který jsi nikdy neviděl, ukázal na náhodné místo a zeptal se "co se tady dělá?", kolik toho z programu bys musel přečíst, než bys to dané místo pochopil. Ale když si nikdy větší program v Lispu nečetl (já taky ne), těžko nad tím takhle uvažovat.

V Lispu si můžeš pro kontrolu nechat makro expandovat interpretem - včetně specifikace, do jaké hloubky má při té expanzi jít. V C to vzhledem k jednoduchosti nutné obvykle není a málokdo v rámci ladění kouká na výstup preprocesoru, přestože ta možnost tam je taky. Navíc v C mají makra často povahu technické obezličky (úprava deklarace či jiné dodatečné specifikátory, platformě závislé modifikace aj.) a ne části algoritmu, takže výstup preprocesoru má obvykle gulášoidní charakter.

Já myslím, že cílem jazyků, jako je Lisp, je právě to, aby nebylo nutné psát velké programy. ;-) Navíc "problém", na který narážíš, je obecně charakteristický snad pro všechny neimperativní jazyky*, vlastně i pro objektové imperativní jazyky, jako je třeba Smalltalk, ale do jisté míry i C++ - no zkrátka pro všechny jazyky, kde jsou jiné rysy (deklarativnost, funkcionálnost, implicitnost...) posíleny na úkor imperativnosti. Jenže to je přirozená vlastnost takových jazyků, protože právě o to v nich jde, abych nemusel "disassemblovat" funkčnost programu jako překladač, ale mohl si to přečíst jako člověk, tj. pomocí názvů objektů a komentářů... ;-)

* v Lispu se samozřejmě dá programovat i imperativně, ale pro tento styl programování existují mnohem vhodnější jazyky. :-)

"Já myslím, že cílem jazyků, jako je Lisp, je právě to, aby nebylo nutné psát velké programy. ;-)"

S tím souhlasím, ale tvrdím, že u velkého programu, co píše mnoho lidí, to není podstatné kritérium. Řeknu protipříklad: máš dva ovladače, každý má N řádek kódu. Sloučíš je do jednoho obecného ovladače, který má 1,5*N řádek kódu. Sice jsi kód zmenšil, ALE před sloučením člověku pro pochopení jednoho ovladače a provedení změny stačilo přečíst N řádek kódu, po sloučení človek musí přečíct 1,5*N řádek kódu.

Není na to obecné pravidlo, kdy slučovat a kdy ne. Třeba kdyby bylo často potřeba stejnou změnu provést do obou ovladačů, tak by se sloučení vyplatilo --- vzhledem k tomu, že dopředu nevíš, jaké změny budou potřeba, tak ani nemůžeš exaktně určit, kdy je slučování kódu žádoucí nebo ne.

U velkých programů není důležité kolik to má řádek kódu (stejně je všechny nepřečteš nikdy), ale jak rychle člověk danou část programu pochopí a je schopen tam něco změnit nebo dopsat.

Já myslím, že není důvod se toho příliš děsit. Je to jak píše JS - kromě možnosti definovat funkce máš možnost definovat "metafunkce", čili makra. Přirovnal bych to asi k takovému rozdílu, že v klasických jazycích máš možnost napsat výraz a nechat počítač ať ti ho vyčíslí, zatímco v jazycích typu Lisp máš možnost napsat rovnici a nechat počítač ať ti ji vyřeší a výsledné řešení případně vyčíslí. Jistě, nebudeme si nic nalhávat - je to náročnější na představivost, ale řekl bych v tom pozitivním smyslu - tak jako ve fyzice (středoškolské) většina lidí asi pochopí, jak vyřešit rovnici a najít tak výraz, ovšem podstatně méně lidí už dovede na základě nějakého problému sestavit tu rovnici, jejímž vyřešením dojde k výrazu, po jehož vyčíslení obdrží kýžený výsledek (u VŠ fyziky je to spíš naopak, že - rovnici dám dokupy docela snadno, ale neumím s ní pohnout :-). Proto říkám, že k efektivnímu použití Lispu je třeba překopat myšlení - uvědomit si ty metavlastnosti jazyka a dokázat je vhodně využít. Takže když jsem psal o tom návrhu lexikálních prostředků - může to fungovat např. tak (jen jednoduchý příklad, vždycky když člověk potřebuje nějaký zajímavý příklad, tak ho napotvoru nic nenapadne :-) , že v C máš k disposici 1D a 2D pole; nemaje lexikálních prostředků k vyšším rozměrům patrně uděláš 1D pole a jeho indexaci budeš řešit "ručně" a úplně jinak než ty dva speciální případy (pomocí ne úplně přímočaré funkce nebo pomocí funkce vygenerované makrem - ale dost krkolomně a budeš omezen na znalost dimenze v době preprocesingu) - tohle mi nepřipadá zrovna moc přehledné a "ortogonální"; v Lispu si napíšeš velice jednoduché a přímočaré makro, které ti na požádání vygeneruje N-rozměrnou indexovací funkci, kde N je argumentem toho makra - takže ti tu potřebnou funkci vygeneruje třeba na základě dosavadních výsledků apod. I když tohle je primitivnost která ti je jasná, zdůrazňuji, že tenhle mechanismus máš k disposici v run-timu a jazykové prostředky, jež při tom můžeš využít, nejsou nijak omezené, jak už psal JS - obojí v protikladu s makroprocesorem v C: tím makrem můžeš za běhu (!) vygenerovat třeba (nebo spíš obvykle ;-) lambda-funkci, kterou předáš jako argument k dalšímu upotřebení, nebo dokonce jiné makro. V tomhle já právě vidím tu úžasnou tvárnost toho jazyka.
Jasně - na první pohled je asi zřejmé, že síla tohoto mechanismu bude nejvíc vidět u problémů, kde složitost závisí na vstupních parametrech - typicky problémy vedoucí k N vnořeným cyklům, k N-rozměrné rekursi atp., kde N není jen parametrem, ale vystupuje v těch algoritmech jako normální argument. Ale není nezbytně nutné řešit s tím jen tyhle "akademické" problémy - zatímco v C budeš řešit, jakou vhodnou datovou strukturu použít jako kompromis mezi optimálním popisem informace a složitostí a přehledností operací, jež s ní chceš provádět, protože při realisaci těch operací jsi v podstatě omezen jen na funkce, u nichž jsi poměrně značně svázán pokud jde o nutnost znalosti povahy těch dat v době kompilace, v Lispu si můžeš velice výrazně pomoci makry. V C máš k realisaci dynamické mnohotvárnosti dat programu k disposici v podstatě jen ukazatele jakožto nástroj funkcí - což je ze své podstaty pasivní objekt (a taky dost nebezpečný). V Lispu na to můžeš použít aktivní objekty - funkce+makra (o nic méně bezpečná, nicméně řádově silnější než kombinace funkce+pointery). Jde jen o to si na tenhle kvalitativně dost odlišný přístup k návrhu postupně zvyknout, uvědomit si, že už nejsem vázaný na poměrně rigidní datové struktury, ale že si cokoli můžu kdykoli velice plasticky přetransformovat, reinterpretovat podle potřeby.

Zkrátka abych to shrnul - jestliže v klasických jazycích jsi omezený na programování v 1D, 2D (nebo 2,5D :-), v Lispu můžeš dělat v N - jsi omezen jen svou hlavou, do jaké dimenze to zvládne. :-) Dostat se od nás do Austrálie je docela zdlouhavé - pokud jsi omezen jen na povrch Země. Když můžeš skrz, je to jednoduché a přímočaré, pokud si dokážeš představit, že je Země kulatá. A zrovna tak je to s přehledností dobrých programů v Lispu - nejsou write-only, ani nejsou složité, naopak - obvykle jsou mnohem jednodušší než jejich ekvivalenty v jiných jazycích. Ale chce to sžít se s přítomností maker a dokázat vystoupit z té plochy a uvědomit si, že teď už můžeš jít i "skrz".

Jo, to s tím vícerozměrným polem chápu. V C můžeš mít pole o libovolném počtu rozměrů, ale nemůžeš ten počet rozměrů dát jako parametr --- ani jako compile-time parametr, ani jako run-time parametr. To v Lispu jde.

Představ si, že někdo napíše makro pro přístup do pole o libovolném počtu rozměrů, pak napíše další makro, které to obecné pole bude procházet a na každý prvek aplikovat nějakou funkci, pak další makro, které to obecné pole bude zpracovávat medou rozděl a panuj a tak dál.

S použitím těch maker můžeme na jeden řádek napsat třídění, na jeden řádek napsat nalezení nejmenšího prvku a spoustu dalších algoritmů.

A teď ten problém: Většina polí ve velkém programu je jednorozměrná. Napsat nalezení nejmenšího prvku na jednorozměrném poli můžeme v C na 4 řádky:

int i;
int minimum = MAXINT;
for (i = 0; i < sizeof(pole) / sizeof(*pole); i++)
        if (pole[i] < minimum) minimum = pole[i];

V Lispu s tím makrojazykem to sice napíšeme na jeden řádek, ale abychom pochopili co to dělá, musíme přečíst třeba 50 řádků (celý ten makro-systém na N-rozměrná pole).

Čili v C napíšeme 4 řádky a přečteme 4 řádky (stačí ti přečíst jen ty 4 řádky, zbytek programu tě vůbec nemusí zajímat), v Lispu napíšeme 1 řádek a přečteme několik desítek řádků.

Mně to vhodné pro vývoj aplikací vůbec nepřijde. Takový makrojazyk může být vhodný pro řešení matematických problémů, ale v běžných programech se 2-rozměrné pole vyskytuje zřídka a vícerozměrné skoro nikdy.

Mně to přijde tak, že čím víc má některý jazyk syntaktických prostředků, tím snáze se v něm programuje a tím hůře se v něm čte. Protože práce na aplikačních program je z větší části čtení kódu (nikoli psaní), tak použít jazyk, který si kdo chce může jak chce upravit, nemusí být nejlepší.

Nebo proč jinak myslíš, že se Lisp nepoužívá, a používá se místo něho C, C++, Java, Python? Existuje vlastně nějaký velký uživatelský program v Lispu?

No, teorie je to dobra. Nicmene je otazka, zda Perl/Python/Ru­by/PHP jsou vhodne na psani aplikaci - take neni trivialni pochopit dane misto a zmenit, diky zejmena duck typum a dalsim featuram (nejvic u Ruby a Perlu).

Ja myslim, ze duvod, proc lide na psani aplikaci pouzivaji C,C++, Javu a Python souvisi s revoluci mikropocitacu (kdy se temer vse kolem pocitacu vynalezalo od piky). Lisp mel GC a byl na male pocitace pomaly bez kompilace, proto se lide naucili pouzivat C a C++, na ktere v podstate prechazeli z BASICu a Pascalu (a ze stejneho duvodu ignorovali Lisp a Smalltalk, kde druhy by byl jasny kandidat).

No a to se historicky pak uz preneslo dal. Podle me pouzivani toho ktereho jazyka souvisi s vychozi platformou a zkratka historii, mene s tim, jak dobre se v nem programuje. (Ostatne, dalsi vec, ktera Lisp pohrbila, bylo mnoho konkurujicich uzavrenych implementaci, kazda s jinou knihovnou. Mam teorii, ze slozitost implementace jazyka - nebo jineho SW systemu - je pro nej evolucni vyhodou, a usnadnuje jeho preziti - viz tez Forth.)

Já bych to bral naopak jako velké minus - lidi, kteří mají schopnosti leda na kopání výkopů nebo obsluhu dopravníku hnoje na statku, se motají do něčeho, nač nemají a jejich hlavu jim nenahradí ani sebesofistiko­vanější nástroj - se všemi důsledky, jež z toho plynou (pro lidstvo :-).

No, ale zase takoví lidé mají nižší procento výskytu poruchy osobnosti a jsou schopni styku se ženou. Viz zde: http://www.jikos.cz/~mikulas/komix/FREESOFT.GIF

:-D
Ty sis dělal nějaký statistický průzkum? :-) Znám i pár jakože-programátorů, kteří mají asi taky poruchy a nejsou schopni styku se ženou (proti nim si můžeš fandit - představ si, že bys byl looser i v programování :-), znám dokonce i traktoristu, který není schopen styku se ženou kvůli nějaké psychické poruše, stejně jako znám dost dobré matematiky, fyziky, programátory, kteří se ženami styk mají. :-) Krom toho - nevidím nic sexy na tom, že někdo umí splácat jakousi patlaninu v ASP.NET - to dnes umí každý druhý. Ale když sedím s kolegy - BFprogramátory a samicemi, jež si přivedli, třeba v hospodě, pozoruji zvýšený zájem, když zeptavše se mě na mou práci obdrží od těch kolegů odpověď "na to se ho radši neptej, to nechápeme ani my". :-)

Někteří psychologové tvrdí, že schizoidní porucha koreluje s vysokou inteligencí.

Kdybych byl blbej na programování a ještě k tomu psychopat, tak bych mohl sociální interakci rozvíjet jinak, třeba takhle: http://comix.spaceport.cz/index.php?id=12975

"nevidím nic sexy na tom, že někdo umí splácat jakousi patlaninu v ASP.NET" --- no ta ženská to nevidí taky, protože neví, co je to ASP.NET, je jí prakticky jedno, jestli řekneš, že jsi napsal webovou stránku v ASP.NET nebo že jsi vyřešil nějaký problém kernelu. Ba ne, tu webovou stránku ocení víc než kernel, protože na tu se aspoň umí podívat.

Já bych hlavně ty poruchy nebral zas tak smrtelně vážně. Psychická porucha je odchylkou od normálního stavu mysli. Vysoká inteligence je nepochybně taky odchylkou od normálu, takže mi ta korelace nepřipadá zase tak podivná. Je to určitě příjemnější odchylka než podprůměrně nízká inteligence a s ní korelované poruchy. :-) Narozdíl od těchto něšťastníků ti tvoje mysl dovoluje analyzovat chování druhých a syntetisovat na základě těchto analýz postupy vhodné pro tvoji interakci s okolím. :-)

To bych neřekl. Ženské bude jedno, že neví co to je. K tomu, abys v jejích očích poskočil na žebříčku atraktivity jí stačí vědět, že je to něco, v čem se vyznáš ty a pár dalších a jinak nikdo a všichni to o tobě vědí. :-)

"Ženské bude jedno, že neví co to je. K tomu, abys v jejích očích poskočil na žebříčku atraktivity ..." --- takový ženy sice jsou, že kdybych se před nimi přímo nebo nepřímo vychloubal, tak by se vzrušily. Ale podobná "hra" zase vůbec nevzrušuje mě. Nedokázal bych si vážit ženy, která se nechá takhle jednoduše manipulovat.

"ti tvoje mysl dovoluje analyzovat chování druhých a syntetisovat na základě těchto analýz postupy vhodné pro tvoji interakci s okolím." --- jenže inteligence mi neumožňuje syntetizovat vhodné emoce. Pohled v očích, výraz tváře, tón hlasu --- to se nedá emulovat.

Nic o vychloubání jsem neříkal.

No jo, ale potom není co řešit. To je jako by všichni kolem tebe pravidelně chodili na cigaretu a ty jsi měl deprese z toho, že si tu cigaretu nemůžeš dát taky, protože ti to chuťově nic neříká. Tak buď ti "styk se ženami" chybí a tedy to na tebe emočně nějak působí a když vidíš nějakou atraktivní holku tak nějaké emoce při tom pociťuješ, nebo žádné emoce nemáš, ale pak je mi divné, že z toho můžeš mít špatné emoce. :-)

"To je jako by všichni kolem tebe pravidelně chodili na cigaretu a ty jsi měl deprese z toho, že si tu cigaretu nemůžeš dát taky, protože ti to chuťově nic neříká."

S tím souhlasím. To jsi přirovnal velmi přesně. Ale nevidím v tom žádný rozpor.

Kdybys měl společnost, která "chození na cigaretu" považuje za sociální rituál, kterým utužuje vztahy mezi jednotlivými členy, a do takové společnosti se dostane člověk, kterému cigareta nechutná, tak je ten člověk v té společnosti úplně vyřízený. Nemůže nic. Nemůže mít kamarády (protože by to znamenalo "jít na cigaretu"), nemůže mít partnerku (protože by s ním chtěla chodit na cigaretu), nerozumí se spolužáky ani kolegy (protože oni si přece utužují kolektiv u cigarety) atd. Nevím, nad čím se divíš --- deprese je logické vyústění situace.

"Tak buď ti 'styk se ženami' chybí a tedy to na tebe emočně nějak působí a když vidíš nějakou atraktivní holku tak nějaké emoce při tom pociťuješ"

Občas (zřídka) takové emoce k ženě pociťuju. Někdy jsem si i představoval, jak krásné by to bylo ženu milovat. Ale jde právě o to, že cítit samotné emoce nestačí, při navázání vztahu i během vztahu je potřeba provádět spoustu sociálních rituálů, a ty mi nic neříkají.

Problém ani není v tom, že bych se ty sociální rituály nemohl naučit. Problém je v tom, že když můj mozek něco vyhodnotí jako rituál, tak to pro mě přestane být zajímavé a nedokážu se tím nijak nadchnout.

Já s nimi na tu cigaretu také nejdu, a ještě jim klidně vynadám že jsou banda smradlavých feťáků ;-)

Ale to je totéž, co tu už naznačoval JS - jak se tebou nadnesený problém liší např. od použití knihovních funkcí nebo knihoven tříd? Přece při programování obvykle nestuduješ, jak fungují jednotlivé funkce v knihovnách, ostatně často to ani není možné, když k nim nemáš zdrojáky. Ty jsi asi spíš systémový programátor, co? ;-) Protože tyhle argumenty jsou blízké lidem, co dělají blízko železu - ovladače, jádra OS atp. a jsou zvyklí na to, že na téhle úrovni softwaru je poměrně obtížné programovat čistě a stejně z toho nakonec vyleze větší či menší programový chrchel, takže je nutné přesně vědět nejen co dělají, ale i jak jednotlivé komponenty toho chrchlu fungují. Jinak bys mohl zpochybnit celé objektové programování a vlastně i strukturované programování - místo abys napsal něco jako GOSUB xxx, tak napíšeš jméno nějaké rutiny, ale stejně si musíš přečíst, co ta rutina dělá. Přece všechny ty heterogenní datové struktury, uživatelsky definované funkce a později třídy a objetky byly vymyšleny hlavně kvůli tomu, abys mohl uzamknout jednotlivé funkční celky, mohl je ladit pokud možno odděleně a nezávisle a pak k nim mohl přistupovat jako k černým škatulkám, kdy nutnost znalosti jejich vnitřku je naopak nežádoucí, protože navenek se mají z hlediska programátora projevovat jen svým rozhraním.

S těmi syntaktickými prostředky - to bych váhal. Když si vezmeš třeba Adu nebo i obyčejný Pascal, tak ty mají těch syntaktických prostředků poměrně dost, ale přesto se v nich dá číst velice dobře i poměrně špatně napsaný program. Souhlasím, že u Lispu nebo u Forthu je to vyloučeno - tam špatný program vypadá fakt jak mimozemská šifra. Ale dobrý program se tam čte jak pohádka pro děti. Kdybych vzal Adu a proti ní postavil Lisp, řekl bych, že autoři Ady předpokládají, že programátor je blbec, může zkopat co se dá a pokud se nedokáže vyžvejknout jasně, tak to je příznakem, že neví, co chce a je třeba ho okamžitě zabrzdit v jeho počínání. U Lispu to je přesně obráceně - autoři předpokládali, že programátor obvykle ví co dělá a jak toho chce docílit, proto má možnosti otevřené do té míry, že si k těmto účelům může neomezeně tvořit syntaktické prostředky. Syntaxe samotného Lispu je zcela primitivní. Syntaxi Ady vymýšleli zkušené otevřené hlavy, jenže programy tvoří obvykle hlavy mnohem méně zkušené a bystré, čehož si ty první hlavy byly velice dobře vědomé.
Riziko jazyků typu Lisp je právě v tom, že i nezkušený člověk s ne příliš vyvinutým abstraktním a analytickým myšlením má možnost dělat věci, k nimž mají u jiných jazyků výsadu pouze jejich tvůrci - zasahovat do syntaxe. A řekl bych, že i to je důvodem, proč se jazyky jako Lisp nebo Forth nepoužívají masově - protože málokdo má k jejich efektivnímu použití vlohy. Že většina lidí v životě neřeší diferenciální rovnice nebo při nakupování neoperuje se simplexovou metodou není problém těch rovnic - to je problém těch lidí, že na to nemají hlavu.
C se jednoznačně rozšířilo s Unixem a s MS-DOSem. A nejsem si jist, že to bylo zrovna nejšťastnější řízení osudu. Když v něm zkušený člověk píše jádro OS, je to perfektní jazyk. Ale když v něm průměrně schopný programátor dělá aplikaci... Ovšem i můj pohled na C jakožto na ideální systémový jazyk byl otřesen, když jsem studoval Oberon, což je IMHO důkaz, že i OS se dá elegantně napsat v hodně restriktivním a přitom docela jednoduchém jazyku a že to má velice pozitivní vliv na návrh jeho datových struktur a srozumitelnost jeho zdrojáků.

Když použiješ knihovní funkci na pole, jiný programátor s velkou pravděpodobností ví, jak to funguje. Když použiješ vlastní makro biktopovo-n-rozmerne-pole, tak nikdo neví, jak to funguje.

Jak by se to metaprogramování mělo řešit na velkém projektu?

* nechat si každého programátora napsat vlastní makro na pole --- pak jeden nepřečte kód druhého, ani si to pole nebudou schopni efektivně předat.

* seskupit programátory a nechat je navrhovat makro způsobem "a já bych tam ještě přidal proměnný počet rozměrů" ... "a já bych tam ještě přidal kompresi nepoužitých prvků" ... "a já bych tam ještě přidal efektivní přidávání prvků doprostřed" ... "a já bych tam ještě přidal bla bla bla" --- pak ti z toho vznikne neuzvěřitelný bastl.

* nebo vedoucí projektu to makro na pole navrhne a pak direktivně řekne "použije se toto makro na pole, jiná makra na pole jsou zakázána, chce-li někdo funkcionalitu, která tam není, má smůlu, musí ten svůj problém jinak řešit". Asi nejlepší řešení. Jenže místo toho rovnou můžeš říct "použije se C++ STL, vlastní implementace datových struktur jsou zakázané", vyjde to nastejno, navíc ušetříš čas návrhu a implementace a učení-se těch vlastních maker.

"Přece při programování obvykle nestuduješ, jak fungují jednotlivé funkce v knihovnách" --- knihovny nestuduji, ale studuji, jak fungují jednotlivé funkce, které napsali jiní programátoři na témže programu. To jinak ani nejde. Program (ani aplikační) nenapíšeš způsobem "uděláme specifikaci rozhraní mezi moduly, pak jednu skupinu necháme psát implementaci toho rozhraní, druhou skupinu necháme to rozhraní použít, a jedna skupina se nebude muset dívat na kód druhé". Když to rozhraní navrhneš, tak to navrhneš s velkou pravděpodobnostní blbě, že to půjde těžko implementovat nebo to bude nepoužitelné. Když se zjistí, že je to těžko implementovatelné, musí se to rozhraní změnit. Když se zjistí, že je to nepoužitelné, musí se to rozhraní taky změnit.

Ten návrh rozhraní mezi částmi programu je spíše iterativní cyklus "pokusíme se to specifikovat, pokusíme se to implementovat, opravíme specifikaci, aby se to lépe implementovalo, pokusíme se to použít, opravíme specifikaci, aby to bylo použitelné, změníme implementaci podle specifikace, pokusíme se to použít víc, zjistíme, že je tam ještě potřeba tohle, zjistíme, že tohle ve specifikaci jsme nikde nepoužili, tak to odstraníme, atd." Když tenhle cyklus dobře opakuješ, vznikne ti z toho solidní použitelné rozhraní. Když ten cyklus neděláš, tak z toho vznikne "návrh od komise".

Přiznám se ti, že já na žádných velkých projektech, kde se motá halda programátorů, nedělám. Nějak mě unavovalo hádat se s hlavním analytikem, který netuší, co to ta analýza vlastně je a nechávat si posílat zdrojáky kolegů, kteří umějí programovat asi jako má matka po 14denním zaškolení...
Ovšem stejně mi pořád nedochází, kde vidíš ty hlavní problémy - přece dostanu-li za úkol vytvořit modul, který bude realisovat nějakou databázi a bude reagovat na dotazy vyšší vrstvy, nikoho nemusí zajímat, jaká makra si tam vytvořím k "fyzické" realisaci těch dotazů; to bude sloužit interně jenom tomu mému modulu - např. makra generující nějaké výběrové funkce, indexové funkce aj. A organisačně se takový projekt v Lispu nijak výrazně lišit nebude od organisace projektu třeba ve Fortranu nebo v čemkoli jiném - proč by měl?

"nikoho nemusí zajímat, jaká makra si tam vytvořím k 'fyzické' realisaci těch dotazů; to bude sloužit interně jenom tomu mému modulu"

Bude to lidi zajímat:

- Někdo ten tvůj modul použije, nebude mu to fungovat. Musí zjistit, zda je chyba u tebe nebo u něho (a přečíst i tvůj kód).

- Program bude pomalý, musí se zjistit proč. Opět bude někdo číst tvůj kód.

- Ta specifikace rozhraní bude neúplná, někdo tam bude potřebovat něco dopsat.

Zde bohužel, čím kreativnější programátorské techniky použiješ, tím se to bude neznalému člověku hůř číst. Třeba složitost jde u takových jednoduchých programů zjistit banálně podle vnořených cyklů. Ale když si ty vnořené cykly budeš generovat makry, co si sám napíšeš, tak už to tak snadno zjistit nepůjde (člověk bude muset prvně pochopit ideu těch maker než se bude moct ptát "jakou to má složitost?").

To jo, ať si to přečte, ale nemusí je používat. A já si fakt nemyslím, že by to bylo tak nepochopitelné. Když jsem měl za úkol upravit cosi v programu na rozpoznávání drah částic napsaném ve FORTRANU 66 bez jediného řádku komentáře, byl to mnohem horší zážitek než probírat se lispovskými makry. Promiň, ale mně to připadá, jako bys tvrdil, že algebraické výrazy jsou nepřehledné, protože tam místo čísel vystupují písmena, když to trochu zjednoduším. Nebo že matematická tvrzení jsou nepřehledná, protože místo konkrétních funkcí, konkrétních objektů hovoří jen o nějakých blíže nespecifikovaných objektech, splňujících vlastnosti uvedené v předpokladech. Pro spoustu lidí to opravdu je nad jejich síly, ale pro ty, pro něž to nad jejich síly není, je to přece obrovské usnadnění a zbraň, jež jim dovoluje jít mnohem dál nebo aspoň s mnohem menší námahou, než ti omezenější. Je to sice zas takový trochu blbý příměr, ale absolvent gymnázia (dnes už asi spíš prváku na VŠ) bude schopen spočítat integrál přes 2pí z sin na 4. krát cosinus na 5. Docela se u toho zapotí využívaje jen ta nejstupidnější pravidla o integrování. Ale člověk, který má trošku abstraktní nadhled, to spočítá z hlavy během chviličky pomocí Beta-funkce. Když si to po něm přečteš, nebude ti to připadat nikterak překvapivé a nepochopitelné - výpočet na půl řádku. Pokud bude výsledek nesprávný, snadno najdeš chybu - třeba vynechal jeden Gamma-faktor při vyčíslování té Beta-fce. Pro toho, co zná jen per partes, to bude postup jak ze star treku a absolutně nebude chápat, co to tam ten dotyčný vlastně dělal. Ale když budeš muset ty hledat chybu v jeho myšlenkově jednoduchém, leč pracném postupu, budeš muset projít půl A4ky výpočtů, kdy v každém kroku mohl udělat nějakou botu. Přece postup využívající speciální funkce není nepřehlednější nebo dokonce horší než ten primitivní jen kvůli tomu, že spousta lidí si nedokáže dát dvě a dvě dohromady a ulehčit si práci...
Já si naopak myslím (a nejsem sám a zdaleka ne první, koho to napadlo), že množství chyb je korelováno s množstvím napsaného kódu. Takže minimalisací nutnosti psát kód taky minimalisuji pravděpodobnost zanesení chyby. Pokud dokážu postup výpočtu a strukturu dat vzájemně dekomponovat tak, že celý program budu moci poskládat s maximálním využitím jednoduchých kroků automaticky vygenerovaných jinými nekomplikovanými algoritmy, tak to přece je zpřehlednění, zjednodušení a snížení rizika chyby - mám jednoduše strukturovaná data, s nimiž budu provádět četné jednoduché operace (kdybych je měl psát ručně, tak bych se zbláznil nebo by to dokonce bylo nemožné, proto u "klasického" návrhu bych musel postupovat úplně odlišně, data jinak strukturovat, k jejich zpracování použít jiné metody), jež budou ad hoc generovány pomocí jednoduchých receptů.
Podle mě to prostě není taková divočina, jakou v tom vidíš ty. To je podobné, jako by ses děsil, že matematická logika připouští vedle obyčejných výroků i predikáty. Většina normálních lidí má problémy i s těmi obyčejnými výroky, ale těm, kterým ty predikáty problémy nečiní, schopnost pracovat s nimi výrazně ulehčuje práci. Zarecituj obyčejnému smrtelníkovi klasickou definici limity číselné posloupnosti - u třetího kvantifikátoru to přestane brát. Máme snad kvůli lidem jako on rezignovat na počítání s limitami nebo se domnívat, že je to až příliš komplikované?

Mně přijde, že člověk by měl používat nejjednodušší prostředky, které vyřeší daný problém.

Ad ty úvahy o složitosti matematiky:
Představ si třeba, kdybys popsal růst dluhu diferenciální rovnicí. To můžeš, je to popsáno matematicky elegantně, ale má to problém --- vymahačská firma tomu nerozumí (proč by měla zaměstnávat matematika?), dlužník tomu asi taky nebude rozumnět ... a kdybys to chtěl vymáhat soudně, tak tomu soudce nebude rozumět též a ty si budeš muset zacvakat soudního znalce, který tam tu diferenciální rovnici vyřeší a zjistí, kolik teda má dlužník platit. Proto se prostě dluh neřeší diferenciální rovnicí, ale diskrétními vzorečky, které to den po dnu napočítávají. Řešení je to neelegantní, tupé, ale splní to účel a průměrný účetní si do toho vzorečku dokáže dosadit a spočítat to.

Čímž nemyslím, že diferenciální rovnice jsou blbost. Jen je to na daný problém dluhu jako "kanón na vrabce". Myslím, že jde-li problém řešit bez diferenciálních rovnic, tak ho řešit bez nich. Stejně tak, když jde program napsat bez metaprogramování, tak ho psát bez něj.

"Pokud dokážu postup výpočtu a strukturu dat vzájemně dekomponovat tak, že celý program budu moci poskládat s maximálním využitím jednoduchých kroků automaticky vygenerovaných jinými nekomplikovanými algoritmy, tak to přece je zpřehlednění, zjednodušení a snížení rizika chyby" --- otázka je, kde takový správně dekomponovaný veliký program v Lispu je? Já znám v Lispu jen toho psychiatra v Emacsu, se kterým si občas povídám o své psychické poruše. Když něco tvrdíš, tak to ukaž.

A co kdybys to zkusil ty, naprogramovat neco netrivialniho v Common Lispu? Vzdyt - zivot je kratky, na zeny stejne kasles, tak v cem je problem?

Treba ti ten jazyk zacne vyhovovat. Je dost velmi chytrych lidi, kterym vyhovuje, coz uz samo o sobe je duvod to zkusit. Nekterym mozna ne, ale i ti uznavaji, ze je "life-changing experience" (jako Eric Raymond).

Ja jsem to tak udelal, a kdyby pro me stale nebylo v Pythonu par veci snazsich (coz je spis otazka moji Lispove nezkusenosti, zatim) a nemel lepsi standardni knihovnu, tak uz na svoje programovani pouzivam Lisp temer exkluzivne.

(Jinak Emacs Lisp neni nic moc, co jsem slysel, protoze nema lexikalni promenne.)

Určitě jsi už slyšel nějakou tu lidovou hádanku typu "Otec měl tři syny. Po jeho smrti si měli dědictví rozdělit takto: první měl dostat o 2/3 víc než druhý, jenž měl dostat o deset liber méně a 1/5 více než třetí, atd..." Nebo "až bude matce 2x tolik co jejímu staršímu synovi, bude její dceři o 5 let méně než..." BFU to řeší víceméně pokus-omylem, proto je to pro ně tak náročné. Nevím jak ty, ale já si napíšu (nebo představím) rovnice pro ty jednotlivé persóny a ty prostě vyřeším. Podle tebe jdu s kanónem na vrabce jen kvůli tomu, že většina populace můj postup nepochopí, přestože na něm nic nepochopitelného není - naopak, je přímočarý a deterministický, narozdíl od toho jejich?
Jít s kanónem na vrabce - to je počítat obsah trojúhelníku pomocí integrálu, když na to mám jednoduchý vzoreček, nebo třídit nějaké pole pomocí quicksortu, když těch prvků tam je pár desítek a potřebuju je seřadit jednou za uherský rok. Ale z pohledu lispaře takovým kanónem může být třeba snaha napsat nějakou komplikovanou funkci pro generování kódu v nějakém překladači, beroucí v úvahu stopadesát různých možností, když se dá napsat makro, jež mi ty odpovídající konkrétní funkce vygeneruje.

Záleží, co to je podle tebe velký projekt... Vedle emacs třeba
http://www.paulgraham.com/carl.html
http://www.franz.com/success/customer_apps/bioinformatics/mdl_story.lhtml
http://flightcaster.com

A v historii by se toho našlo víc - na Lisp Machines toho bylo dost :-)

Je neúčelné učit se řešit N rovnic o N neznámých kvůli kvízům. Pro BFU je skutečně časově méně náročné, když těch pár kvízů, co v životě uvidí, bude hádat, než když se bude několik měsíců učit matematický aparát. Ty rovnice nebyly dělány na kvízy, to, že se jimi dají řešit kvízy, je side-efekt.

Stejně tak považuju za neúčelné používat abstrakci na pole s proměnným počtem dimenzí, když v běžném aplikačním programu jsou skoro všechna pole max. dvourozměrná. Abstrakce na nesprávném místě škodí.