Vlákno názorů k článku Underscore aneb další knihovna pro funkcionální programování v JavaScriptu od novýmuf - Jo, zajímavé, když se já učil funkcko, říkali...
-
novýmuf (neregistrovaný)
Jo, zajímavé, když se já učil funkcko, říkali nám, že jediný rozumný jazyk je Lisp a pro studijní potřeby Haskell. Učili se to povinně všichni (dost lidí z toho vylítlo) a přitom se to nedalo moc použít, většinou se to považovalo za perverzi. Dneska je situace přesně opačná. Na FI MU odstavili funkcko na vedlejší kolej, vyhnali Liborka, a to v době, kdy se začíná (nebo možná jen začínám?) objevovat čím dál víc knihoven a jazyků funkcionálního paradigmatu a programovat funkcionálně je "trendy"...
-
Pavel TišnovskýZlatý podporovatelTak vývoj jde po spirále (pesimista by řekl, že se točí pořád dokola :-) a co se před pár lety ještě někdy dost násilím tlačilo do OO stylu založeného na třídách, tak se dneska opět řeší funkcionálně. Místo LISPu teď letí Clojure, to mám osobně asi nejraději, ale FF styl je dneska skoro v každém jazyku, co je zrovna v módě :-)
Situaci na FI MUNI neznám (spíš na konkurenční nejmenované VUT FIT :-), to je zajímavé, protože právě tam podle mě Haskell dost tlačili ne? To se tedy změnilo?
-
nový muf (neregistrovaný)
Tak já jsem z fakulty pryč už nějaké 3 roky, takže mám jen drby a přehledy v ISu, ale za nás byl předmět Úvod do funkcionálního programování povinný pro všechny obory včetně cvik v Haskellu, učil ho skvělý Libor Škarvada, měl navazující předmět Funkcionální programování. Momentálně vidím v ISu jen předmět Neimperativní paradigmata, který patlá do jednoho funkcko a logické paradigma, na které jsme my měli další celosemestrální předmět, čili zbastlili dva předměty do jednoho. Učí to Barnat, který nebyl špatný, ale Liborkovi se nikdo nevyrovná. Co jsem slyšel, tak odešel z fakulty před nějakým tím rokem mimo jiné kvůli tomu, že osekávali funkcko ve studijních plánech pod míru, kterou by byl ochoten akceptovat, aby studenti měli šanci tomu porozumět... A fakt bych chtěl vidět, jak se někdo kloudně naučí funkcko za půlku semestru, když u nás bylo běžné dávat si ten celosemestrální předmět i 3x ;-).
-
ebik (neregistrovaný)
Nejlepší nástroj je beztak vlastní hlava. :-). Někde se věci chovají jako objekty - chceme vyspecifikovat interface (klidně implicitně duck-typingem) a závisí na každém objektu (třídě) jak ten interface implementuje.
Jindy máme pole dat a z něj potřebujeme dostat transformacemi (funkcemi) to, co nás zajímá. A ve většině případů je to něco mezi. Ideální je umět myslet oběma (všemi) způsoby a použít ten, ve kterém je konkrétní část programu čitelnější a udržovatelnější. Někdy je to i o explicitním versus implicitním přístupu k problému, implicitní často usnadňuje zobecnění, zatímco explicitní často usnadňuje verifikaci správnosti kódu. -
Pavel TišnovskýZlatý podporovatel
Jj je to tak, něco mezi. Ovšem stačí si přečíst pár (dnes již starších) článků na téma "všechno je objekt" a "dědičnost je stříbrná kulka v IT" (teď trošku přeháním), v nichž se koncept většinou třídního OOP přeháněl a snažil se napasovat na všechny problémy, což samozřejmě vedlo k horšímu kódu (už jen tím, že exponenciálně narostl stavový prostor, který se musí nějak otestovat).
Opačný extrém je asi jen v Haskellu, jinak ostatní jazyky a knihovny nebývají čistě funkcionální, ale nechávají to na programátorech, kteří většinou přijdou na to, že FF konstrukce mají své výhody, ale ne vždy je vhodné a nutné je použít.
-
Pavel TišnovskýZlatý podporovatel
To je hodně těžké říct obecně (už jen proto, že přecházím mezi několika jazyky), ale z těch nástrojů, co dělám poslední rok, tak se na ně většinou dívám takto:
1) nejedná se nutně o objekty s vlastnostmi (atributy), které mezi sebou komunikují (a tvoří tak mnohdy šíleně složitou síť vzájemných vztahů)
2) spíše celý ten tool dělá transformaci dat. Na vstupu té transformace je řekněme dotaz od prohlížeče (query), na konci je odpověď poslaná zpět do prohlížeče (response). To, co je mezi tím, by teoreticky měla být "jen" transformace, ve skutečnosti tam samozřejmě bude nějaká změna vnitřního stavu (logy, zápisy do DB, update stavu session), ale to je dobré co nejvíce izolovat.
3) to "něco", co drží stav toolu popř. session, se klidně může implementovat přes OOP, ale nemusí, však mnohdy stačí i mapy, vektory, pole atd. (ale kdo chce a je placený od počtu řádků:) klidně nechť si nechá vygenerovat value objekty - ostatně už to, že to dokáže vygenerovat IDE znamená, že tam vlastně žádná podstatná funkcionalita není přidána :) Ostatní části transformace jsou čisté funkce NEpřistupující ke globálním datům a bez vedlejších efektů. Potom je testování mnohem jednodušší, protože se oblast testování vlastně redukuje na jedinou izolovanou funkci se vstupy a výstupy, bez dalších vazeb na okolí.
Určitě to není čistě FF přístup, v žádném případě to není čistě OO přístup, ale tím, že se soustředím na tu transformaci dat (či jejich tok) se mě to daří udržet v konzistenci bez nutnosti tvořit velkou hierarchii objektů.
ČLÁNKY DO MAILU