Dobře, když máte výraz x = a(b(c(d(e(f(g)))))), tak jak otestujete, která funkce je špatně bez přepisování kódu. Jak se dozvíte, co je výsledkem c na reálných datech?
A jak se to vztahuje k FP? To jako ze tam jsou funkce tak je to FP? To co jste uvedl (asi) nepouziva ani funkce vyssich radu, vypada to jako normalni imperativni kod. Co mi brani to takto napsat v Pythonu, nebo pripadne v jazyce, ktery zadne extra FP ficury nema?
Kdyby byl Python nepouzitelny jazyk, jak tvrdis, tak ho nikdo nebude pouzivat, ale on je naopak siroce pouzivany.
Staci se podivat na PHP. Jazyk, ktery mel byt utracen davno (hrozna "specifikace", jazyk i interpret), je to jako splacane od zacinajiciho studentika VS, presto tu dal uspesne preziva. Kvalita nema bohuzel s popularitou nic spolecneho.
Rec je o pouzitelnosti, nikoliv kvalite a popularite. Je dobre rozlisovat mezi akademickou kvalitou a praktickou pouzitelnosti a zamyslet se, proc se tem akademickym jazykum v praxi tolik nedari. Velmi pravdepodobne v posouzeni kvality jazyka bude kazdy zduraznovat jine vlastnosti, rozhodne bych to neredukoval jen na cistotu syntaxe.
Tak napr. PHP je nekvalitni v tolika aspektech (casti jazyka nespecifikovane, std knihovna nema/nedodrzuje zadne konvence pojmenovani a navratovych hodnot, parser je patlany a casto jsou tam nesmysle podminky jen kvuli jednoduchosti implementace [takovou hruzu jsem nevidel snad v zadnem jinem bezne pouzivanem jazyce], konfigurace se provadi na mnoha mistech a to i u veci ze std knihovny [compile flagy, config v ini souboru, config v aplikaci, parametry dane funkce]) a rekl bych, ze prave proto i spatne pouzitelny. Byl jen na dobrem miste v dobry cas a napsalo se pro neho spostu kodu (a rozjelo dost hostingu), ktery se lidem nechce opoustet, tak u neho zustavaji. Jak pise Kit, programovat se da i v takovem bordelu, jen clovek musi presne vedet, kam nema slapat, aby neprisel o nohu.
Ja ho naopak preferuji a uprednostnuji kde muzu a nemusim naopak Javu, ktera me osobne prijde celkove tezkopadna a neohrabana.
Python me prijde stejne neohrabany jako Java. Moc to nesleduju, ale Java 8 myslim prinasela dost FP veci, coz vede k mnohem jednodussimu kodu. Osobne me prijde Scala jako dobry kompromis mezi uplatnitelnosti (JVM) a "krasou" jazyka (velmi jednoduse zapsane slozite veci, podpora DSL, FP atd).
Neumim si predstavit, ze bych neco jako scala pouzival prakticky, tj. ze bych mel odvahu to nasadit u zakaznika v rozsahu desitek tisic radkukodu a udrzoval/rozvijel to 15+ let. Pro me je to neduveryhodny a proto _prakticky_ nepouzitelny jazyk.
Prakticky se pouziva, dokonce i na dost velke veci. Naopak veci v Pythonu nebo JavaScriptu s trochu vic radky bych se bal udrzovat. Bez typu se hezky vyviji v malickem meritku s malo lidmi, ale jakmile se to rozroste a uz nemate v hlave mentalni model cele aplikace, tak mate problem. V Jave/Scale vam pomuze IDE a prekladac vam kdyztak vynada, v JavaScriptu nebo Pythonu je to mnohem horsi. Treba v JS musite spolehat na dokumentaci a IDE, ze to nejak prechroupe a zobrazi zhruba co by mohlo sedet k tomu, co potrebujete.
(V podstate to stejne pise BoneFlute - v dynamickych jazycich si musite vypomahat dobrovolnymi typy v dokumentaci, ve statickych je vynucuje prekladac.)
V Pythonu me vadi velke mnozstvi boilerplatu (napr. @property, @staticmethod, lambda, nenasel jsem zpusob, jak lehce retezit volani funkci, takze pokusy o FP styl pusobi hrozne) a kod celkove pusobi roztahane.
Samozrejme na Haskell, co se tyce "krasy" a strucnosti, as nic moc nema*. A to jsem v nem "noob", pamatuji si ho pouze ze skoly. Ale uz i jen ty zaklady byly nezapomenutelne (pro ostatni studenty spise v tom spatnem slova smyslu
).
*: Resp. nic lepsiho jsem jeste nevidel. Pokud neco znate, tak sem s tim.
Dekoratory nejsou boilerplate, to je naopak reseni eliminujici boilerplate, ktere vede k prehlednosti a strucnosti, nejsou povinne a jsou velmi flexibilni, muzes si je prizpusobit svym potrebam. Na haskellu mi nic krasneho neprijde, ale nema smysl porovnavat funkcionalni jazyk s imperativnim a tomu druhemu vycitat opacny stav. Argument, ze pokusy programovat v haskellu imperativne vypada hrozne, bych osobne povazoval za fail :-).
Je to kod, navic na cely radek (alespon tak to vsude vidim), ktery se casto opakuje. Stejne tak lambda - v jinych jazycich vidime co nejkrasi zapis, jako treba ->, => nebo \, v Pythonu je to ale cele slovo? Snad hur na tom byval jen JavaScript a i ten to uz napravil.
Ale Haskell nezavadi imperativni programovani jako nejakou svou feature, castecne ho umoznuje pomoci do notace. Python naopak se vsi slavou zavedl ruzne ficury z FP sveta (zakladni funkce nebo ty ukecane lambdy), ale uz se jaksi zapomnelo na to, ze jsou skoro nepouzitelne, protoze nejdou hezky retezit
![Smích :D](http://forum.root.cz/Smileys/default/cheesy.gif)
.
A naopak, moznost program casto a co nejdriv spoustet je jedna z vyhod interpretovanych jazyku.
Vzhledem k tomu, ze existuji inkrementalni prekladace (tusim ze jej ma Java i Scala a urcite mnoho dalsich), tak tohle je standard, ne vyhoda. Stejne tak i kompilovana Scala ma REPL, take to neni vyhrada Pythonu nebo interpretovanych jazyku.
Neni to standard a naopak, ze se o to snazi i kompilovane jazyky jen dokazuje, ze to ma smysl a je to vyhodou pro kazdy jazyk, ktery to umi.
Snazi? Ony to uz davno umi, vzdyt jinak by vyvoj v Jave byl hrozny, kdyby se vse vzdy muselo prekladat od 0. To by nesly rozumne psat (a testovat) ty dinosauri enterprise aplikace.
REPL pokud vim je i pro Javu, jen ne zatim oficialni (jestli se nepletu, tak je to soucasti nejakeho navrhu). JavaScript ma NodeJS, nebo primo prohlizec; ruby je na tom stejne jako Python, v Haskellu staci pusti ghci, atd.
To, ze Python ma REPL, ho nad konkurenci rozhodne nevysouva.