Typový system versus unittesty

[Bacsa]

Nikde není napsáno, že interface musí být typový. Nějaká Java není argumentem.

Co je netypový interface?

Zřejmě má na mysli duck typing.

Aha. Tak to pak jo. To byla ostatně, pokud se správně pamatuju, úplně první verze rozhraní.

A kde se to používalo? U Javy?

Ani náhodou Ve Smalltalku. Java ale své "interface" okopčila z Objective-C, ta historie je celkem zajímavá, na Javě dělali (hlavně standardní knihovnu) ObjC vývojáři po tom, co Sun koupil Lighthouse Design, takže tam přenesli své znalosti, zvyky a postupy.

[Reklama]

[BoneFlute]

A kde se to používalo? U Javy?

Ani náhodou Ve Smalltalku. Java ale své "interface" okopčila z Objective-C, ta historie je celkem zajímavá, na Javě dělali (hlavně standardní knihovnu) ObjC vývojáři po tom, co Sun koupil Lighthouse Design, takže tam přenesli své znalosti, zvyky a postupy.

Jo aha. OK, ale to se pak nebavíme o typech, ne? Smalltalk typy nepoužívá, takže to už tolik nepřekvapí. V javě jsou interface typy, a jako takové se tak používají - jako nominální typ. Jakou ideu má ObjC to už netuším.

Nechceš to "takže tam přenesli své znalosti, zvyky a postupy." trochu rozvést, ať je tu alespoň něco zajímavého?

[listoper]

A kde se to používalo? U Javy?

Ani náhodou Ve Smalltalku. Java ale své "interface" okopčila z Objective-C, ta historie je celkem zajímavá, na Javě dělali (hlavně standardní knihovnu) ObjC vývojáři po tom, co Sun koupil Lighthouse Design, takže tam přenesli své znalosti, zvyky a postupy.

Jo aha. OK, ale to se pak nebavíme o typech, ne? Smalltalk typy nepoužívá, takže to už tolik nepřekvapí. V javě jsou interface typy, a jako takové se tak používají - jako nominální typ. Jakou ideu má ObjC to už netuším.

Nechceš to "takže tam přenesli své znalosti, zvyky a postupy." trochu rozvést, ať je tu alespoň něco zajímavého?

Smalltalk ma protokoly ne? Neni to totez co interface respektive typ?

A btw. nejsem si jisty, ze mel SB tohle na mysli.
@SB: Je to tak? Co je to ten netypovy interface?

[BoneFlute]

Smalltalk ma protokoly ne? Neni to totez co interface respektive typ?

Tak tady je to těžký - máš nominální typ, to jsou ty interface z Javy. Pak máš strukturální typy, což je hodně volně podobné duck typingu.

V případě tohoto vlákna se cca bavíme o statickém typování. Takže nakolik Smalltalk znám, tak ten padá.

Takže si asi definovat, co je typ o kterém se to bavíme :-)

[Bacsa]

A kde se to používalo? U Javy?

Ani náhodou Ve Smalltalku. Java ale své "interface" okopčila z Objective-C, ta historie je celkem zajímavá, na Javě dělali (hlavně standardní knihovnu) ObjC vývojáři po tom, co Sun koupil Lighthouse Design, takže tam přenesli své znalosti, zvyky a postupy.

Jo aha. OK, ale to se pak nebavíme o typech, ne? Smalltalk typy nepoužívá, takže to už tolik nepřekvapí.

No jasně, ale otázka zněla na "netypový interface".

[Reklama]

[Bacsa]

A kde se to používalo? U Javy?

Ani náhodou Ve Smalltalku. Java ale své "interface" okopčila z Objective-C, ta historie je celkem zajímavá, na Javě dělali (hlavně standardní knihovnu) ObjC vývojáři po tom, co Sun koupil Lighthouse Design, takže tam přenesli své znalosti, zvyky a postupy.

Nechceš to "takže tam přenesli své znalosti, zvyky a postupy." trochu rozvést, ať je tu alespoň něco zajímavého?

Tady je k tomu info přímo z první ruky: https://cs.gmu.edu/~sean/stuff/java-objc.html

[BoneFlute]

No jasně, ale otázka zněla na "netypový interface".

Tak jasně. Jsem původně nabyl (mylného) dojmu, že se u Javy začínalo s interfacemi bez typů, nebo tak něco zajímavého :-)

[Petr]

Potrebuju jeste na chvilku vyhrabat tohle vlakno, protoze si myslim, ze jsem narazil na oblast kde unit testy predci typy.
A chtel bych si nechat poradit jestli je to tak nebo ne...

Problem typu je zavislost na kompilatoru. Ve smyslu ja musim 'verit' kompilatoru, ze provede spravne statickou typovou kontrolu. U unit testu kompilatoru verit nemusim, protoze overeni spravnosti je na nem nezavisle.

Ve vetsine pripadu to asi nebude velky problem, ale co kdyz se budu u nejakeho projektu rozhodovat, ze vymenim kompilator za jiny, protoze ma nejake vyhody, kterych chci vyuzit(napada me jen rychlost, ale muze jich asi byt vic).

Co myslite?

Ano, to je jeden z problémů, ktdrý skrz své malé zkušenosti nevnímáš v celé jeho šíři. Změna kompilátoru není výjimečná, je běžná. Stačí změna platformy (multiplatformní program) či architektury. Kompilátor se mění i s jeho verzí.

Tyto nemají zaručeně ani stejný výstup, ani stejnou kontrolu. Často pak upravuješ program ne proto, že je chybný, ale aby prošel tím ne o onním kompilátorem.

A to ani nemusíme zabředávat do typů, které mění své vlastnosti podle architektury.

Ve výsledku statické typy představují spíše překážku než pomoc, protože překáží, kód je kvůli nim zbytečně těžkopádný a nepřehledný, což zvyšuje počet jiných chyb, které kompilátor neodhalí, a tak se stejně program musí testovat tak jako tak.

Typový systém není cesta k bezchybnému kódu a dokonce ani cesta ke snížení počtu chyb v programu.

Testy jsou lepší cesta. Sice se dá argumentovat, že to je také zbytečný kód navíc podobně jako u statických typů (což je pravda, práci to neušetří), ale je to kód, který není součástí výsledného programu.

Cesta k ideálu bezchybného kódu vede podle mě jinudy. Je to cesta krátkého, přehledného a dobře srozumitelného kódu. Čím méně má program řádků, tím méně má spolehlivě statisticky chyb, čím má jazyk pokročilejší konstrukce, které program zkracují a zpřehledňují či dokonce zabraňují udělat některé chyby, tím lépe.

Přičemž přehlednost a krátkost se mohou navzájem tlouci, takže zkracovat ano, ale nikdy na úkor přehlednosti.

Líbí se mi třeba konstrukce with, nebo zákaz používání přiřazení v podmínkách a podobně. To jsou jednoduchá opatření, která snižují počet chyb spolehlivěji, než statické typy, protože oproti nim si nenesou s sebou negativa.

To je zase blábol 

Svou vlastní reakci jsi vystihnul naprosto přesně. Můj příspěvek je založen na 30+ leté praxi, která se poněkud liší od školních teorií, s kterými mladá ucha chodí do týmu ze školních projektů. Typy nejsou to, na čem kvalita kódu stojí, jejich přínos je z hlediska praktické kvality kódu pofiderní, spíše negativní. Jejich benefit spočívá ve výkonu, což je pro některé úlohy významný a pro jiné bezvýznamný faktor. Bez testování se naopak žádná aplikace neobejde a čím více je testovaní prováděno jako standardizovaná rutina, tím lépe. Kdo tohle neví nebo nechápe, ten si žádnou praxí neprošel a je jen něčím, co nazývám salonním programátorem, který nikdy nestrávil pár nocí u zákazníka, kterému záhadně kolabuje regulační systém a podobně. Tohle vás naučí rozlišovat podstatné od nepodstatního a jak si vytvořit dobrou QA.

[Petr]

A něco poučného na téma složitosti: http://www.knesl.com/budoucnost-programovacich-jazyku

[Bacsa]

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čí?

[.]

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.

[Bacsa]

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 jaké jazyky jsou ty složité k pochopení? Kromě Haskellu teda.

[SB]

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čí?

https://en.wikipedia.org/wiki/Virtual_method_table

A kterou že to VŠ jste studoval vy?

[Bacsa]

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.

[SB]

Smalltalk ma protokoly ne? Neni to totez co interface respektive typ?

A btw. nejsem si jisty, ze mel SB tohle na mysli.
@SB: Je to tak? Co je to ten netypovy interface?

Protokolem ve Smalltalku je seznam jmen zpráv, kterým objekt rozumí. Není definován odděleně jako interface, ale v rámci třídy (třídně-instanční systém). Pokud si pamatuju, Smalltalk žádný mechanismus definice samostatného rozhraní a ověřování objektů na shodu s ním nemá.

Je-li interface (třeba v OOP) jakousi dohodou mezi systémem (objektem) a jeho uživatelem o poskytované funkcionalitě, pak asi bude logicky v netypových jazycích taky netypový. Není důvodu, proč by to nešlo, ale nikde jsem to neviděl (což na podstatě nic nemění).