Typový system versus unittesty

Kit

Re:Typový system versus unittesty
« Odpověď #900 kdy: 25. 10. 2018, 10:29:43 »
Jejich benefit spočívá ve výkonu
Typy s výkonem nijak nesouvisí. Jeden blud za druhým, ach jo, to už na těch VŠ nic kloudného neučí?

Vytrženo z kontextu. Tvá první věta je nepodložená. Druhá je zavádějící a zcela zbytečná, neboť neobsahuje argumenty.


SB

Re:Typový system versus unittesty
« Odpověď #901 kdy: 25. 10. 2018, 10:38:39 »
Jejich benefit spočívá ve výkonu
Typy s výkonem nijak nesouvisí.
https://en.wikipedia.org/wiki/Virtual_method_table
A co s tím? Virtuální metody nijak nesouvisí s tím, jestli má jazyk (statické) typy nebo ne. Ten odkaz by klidně mohl být na Kozinovu větu a vyšlo by to nastejno.

Takže nevíte...
Aby některé rádobyobjektové jazyky zvýšily rychlost zpracování, nahradily zasílání zpráv voláním funkcí. Protože by tím ale přišly o polymorfismus, oprasily to tak, že zavedly tzv. "podtypový polymorfismus", kdy volaná funkce je dohledávána právě v VMT z omezené množiny podtypů daných typovým stromem. Měl to tak Pascal, Java bude mít pravděpodobně něco podobného.

Bacsa

Re:Typový system versus unittesty
« Odpověď #902 kdy: 25. 10. 2018, 10:39:38 »
Jejich benefit spočívá ve výkonu
Typy s výkonem nijak nesouvisí.
Vytrženo z kontextu.
Kontext tam žádný nebyl, jen snůška nesmyslů. Ale jestli si taky myslíš, že typy mají přímý vliv na výkon, dej příklad. Obratem to ho vyvrátím ;)

Kit

Re:Typový system versus unittesty
« Odpověď #903 kdy: 25. 10. 2018, 10:41:38 »
Jejich benefit spočívá ve výkonu
Typy s výkonem nijak nesouvisí.
https://en.wikipedia.org/wiki/Virtual_method_table
A co s tím? Virtuální metody nijak nesouvisí s tím, jestli má jazyk (statické) typy nebo ne. Ten odkaz by klidně mohl být na Kozinovu větu a vyšlo by to nastejno.

Statické typy umožňují určit už v době kompilace, která metoda bude použita. Virtuální metoda se musí vybírat ze seznamu před každým voláním.

Bacsa

Re:Typový system versus unittesty
« Odpověď #904 kdy: 25. 10. 2018, 10:45:13 »
Jejich benefit spočívá ve výkonu
Typy s výkonem nijak nesouvisí.
https://en.wikipedia.org/wiki/Virtual_method_table
A co s tím? Virtuální metody nijak nesouvisí s tím, jestli má jazyk (statické) typy nebo ne. Ten odkaz by klidně mohl být na Kozinovu větu a vyšlo by to nastejno.
Takže nevíte...
Aby některé rádobyobjektové jazyky zvýšily rychlost zpracování, nahradily zasílání zpráv voláním funkcí. Protože by tím ale přišly o polymorfismus, oprasily to tak, že zavedly tzv. "podtypový polymorfismus", kdy volaná funkce je dohledávána právě v VMT z omezené množiny podtypů daných typovým stromem. Měl to tak Pascal, Java bude mít pravděpodobně něco podobného.
Virtuální metody fungují úplně stejně jako dispatch - objekty mají odkaz na tabulku metod svého typu, Java stejně jako třeba ObjC. Vzhledem k type erasure Javě typy v runtimu nijak nepomáhají, slouží jen k seřvání vývojáře, když píše blbě, v době překladu.


Bacsa

Re:Typový system versus unittesty
« Odpověď #905 kdy: 25. 10. 2018, 10:46:12 »
Jejich benefit spočívá ve výkonu
Typy s výkonem nijak nesouvisí.
https://en.wikipedia.org/wiki/Virtual_method_table
A co s tím? Virtuální metody nijak nesouvisí s tím, jestli má jazyk (statické) typy nebo ne. Ten odkaz by klidně mohl být na Kozinovu větu a vyšlo by to nastejno.
Statické typy umožňují určit už v době kompilace, která metoda bude použita. Virtuální metoda se musí vybírat ze seznamu před každým voláním.
Tak C++ má statické typy i virtuální metody. Proč asi?

Kit

Re:Typový system versus unittesty
« Odpověď #906 kdy: 25. 10. 2018, 10:49:23 »
Virtuální metody fungují úplně stejně jako dispatch - objekty mají odkaz na tabulku metod svého typu, Java stejně jako třeba ObjC.

Co když volaná metoda v té tabulce není? Musí hledat dál, což je další režie.

Kit

Re:Typový system versus unittesty
« Odpověď #907 kdy: 25. 10. 2018, 10:54:20 »
Vzhledem k type erasure Javě typy v runtimu nijak nepomáhají, slouží jen k seřvání vývojáře, když píše blbě, v době překladu.

Však se o Javě nebavíme jako o typovém jazyce. V runtimu jsou typy jen jako atributy.

Bacsa

Re:Typový system versus unittesty
« Odpověď #908 kdy: 25. 10. 2018, 11:00:39 »
Vzhledem k type erasure Javě typy v runtimu nijak nepomáhají, slouží jen k seřvání vývojáře, když píše blbě, v době překladu.
Však se o Javě nebavíme jako o typovém jazyce. V runtimu jsou typy jen jako atributy.
Tak se nejdřív vy tři domluvte, co je podle vás “typový” (sic!) jazyk. Pokud by to měl být jen Haskell, tak pak jo, ovlivní to výkon.

Petr

Re:Typový system versus unittesty
« Odpověď #909 kdy: 25. 10. 2018, 11:18:28 »
A něco poučného na téma složitosti: http://www.knesl.com/budoucnost-programovacich-jazyku
Ten článek není úplně špatný. Akorát na konci se autor dopustil poměrně zásadní a docela časté chyby. Formuloval závěr na základě jim specifikovaných předpokladů, ale jaksi opomněl, že mu tam další předpoklady chybí.

Vynechal totiž nejdůležitější faktor, ovlivňující prodloužení doby vývoje: programátora. S bandou opic nejnovější funkcionalitu prostě nenaprogramujete, i když budete mít ty nejlepší nástroje. A protože poptávka po programátorech neustále stoupá, tak za současné situace logicky jejich kvalita klesá. A tady narážíme na limitující prvek. Klesající kvalita programátorů (nebo třeba nemožnost získat dostatečně kvalitní programátory) způsobí prodloužení doby implementace v případě použití složitého a vysoce sofistikovaného jazyka. Tak, jak se někdo v matematice zastaví u trigonometrických funkcí, někdo u logaritmů a další u integrálů a derivací, tak se zastaví u různé složitosti konstrukcí programovacích jazyků. A protože se jedná o pyramidu (skoro všichni zvládnou goniometrické funkce, logaritmy už menší skupina a integrály a derivace jen "hrstka"), můžete mít sice dokonalý jazyk, ale jeho zvládnutí vás může stát více času (pokud to vůbec dáte), než to funkčně naprogramovat v něčem primitivnějším.

A to je taky problém celého tohoto vlákna. Zatímco typový systém ekvivalentní unit testům možná dokáže navrhnout autor (a možná ještě další jeden nebo dva), napsat nějaký unit test dokáží víceméně všichni. A po nějakém tréninku velká většina z množiny všichni bude schopna psát kvalitní unit testy. Kolik dalších lidí zvládne Haskell na úrovni, kdy nahradí unit testy správnou volbou typů si netroufnu ani odhadovat.
Souhlasim. Neslo mi o jazyky s dynamickou syntaxi, o jejichz realne prakticnosti mam pochyby,  ale uvidime, co prinese budoucnost. Slo mi o fenomen slozitosti, ktery se tu prehlizi a je imho vyznamne podstatnejsi ohledne kvality a spolehlivosti vysledne aplikace. Chci-li vysokou spolehlivost, nevyresim to typovym systemem, ale a) vhodnou metodou vyvoje software, zalozenou na dukladnych testech, viz treba extremni programovani, b) kvalitnim testovacim prostredim a c) zvolenám prostredku, ktere mi rozumne snizi druhotnou slozitost, jenz je vyznamnym zdrojem chyb (proto typicky neprogramujeme ve strojovem kodu nebo asm a proto se vyvoj nezastavil ani u jejich nastupcu C, C++, Java /C# nebo dnes popularni JS a Python, kde Python je nejpokrocilejsi, ale take nejmene vykonny). Ony ty testy take zvysuji druhotnou slozitost, ale maji vyhodu, ze nejsou soucasti produkcni aplikace a nezasahuji do ni, ale to uz se ale opakuji. Typovy system slozitost programu zvysuje a to primo umerne se svou silou. Tedy cim dukladneji resi jeden zdroj chyb, tim posiluje jiny zdroj chyb, druhotnou slozitost. Argument kvality a spolehlivosti je u staticky typu proto falesny. Jejich opodstatneni je jine, v moznosti lepsi optimalizace a vyssiho vykonu aplikace. Ale k tomu neni potreba, hadam, vyssi typovy system, staci k tomu datove typy na urovni architektury.

Petr

Re:Typový system versus unittesty
« Odpověď #910 kdy: 25. 10. 2018, 11:47:27 »
Jejich benefit spočívá ve výkonu
Typy s výkonem nijak nesouvisí. Jeden blud za druhým, ach jo, to už na těch VŠ nic kloudného neučí?
Datove typy s vykonem aplikace souvisi velmi. Staticke typy umoznuji instrukce programu optimalizovat v dobe prekladu a zvysit jeho efektivitu. Dynamicke typy se musi vyhodnocovat runtime, takze a) instrukce nejde tak dobre optimalizovat, b) je s tim spojen vyssi overhead, navic to typicky vyzaduje behovou vrstvu navic, ktera zere pamet a ma vlastni overhead.

Co vas na VS ucili nevim, ale co jste si z toho odnesl je zalostne. Ale nezoufejte,  bud realne programovat neco duleziteho nikdy nebudete a nebo si parkrat v produkci nabijete cumak na staticky typovanem jazyku a ono se vam v hlave srovna, jaky prinos maji typy a jaky testy.

Kit

Re:Typový system versus unittesty
« Odpověď #911 kdy: 25. 10. 2018, 11:57:53 »
Typovy system slozitost programu zvysuje a to primo umerne se svou silou. Tedy cim dukladneji resi jeden zdroj chyb, tim posiluje jiny zdroj chyb, druhotnou slozitost. Argument kvality a spolehlivosti je u staticky typu proto falesny. Jejich opodstatneni je jine, v moznosti lepsi optimalizace a vyssiho vykonu aplikace. Ale k tomu neni potreba, hadam, vyssi typovy system, staci k tomu datove typy na urovni architektury.

Z příspěvků zde uváděných mám občas pocit, že k zvládnutí Haskellu je nutné mít vystudovaný matfyz. Když však nahlédnu do reálných aplikací, tak  vidím, že mnoho programátorů nezvládá ani namespace, které má Haskel na velmi dobré úrovni. Nejde tedy jen o to, jak moc je daný jazyk kvalitní, ale také jak jednoduché či složité je jeho používání.

Bacsa

Re:Typový system versus unittesty
« Odpověď #912 kdy: 25. 10. 2018, 12:08:58 »
Typovy system slozitost programu zvysuje a to primo umerne se svou silou. Tedy cim dukladneji resi jeden zdroj chyb, tim posiluje jiny zdroj chyb, druhotnou slozitost. Argument kvality a spolehlivosti je u staticky typu proto falesny. Jejich opodstatneni je jine, v moznosti lepsi optimalizace a vyssiho vykonu aplikace. Ale k tomu neni potreba, hadam, vyssi typovy system, staci k tomu datove typy na urovni architektury.
Z příspěvků zde uváděných mám občas pocit, že k zvládnutí Haskellu je nutné mít vystudovaný matfyz.
Haskell je naopak snadný na používání.

Petr

Re:Typový system versus unittesty
« Odpověď #913 kdy: 25. 10. 2018, 12:27:04 »
Typovy system slozitost programu zvysuje a to primo umerne se svou silou. Tedy cim dukladneji resi jeden zdroj chyb, tim posiluje jiny zdroj chyb, druhotnou slozitost. Argument kvality a spolehlivosti je u staticky typu proto falesny. Jejich opodstatneni je jine, v moznosti lepsi optimalizace a vyssiho vykonu aplikace. Ale k tomu neni potreba, hadam, vyssi typovy system, staci k tomu datove typy na urovni architektury.
Z příspěvků zde uváděných mám občas pocit, že k zvládnutí Haskellu je nutné mít vystudovaný matfyz. Když však nahlédnu do reálných aplikací, tak  vidím, že mnoho programátorů nezvládá ani namespace, které má Haskel na velmi dobré úrovni. Nejde tedy jen o to, jak moc je daný jazyk kvalitní, ale také jak jednoduché či složité je jeho používání.
To imho neni vlastnost haskellu, ale funkcionalniho programovani, ktere se, alespon nam starym praktickým programatorum, jevi jako hodne nekompatibilni s lidskym myslenim. Ale mozná je to jen o zvyku. Je to takove ufonske, nebo by se to mohlo brat jako jakysi druh nepraktickeho umeni. Ma to smysl zkoumat akademicky, vysledky badani mohou obohatit ostatni jazyky. Ze by to nahradilo zavedene strukturovo objektove paradigma v nejblizsich letech neocekavam.

Petr

Re:Typový system versus unittesty
« Odpověď #914 kdy: 25. 10. 2018, 12:44:56 »
Nejde tedy jen o to, jak moc je daný jazyk kvalitní, ale také jak jednoduché či složité je jeho používání.
Ano, slozitost je potreba posuzovat na nekolika urovnich. Jak jednoduse je v jazyce mozno vyjadrit myslenku, kolik tomu klade formalnich prekazek.  Jak prehledny a citelny/pochopitelny je zapis. Jak bohate a uzitecne jsou standardni knihovny a odladene knihovny tretich stran. Jak je jazyk intuitivni/logicky a chova se dle ocekavani, tj. jak snadno se da naucit a na kolik se musi myslet speku. Jak dobre je zdokumentovany. Jakou ma podporu v produkci, kvalitni ide, podporu pro debugovani, testovani, psani vlastni dokumentace. Jakou ma podporu u vyrobce nebo komunity, kdyz se vyskytne nejaky zapeklity problem - chyba ve vlatnim programovacim jazyce, at kompileru nebo behovem prostredi nebo systemovych knihovnach. A dalsi me asi hned nenapadly.