devel.cz

Question

Je lepší Flow, alebo Typescript? rubrika: Programování: JavaScript

Anonym

položil/-a 2.12.2017

upravil/-a 2.12.2017

Nie som zrovna zástanca rozšírení ako TypeScript, plne súhlasím s týmto článkom. Ale je pravda, že občas sa dátové typy hodia, hlavne u komplikovanejších projektov. Lenže ak použijem TS, musí byť všetko "TS" - to je to, čo mi nevyhovuje a chýba mi funkcionalita z PHP7. Tam proste dátové typy nemusím používať, ale kde sa to vyslovene hodí, tak ich nadefinujem a je vybavené. A to je prakticky to, čo ponúka Flow. Statické typy len tam, kde ich vyslovene chcem - bez nutnosti používať ich v celom projekte. Čo má aj inú výhodu - ak už je projekt rozrobený, začať používať TS znamená nutnosť najskôr prepísať - doplniť - všetok už hotový kód o definície typov. Kdežto s Flow môžem proste zrazu začať používať statické typy a predošlý kód nemusím meniť hneď, doplním tam typy podľa potreby kedykoľvek neskôr...

To je však len môj pohľad na vec, po predchádzajúcom naštudovaní základov TS a Flow, lebo chcem začať používať statické typy. Preto ma opravte ak sa mýlim, plus dajte vlastné postrehy z praxe prečo to, či ono... Ď.

Komentáře

harrison314 : Nie je to celkom tak, v TS zapnes imlicit any, a vsetok JS kod je automaticky validny TS, plus novsie verzie TS vedia inkludovat JS kod bez problemov a umoznuju vyuzivat tony JS kniznic, z ci bez definicnych suborov. — 2.12.2017
Jakub Macek : Podpořím předchozí komentář. TypeScript jsem si proti jiným jazykům kompilovaným do JS vybral právě proto, že je zpětně kompatibilní s JS. Tak trochu nutno kvůli zpětné kompatibilitě s kolegy :) — 3.12.2017
Josef Ježek : Jestli souhlasis s uvedenym clankem, tak TS v urcitych use cases neni treba. Kdyz komplexni kod rozdelis mezi moduly, ktere mezi sebou komunikuji pres API s doc, tak lze TS vynechat. Na front-endu pro to mame webove komponenty. Na back-endu zas microservisy, viz napr tyto https://github.com/firebase/functions-samples — 3.12.2017
Anonym : Nie celkom chápem Jakub ako si si mohol vybrať TS, keď pre Teba bola priorita spätná kompatibilita s JS. Aj Flow, aj TS sú kompatibilné s netypovaným kódom, ale v tomto je zrovna lepší Flow - ďaleko jednoduchšie použiteľný s / v netypovanom kóde. — 3.12.2017
Anonym : Neviem si ani predstaviť Jozef, čo by mohol mať Flow / TS spoločné s architektúrou aplikácie. A keď už, možno zrovna pri modulárnej aplikácii s veľkým nezávisle vyvíjaných modulov, by som pre istotu siahol po Flow / TS. — 3.12.2017
Josef Ježek : Tak se podivej do katalogu webcomponents.org, kolik modulu pouziva TS. A kolik mikro sluzeb pomoci Firebase Functions pouziva TS? — 3.12.2017
Josef Ježek : Kdyz mame tolik cli toolu a pluginu pro editory, ktere nas hlidaji a pomahaji nam, tak proc prasit cisty kod, ktery pak nebude citelny pro vsechny? TS pak svadi jen pouzivat novy jazyk, ktery neni standardizovany, tim padem neni udrzitelny. — 3.12.2017
Josef Ježek : To je jen dalsi loby od MS. :-/ Aby MS byl alespon trochu videt. Kdyz doted nic poradneho nedokazal. ;-) — 3.12.2017
harrison314 : @Josef Ježek: skus si pred tym, ako nnieco napises zistit nieco o TS.Tvoje dva posledne komenty nemaju s realitov nic spolocne. — 3.12.2017
Josef Ježek : https://medium.com/@richardeng/ive-used-many-programming-languages-over-... — 3.12.2017
vojta.tranta : @Josef Ježek Josefe Josefe, ta vaše láska k jedné technologii vás zabije. Technologie nejsou holky, abyste omlouvali to, že neumí vařit tím, že je hezká. Nevybírejte si články podle toho, jeslti souhlasí s vaším světonázorem, ale čtěte ty, které s tím nesouhlasí. — 6.12.2017
Kit : @vojta.tranta: Obvykle čteme všechny články a prezentujeme ty, se kterými souhlasíme. Statické typování ničemu nepomáhá, pouze překáží při psaní i při čtení. — 6.12.2017
Kit : http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html - když někdo používá TDD, statické typování je mu jen na obtíž. — 6.12.2017
harrison314 : @Kit: "TDD replaces a type checker in a dynamically typed language in the same way that a bottle of whisky replaces your daily problems" - https://twitter.com/mattgumbley/status/727140296912441345 — 6.12.2017
Kit : @harrison314: Tohle přirovnání kulhá na obě nohy, protože nenese žádnou relevantní informaci. Typová kontrola prostě nikdy nezvládne to co TDD. — 6.12.2017
harrison314 : @Kit: ja viem, ze TDD zvladne viac. Ale ulohou TDD nie je kontrolovat syntax kodu ani pouzite typy a preklepy programtora. Ja s tym twitom uplne suhlasim. — 6.12.2017
Kit : @harrison314: TDD nekontroluje syntaxi, to dělá překladač i v interpretrech. Překlepy programátora typovou kontrolou také neodhalíš. Dokonce typovou kontrolou neodhalíš ani špatný typ obsahu proměnné, když je v ní null. — 6.12.2017
harrison314 : Kit bud trolujes, alebo si v zivote nevidel kompilovany jazyk. " TDD nekontroluje syntaxi, to dělá překladač i v interpretrech." - ten citat bol prave o zneuzivani TDD na nieco taketo, videl som to mnohkrat u Rubistoch aj PHP-ckaroch, robia s testovania nieco co nie je. Dokonca sam som bol nuteny robit integracne testyna REST-ove sluzby, kvoli testu konzistnetnosti a preklepoch. "Překlepy programátora typovou kontrolou také neodhalíš." - dovol mi aby som sa zasmial, toto uz naozaj trolujes, alebo zijes vo vlastnom svete. "Dokonce typovou kontrolou neodhalíš ani špatný typ obsahu proměnné, když je v ní null." - v styticky typovanych jazykoch nentlacis zly typ, lebo ti to kompilator otrieska o hlavu. Null je kapitolsa sama o sebe, ale to sa da elegantne riesit (nevracat null, kontrolovat argumenty na null, Null objekt). — 6.12.2017
Anonym : @harrison314 Silně typovaný jazyk je fajn, jestli statický nebo dynamický, to je jiná otázka. Dej si pohov s Rubisty, PHP-káři prosím, trochu respektu by neškodilo. "v styticky typovanych jazykoch nentlacis zly typ" Ve staticky typovaných jazycích natlačíš špatný typ ... statické typování neznamená silné -- podle mne si pleteš pojmy. — 7.12.2017
harrison314 : Sam som bol PHP-ckar :D a hej su pripady, ked v staticky typovom jazyku dopremennej natlacis nieco ine, no kedze pouzivam silnejsie typove, tak sa s niecim takym velmi nestretvam — 7.12.2017
vojta.tranta : Já píšu "téměř" TDD a prostě vidim a jasně vim, že typy odhalujou zcela jinej typ bugů než testy. Ano, typy odhalí překlepy. Ano, jsou tady silně typované statické jazyky, kde je to typování otravné a zdržující (Java). Pak tu jsou jazyky, kde je silné statické typování skvěle udělané a je perfektní pomocník (Haskell, Elm, Reason...). Pak tu jsou jazyky, které jsou dynamické, ale silně typové a dají se slušně používat (Python). NO a pak tu jsou jazyky na hovno, které jsou slabě a dynamicky typované a je v nich příšerně bugů - Javascript. Měly bychom se ale univerzálně shodnout na tom, že když někam posílám string a má tam být pole, tak je můj program prostě blbě. Čím dřív na to přijdou, tím líp. Pokud mám jazyk, který nedovoluje existenci takového kód - například Elm nebo Haskell - pak to je největší pomoc, co mám. — 7.12.2017
Taco : @vojta.tranta: K čemu jsou v Pythonu typy? (A to nepíšu proto, že bych Python neznal.) — 7.12.2017
Kit : @harrison314: Pokud jsou v kódu syntaktické chyby, tak nejde zkompilovat - není tedy ani co testovat. To platí v Javě i v PHP. — 8.12.2017
Anonym : @vojta.tranta které jsou slabě a dynamicky typované a je v nich příšerně bugů - Javascript <- Príšerne veľa bugov v JavaScripte? Môžeš to upresniť? Pretože si myslím, že kecáš - hejtuješ. — 8.12.2017
Kit : @vojta.tranta: Na začátku každé funkce a metody je třeba si ověřit, že vstupní data jsou v pořádku - typová kontrola na to nestačí. Navíc je mnoho metod, které mají připouštět na vstupu pole, string, int nebo null a všechny musí umět zpracovat. — 8.12.2017
Anonym : @Taco "K čemu jsou v Pythonu typy?" Pro tohle: TypeError: unsupported operand type(s) for +: 'int' and 'str'. Bohužel tohle často vyskočí až za běhu. Type hints jsou sice lákavé a sám je píšu, ale zase se neuvěřitelně natahujou signatury, navíc je úzus stejně tohle psát do dokumentace a pak to vlastně píšeš dvakrát -- no je vidět že je to do jazyka zatím tak nějak nalepené."https://www.reddit.com/r/Python/comments/5nb0si/why_optional_type_hinting_in_python_is_not_that/". Nejvíc chyb stejně bývá na hranici vstup od uživatele nebo při parsování nějakého souboru při dolování dat. Co je blbý na jazycích jako Python, je že se to hrozně blbě refaktoruje. — 8.12.2017
Taco : @uetoyo: Jo, když by se tohle takhle chovalo, tak by to bylo fajn, ale ono nechová. (S typehinty od 3.6 jsou zajímavou změnou.) Už tu tuším na tohle téma byl nějaký flame. V Pythonu jsou typy jen na okrasu. Ano, objekt má nálepku, že je to int, a když máš štěstí, tak v té či oné funkci je nějaký assert, který tu nálepku zohledňuje, ale jinak se prostě nepoužívají. Je to jen na to, aby se na wikipedii mohlo napsat, že má silnou typovou kontrolu. Ale nemůžu se zbavit dojmu, že je to jen takovej kec. *** Omluvám se, odbočuju od tématu této otázky. — 8.12.2017
Anonym : @Taco Tak ty flamy nevyvolávej :D. Python ti nepřevede číslo na řetězec tím že se mu budeš snažit podsunout `1 + "1"` -- je silně ale dynamicky typovaný. Zřejmě v něm neprogramuješ, takže ti přijdou na okrasu -- to chce cvik. BTW: PHP udělá co při `1 + "1"? ... Jo, koukám vrací 2 -- paráda, ale žít se s tím asi dá (JS vrací '11' :D). "Jo, když by se tohle takhle chovalo, tak by to bylo fajn, ale ono nechová." Ale chová, otevři konzolu a zkus si to. — 8.12.2017
Kit : Python: print('2' * 2) :) — 8.12.2017
Anonym : @Kit Ale to bys musel vědět, proč to tak, je. Rozhodně ne proto, že by si to někdo záhadně nacpal do jazyka, ale protože String má přetížený operátor `*` právě pro generování sekvencí -- řetězců: `print('a' * 10) >> aaaaaaaaaa` -- tady se neprovádí žádná implicitní konverze! > s * n, n * s equivalent to adding s to itself n times: https://docs.python.org/2/library/stdtypes.html#sequence-types-str-unico... — 8.12.2017
Kit : @uetoyo: Vím, proč to tak je. Je to právě důsledek silného typování a je to tak správně. Lisp takovou operaci odmítne, protože * neumí přetížit. — 8.12.2017
Anonym : @Kit "Lisp takovou operaci odmítne, protože * neumí přetížit" A to je taky fajn; operátory umí být nepřehledný. — 8.12.2017
Kit : I v tom Pythonu to může být zrádné. Napíši si funkci, která má za úkol vynásobit 2 parametry. Pak ji někdo zavolá, jako první parametr dá omylem string (např. ze vstupu) a nestačí se divit. — 8.12.2017
Taco : @uetoyo: Nerozumíme si. `1 + "1"` odmítne proto, protože funkce `+` má v sobě assert. Což je fajn. Ale neznamená to, že by Python byl silně typovaný. Znamená to, že někdo pro objekt Integer nezapoměl validovat vstup. Něco takového jde dělat úplně stejně v Javascriptu, PHP, Lue. (Pro uživatelské typy. S vestavěnýma se toho moc už dělat nedá.) — 9.12.2017
Anonym : @Kit Tohle beru, to je právě nevýhoda duck-typing; podobně funguje C++ s šablonama - pokud je pro parametry definovaný operátor, projde to @Taco Já tě chápu ale nemáš pravdu. Jde o to, že Python ti *neprovede implicitní konverzi* -- JS ano, PHP ano. Operátor projde jen když je pro levou stranu definován, tj. pokud existuje metoda __add__() -- kterou ale musíš sám definovat -- jestli blbě, je tvůj problém. — 9.12.2017
Taco : @uetoyo: "Python ti *neprovede implicitní konverzi*" - v tomhle máš žel (pro PHP) pravdu. Je otázka, zda to v praxi je k něčemu dobré. Ano, v PHP se mi občas automaticky spojí text s objektem, který má definovanou __toString() metodu, aniž bych to chtěl. Jenže v PHP si mohu zajistit, aby mi jako argument metody šla jen hodnota konkrétního typu. To v Pythonu (do verze 3.6) nejde. PHP je sice jazyk hnusnej a občas děsně zmatenej, ale práci s typy má zmáknutou mnohem lépe než Python. Protože je fakt používá. — 9.12.2017
Anonym : @Taco Chtěl sem se právě vyhnout nějakému obecnému hodnocení. Neznám PHP, jak používá typy lépe? Jinak `type hints` jsou už od verze 3.5 a některá IDE to umí docela použít. Pro mne je důležitá syntaxe, jak se mi kód čte a v tomhle mi PHP nevyhovuje, to už radši JS a stejně tak mne bolí Haskell a čtu lépe OCaml, ale to je už na jinou debatu. Pamatuju si že tu jednou někdo psal, že dnes je všechno typ String, což je v rámci webu docela trefný. @vojta.tranta Reason (BuckleScript) vypadá rozumně, má to u vás někdo povolený v práci? — 9.12.2017
Taco : @uetoyo: Programování je hodně o emocích :-) Já jsem se na Python strašně dožral právě kůli těm typům. Zápis má naprosto famózní. Struktura pomocí odsazování, podtržítkové magic funkce, implicitní self, metaclass, anotace - na to se děsně rychle zvyká. Ale ty typy, ty typy! :-D — 9.12.2017
Kit : @uetoyo: V PHP jsou typy nepovinné, ale když už je použiješ, jsou kontrolovány. Totéž s rozhraním. Obojí používám všude, kde to má smysl. V Javě jsem povinné typování cítil jako opruz, v PHP nepovinné typování cítím jako benefit. — 9.12.2017
Anonym : @Kit @Taco Osobně mi nejvíc vadí rovnost definovaná referenčně. Většina potřebuju strukturální, přetěžovat pořád `eq` a `hash` je hrůza, sic by se stím dala dělat nějaká metaprogramovací magie. — 9.12.2017
vojta.tranta : @vladislav.ladicky - ano, hejtuju. Kecám? Psal jsi někdy javascript a máš pocit, že to je jazyk, kterej vývojáři pomáhá v tom, aby nepsal bugy? To asi těžko.. Já se Javascriptem už čtyři roky živim, takže to není tak, že bych "hejtoval" z nějaké "nenásiti", ale v praxi vidim, že Javascript je jeden ze zdrojů problémů. Představ si, že jsou jazyky, kde "undefined is not a function" nebo "cannot read property of null" nebo "cannot read property of undefined" prostě neexistujou. Takový chyby nemůžou nastat. Představ si javascript, kde takový chyby neexistujou. Kolik desítek procent bugů by najednou zmizelo ze světa. V práci jsme si prosadili statickou typovou kontrolu přes Flow type a to se už dá přežít. Když to srovnám s tou předchozí tragédií v čistém JS a Coffee scriptu, tak je to asi jako jako assembler a Java. Dřív jsm psával s Closure compilerem za zády a tehdy jsem Javascript obhajoval, že to není tak děsný. Když jsem ale viděl codebase, kde absolutně chybí jakákoliv typová kontrola... Tak jsem prozřel. Btw. já nepíšu nějaký jquery webíky, ale aplikačky, samozřejmě chápu, že lidem, co píšou takové menší věci jsou statické typové kontroly na obtíž. — 11.12.2017
vojta.tranta : @taco - měl jsem na mysli silné typování, to jak funguje jazyk. Né typové anotace. — 11.12.2017
vojta.tranta : @uetoyo ne, reason nepoužíváme a ani to neplánujeme. Vono s těma zlepšujícíma se nástrojema pro JS se ty rozdíly mezi Elmem, Reasonem, Purescriptem a JSkem postupně mažou. Respektive ty výhody nejsou dostatečně velký proto, abychom tu naší velikou codebase začali přepisovat. Dostali jsme se do bodu, kdy mám 70% Flow coverage na projektu a to je při refaktorování fest znát. Když to srovnám s loňskym rokem, kdy jsme měli ještě 90% kódu v Coffee scriptu, kde nefungoval ani Coffee Lint tak. PRostě nebe a dudy. NIkdy zpátky do čistého JS. (opakuji, že to neplatí pro každý projekt) — 11.12.2017
vojta.tranta : @kit > "Na začátku každé funkce a metody je třeba si ověřit, že vstupní data jsou v pořádku - typová kontrola na to nestačí" - tak to mi přijde dost WTF. Jasně, pokud tam posíláš wanabe json string, tak je jasný, že tam musíš normalizovat a validate. Ale když tam máš metoda(str: string) {} tak fakt nevidim důvod, proč by an tohle statická typová kontrola nestačila. Nebo mi dej nějakej příklad. Pře tomu nerozumim asi. — 11.12.2017
vojta.tranta : @kit: ještě jedna poznamka. Pokud tě štve číst typové anotace, což naprosto plěn chápu, tak si předtav, že jsou jazyky, jejižch typy vycházej přímo z kódu, kterej píšeš. Třeba takový Elm, Haskell nebo Reason to tak mají. Ty prostě ty typy nepíšeš, píšeš kód. NO a temn kód ti sám řiká, co v něm máš blbě a co prostě nebude fungovat, ani kdyby ses postavil na hlavu. Zkus se na to mrknout. Já jsem byl proti statickém typování stejně jako ty, než jsem zjistil, že se to dá dělat i dobře a užitečně a neotravně. — 12.12.2017

harrison314 : Nie je to celkom tak, v TS zapnes imlicit any, a vsetok JS kod je automaticky validny TS, plus novsie verzie TS vedia inkludovat JS kod bez problemov a umoznuju vyuzivat tony JS kniznic, z ci bez definicnych suborov. — 2.12.2017
Jakub Macek : Podpořím předchozí komentář. TypeScript jsem si proti jiným jazykům kompilovaným do JS vybral právě proto, že je zpětně kompatibilní s JS. Tak trochu nutno kvůli zpětné kompatibilitě s kolegy :) — 3.12.2017
Josef Ježek : Jestli souhlasis s uvedenym clankem, tak TS v urcitych use cases neni treba. Kdyz komplexni kod rozdelis mezi moduly, ktere mezi sebou komunikuji pres API s doc, tak lze TS vynechat. Na front-endu pro to mame webove komponenty. Na back-endu zas microservisy, viz napr tyto https://github.com/firebase/functions-samples — 3.12.2017
Anonym : Nie celkom chápem Jakub ako si si mohol vybrať TS, keď pre Teba bola priorita spätná kompatibilita s JS. Aj Flow, aj TS sú kompatibilné s netypovaným kódom, ale v tomto je zrovna lepší Flow - ďaleko jednoduchšie použiteľný s / v netypovanom kóde. — 3.12.2017
Anonym : Neviem si ani predstaviť Jozef, čo by mohol mať Flow / TS spoločné s architektúrou aplikácie. A keď už, možno zrovna pri modulárnej aplikácii s veľkým nezávisle vyvíjaných modulov, by som pre istotu siahol po Flow / TS. — 3.12.2017
Josef Ježek : Tak se podivej do katalogu webcomponents.org, kolik modulu pouziva TS. A kolik mikro sluzeb pomoci Firebase Functions pouziva TS? — 3.12.2017
Josef Ježek : Kdyz mame tolik cli toolu a pluginu pro editory, ktere nas hlidaji a pomahaji nam, tak proc prasit cisty kod, ktery pak nebude citelny pro vsechny? TS pak svadi jen pouzivat novy jazyk, ktery neni standardizovany, tim padem neni udrzitelny. — 3.12.2017
Josef Ježek : To je jen dalsi loby od MS. :-/ Aby MS byl alespon trochu videt. Kdyz doted nic poradneho nedokazal. ;-) — 3.12.2017
harrison314 : @Josef Ježek: skus si pred tym, ako nnieco napises zistit nieco o TS.Tvoje dva posledne komenty nemaju s realitov nic spolocne. — 3.12.2017
Josef Ježek : https://medium.com/@richardeng/ive-used-many-programming-languages-over-... — 3.12.2017
vojta.tranta : @Josef Ježek Josefe Josefe, ta vaše láska k jedné technologii vás zabije. Technologie nejsou holky, abyste omlouvali to, že neumí vařit tím, že je hezká. Nevybírejte si články podle toho, jeslti souhlasí s vaším světonázorem, ale čtěte ty, které s tím nesouhlasí. — 6.12.2017
Kit : @vojta.tranta: Obvykle čteme všechny články a prezentujeme ty, se kterými souhlasíme. Statické typování ničemu nepomáhá, pouze překáží při psaní i při čtení. — 6.12.2017
Kit : http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html - když někdo používá TDD, statické typování je mu jen na obtíž. — 6.12.2017
harrison314 : @Kit: "TDD replaces a type checker in a dynamically typed language in the same way that a bottle of whisky replaces your daily problems" - https://twitter.com/mattgumbley/status/727140296912441345 — 6.12.2017
Kit : @harrison314: Tohle přirovnání kulhá na obě nohy, protože nenese žádnou relevantní informaci. Typová kontrola prostě nikdy nezvládne to co TDD. — 6.12.2017
harrison314 : @Kit: ja viem, ze TDD zvladne viac. Ale ulohou TDD nie je kontrolovat syntax kodu ani pouzite typy a preklepy programtora. Ja s tym twitom uplne suhlasim. — 6.12.2017
Kit : @harrison314: TDD nekontroluje syntaxi, to dělá překladač i v interpretrech. Překlepy programátora typovou kontrolou také neodhalíš. Dokonce typovou kontrolou neodhalíš ani špatný typ obsahu proměnné, když je v ní null. — 6.12.2017
harrison314 : Kit bud trolujes, alebo si v zivote nevidel kompilovany jazyk. " TDD nekontroluje syntaxi, to dělá překladač i v interpretrech." - ten citat bol prave o zneuzivani TDD na nieco taketo, videl som to mnohkrat u Rubistoch aj PHP-ckaroch, robia s testovania nieco co nie je. Dokonca sam som bol nuteny robit integracne testyna REST-ove sluzby, kvoli testu konzistnetnosti a preklepoch. "Překlepy programátora typovou kontrolou také neodhalíš." - dovol mi aby som sa zasmial, toto uz naozaj trolujes, alebo zijes vo vlastnom svete. "Dokonce typovou kontrolou neodhalíš ani špatný typ obsahu proměnné, když je v ní null." - v styticky typovanych jazykoch nentlacis zly typ, lebo ti to kompilator otrieska o hlavu. Null je kapitolsa sama o sebe, ale to sa da elegantne riesit (nevracat null, kontrolovat argumenty na null, Null objekt). — 6.12.2017
Anonym : @harrison314 Silně typovaný jazyk je fajn, jestli statický nebo dynamický, to je jiná otázka. Dej si pohov s Rubisty, PHP-káři prosím, trochu respektu by neškodilo. "v styticky typovanych jazykoch nentlacis zly typ" Ve staticky typovaných jazycích natlačíš špatný typ ... statické typování neznamená silné -- podle mne si pleteš pojmy. — 7.12.2017
harrison314 : Sam som bol PHP-ckar :D a hej su pripady, ked v staticky typovom jazyku dopremennej natlacis nieco ine, no kedze pouzivam silnejsie typove, tak sa s niecim takym velmi nestretvam — 7.12.2017
vojta.tranta : Já píšu "téměř" TDD a prostě vidim a jasně vim, že typy odhalujou zcela jinej typ bugů než testy. Ano, typy odhalí překlepy. Ano, jsou tady silně typované statické jazyky, kde je to typování otravné a zdržující (Java). Pak tu jsou jazyky, kde je silné statické typování skvěle udělané a je perfektní pomocník (Haskell, Elm, Reason...). Pak tu jsou jazyky, které jsou dynamické, ale silně typové a dají se slušně používat (Python). NO a pak tu jsou jazyky na hovno, které jsou slabě a dynamicky typované a je v nich příšerně bugů - Javascript. Měly bychom se ale univerzálně shodnout na tom, že když někam posílám string a má tam být pole, tak je můj program prostě blbě. Čím dřív na to přijdou, tím líp. Pokud mám jazyk, který nedovoluje existenci takového kód - například Elm nebo Haskell - pak to je největší pomoc, co mám. — 7.12.2017
Taco : @vojta.tranta: K čemu jsou v Pythonu typy? (A to nepíšu proto, že bych Python neznal.) — 7.12.2017
Kit : @harrison314: Pokud jsou v kódu syntaktické chyby, tak nejde zkompilovat - není tedy ani co testovat. To platí v Javě i v PHP. — 8.12.2017
Anonym : @vojta.tranta které jsou slabě a dynamicky typované a je v nich příšerně bugů - Javascript <- Príšerne veľa bugov v JavaScripte? Môžeš to upresniť? Pretože si myslím, že kecáš - hejtuješ. — 8.12.2017
Kit : @vojta.tranta: Na začátku každé funkce a metody je třeba si ověřit, že vstupní data jsou v pořádku - typová kontrola na to nestačí. Navíc je mnoho metod, které mají připouštět na vstupu pole, string, int nebo null a všechny musí umět zpracovat. — 8.12.2017
Anonym : @Taco "K čemu jsou v Pythonu typy?" Pro tohle: TypeError: unsupported operand type(s) for +: 'int' and 'str'. Bohužel tohle často vyskočí až za běhu. Type hints jsou sice lákavé a sám je píšu, ale zase se neuvěřitelně natahujou signatury, navíc je úzus stejně tohle psát do dokumentace a pak to vlastně píšeš dvakrát -- no je vidět že je to do jazyka zatím tak nějak nalepené."https://www.reddit.com/r/Python/comments/5nb0si/why_optional_type_hinting_in_python_is_not_that/". Nejvíc chyb stejně bývá na hranici vstup od uživatele nebo při parsování nějakého souboru při dolování dat. Co je blbý na jazycích jako Python, je že se to hrozně blbě refaktoruje. — 8.12.2017
Taco : @uetoyo: Jo, když by se tohle takhle chovalo, tak by to bylo fajn, ale ono nechová. (S typehinty od 3.6 jsou zajímavou změnou.) Už tu tuším na tohle téma byl nějaký flame. V Pythonu jsou typy jen na okrasu. Ano, objekt má nálepku, že je to int, a když máš štěstí, tak v té či oné funkci je nějaký assert, který tu nálepku zohledňuje, ale jinak se prostě nepoužívají. Je to jen na to, aby se na wikipedii mohlo napsat, že má silnou typovou kontrolu. Ale nemůžu se zbavit dojmu, že je to jen takovej kec. *** Omluvám se, odbočuju od tématu této otázky. — 8.12.2017
Anonym : @Taco Tak ty flamy nevyvolávej :D. Python ti nepřevede číslo na řetězec tím že se mu budeš snažit podsunout `1 + "1"` -- je silně ale dynamicky typovaný. Zřejmě v něm neprogramuješ, takže ti přijdou na okrasu -- to chce cvik. BTW: PHP udělá co při `1 + "1"? ... Jo, koukám vrací 2 -- paráda, ale žít se s tím asi dá (JS vrací '11' :D). "Jo, když by se tohle takhle chovalo, tak by to bylo fajn, ale ono nechová." Ale chová, otevři konzolu a zkus si to. — 8.12.2017
Anonym : @Kit Ale to bys musel vědět, proč to tak, je. Rozhodně ne proto, že by si to někdo záhadně nacpal do jazyka, ale protože String má přetížený operátor `*` právě pro generování sekvencí -- řetězců: `print('a' * 10) >> aaaaaaaaaa` -- tady se neprovádí žádná implicitní konverze! > s * n, n * s equivalent to adding s to itself n times: https://docs.python.org/2/library/stdtypes.html#sequence-types-str-unico... — 8.12.2017
Kit : @uetoyo: Vím, proč to tak je. Je to právě důsledek silného typování a je to tak správně. Lisp takovou operaci odmítne, protože * neumí přetížit. — 8.12.2017
Anonym : @Kit "Lisp takovou operaci odmítne, protože * neumí přetížit" A to je taky fajn; operátory umí být nepřehledný. — 8.12.2017
Kit : I v tom Pythonu to může být zrádné. Napíši si funkci, která má za úkol vynásobit 2 parametry. Pak ji někdo zavolá, jako první parametr dá omylem string (např. ze vstupu) a nestačí se divit. — 8.12.2017
Taco : @uetoyo: Nerozumíme si. `1 + "1"` odmítne proto, protože funkce `+` má v sobě assert. Což je fajn. Ale neznamená to, že by Python byl silně typovaný. Znamená to, že někdo pro objekt Integer nezapoměl validovat vstup. Něco takového jde dělat úplně stejně v Javascriptu, PHP, Lue. (Pro uživatelské typy. S vestavěnýma se toho moc už dělat nedá.) — 9.12.2017
Anonym : @Kit Tohle beru, to je právě nevýhoda duck-typing; podobně funguje C++ s šablonama - pokud je pro parametry definovaný operátor, projde to @Taco Já tě chápu ale nemáš pravdu. Jde o to, že Python ti *neprovede implicitní konverzi* -- JS ano, PHP ano. Operátor projde jen když je pro levou stranu definován, tj. pokud existuje metoda __add__() -- kterou ale musíš sám definovat -- jestli blbě, je tvůj problém. — 9.12.2017
Taco : @uetoyo: "Python ti *neprovede implicitní konverzi*" - v tomhle máš žel (pro PHP) pravdu. Je otázka, zda to v praxi je k něčemu dobré. Ano, v PHP se mi občas automaticky spojí text s objektem, který má definovanou __toString() metodu, aniž bych to chtěl. Jenže v PHP si mohu zajistit, aby mi jako argument metody šla jen hodnota konkrétního typu. To v Pythonu (do verze 3.6) nejde. PHP je sice jazyk hnusnej a občas děsně zmatenej, ale práci s typy má zmáknutou mnohem lépe než Python. Protože je fakt používá. — 9.12.2017
Anonym : @Taco Chtěl sem se právě vyhnout nějakému obecnému hodnocení. Neznám PHP, jak používá typy lépe? Jinak `type hints` jsou už od verze 3.5 a některá IDE to umí docela použít. Pro mne je důležitá syntaxe, jak se mi kód čte a v tomhle mi PHP nevyhovuje, to už radši JS a stejně tak mne bolí Haskell a čtu lépe OCaml, ale to je už na jinou debatu. Pamatuju si že tu jednou někdo psal, že dnes je všechno typ String, což je v rámci webu docela trefný. @vojta.tranta Reason (BuckleScript) vypadá rozumně, má to u vás někdo povolený v práci? — 9.12.2017
Taco : @uetoyo: Programování je hodně o emocích :-) Já jsem se na Python strašně dožral právě kůli těm typům. Zápis má naprosto famózní. Struktura pomocí odsazování, podtržítkové magic funkce, implicitní self, metaclass, anotace - na to se děsně rychle zvyká. Ale ty typy, ty typy! :-D — 9.12.2017
Kit : @uetoyo: V PHP jsou typy nepovinné, ale když už je použiješ, jsou kontrolovány. Totéž s rozhraním. Obojí používám všude, kde to má smysl. V Javě jsem povinné typování cítil jako opruz, v PHP nepovinné typování cítím jako benefit. — 9.12.2017
Anonym : @Kit @Taco Osobně mi nejvíc vadí rovnost definovaná referenčně. Většina potřebuju strukturální, přetěžovat pořád `eq` a `hash` je hrůza, sic by se stím dala dělat nějaká metaprogramovací magie. — 9.12.2017
vojta.tranta : @vladislav.ladicky - ano, hejtuju. Kecám? Psal jsi někdy javascript a máš pocit, že to je jazyk, kterej vývojáři pomáhá v tom, aby nepsal bugy? To asi těžko.. Já se Javascriptem už čtyři roky živim, takže to není tak, že bych "hejtoval" z nějaké "nenásiti", ale v praxi vidim, že Javascript je jeden ze zdrojů problémů. Představ si, že jsou jazyky, kde "undefined is not a function" nebo "cannot read property of null" nebo "cannot read property of undefined" prostě neexistujou. Takový chyby nemůžou nastat. Představ si javascript, kde takový chyby neexistujou. Kolik desítek procent bugů by najednou zmizelo ze světa. V práci jsme si prosadili statickou typovou kontrolu přes Flow type a to se už dá přežít. Když to srovnám s tou předchozí tragédií v čistém JS a Coffee scriptu, tak je to asi jako jako assembler a Java. Dřív jsm psával s Closure compilerem za zády a tehdy jsem Javascript obhajoval, že to není tak děsný. Když jsem ale viděl codebase, kde absolutně chybí jakákoliv typová kontrola... Tak jsem prozřel. Btw. já nepíšu nějaký jquery webíky, ale aplikačky, samozřejmě chápu, že lidem, co píšou takové menší věci jsou statické typové kontroly na obtíž. — 11.12.2017
vojta.tranta : @taco - měl jsem na mysli silné typování, to jak funguje jazyk. Né typové anotace. — 11.12.2017
vojta.tranta : @uetoyo ne, reason nepoužíváme a ani to neplánujeme. Vono s těma zlepšujícíma se nástrojema pro JS se ty rozdíly mezi Elmem, Reasonem, Purescriptem a JSkem postupně mažou. Respektive ty výhody nejsou dostatečně velký proto, abychom tu naší velikou codebase začali přepisovat. Dostali jsme se do bodu, kdy mám 70% Flow coverage na projektu a to je při refaktorování fest znát. Když to srovnám s loňskym rokem, kdy jsme měli ještě 90% kódu v Coffee scriptu, kde nefungoval ani Coffee Lint tak. PRostě nebe a dudy. NIkdy zpátky do čistého JS. (opakuji, že to neplatí pro každý projekt) — 11.12.2017
vojta.tranta : @kit > "Na začátku každé funkce a metody je třeba si ověřit, že vstupní data jsou v pořádku - typová kontrola na to nestačí" - tak to mi přijde dost WTF. Jasně, pokud tam posíláš wanabe json string, tak je jasný, že tam musíš normalizovat a validate. Ale když tam máš metoda(str: string) {} tak fakt nevidim důvod, proč by an tohle statická typová kontrola nestačila. Nebo mi dej nějakej příklad. Pře tomu nerozumim asi. — 11.12.2017
vojta.tranta : @kit: ještě jedna poznamka. Pokud tě štve číst typové anotace, což naprosto plěn chápu, tak si předtav, že jsou jazyky, jejižch typy vycházej přímo z kódu, kterej píšeš. Třeba takový Elm, Haskell nebo Reason to tak mají. Ty prostě ty typy nepíšeš, píšeš kód. NO a temn kód ti sám řiká, co v něm máš blbě a co prostě nebude fungovat, ani kdyby ses postavil na hlavu. Zkus se na to mrknout. Já jsem byl proti statickém typování stejně jako ty, než jsem zjistil, že se to dá dělat i dobře a užitečně a neotravně. — 12.12.2017

Answer 1

odkaz

Anonym

odpověděl/-a 2.12.2017

Hm. Zatiaľ som sa dočítal, že sémanticky a syntakticky sú si veľmi podobné, ale TS je predsa len v pár veciach lepší a hlavne má väčšiu komunitu a podporu. A áno, keď som sa dočítal, že aj netypované knižnice idú bez problémov pridať, tak zatiaľ proste víťazí TS v každom ohľade.

Komentáře

vojta.tranta : Jo, TSko je fajn. Flow má některé věci vychytanější, ale na druhou stranu je pak trošku blbý řešit flow-typed knihovny. Pokud je možnost psát od znova, tak bych bral typesript, pokud se typy přidávaj inkrementálně, tak Flow. — 11.12.2017

devel.cz

Je lepší Flow, alebo Typescript? rubrika: Programování: JavaScript

Komentáře

Komentáře

Pro zobrazení všech 2 odpovědí se prosím přihlaste:

Aktuální otázky v rubrice Programování: JavaScript

Otázky uživatele