Názory k článku Funkce vyššího řádu v knihovně Underscore

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).

"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.

"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.

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 :-)

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é.