Vlákno názorů k článku Funkce vyššího řádu v knihovně Underscore od WWW - Nemůžu si pomoct, ale tahle knihovna mi přapadá...

  • Článek je starý, nové názory již nelze přidávat.
  • 15. 3. 2016 15:40

    WWW (neregistrovaný)

    Nemůžu si pomoct, ale tahle knihovna mi přapadá jako naprosto zbytečná. Při pohledu do seznamu všech funkcí v knihovně jsem našel jenom pár, které nejsou buď dávno přímo v jazyce nebo u kterých stojí za to vůbec vytvářet funkci. Pár let zpátky asi to asi význam mělo, ale k čemu je to dobré teď?

  • 15. 3. 2016 16:19

    Pavel Tišnovský
    Zlatý podporovatel

    Success story sem z několika důvodů dávat nebudu, ale jen podotknu, že pokud existuje funkce, která danou oblast už implementuje, tak ji Underscore použije (třeba map apod.). Pokud neexistuje - což je zcela normální, a to nejenom na klientovi - tak si použije svoji implementaci se stejným chováním. Podle mě je to prakticky ideální chování, navíc to nijak nezasahuje do standardních objektů (což dělají některé jiné knihovny).

  • 15. 3. 2016 23:10

    WWW (neregistrovaný)

    Osobně radši sáhnu třeba po Babel a budu psát obyčejný JS, srozumitelný komukoliv bez nutnosti znát další knihovnu ;-) Případně jsou tady polyfy(ES5, ES6), které sice zasahují do standardních objektů, ale při dodržování best practices to podle mě v podstatě ničemu nevadí.

  • 16. 3. 2016 10:25

    Pavel Tišnovský
    Zlatý podporovatel

    Jasně, to je taky jedna z možností. Já si tedy osobně nemyslím, že zrovna Underscore je vhodné pro všechno, ale tady v seriálku o Mori+Undersco­re+(možná)Immu­table.js má místo, protože je asi nejjednodušší a kupodivu toho nabízí hodně, i tu výše zmíněnou memoizaci. Interně jsou to všechno dost jednoduché věci, proto i Underscore není žádný moloch, naimportuju ho všude a pořád píšu ten zmíněný obyčejný JS :-) [protože když už se drbat s překladačem, tak to můžu rovnou JS nahradit něčím rozumnějším, ale jak říkám, to je můj osobní názor člověka, který má trošku jiný background, než frontendy]

  • 17. 3. 2016 7:16

    WWW (neregistrovaný)

    To "drbání s překladačem" znamená dva příkazy v terminálu :-) Pokud vás to dokáže přimět až k uvažování o změně jazyka, pak přenositelnost kódů z jednoho programátora na druhého asi není zrovna vaše priorita a nemá smysl řešit ani ignorování standardních prostředků jazyka. Taky nemám background ve frontendech, ale připadá mi to jako antipattern, byť použitý s dobrým úmyslem(kompa­tibilita). Memoizace proč ne, to je ostatně jedna z těch asi pěti věcí, které bych z celé knihovny využil. I ta by ale šla řešit efektivněji(výkon) s použitím standardních prostředků(Map, WeakMap).

  • 17. 3. 2016 10:38

    Pavel Tišnovský
    Zlatý podporovatel

    Jo já vím, ale pořád to podle mě vyjde nastejno:

    1) mám na GITu normální, standardní, 10 let zpětně kompatibilní JS kód, který na začátku importuje jednu knihovnu ve jmenném prostoru _. Problémy? Stáhne se přibližně 5kB gzippovaný soubor, nic víc, nic míň, jede to s velkou pravděpodobností všude, i v Rhinu (což zrovna trápilo mě, protože pár velkých Java aplikací se takto rozšiřuje).

    2) mám na GITu na první pohled jakoby normální JS kód bez knihovny, který obsahuje buď nějakou formu Makefile (přiznám se, že nevím, co teď v JS světě letí) popř. instrukce jak to transformovat a spustit, pokud uživatel zrovna nemá štěstí, nebo když ten buildovací nástroj nepochopí závislosti (dobře to možná není férové, protože ty projekty se nebudou překládat hodiny, ale...).

    Ani jedno z toho nevidím jako nějaký nepřekonatelný problém (a určitě méně problematický než například skripty typu 2to3, tam je snaha dobrá, ale prostě to skřípe).

  • 17. 3. 2016 11:24

    WWW (neregistrovaný)

    Funguje to tak, že kód napsaný v současném standardu kompiler překlopí do standardu staršího. Řeší to mimochodem třeba i problémy jako v článku zmiňované chování smyček a hromadu dalších nepříjemností. Pro použití takového zkompilovaného kódu není následně potřeba dělat vůbec nic. Pro provedení změn stačí jedním příkazem spustit watcher(případně nějaký task runner, pokud se toho s kódem dělá víc) a o nic dalšího není třeba se starat. Proti použití underscore mám v zásadě to, že dneska to působí spíš jako nějaký relikt z doby deset let zpátky než jako něco vhodného k doporučení.

  • 17. 3. 2016 13:14

    Pavel Tišnovský
    Zlatý podporovatel

    "Proti použití underscore mám v zásadě to, že dneska to působí spíš jako nějaký relikt z doby deset let zpátky než jako něco vhodného k doporučení."

    aha pokud je problém tady, tak to je vlastně v pořádku, protože ten seriál směřuje k porovnání podobných knihoven s novou ECMA (jak jsem psal, bude to minimálně Mori vs Underscore vs Immutable.js, se všemi rozdíly, které mezi těmi řešeními jsou = nejde o ekvivalenty). Resp. plan je to porovnat se sestkou, mozna by ale bylo jeste zajimavejsi zahrnout soucasnou variantu sedmicky.

  • 17. 3. 2016 10:48

    Pavel Tišnovský
    Zlatý podporovatel

    "Pokud vás to dokáže přimět až k uvažování o změně jazyka, pak přenositelnost kódů z jednoho programátora na druhého asi není zrovna vaše priorita a nemá smysl řešit ani ignorování standardních prostředků jazyka"

    to na mě platí prakticky na 100% :-) Vzhledem k tomu, že moje tooly dělané poslední dobou jsou relativně jednoduché, ale musí komunikovat s dalšími nástroji, tak je důležité především zajistit korektní chování na úrovni API, to je alfou omegou úspěchu a dlouhodobé stability celého ekosystému.

    Jestli jeden tool je v Pyhtonu, Ruby (ten je nejpomalejší :-) nebo v C, není až tak podstatné, já to stejně neovlivním a ať si to klidně každý měsíc přepíšou, když dodrží API. Takže v tomto případě - a s přihlédnutím na to, že všechno by mělo být hotové nejlépe ASAP a je to v podstatě one man show - vítězí volba jazyka, ve kterém se dají implementovat algoritmy velmi rychle (a efektivita je až na třetím místě za testovatelností). JS do toho moc nezapadá (je tady v něm jedna aplikace na node.js), ale prostě někdy je potřeba sáhnout i na ten frontend no :-) Proto se taky nebráním transpilerům, to vůbec ne, spíš naopak.

  • 17. 3. 2016 11:37

    WWW (neregistrovaný)

    Do zákulisí toho projektu nevidím, takže si netroufám soudit, třeba je takový přístup v tomhle konkrétním případě opravdu efektivní.

    Obecně se ale snažím za každou cenu neopakovat chyby ostatních. Jeden příklad za všechny: v GitHubu při vývoji Atomu sáhli po CoffeeScriptu, aby urychlili vývoj ušetřením pár znaků kódu. A to je přece super, dokonce se taková úspora času dá i spočítat. Uplynul ale nějaký čas a teď se potýkají s nedostatkem doplňků a potažmo vývojářů, v CoffeeScriptu totiž víceméně nikdo neprogramuje(a upřímně s příchodem ES6 to pozbylo i ten sporný význam, který to kdysi mělo). Čili z úspory času je rázem naprosto ukázková střelba do vlastní nohy.

    Stejně tak můžete svůj webový projekt napsat ve Scale, Smalltalku nebo rovnou v Cobolu a mít dobrý pocit, jak jste na to tím "rozumnějším jazykem" vyzráli. Minimálně do chvíle, kdy budete potřebovat rozšířit tým. U webařů Smalltalk zrovna dvakrát nefrčí a na úpravy kódů vyjetých z kompileru vám nezdrogovaný člověk nekývne. Nakonec stejně v zájmu zachování zdravého rozumu nezbyde, než celý projekt přepsat do JavaScriptu.

    Tolik zase k mojim pohnutkám. Jinak vás uznávám, prošel jsem si pár vašich článků a vy určitě víte, co děláte nebo se minimálně dokážete poprat s následky.

  • 17. 3. 2016 21:18

    Pavel Tišnovský
    Zlatý podporovatel

    To je zajímavé, o těch problémech s vývojáři pro Atom jsem nevěděl a dává to smysl. Jen pro zajímavost a pro potvrzení vaší myšlenky jsem se podíval na Ohloh (dneska OpenHub), kde sice nejsou sledovány úplně všechny OS projekty, ale asi ta statistika nebude úplně špatná:

    https://www.openhub.net/languages/compare?utf8=%E2%9C%93&measure=commits&language_name[]=-1&language_na­me[]=coffeescrip­t&language_na­me[]=haxe&lan­guage_name[]=ja­vascript&langu­age_name[]=-1&commit=Update

    (chtěl jsem tam hodit i Dart a TypeScript, ale ten pravděpodobně nedokážou rozpoznat, takže jen JS, Haxe a CoffeeScript).

    Já s tím, co píšete, naprosto souhlasím. Kdybych byl někdy v pozici nutnosti řízení většího projektu, kde se mi budou střídat programátoři (což je na nezajímavých projektech běžné), tak v normální situaci nemá smysl jít do něčeho exotického, ostatně proto to v mnoha projektech vyhrává například Java(Script). Prostě díky zpětné vazbě najdu programátory na trhu, ti naopak ví, že najdou uplatnění atd.atd.

    Teď jsem spíše v situaci, která tuším panovala v Amazonu, kde co projekt, to jiný jazyk (teď samozřejmě přeháním). Vyřešili to tak, že se stanovilo API, to se prostě dodržovalo a udržovalo a projekty normálně běžely dál. Nakonec to bylo k dobru věci, protože teď bez problémů dávají do cloudu celkem cokoli a nejsou orientováni na jednu platformu.

    A ještě v jiné situaci byl Paul Graham, když psal Beating the averages (ovšem kdyby to psal dneska, tak by určitě vzal JS - který nezmiňujě - na milost, ten jazyk se hodně změnil a pěkně zlispovatěl, což je dobře :-)

  • 18. 3. 2016 10:04

    uetoyo (neregistrovaný)

    To vypadá, že u vás frčí Microservices :); Jinak k tomu Makefile v JS projektech... je to zcela aktuální, mnoho velkých věcí ho stále standardně (a úspěšně) používá vedle npm skriptů (případně Gulp/Grunt). Node.js (npm) začíná být nutnost i pro frontend + WebPack/Babel je fajn.

    https://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/

  • 19. 3. 2016 16:12

    Pavel Tišnovský
    Zlatý podporovatel

    Ano je to tak, ještě že to má takové cool pojmenování :-) Asi začnu říkat našemu ftp serveru cloudový storage system.

    Ten článek je zajímavý (pěkně ten vývoj jde po spirále :-), akorát mě trošku překvapuje, že tam mají nodejs jako viditelný endpoint pro klienty (a ne nějaký httpd se statickým obsahem a proxy na nodejs). Ale možná jen nechtěli ty obrázky dělat moc složité.

  • 15. 3. 2016 20:53

    atarist (neregistrovaný)

    Uz jsme to resili v diskuzi minule, v podstate jde o to, ze ne vzdycky mas k dispozici posledni ECMA. Jeden tezkej klient (od nejmenovane tripismenkove firmy :) napriklad pouziva Rhino z Javy, to ma (nebo melo) k posledni ECMA dost daleho, coz porad prinasi problemy.

  • 15. 3. 2016 20:59

    atarist (neregistrovaný)

    Abych jen tak plane nemluvil, ona ta kompatibilita je nekdy dost osemetna:

    http://kangax.github.io/compat-table/es6/

    A to tam nemaji zdaleka vsechny JS interpretry, s kteryma se da porad setkat.

  • 16. 3. 2016 10:53

    ivoszz

    A právě na to je Babel. Který vám z docela široké podpory ES2015 vygeneruje čistý ES5. Když k tomu použijete navíc ještě webpack, pak můžete mít ve vysledku jen jeden soubor včetně všech závislostí. A to nemluvím o bonusech jako třeba vyhození všech vámi nepoužívaných knihovních funkcí.