Názory k článku Underscore aneb další knihovna pro funkcionální programování v JavaScriptu
-
Pavel TišnovskýZlatý podporovatelTo je pravda, lodash je taky zajimava knihovna. Asi zalezi na mistnich podminkach, protoze Underscore je taky hodne pouzivany.
-
Pavel TišnovskýZlatý podporovatel
Porad je navic Underscore pekne minimalisticky, jeden minifikovany soubor se vsim ma po gzipu (aby se to dalo porovnat) necelych 6kB. Ale jak rikam, obe ty knihovny jsou uzitecne, hlavne pro jazyk se semantikou JS :)
-
Tomas (neregistrovaný)
Zda se ze reseni na otazku ktery z tech dvou je in progress https://github.com/underdash/underdash
-
Pavel TišnovskýZlatý podporovatel
Tak to jsou asi hodne na zacatku :) Ale proc ne, evidentne tyto knihovny maji spolecny cil.
-
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ý podporovatel
Tak 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ů.
-
XMen (neregistrovaný)
No ja to poviem asi takto. Moda, kde sa zacal pouzivat javascript a to pomocou roznych kniznic je uplna nocna mora. Kazde zhruba 1-2 roky sa objavi nejaka super uzasna JS kniznica a vela blbcov ju zacne pouzivat. Kedze ich je vela zacnu ju pouzivat aj ostatny. Samozrejme kniznica sa po 2-3 rokoch zivotnosti prestane pouzivat, lebo uz nebude v mode alebo sa prestane supportovat (alebo moj oblubeny sposob ze sa rozforkuje). To co dnes tieto kniznice urobili je vlastne chaos. Co projekt, to ina kniznica. Tu sa samozrejme musite ucit a to znamena ze stale riesite defacto tie iste problemy. Navyse kod, ktory sa vytvori je z dlhodobeho hladiska neudrzatelny a migracia rozsiahlych aplikacii je prakticky nemozna (hlavne z financneho hladiska). Tento chaos nema konca. Stale sa vytvaraju nove a nove kniznice a riesia sa stale tie iste problemy, ktore sa ale defacto nikdy nedoriesia. Jedine co zostava je verit, ze sa presadi standard webassembly a posle cely svet JavaScriptu do hrobu. Bolo by super zas programovat v JAVE alebo .NETe aj na klientovi a neriesit, ci o 3 roky budem moct pouzivat stale ten isty jazyk alebo kniznicu. Treba navrat k mainstreamovym nastrojom a neriesit donekonecna rovnaku problematiku.
Go to hell JS.
Pozn. robil som v knizniciach: underscore,knockout,extjs,kendo,backbone,angular, angular2, a ine wtf kniznice a to za posledny rok a pol. Osobne si myslim, ze mi to ubralo aspon 5 rokov mojho zivota ak nie viac a zacinam trpiet syndromom vyhorenia. Ako keby som sa nedokazal dostat za ten cas inam. Mam uz dost tychto super funkcionalnych programovacich jazykov ako jsF*ck (za * dostadit u) a jeho esoterickych inkarnacii v podobne "super genialnych" kniznic.
-
Pavel TišnovskýZlatý podporovatel
Tak s tím se dá částečně souhlasit, JS svět je skutečně "neintegrovaný", což ale nemusí být vždycky na škodu. Já třeba osobně nemám až tak moc problémů s tím, že se nějaká knihovna přestane vyvíjet. Jako co se stane? To zrezaví nebo se z ní stane nějaká zombie, popřípadě to rozbije počítač? Prostě budeš mít ve svém projektu starou knihovnu no, však stejně to většinou řeší jen client-side, kterému nikdo nevěří a na server-side si všechno znovu a znovu ověřuje.
A z projektů postavených na Javě, na kterých jsem dělal, to teprve byly staré knihovny a verze JVM. Kupodivu dost kódu, s kterým se všichni nepřímo setkáváme, jede pořád na 1.4.2, některé na 1.5, ti jo dobří přešli na Javu 6 (a to tady máme osmičku).
PS: já nejsem skalní zastánce JS, spíš naopak, ale ten jazyk se kromě jiného prosadil i velkou elasticitou a tím pádem i mnoha způsoby, jak věci řešit. COBOL z toho nikdy nebude :D
-
XMen (neregistrovaný)
No mrtva kniznica moze znamenat hlavne nebezpecie. Co ak sa tam najdu nejake problemy? Kazdy dobre vie, ze na rozumnej platforme (java alebo .net) dnes defacto neexistuju sql injection utoky, pretoze to mali osetrene hned. Zato take PHP weby su uplna chutovka. Pri JS utokoch je to vsak ovela horsie. Preto ak sa vyskytne nejaky problem na mrtvej kniznici je to vyslovene na vas ako sa k tomu postavite a ci ten problem vobec objavite skor nez niekto druhy. Dalsi problem je to, ze JS kniznice maju velmi kratku nazvyme to "moralnu zivotnost". Kazdy ma pocit ze dalsi projekt musi urobit v inej kniznici, ktora je prave v mode. V neposlednom rade ide aj o podporu roznych features, ktore dostanete v supportovanej kniznici ale v mrtvej je to uz vsetko na vas, cim sa vyrazne predrazuje projekt ako penazne tak aj casovo. Mozno by nebolo od veci, keby sa zacali ludia zamyslat nad tym, kolko tento chaos predrazuje samotne projekty. A taktiez aj nad tym, cim su prinosne nove kniznice, ktore robia iba veci inak ale v podstate riesia to iste alebo ich charakter ich predurcuje k dobremu rieseniu iba pri niektorych situaciach.
Co sa tyka javy tam vidim vyhodu v tom, ze vas nikto nenuti pouzivat features z java 8 alebo 7 alebo 6 a dokonca aj 5. Je to cisto na programatorovy ci to pouzije ale hlavne je to, ze sa dodrziava kompatibilita. Prechod z verzie java 1.2 na java 8 je bezproblemovy a teda aj 19 rocne aplikacie je mozne dalej upravovat. to je velka sila javy. To pri mrtvych JS knizniciach robit nemozte
PS: To ze ukazal vela moznosti akymi riesit problemy nemusi byt dostatocne, ked sa stale riesia tie iste. Navyse maloktora kniznica ich riesi vsetky a preto sa ludia uchyluju k roznym ohybaniam kniznic a ako som uz vela krat pisal, defacto riesia na kazdej kniznici tie iste problemy.
-
Pavel TišnovskýZlatý podporovatel
Jo já souhlasím, akorát prostě svět není ideální no :-) Dopředu se dá těžko říct, co a jak bude udržované, samozřejmě JS komunita je (pravděpodobně, ale já jsem o tom pevně přesvědčen) složená z mladších vývojářů, a ti nemají problém něco forknout, vytvořit novou knihovnu, starou zahodit atd. Tak to prostě je, navíc samotný JS je v základu dodáván jen s pár funkcemi, což to dělá ještě horší (tu funkcionalitu je zapotřebí nějak přidat). To, že kdyby se namísto JS prosadil jiný jazyk a vše mohlo být jinak, je pěkná debata, je to tak, ale co nadělat :-) [jestli si dobře pamatuji, tak jediní dva trošku vážnější konkurenti byli TCL a VBScript, takže to možná až tak nejhůř nedopadlo].
Já tedy vidím obecně větší problém v home made knihovnách, protože i pro starou JS knihovnu se dá něco sehnat, někdo to napsal, udělal docku atd., prostě se už v minulosti stalo něco, co lidi přesvědčilo o tom tu knihovnu použít. Pro home made (DYI) knihovny většinou není docka, testy nic (a to si sám sypu popel na hlavu, párkrát jsem si něco zbytečně implementoval sám a potom si to taky udržoval :/).
-
Pavel TišnovskýZlatý podporovatel
Jinak k Javě: jsem psal, že hodně kódu "jede" na 1.4.2, 5.0 či 6.0. Myslel jsem tím JVM, takže ti lidi z mnoha různých (někdy dost divných) důvodů musí používat starší JVM. I přes snahu vývojářů a QA JVM (kam jsem taky pár let patřil :-) totiž není kompatibilita stoprocentní a pro echt business aplikace prostě firmy raději zaplatí za udržování starší JVM než riskovat nějaké problémy. Je fakt, že v API se nejvíce změnilo mezi 7 a 8, jinak jak píšeš je to zdánlivě bez problémů, ale chování je někdy trošku odlišné, většinou různé corner cases. Ale tomu se prostě nejde u tak velkého nástroje vyhnout.
Btw co se týče verzí - je zajímavé se na to zeptat lidí udržujících Pythoní balíčky a projekty. Ti jsou taky "nadšení" z toho, že mají Python 3.x a Python 2.x, takže 2x tolik práce.
-
ivan (neregistrovaný)
Lodash / underscore je fajn, ale jak se posouvá javascript (babel), tak se dá bez těchto knihoven dýl obejít. Viz třeba https://github.com/cht8687/You-Dont-Need-Lodash-Underscore
-
atarist (neregistrovaný)
To sice jo, ale kazda ta transformace znamena, ze chybova hlaseni, krokovani apod nebudou sedet na puvodni zdrojak. Ted se priznam ze nevim, jestli Babel tvori mapy pro debugger, asi jo, ale i tak je to dalsi opaque vrstva. To uz radeji ty _ knihovny :) [dneska, samozrejme az bude nova ECMA vsude, je to neco jineho]
