1651
Vývoj / Re:Zkušenosti s TypeScriptem
« kdy: 28. 03. 2020, 18:51:12 »Ne.Ech. Něco jiného než rychlost?Co jsou zač ty nevýhody?Dynamický dispatch je pomalejší.
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Ne.Ech. Něco jiného než rychlost?Co jsou zač ty nevýhody?Dynamický dispatch je pomalejší.
Co jsou zač ty nevýhody?Dynamický dispatch je pomalejší.
Jinak ten problém s kovariantním polem hezky ukazuje, kde se dynamický runtime hodí. Typová kontrola v tomto případě ověří přiřazení a za běhu program nepadne. Je to vykoupeno nevýhodami jinde, ale jako příklad hezké.To je pravda, ale s tou výhradou, že plně automatickou inferenci udělat nelze.Ještě takové drobné pošťouchnutí. Pokud bychom to vzaly trochu obecněji, tak plně automatická inference existuje, a používá se například u Javascriptu (pravděpodobně nejen). Ten vezme ten kód, celej se přeloží do nějaké té interní reprezentace, všechny typy se zahodí, a podle logiky toho kódu se vymyslí nové.
plně automatická inference existuje, a používá se například u Javascriptu (pravděpodobně nejen). Ten vezme ten kód, celej se přeloží do nějaké té interní reprezentace, všechny typy se zahodí, a podle logiky toho kódu se vymyslí nové.V tom žádná inference není.
Nic neskončilo, vše se vrátí do starých kolejí.Křišťálové koule kupuješ kde?Stačí mi mať oči otvorené, chápem, že niekomu robí problém priznať si, že dobré časy skončili.
To je pravda, ale s tou výhradou, že plně automatickou inferenci udělat nelze.Nutno ale podotknout, že v dnešní době chytrých jazyků s typovou inferencí už typová kontrola přináší jen benefity (žádné zvyšování složitosti kódu ani snižování dynamičnosti či obecnosti se již nekoná).Samozřejmě. Znamenalo by to, že si pouze myslíte, že jste odstranil 100 % (všimněte si mezery za číslem) chyb, ale ve skutečnosti vám jich tam ještě 50 % (opět si všimněte mezery za číslem) zůstalo.V tom případě 50% nalezených chyb v době kompilace je super, a beru to.
Výborně. Tak teď, když už víme, že nám typová kontrola (zdaleka) nepochytá všechny chyby, je na čase zvážit, zda se nám vyplatí ji na chytání chyb zavádět a zvyšovat tím složitost kódu a snižovat jeho dynamičnost a obecnost.
Neřešte to znovu, už se to tu řešilo, a zjistilo se, že každý soudruh to má jinak. Věnujte se místo toho raději pravopisu, ten by naopak měl mít každý soudruh stejný (= dle pravidel).
Jasně, že to jde, už i GCC to umí (pod tlakem clangu)50% je paráda, ovšem tedy za předpokladu nekryptických chybových hlášek. Ale už i překladače C++ se polepšily.V tom případě 50% nalezených chyb v době kompilace je super, a beru to.A kdyby to bylo 50% všech chyb? Měnilo by to význam?...Ja preferuji silněji typovaná prostředí - chyby jsou nalezeny již v době kompilace...
Nechtěl jste napsat „některé chyby“?
Samozřejmě. Znamenalo by to, že si pouze myslíte, že jste odstranil 100 % (všimněte si mezery za číslem) chyb, ale ve skutečnosti vám jich tam ještě 50 % (opět si všimněte mezery za číslem) zůstalo.
Rust má chybovky příkladný, řekl bych. Z čehož vyvozuji, že to jde :-)
50% je paráda, ovšem tedy za předpokladu nekryptických chybových hlášek. Ale už i překladače C++ se polepšily.V tom případě 50% nalezených chyb v době kompilace je super, a beru to.A kdyby to bylo 50% všech chyb? Měnilo by to význam?...Ja preferuji silněji typovaná prostředí - chyby jsou nalezeny již v době kompilace...
Nechtěl jste napsat „některé chyby“?
Samozřejmě. Znamenalo by to, že si pouze myslíte, že jste odstranil 100 % (všimněte si mezery za číslem) chyb, ale ve skutečnosti vám jich tam ještě 50 % (opět si všimněte mezery za číslem) zůstalo.
To je spíše tím, kdo ten kód píše. Akademik válící Haskell levou zadní píše i v Pythonu jinak, jako když ránu zašívá chirurg vs holič. Většinou to je fuk, ale rozdíl to je, no.Mně vždy přišlo, že pokud se použije typová inference, tak se zdrojový kód staticky typovaný neliší od dynamicky typovaného. Některé jazyky to neumožňují u všech deklarací, ale teoreticky to jde a třeba v C++ už jde psát bez explicitních typů (s plnou kontrolou při překladu).
Může být.
Když si vybavím kód v Javascriptu, Pythonu - tak vidím jiný druh práce s kódem, než třeba v Haskellu. Haskell sice má typovou inferenci, takže je ukecanej stejně málo jako Python, ale ty typy tam cítíš. Opíráš se o ně. Stavíš na nich. To mi v Pythonu nebo Javascriptu nepřijde. Tam typy, respektive třídy používáš jako konstrukční nástroje, kdy dědíš (a mixuješ) do bezvědomí.
Další věc je, ale to už je dost specialita statického typování - tak u Haskellu máš "buď a nebo". Ten kód je takovej jakože ultimátní. Když do toho pustíš data, tak ti to buď správně sežere, nebo ti to vyhodí chybu. U Pythonu je to větší sázka do loterie. Ale to je asi známá věc.
PS:
Mluvím o kódu, se kterým přicházím do styku. Samozřejmě pak ještě záleží na rukou.
Monády jsou pro malé děti, pro profíka jsou triády.Tydlencty "monady" mame v Pythonu odjakziva.Tenhle hnus je nějaká forma unique nebo distinct?
.filter((num, index, nums) => nums.indexOf(num) == index)
Ano, to je unique, a neni to Lua, ale Javascript - to je takovy ten jazyk, ktery brzo prevalcuje Python, a ktera ma dneska spousta Javistu v zaloze
Tvl tady Pythonisti ani neznaji monady, a pritom my to v Jave pouzivame uz od verze 1.8
Mně vždy přišlo, že pokud se použije typová inference, tak se zdrojový kód staticky typovaný neliší od dynamicky typovaného. Některé jazyky to neumožňují u všech deklarací, ale teoreticky to jde a třeba v C++ už jde psát bez explicitních typů (s plnou kontrolou při překladu).Osobně mám zkušenost, že Typy nutí uvažovat konkrétním způsobemTo mě zaujalo. Jakým? Případně jaké typy, primitivní, generické, závislostní...? Že odchytnou většinu chyb je jasné, ale to specifické uvažování mě zajímá.
To sem si zase naběh'.
Nemám to tak promyšlené, takže prosím o shovívavost.
Když nemám typy, tak pracuju s chlívečkama. Sem dej tohle číslo, pak hoď sem, tam se s ním bude počítat. Vzniká kód ve stylu:Kód: [Vybrat]foo.title = "Mr"
if foo.sex:
foo.title = "Ms"
foo.title += ": "
foo.title += name
foo.title += " "
foo.title += surname
Když mám typy, alespoň takové ty hodně blbé aka Java, C#, tak bude tendence to někam uklízet. Ale moc to nefunguje.
Když se přitlačí s imutabilitou, tak začne víc dekompozice na stromeček:Kód: [Vybrat]Foo(buildName(src1, src2), buildSurname(src1, src4))
když nemohu přetěžovat funkce/metody, tak píšu hodně switch:Kód: [Vybrat]function renderAny(x):
switch (type(x)):
case "Application":
return renderApplication(x)
case "Window"
return renderWindow(x)
default:
error()
Pokud mám k dispozici imutabilitu, statické typování tak mám tendenci to stavět jako kompozici funkcí. (Pokud ne, tak taky, ale protože jsem už ovlivněnej.) Opírám se o to, že mi sem přijde typ Person. Zatímco když nemám typy, tak počítám s tím, že mi sem přijde struktura obsahující name, surname. S typem Person nemohu to co se strukturou.
Když mi přijde třída Renderable tak jí renderuju. Protože tak nějak uvažuju, že ty záruky se vztahují jen na Renderování. Zatímco když mám funkci render přijímající sturkturu, tak renderuju tu strukturu. A přirozeně i něco vypočítám navíc, něco si odložím, něco vytáhnu pokoutně...
Asi to nebude všechno, jen prvotní co mě napadlo.
Osobně mám zkušenost, že Typy nutí uvažovat konkrétním způsobemTo mě zaujalo. Jakým? Případně jaké typy, primitivní, generické, závislostní...? Že odchytnou většinu chyb je jasné, ale to specifické uvažování mě zajímá.
V úvodu každého předmětu dělá zkráceně i potřebnou matematiku a celkem vzato o hodně praktičtěji než by to udělal matematik.To je výhoda fyziků, že berou matematiku bez důrazu na absolutní přesnost, takže výklad má sice formální mezery, ale zato zbývá víc času a energie na praktické aspekty.
Ak by ste mali nejakú literatúru, kde by boli rozoberané praktické aplikácie matematiky, bol by som rád a určite by som si tie knihy prečítal.Jakýkoliv úvod pro bakaláře do kosmologie nebo kvantové mechaniky, tam se to integrály jen hemží a všechny mají praktickou motivaci.