Co si myslíte o OOP?

[Kit]

Celý ten případ s JSONem je na hlavu postavený. Pokud chci pracovat s hlubokou strukturou, prostě použiji JSONPath, stejně jako dříve uvedený příklad a mám to stejně rychle. Podle jazyka pak zpracuji chybu, pokud položka neexistuje. Žádný rozdíl.

Nejsem žádný mistr přes jazyky, ale pokud vím, všechny běžně používané staticky typované jazyky umožňují nějakým způsobem reflexi, takže není problém do nich dynamické typování "dodělat". Statické typování do dynamicky typovaných jazyků ale dodělat nelze.

Mám zkušenosti s oběma skupinami a největší rozdíl vidím v dokumentaci. Na co ve staticky typovaných jazycích stačí 3 řádky a odkaz na strukturu, je potřeba v dynamicky typovaných jazycích zpravidla 3x tolik informací. A ani potom nemám moc velkou jitotu, co tam skutečně může být.

Nakonec jsme se dopracovali k tomu, že ve staticky typovaných jazycích používáš dynamické typování, protože bez něj bys tu úlohu neudělal. Zpracování reflexe je také z dynamického typování. Otázkou je, k čemu by mi bylo statické typování v dynamicky typovaném jazyce. A že nejdou dodělat? V PHP jdou...

Na co v dynamicky typovaných jazycích stačí jedna metoda, ve staticky typovaných potřebuješ třeba tři přetížené. Například pokud potřebuješ sort pro integer, float nebo string.

[Reklama]

[BoneFlute]

... největší rozdíl vidím v dokumentaci.

Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.

[Kadet]

... největší rozdíl vidím v dokumentaci.

Mě teda oslovilo compile time. Když konečně přesvědčím kompilátor, aby to přeložil, tak mám obecně hotovo. Zbejvaj sémantické chyby. Zatímco u dynamického jazyka furt něco padá.

Problem je 'presvedcit kompilator'. Napr. existuji programy, ktere dokaze clovek interpretovat, ale nelze je staticky overit. Soundness vs Completeness.

Prakticky kazdej praktickej clovek, kdo kdy delal v necem staticky typovanym a pak zkusil neco napsat v pythonu, jq nebo one line pipelinu ve shellu, chtel staticky jazyky hodit do kose. Staticky jazyky jsou dobry akorat na definovani jednoduchy funkce, kterou je treba silne zoptimalizovat. Do dynamickych jazyku se pak lehce importuje skrz FFI. Z pohledu dynamickyho jazyka je takova importovana staticka funkce ekvivalentni hardwaru. Funkce je rychlejsi a je nemenici se = nova instrukce = hardware.

Napr. si napisu v C funkci add_vector(xs: ints, ys: ints) ktera mi vrati soucet obou vstuonuch vektoru. V pythonu si to importnu a muzu to brat jako optimalizovanou vektorizovanou CPU instrukci.

[BoneFlute]

Mam dva objekty. Chci ziskat 'name'.

V dynamickym jazyce zavolam 'query("name")' a jdu domu, splneno. Jak bude vypadat ve statickym jazyce typ kterej mi zvladne oba priklady? Nebo musim vytvorit powerset vsech kombinaci pritomnych/chybejicich poli?
Opakuju, pouziti datovyho typu 'JsonNode' je reimplementace dynamickyho typovani.

{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam"}

Pseudokód, rozepsáno (pro laiky):

Kód: [Vybrat]

s = "{id:42, name:"Adam", birthdate:"1995-05-25"}"
type Person = {id: Int, name: String, birthdate: Maybe Date}
print (Person id, name, birthdate) = id .. name .. (case birtdate
   Just x -> x
   Nothing -> '')
print (Json.parse Person s)
Tak samozřejmě, že by to šlo napsat i pomocí toho query("name"), ale myslím si, že by to nikdo soudnej nedělal. Bylo by to přesně to dynamické, aniž by to přineslo nějaký užitek, a jen jeho nedostatky:

Kód: [Vybrat]

s = "{id:42, name:"Adam"}"
print [id, name, birthdate] = id .. name .. birtdate
print (Json.query ['id', 'name', 'birthdate'] s)
->> KeyError

[BoneFlute]

Problem je 'presvedcit kompilator'. Napr. existuji programy, ktere dokaze clovek interpretovat, ale nelze je staticky overit. Soundness vs Completeness.

Prakticky kazdej praktickej clovek, kdo kdy delal v necem staticky typovanym a pak zkusil neco napsat v pythonu, jq nebo one line pipelinu ve shellu, chtel staticky jazyky hodit do kose. Staticky jazyky jsou dobry akorat na definovani jednoduchy funkce, kterou je treba silne zoptimalizovat.

Ano, to jsem psal. Důvody pro dynamicky typovaný jazyk:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování
3. neumím, nebo jazyk neumí typy

Samozřejmě sám sebe označit za praktického člověka a pak všechny ty, kteří to mají jinak označit za nepraktické je hodně odvážně, ale budiž ti přáno.

Takže ještě jednou. Pokud by si byl schopen uvést nějakou výhodu dynamicky typovaných jazyků, krom těch mnou zmíněných tří bodů - sem s tím. V opačném případě to tedy můžem uzavřít.

[Reklama]

[Kadet]

Mam dva objekty. Chci ziskat 'name'.

V dynamickym jazyce zavolam 'query("name")' a jdu domu, splneno. Jak bude vypadat ve statickym jazyce typ kterej mi zvladne oba priklady? Nebo musim vytvorit powerset vsech kombinaci pritomnych/chybejicich poli?
Opakuju, pouziti datovyho typu 'JsonNode' je reimplementace dynamickyho typovani.

{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam"}

Pseudokód, rozepsáno (pro laiky):

Kód: [Vybrat]

s = "{id:42, name:"Adam", birthdate:"1995-05-25"}"
type Person = {id: Int, name: String, birthdate: Maybe Date}
print (Person id, name, birthdate) = id .. name .. (case birtdate
   Just x -> x
   Nothing -> '')
print (Json.parse Person s)
Tak samozřejmě, že by to šlo napsat i pomocí toho query("name"), ale myslím si, že by to nikdo soudnej nedělal. Bylo by to přesně to dynamické, aniž by to přineslo nějaký užitek, a jen jeho nedostatky:

Kód: [Vybrat]

s = "{id:42, name:"Adam"}"
print [id, name, birthdate] = id .. name .. birtdate
print (Json.query ['id', 'name', 'birthdate'] s)
->> KeyError

Diky, to byl zacatek. Druhej den mi api posle json s velikosti bot. Treti den se tam objevi pole s vysi jeho platu, atd atd.

{id:42, name:"Adam"}
{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam", birthdate:"1995-05-25", shoesize:43}
{id:42, name:"Adam", birthdate:"1995-05-25", salary:200000}

K moji smule musim kazdej den prepisovat typ Person i kdyz me zajima jenom jeho jmeno.

Druha vec. Je rozdil mezi chybejicim polem birthdate a kdyz je birthdate v jsonu null. Takze ten typ by vypadal spis (Maybe (Date|null)).

Dynamicky by to udelal kazdej soudnej clovek co chce domu prinest penize a nakrmit zenu a deti. Tyhle haskell hratky jsou pro lidi produkujici akademicky hracky. Mam tu cest s takovyma pracovat a jejich napln dne je debatovat nad morfismama a kategoriema misto dodavani vysledku.

[Kadet]

Problem je 'presvedcit kompilator'. Napr. existuji programy, ktere dokaze clovek interpretovat, ale nelze je staticky overit. Soundness vs Completeness.

Prakticky kazdej praktickej clovek, kdo kdy delal v necem staticky typovanym a pak zkusil neco napsat v pythonu, jq nebo one line pipelinu ve shellu, chtel staticky jazyky hodit do kose. Staticky jazyky jsou dobry akorat na definovani jednoduchy funkce, kterou je treba silne zoptimalizovat.

Ano, to jsem psal. Důvody pro dynamicky typovaný jazyk:
1. za běhu měnitelný systém (znám jen Erlang)
2. prototypování
3. neumím, nebo jazyk neumí typy

Samozřejmě sám sebe označit za praktického člověka a pak všechny ty, kteří to mají jinak označit za nepraktické je hodně odvážně, ale budiž ti přáno.

Takže ještě jednou. Pokud by si byl schopen uvést nějakou výhodu dynamicky typovaných jazyků, krom těch mnou zmíněných tří bodů - sem s tím. V opačném případě to tedy můžem uzavřít.

Uzavrem to klidne. Myslim ze se shodnem na tom, ze schopnost dodat vysledek v staticky typovanym jazyce se v nekterych konkretnich prikladech realneho sveta blizi k nule. Muj verdikt o dynamickych jazycich v kontrastu tedy, muzes si to pridat jako dalsi bod, je ze jsou POUZITELNY. Jinymi slovy jsem schopen dodat vysledek. Se statickym jazykem ostatni lidi mezitim dodavaji akorat hromadu slibu.

[BoneFlute]

Mam dva objekty. Chci ziskat 'name'.

V dynamickym jazyce zavolam 'query("name")' a jdu domu, splneno. Jak bude vypadat ve statickym jazyce typ kterej mi zvladne oba priklady? Nebo musim vytvorit powerset vsech kombinaci pritomnych/chybejicich poli?
Opakuju, pouziti datovyho typu 'JsonNode' je reimplementace dynamickyho typovani.

{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam"}

Pseudokód, rozepsáno (pro laiky):

Kód: [Vybrat]

s = "{id:42, name:"Adam", birthdate:"1995-05-25"}"
type Person = {id: Int, name: String, birthdate: Maybe Date}
print (Person id, name, birthdate) = id .. name .. (case birtdate
   Just x -> x
   Nothing -> '')
print (Json.parse Person s)
Tak samozřejmě, že by to šlo napsat i pomocí toho query("name"), ale myslím si, že by to nikdo soudnej nedělal. Bylo by to přesně to dynamické, aniž by to přineslo nějaký užitek, a jen jeho nedostatky:

Kód: [Vybrat]

s = "{id:42, name:"Adam"}"
print [id, name, birthdate] = id .. name .. birtdate
print (Json.query ['id', 'name', 'birthdate'] s)
->> KeyError

Diky, to byl zacatek. Druhej den mi api posle json s velikosti bot. Treti den se tam objevi pole s vysi jeho platu, atd atd.

{id:42, name:"Adam"}
{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam", birthdate:"1995-05-25", shoesize:43}
{id:42, name:"Adam", birthdate:"1995-05-25", salary:200000}

K moji smule musim kazdej den prepisovat typ Person i kdyz me zajima jenom jeho jmeno.

Nemusíš. Naparsují se hodnoty, které tam jsou, které vyžaduješ. Ostatní je smetí, které se bude ignorovat.

Druha vec. Je rozdil mezi chybejicim polem birthdate a kdyz je birthdate v jsonu null. Takze ten typ by vypadal spis (Maybe (Date|null)).

Nevypadal.

Uzavrem to klidne. Myslim ze se shodnem na tom, ze schopnost dodat vysledek v staticky typovanym jazyce se v nekterych konkretnich prikladech realneho sveta blizi k nule. Muj verdikt o dynamickych jazycich v kontrastu tedy, muzes si to pridat jako dalsi bod, je ze jsou POUZITELNY. Jinymi slovy jsem schopen dodat vysledek. Se statickym jazykem ostatni lidi mezitim dodavaji akorat hromadu slibu.

Neschodnem. Mě by zajímal konkrétní scénář, kdy je dynamický jazyk tak výrazně použitelnější, že to slovo píšeš kapitálkama. (Parsování JSON to evidentně není.) To, že to prohlašuješ mi pochopitelně nestačí.

Možná si budu muset počkat na někoho, kdo rozumí obému.

[Kadet]

Mam dva objekty. Chci ziskat 'name'.

V dynamickym jazyce zavolam 'query("name")' a jdu domu, splneno. Jak bude vypadat ve statickym jazyce typ kterej mi zvladne oba priklady? Nebo musim vytvorit powerset vsech kombinaci pritomnych/chybejicich poli?
Opakuju, pouziti datovyho typu 'JsonNode' je reimplementace dynamickyho typovani.

{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam"}

Pseudokód, rozepsáno (pro laiky):

Kód: [Vybrat]

s = "{id:42, name:"Adam", birthdate:"1995-05-25"}"
type Person = {id: Int, name: String, birthdate: Maybe Date}
print (Person id, name, birthdate) = id .. name .. (case birtdate
   Just x -> x
   Nothing -> '')
print (Json.parse Person s)
Tak samozřejmě, že by to šlo napsat i pomocí toho query("name"), ale myslím si, že by to nikdo soudnej nedělal. Bylo by to přesně to dynamické, aniž by to přineslo nějaký užitek, a jen jeho nedostatky:

Kód: [Vybrat]

s = "{id:42, name:"Adam"}"
print [id, name, birthdate] = id .. name .. birtdate
print (Json.query ['id', 'name', 'birthdate'] s)
->> KeyError

Diky, to byl zacatek. Druhej den mi api posle json s velikosti bot. Treti den se tam objevi pole s vysi jeho platu, atd atd.

{id:42, name:"Adam"}
{id:42, name:"Adam", birthdate:"1995-05-25"}
{id:42, name:"Adam", birthdate:"1995-05-25", shoesize:43}
{id:42, name:"Adam", birthdate:"1995-05-25", salary:200000}

K moji smule musim kazdej den prepisovat typ Person i kdyz me zajima jenom jeho jmeno.

Nemusíš. Naparsují se hodnoty, které tam jsou, které vyžaduješ. Ostatní je smetí, které se bude ignorovat.

Druha vec. Je rozdil mezi chybejicim polem birthdate a kdyz je birthdate v jsonu null. Takze ten typ by vypadal spis (Maybe (Date|null)).

Nevypadal.

Uzavrem to klidne. Myslim ze se shodnem na tom, ze schopnost dodat vysledek v staticky typovanym jazyce se v nekterych konkretnich prikladech realneho sveta blizi k nule. Muj verdikt o dynamickych jazycich v kontrastu tedy, muzes si to pridat jako dalsi bod, je ze jsou POUZITELNY. Jinymi slovy jsem schopen dodat vysledek. Se statickym jazykem ostatni lidi mezitim dodavaji akorat hromadu slibu.

Neschodnem. Mě by zajímal konkrétní scénář, kdy je dynamický jazyk tak výrazně použitelnější, že to slovo píšeš kapitálkama. (Parsování JSON to evidentně není.) To, že to prohlašuješ mi pochopitelně nestačí.

Možná si budu muset počkat na někoho, kdo rozumí obému.

Aha, takze nechces typovat celej ten json objekt, ale pouze tu podmnozinu se kterou chces pracovat.

Prakticky si svym Person typem nadefinoval json schema, podle kteryho prichozi json objekt zvalidujes. Dela to za tebe zrejme json.parse funkce a statickej typ je jaon schema.

Takze prijmes objekt, zvalidujes ho podle schematu, vyberes si jen ty hodnoty, ktery tvuj typ definuje a pretransformujes json reprezentaci do ekvivalentni interni stromovy reprezentace v haskellu treba.

Kdyz mas dobrej ekosystem, ve kterym mas tak dobrej parser a serializer, ze dokaze pouzit reflexi nad typem, tak ti to bude fungovat.
Pak musis mit v ekosystemu spoustu sikovnych funkci, ktery ti umozni s takovym typem obecne pracovat. Prece nebudes pro kazdy pridany pole pridavat funkcionalitu do funkci ktery nad tim typem pracujou. Tzn. asi nejaka silna reflexe.

V dynamickym prostredi to deserializuju do obyc nestovanyho dict objektu, nad kterym mam dostupnych tisic generickych funkci. Konverzi do vsech moznych formatu. Vse dostupne out of the box.
Chci mit nejakou garanci o tom objektu?  Dam si praci a nadefinuju schema podle kteryho objekt overim, podobne jako ve tvym statickym prikladu.

[n]

Mohl by jsi uvezt priklad z oblasti sw inzenyrstvi, kde nejaky produkt mel hlavne dobry marketing, ale jinak nestal za moc?

Z ktere oblasti chces priklad? MS-DOS, Windows 95, MS Word, MS Excel, PHP, IE, VB, ASP, Javascript, Eclipse, Hadoop, MongoDB..

Ke kazde z tech veci v te dobe existovaly podstatne lepsi alternativy, jen byly (z toho ci onoho duvodu = marketing) mene zname.

Mohl bys prosimte napsat alternativy k win95, word, excel, hadoop?

[Octopuss]

Jsou to teroristi!?!

[Mirek Prýmek]

1. Erlang dokáže za chodu opravovat/upravovat kód. A autoři prohlásili, že tam typy nedali, protože se jim nepovedlo vymyslet jak na to.

Měl bys k tomuhle nějakej odkaz? Přijde mi divný, že by to zaznělo přesně takhle (že by tím důvodem byl právě hot code loading).

---

Jinak k té debatě statický vs. dynamický: ani trochu se nechci účastnit flamewaru, přijde mi to dětinský. Oba přístupy mají svoje pro a proti a každej si může vybrat, co mu víc vyhovuje. IMHO jsi ale udělal v úvahách několik faktických/argumentačních chyb.

1. Několikrát opakuješ obrat "nemá typy". To je minimálně zavádějící. Dynamické jazyky mají typy. Od staticky typovaných se liší jenom tím, jestli informaci o typu znáš (pozitivně, s jistotou) při překladu, nebo až v době běhu. V principu provádíš tu stejnou kontrolu, jenom jindy. Výhoda statických jazyků je v tom, že kontrolu provedeš (ve většině případů - viz 2) jenom jednou, zatímco u dynamického ji musíš provádět pořád dokola, za běhu.

2. Z bodu 1 přímo vyplývá, že statický jazyk má problém v situacích, kdy typ v době překladu z principu nemůžeš znát - to je ten příklad s načítáním JSONu, ale můžeš jich vymyslet bambilion jiných. Můžeš to řešit dvěma způsoby (možná i jinak, ale teď mě jiná možnost nenapadá):

A) buď máš k dispozici algebraické typy a (v době překladu neznámý) typ prohlásíš za nějakou nadmnožinu různých typů, v extrémním případě všech myslitelných a dál pracuješ s tímhle nadtypem

B) nebo typ zjistíš za běhu (dynamické typování!) a program podle typu větvíš, takže i v době překladu víš, že do určité větve ti jde už jenom určitý typ

3. Někde jsi řekl, že do dynamických jazyků nejdou typy (při překladu) dodat. To není pravda. Stejně jako se u statického jazyka občas musíš uchýlit k dynamickému typování, můžeš u dynamického jazyka otypovat ty části programu, kde v době překladu víš, co tam bude za typ. A můžeš to i kontrolovat, úplně stejně jako u statického (viz např. u Erlangu Dializer). Dokonce by asi i šlo (ale nevím o žádném dynamickém jazyce, který by to uměl) třeba některé části programu otypovat staticky a u nich vyhodit kontroly typů za běhu.

Prostě, ty dva přístupy se vzájemně nevylučují. Je třeba si jenom uvědomit, že u některých částí programu víš předem, s jakými daty může pracovat, u jiných částí to nevíš (ani u jednoho typu jazyka). Ty části můžou být různě velké.

Na druhou stranu s tebou docela souhlasím v tom, že udržovat tu část, kde typy znáš, co největší (a tím se vyvarovat runtime chybám) je docela dobrý přístup. Ale i kdyby ses na hlavu postavil, nemůžeš mít takových 100% programu. Někde prostě z principu věci dostaneš data, jejichž typ v době překladu neznáš.

[Mirek Prýmek]

Upřesnění:

máš k dispozici algebraické typy

Tohle jsem moc zúžil. Nemusí to být jenom vyloženě algebraické typy, ale jakýkoliv mechanismus "nadtypů". Třeba i to klasické OOP "načtu přes síť objekt, neznám jeho kompletní typ, ale vím, že umí zpracovat zprávu saveToPdf" - to je taky "nadtyp".

[Mirek Prýmek]

P.S. Taky není od věci si uvědomit, že "znát typ" není nic jiného, než "vědět něco o datech, která se v tomhle místě programu můžou vyskytnout". Přičemž u drtivé většiny jazyků (všech?) to "něco" pořád ještě nestačí k tomu, abys mohl mít jistotu, že program bude ve všech případech běžet korektně.

Např. pokud víš, že ve výrazu x / y je y s jistotou "integer", je ti to víceméně na nic, protože situace, kdy je y nula má stejné důsledky jako kdyby to byl string. Dělení nulou je stejně nedefinované jako dělení stringem. Takže kdykoli se ti v programu objeví dělení (nebo jakákoli jiná parciální funkce), stane se ti ze statického jazyka efektivně dynamický - protože prostě v době překladu nejsi schopný ověřit korektnost.

[Mirek Prýmek]

A co se zeptat opačně - proč by nutně musely mít nějaký dopředu známý patřičný typ? Když jdu nakupovat rohlíky, tak k tomu také nepotřebuji speciální tašku na rohlíky.

Tady podsouváš něco, co není pravda (strawman). Že máš staticky typovaný jazyk ještě neimplikuje, že musíš nutně pracovat jenom s nějakými základními typy a všechny je zvlášť ošetřovat. Stačí ti mít nějaký mechanismus nadtypů (viz výš).

Že některé statické jazyky nadtypy nemají, to považuju za zločin (jo, mluvím o tobě, Go!).

Čili v tom tvém příkladu: máš nadtyp "cokoli do čeho se dá vložit cokoli, co je menší než Boeing"