Problémy s JavaScript v praxi

[andy]

Máš tam jasne vysvetlenú použitú metodológiu, aj jasne prezentované výsledky z tej štúdie vyplývajúce. Ešte aj pekne zarámované. Takže to ja nerozumiem ako tomu môžeš nerozumieť. Čo je nepochopiteľné na vete "Niektoré jazyky sú náchylnejšie na bugy ako iné, avšak rozdiel je malý"? Tak čo máš neustále s tým garbage in garbage out?

No já nechápu, jak ze 2 projektů napsaných v různých jazycích na základě počtu bugů v issue trackeru hodlá někdo usuzovat na náchylnost  jazyku k bugům... tak očekávám, že mi dáš nějaké vysvětlení. A ty zatím místo vysvětlení šermuješ pojmy "nechápeš", "akademický" a "statistika"...

Výsledok z praxe: statické typy sú často preceňované, v tej súvislosti aj samotné TS okolo ktorého je až nezdravý hype, kladivom na chyby je TDD, nie typový systém a JS nie je zďaleka tak škaredý jazyk, ako mnohí amatéri prezentujú - profesionáli si to nemyslia.

Jestli sis nevším, tak ten "JS" profesionál píše, že mu bohatě stačí... IDE s type inference a typové hinty. Což je v podstatě ekvivalentní jazyku se statickými typy. Takže mi ten jeho pohled připadá... tak nějak absurdní..

A to som presne taký prípad aj zažil, nie len o tomto čítal. A praxi tu, v tomto vlákne? Ani jeden protiargument podporený akademicky, či aspoň nejakým doloženým profesionálom.

Protiargument proti čemu? Najdi si články profíků, kteří píšou v Haskellu, prakticky každý, kdo se v tom pohybuje ti řekne, že to je proti JS nebe a dudy.

Jinak evidentně si nevidíš na špičku nosu, když v tom skvělým jazyce sám děláš boty...

Boneflute to popsal moc hezky. Ono nejde o to, že v tom nejde dělat velký projekty. Jde o to, že to je nuda a zbytečná pruda. A další maintenance a refaktoring těch projektů, když už to všem vypadne z hlavy, je tragédie.

[Reklama]

[andy]

Type inference je automatická detekce typů a ohledně C jsem našel jen tohle. Takže naopak já bych doporučil vám si zjistit co to je a následně vysvětlit, jak tím u statických jazyků chcete dosáhnout flexibility dynamických typů. To mi jasné není a opakuji, rád se nechám poučit.

V C to není. Jedná se o jazyky, které implementují nějakou variantu třeba tohodle https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system. V podstatě pokud ty typy nejsou moc složitý a polymorfní, tak to toho odvodí docela hodně (nebo i úplně všechno). V praxi se dělá anotace top-level funkcí, což způsobí, že ty chybové hlášky pak nevylítnou někde, kde by to člověk nejmíň čekal a zároveň to většinou stačí, aby kompiler odvodil všechno ostatní.

[Wal-De-Mar]

No já nechápu, jak ze 2 projektů napsaných v různých jazycích na základě počtu bugů v issue trackeru hodlá někdo usuzovat na náchylnost  jazyku k bugům... tak očekávám, že mi dáš nějaké vysvětlení. A ty zatím místo vysvětlení šermuješ pojmy "nechápeš", "akademický" a "statistika"...

Aké dva projekty? To si pletieš s tým, čo píše ten magor eee. Pozri si to pdf, potom kecaj.

Jestli sis nevším, tak ten "JS" profesionál píše, že mu bohatě stačí... IDE s type inference a typové hinty. Což je v podstatě ekvivalentní jazyku se statickými typy. Takže mi ten jeho pohled připadá... tak nějak absurdní..

Presne taaak, aj bez uvedenia typov mám to pohodlie, čo ten magor so statickými typmi.

Protiargument proti čemu? Najdi si články profíků, kteří píšou v Haskellu, prakticky každý, kdo se v tom pohybuje ti řekne, že to je proti JS nebe a dudy.

No aké nečakané, že novší jazyk bude lepší :/ A hlavne treba následne zrovnávať hrušky s jablkami, resp. Haskell s JS. Veď nech sa páči, použi ho v browseri.

Boneflute to popsal moc hezky. Ono nejde o to, že v tom nejde dělat velký projekty. Jde o to, že to je nuda a zbytečná pruda. A další maintenance a refaktoring těch projektů, když už to všem vypadne z hlavy, je tragédie.

Tragédia je, keď by to robil Boneflute. Inak s dnešnými modernými frameworkami, modulmi, web komponentami, či funkcionálnym prístupom je maintenance a refaktoring hračka.

Takže ak to zhrniem, možno si nevidím na špičku nosa, možno z teba a iných hovorí čistá neznalosť. Who knows?

[andy]

Aké dva projekty? To si pletieš s tým, čo píše ten magor eee. Pozri si to pdf, potom kecaj.

Tak z 50.000 projektů, to je jedno. Do toho PDF jsem se podíval a pořád nechápu, jak na základě toho, že máš 1000 projektů v jednom jazyce, 800 projektů v druhém jazyce, ty projekty jsou jiné, dělají je jiní lidé, a teď porovnáváš nějaká čísla z issue trackeru - dojdeš k tomu, že u projektů z jazyka A je těch issues víc, v jazyce B míň.... a teď jako co? Co z toho hodláš vyvozovat a proč?

Presne taaak, aj bez uvedenia typov mám to pohodlie, čo ten magor so statickými typmi.

Tak ještě jednou, javascript+typová inference+typové anotace je jazyk se statickými typy. Co si myslíš, že se udělá s typy potom, co to proleze překladem? Normálně se to zahodí (type erasure).

Ten jeho argument je absurdní, protože říká, že nepotřebuje statické typy, stačí mu dynamické, protože.... podívejte, jak mi ty statické typy pomáhají, mám je v IDE a funguje to skvěle, kdyby tam byly anotace, aby to odvodilo to, co to neodvodí, tak by to bylo ještě lepší...

No aké nečakané, že novší jazyk bude lepší :/

Haskell - 1990. JavaScript - 1995.....?

A hlavne treba následne zrovnávať hrušky s jablkami, resp. Haskell s JS. Veď nech sa páči, použi ho v browseri.

No on se taky používá, i když transpilace do JS je funkční, ale má to některé nepříjemné vlastnosti, takže do toho nejdu. A pro změnu se jako paradigma experimentuje s Functional Reactive Programming, takže třeba za pár let uvidíme JS a spol. přejímat nějaké ideje. Doufám, že se brzo dotáhne do rozumného stavu WebAssembly, pak by to mohlo být dobrý. Elm je docela oblíbený (i když neexistence typeclass je IMO dost problém), PureScript se používá (ale nemám dobrou zkušenost z jiných důvodů).

Inak s dnešnými modernými frameworkami, modulmi, web komponentami, či funkcionálnym prístupom je maintenance a refaktoring hračka.

Heh... fakt, že jo... takovej refaktoring z angularu do reactu bych chtěl vidět.... A ano, refaktoring z jednoho REST frameworku do jiného, z jedné SQL knihovny do jiné atp. je v haskellu reálně udělatelná záležitost. Největší sranda je, když uděláš megacommit typu stovka změněných souborů, pár dní práce, jdeš to zkusit - a ono to napoprvý funguje. Prostě jenom po rekompilaci. Zažil jsem. Ne jednou. (samozřejmě taky ne vždycky, ale typicky bylo těch chyb naprosté minimum).
A hlavně spousta těch jazyků to dneska přebírá - IDE s typovou inferencí (python, javascript), jazyky s přímou podporou - Kotlin, Scala, Rust, TypeScript, Flow, type hinty v pythonu... takže statické typy jsou na nic, akorát to dneska začínají podporovat skoro všichni...?

[Bacsa]

Type inference je automatická detekce typů a ohledně C jsem našel jen tohle. Takže naopak já bych doporučil vám si zjistit co to je a následně vysvětlit, jak tím u statických jazyků chcete dosáhnout flexibility dynamických typů. To mi jasné není a opakuji, rád se nechám poučit.

V C to není. Jedná se o jazyky, které implementují nějakou variantu třeba tohodle https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system. V podstatě pokud ty typy nejsou moc složitý a polymorfní, tak to toho odvodí docela hodně (nebo i úplně všechno). V praxi se dělá anotace top-level funkcí, což způsobí, že ty chybové hlášky pak nevylítnou někde, kde by to člověk nejmíň čekal a zároveň to většinou stačí, aby kompiler odvodil všechno ostatní.

Polymorfní typy ještě jdou, problém je až v případě zobecněných algebraických typů.

[Reklama]

[Cikáda]

Jestli sis nevším, tak ten "JS" profesionál píše, že mu bohatě stačí... IDE s type inference a typové hinty. Což je v podstatě ekvivalentní jazyku se statickými typy. Takže mi ten jeho pohled připadá... tak nějak absurdní..

Píšu v JS ve VSCode, který hezky barví syntax a podobně, type interference nepoužívám, protože imho není proč, když jsem v dynamicky psaném jazyce. Píšu tak třeba i v Perlu.

Pravdou je, že si zase "typy" dost hlídám sám, reps. kde je to nutné... chce to pečlivost.

Boneflute to popsal moc hezky. Ono nejde o to, že v tom nejde dělat velký projekty. Jde o to, že to je nuda a zbytečná pruda. A další maintenance a refaktoring těch projektů, když už to všem vypadne z hlavy, je tragédie.

Je to nuda a pruda? A co si pod tím mám představit? Respektive v čem je ta nuda? A pruda? To mám naopak občas u C/C++, apod. kde "musím" psát každý blbý typ. (nestěžuji si, jen to je prostě občas pomalejší než let x = "ahoj"; )

Protiargument proti čemu? Najdi si články profíků, kteří píšou v Haskellu, prakticky každý, kdo se v tom pohybuje ti řekne, že to je proti JS nebe a dudy.

Nebe a dudy v čem? Je to jako srovnávat Ferrari s F35...  je to zkrátka něco jiného, užívám si psaní v obou jazycích; imho jde hlavně o to zvolit správný jazyk/technologii vzhledem k problému. Ale argumentovat Haskellem, že je JS špatně navržený jazyk mi přijde trochu přitažené za vlasy...

(nutno podotknout, že bych se určitě nenazval "profíkem, který píše v Haskellu" )

[kunda]

Jak na pískovišti. Já mám lepší bábovičky! Než jsem všechny vybalil, tak tys postavil hrad, ale máš to z nějakýho divnýho písku! To ti určitě spadne! Mááámííí!!!!! Mně se to nelíííbííí!!! Ať to nedělá!!!

[andy]

Píšu v JS ve VSCode, který hezky barví syntax a podobně, type interference nepoužívám, protože imho není proč, když jsem v dynamicky psaném jazyce. Píšu tak třeba i v Perlu.

Pravdou je, že si zase "typy" dost hlídám sám, reps. kde je to nutné... chce to pečlivost.

Ona otázka zní, proč to nepoužívat - když stejně ty funkce konstruuješ způsobem, že by to tím klidně prošlo..

Je to nuda a pruda? A co si pod tím mám představit? Respektive v čem je ta nuda? A pruda? To mám naopak občas u C/C++, apod. kde "musím" psát každý blbý typ. (nestěžuji si, jen to je prostě občas pomalejší než let x = "ahoj"; )
...

Protiargument proti čemu? Najdi si články profíků, kteří píšou v Haskellu, prakticky každý, kdo se v tom pohybuje ti řekne, že to je proti JS nebe a dudy.

Nebe a dudy v čem? Je to jako srovnávat Ferrari s F35...  je to zkrátka něco jiného, užívám si psaní v obou jazycích; imho jde hlavně o to zvolit správný jazyk/technologii vzhledem k problému.

Na frontendu moc na výběr není - na backendu ano. Takže můžeme srovnat, jak by se stejná úloha řešila v Js (node), C#, Javě, Haskellu, Elixiru atd.. Rozdíl je třeba v tom, že prakticky neděláš "iterativní" vývoj. Když píšu v netypovaném jazyku, tak to je typicky - napíšu pár řádek. Zkusím. Napíšu dalších pár řádek. Zkusím. Potřebuju změnit něco, co jsem už zkusil... bez TDD pro větší projekt je to sebevražda.

I C++ už umí dneska "auto". U C++ je naprosto nesnesitelné psát ty příšerné typy např. v iterátoru - "auto" to řeší.

Potřebuješ něco refaktorovat.... už je to docela dávno, potřeboval jsem upravit program (C++), který prováděl síťovou komunikaci, aby fungoval jak na little-endian tak na big-endian strojích. Takže...jak to udělat? Jak najít všechna místa, kde je potřeba přidat tu případnou konverzi do nějakého "network-order"? Ukázalo se, že stačí změnit typ v těch serializovaných strukturách z "int_32" (apod) na nějaký "struct net_int32", spustit kompiler a rovnou z toho vypadl seznam řádek, kde je to potřeba opravit. Při TDD (bez typů) by ti z toho vypadl seznam spadlých testů, a ty bys pak hledal v kódu, kde to opravit a doufal, že ty testy jsou fakt důsledné.

Většina lidí má asi pocit, že typový systém je nějaký artefakt toho, že je potřeba to nakonec nějak zkompilovat a je potřeba to nějak překladači vysvětlit jak. A dynamické typy berou jako "posun vpřed" - proč mu to vysvětlovat, když si to překladač může zjistit sám. Ten pohled, který se dneska prosazuje, je, že statické typy jsou nástroj pro programátora, který využívá k tomu, aby napsal program s méně chybami, méně zbytečného kódu a vyššími možnostmi abstrakce.

Ale argumentovat Haskellem, že je JS špatně navržený jazyk mi přijde trochu přitažené za vlasy...

Taky jsem nic takového neřekl - JS je špatný z jiných důvodů, než že nemá statické typy. Proti JS jsem argumentoval některými věcmi z Pythonu (ten má taky spoustu much) případně Go (runtime). Ještě by se to dalo srovnávat s Elixirem (ale o tom vím akorát, že existuje), případně Clojure/lisp. Proti tvrzení, že statické typy jsou na nic argumentuji haskellem (a dal by se k tomu přidat asi Rust, ale ten je dost mladý).

[listoper]

...
 Ještě by se to dalo srovnávat s Elixirem (ale o tom vím akorát, že existuje), případně Clojure/lisp.
...

Srovnavani jakehokoli(ne lisp) jazyka s lispem ma tu nevyhodu, ze vzdycky vyhraje lisp, takze prinos srovnani bude nizky.
 

[Bacsa]

Je to nuda a pruda? A co si pod tím mám představit? Respektive v čem je ta nuda? A pruda? To mám naopak občas u C/C++, apod. kde "musím" psát každý blbý typ. (nestěžuji si, jen to je prostě občas pomalejší než let x = "ahoj"; )

V C++ to bude

Kód: [Vybrat]

auto x = “ahoj”; Písmenko navíc je problém?

[eee]

Type inference je automatická detekce typů a ohledně C jsem našel jen tohle. Takže naopak já bych doporučil vám si zjistit co to je a následně vysvětlit, jak tím u statických jazyků chcete dosáhnout flexibility dynamických typů. To mi jasné není a opakuji, rád se nechám poučit.

V C to není. Jedná se o jazyky, které implementují nějakou variantu třeba tohodle https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system. V podstatě pokud ty typy nejsou moc složitý a polymorfní, tak to toho odvodí docela hodně (nebo i úplně všechno). V praxi se dělá anotace top-level funkcí, což způsobí, že ty chybové hlášky pak nevylítnou někde, kde by to člověk nejmíň čekal a zároveň to většinou stačí, aby kompiler odvodil všechno ostatní.

Tohle chápu, ale tím si jen ušetříš práci s ručním popisem typů a což má dle mně několik dopadů:
a) asi to ušetří trochu práce s psaním kódu
b) asi to sníží počet chybných otypování proměnných (záleží jak moc to funguje a jak dobře je ošetřeno selhání automařiky)

S tím pomáhají i ta céčková makra.

Ale nijak nevidím, jak by to mělo pomoci s omezeními, které sebou nese statický typový systém, jejichž absence dynamickým jazykům zajišťuje jejich vyšší flexibilitu. Pokud někdo jako jediný nebo hlavní rozdíl mezi statickým a dynamickým jazykem vidí nutnost psaní typů, tak dynamickým jazykům nerozumí a neumí je efektivně používat. Popisování typů je marginálie. A pokud někdo chápe rozdíl mezi dynamickým a statickým programováním, nechť mi prosím vysvětlí, jaký přínos v tomto nese type inference. Imho žádný, pokud neumožní věci jako:'

a = 1
a = 1.1
a = 999999999999999999999999999999999999L
a = 'text'

[Bacsa]

Type inference je automatická detekce typů a ohledně C jsem našel jen tohle. Takže naopak já bych doporučil vám si zjistit co to je a následně vysvětlit, jak tím u statických jazyků chcete dosáhnout flexibility dynamických typů. To mi jasné není a opakuji, rád se nechám poučit.

V C to není. Jedná se o jazyky, které implementují nějakou variantu třeba tohodle https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system. V podstatě pokud ty typy nejsou moc složitý a polymorfní, tak to toho odvodí docela hodně (nebo i úplně všechno). V praxi se dělá anotace top-level funkcí, což způsobí, že ty chybové hlášky pak nevylítnou někde, kde by to člověk nejmíň čekal a zároveň to většinou stačí, aby kompiler odvodil všechno ostatní.

Tohle chápu, ale tím si jen ušetříš práci s ručním popisem typů a což má dle mně několik dopadů:
a) asi to ušetří trochu práce s psaním kódu
b) asi to sníží počet chybných otypování proměnných (záleží jak moc to funguje a jak dobře je ošetřeno selhání automařiky)

S tím pomáhají i ta céčková makra.

Ale nijak nevidím, jak by to mělo pomoci s omezeními, které sebou nese statický typový systém, jejichž absence dynamickým jazykům zajišťuje jejich vyšší flexibilitu. Pokud někdo jako jediný nebo hlavní rozdíl mezi statickým a dynamickým jazykem vidí nutnost psaní typů, tak dynamickým jazykům nerozumí a neumí je efektivně používat. Popisování typů je marginálie. A pokud někdo chápe rozdíl mezi dynamickým a statickým programováním, nechť mi prosím vysvětlí, jaký přínos v tomto nese type inference. Imho žádný, pokud neumožní věci jako:'

a = 1
a = 1.1
a = 999999999999999999999999999999999999L
a = 'text'

Dynamické typování není flexibilnější, jen umožňuje chyby a prasárny jako kód výše. A když už někdo chce mermomocí prasit, může použít any/dynamic.

[Inkvizitor]

Dynamické typování není flexibilnější, jen umožňuje chyby a prasárny jako kód výše. A když už někdo chce mermomocí prasit, může použít any/dynamic.

Ani ja uprimne nechapu tu ohromnou vyhodu, kterou ma prinest moznost postupne do te same promenne prirazovat uplne odlisne typy. A nemusi jit ani o ten extremni pripad od eee - (staticke) funkcionalni jazyky resi nulovatelnost pomoci Option/Maybe a dve ruzne moznosti pomoci Either/Result. "Vyhoda" dynamickych jazyku v teto konkretni veci je v tom, ze autori jazyku i programu v nich nemusi moc premyslet a ono jim to tak nejak (vetsinou) vyjde. Vyjimecne se to hodit muze, ale obecne je to spis z nouze ctnost.

[eee]

Při TDD (bez typů) by ti z toho vypadl seznam spadlých testů, a ty bys pak hledal v kódu, kde to opravit a doufal, že ty testy jsou fakt důsledné.

Ale blbost.
a) při testu ti chybové hlášení přesně řekne kde máš chybu
b) není důvod aby to padalo, pokud to nemáš napsané špatně a používáš stejné rozhraní nad různými daty, takže ti stačí pro nová data upravit akorát objekt, který je nese

[eee]

Type inference je automatická detekce typů a ohledně C jsem našel jen tohle. Takže naopak já bych doporučil vám si zjistit co to je a následně vysvětlit, jak tím u statických jazyků chcete dosáhnout flexibility dynamických typů. To mi jasné není a opakuji, rád se nechám poučit.

V C to není. Jedná se o jazyky, které implementují nějakou variantu třeba tohodle https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system. V podstatě pokud ty typy nejsou moc složitý a polymorfní, tak to toho odvodí docela hodně (nebo i úplně všechno). V praxi se dělá anotace top-level funkcí, což způsobí, že ty chybové hlášky pak nevylítnou někde, kde by to člověk nejmíň čekal a zároveň to většinou stačí, aby kompiler odvodil všechno ostatní.

Tohle chápu, ale tím si jen ušetříš práci s ručním popisem typů a což má dle mně několik dopadů:
a) asi to ušetří trochu práce s psaním kódu
b) asi to sníží počet chybných otypování proměnných (záleží jak moc to funguje a jak dobře je ošetřeno selhání automařiky)

S tím pomáhají i ta céčková makra.

Ale nijak nevidím, jak by to mělo pomoci s omezeními, které sebou nese statický typový systém, jejichž absence dynamickým jazykům zajišťuje jejich vyšší flexibilitu. Pokud někdo jako jediný nebo hlavní rozdíl mezi statickým a dynamickým jazykem vidí nutnost psaní typů, tak dynamickým jazykům nerozumí a neumí je efektivně používat. Popisování typů je marginálie. A pokud někdo chápe rozdíl mezi dynamickým a statickým programováním, nechť mi prosím vysvětlí, jaký přínos v tomto nese type inference. Imho žádný, pokud neumožní věci jako:'

a = 1
a = 1.1
a = 999999999999999999999999999999999999L
a = 'text'

Dynamické typování není flexibilnější, jen umožňuje chyby a prasárny jako kód výše. A když už někdo chce mermomocí prasit, může použít any/dynamic.

To je prasárna jen z pohledu statického progamátora, který má zafixováno paradigma, že proměnná je svázaná s datovým typem a už neumí myslet jinak. Statický programátor nechápe flexibilitu dynamického jazyka a neumí ji využít ani když ji má k dispozici, je omezen ne jazykem, ale vlastním myšlením. Proto ty tragické dopady, když si pak sednou k něčemu jako Python, ale stejně se v něm snaží programovat staticky. Statický programátot proto nevnímá ímšzení statických jazyků a flexibilitu těch dynamických. Naopak to neplatí, statické jazyky dynamického programátora omezují, nutí ho implementivat těžkopádná řešení. V dynamickém jazyku je proměná jen něco jako ukazatel na datový objekt, který si informaci o svém typu nese stále s sebou. Výhodou statických jazyků jsou možnosti optimalizace a výkonu. Co se týče any, bavíme se stále o statickém C nebo už něčem jiném, případně o čem?