Co si myslíte o OOP?

[BaldSlattery]

Tedy "sum type"? Tak tam má Go asi fakt handicap.

Jo. Nebo se používá i termín "composite type".

Určitě? Composite type je prachobyčejný record/struct/class: https://en.wikipedia.org/wiki/Composite_data_type

[Reklama]

[listoper]

To E v REPL znamena "evaluate".  Nevim jak jinde, ale v mem oblibenem clojure proste predhodim REPLu kod a on se evaluuje. To znamena, ze pokud v tom kodu prepisu funkci, nebo cely namespace tak stara verze kodu efektivne zmizi a je nahrazena tou predhozenou.
A uz sem to videl v akci i na produkci... (byl to trochu opruz kvuli sitarum a bezpecakum, ale nakonec to probehlo)

No jistě, ale to je něco jinýho.

Hot reloading v Erlangu je o tom, že ti běží na serveru nějaká aplikace a ty v ní za běhu změníš část kódu. Klíčový je to, že měníš existující aplikaci, zatímco v REPLu vlastně vytváříš novou.

Ano na vzdalenem produkcnim serveru mi bezi existujici aplikace. Pripojim se pomoci nREPL a hot reloadnu si co chci...
V navrhu erlangu to zrejme bylo klicove, zatimco v clojure to funguje spis nahodou, nez ze by to byl cil... ale funguje.
Samozrejme se na nejtere veci musi davat pozor.... Pokud sejdes z cesty a zacnes intenzivne pouzivat java interop, nebo atomy tak si muzes tu bezici aplikaci nakopnout. Ale pokud budes psat pure funkce tak je to bez problemu.

Jednou sem dokonce celou aplkaci vyvyjel na vzdalenem serveru. Nebylo to nic velkeho a bylo to potreba jen na par tydnu. Nastartoval jsem si na cilovem serveru REPL u sebe CIDER a pripojil se na nej. Kdyz jsem byl hotov jen sem odpojil CIDER a nechal to bezet. Druhy den sem se zase pripojil abych pridal novy endpoint a zase odpojil. Bylo to jen v testovacim prostredi (na produkci bych na to nemel koule), ale intenzivne se pouzivalo behem toho co sem vyvyjel....

[Mirek Prýmek]

Protože staticky typovaný jazyk mi říká "hele, tu informaci, co konkrétně se chystáš nakupovat, bezpodmínečně potřebuju znát dopředu",

A to právě není pravda. I ve statickém jazyce můžeš mít kolekci "neznámého" typu. Ten typ musí minimálně splňovat vlastnosti, které jsou pro tu danou kolekci potřeba (např. musí být hashovatelný) a maximálně to může být i konkrétní typ. K praktické implementaci pak potřebuješ parametrizovatelné typy - něco jako Array<String>.

Statické typování mě nutí, abych dopředu znal nějaké omezení

Ne. Dobře udělané statické typování tě jenom nutí, aby ty vkládané objekty měly vlastnosti, které pro vložení do té které kolekce jsou nutně potřeba (např. ta hashovatelnost). A to je správně.

, nebo abych si ho uměle vytvořil

Nic takového se neděje.

[Mirek Prýmek]

Určitě? Composite type je prachobyčejný record/struct/class: https://en.wikipedia.org/wiki/Composite_data_type

No dyť jo Struct můžeš taky zneužít jako nadtyp: pokud chceš funkci, která vrací string nebo int, tak vrátíš struct se dvěma položkami, jedna string a druhá int.

[Mirek Prýmek]

Ano na vzdalenem produkcnim serveru mi bezi existujici aplikace. Pripojim se pomoci nREPL a hot reloadnu si co chci...
V navrhu erlangu to zrejme bylo klicove, zatimco v clojure to funguje spis nahodou, nez ze by to byl cil... ale funguje.
Samozrejme se na nejtere veci musi davat pozor.... Pokud sejdes z cesty a zacnes intenzivne pouzivat java interop, nebo atomy tak si muzes tu bezici aplikaci nakopnout. Ale pokud budes psat pure funkce tak je to bez problemu.

No vždyť já netvrdím, že to v Clojure nejde. Jenom říkám, že to neplyne z toho, že má REPL.

[Reklama]

[Inkvizitor]

Tedy "sum type"? Tak tam má Go asi fakt handicap.

Jo. Nebo se používá i termín "composite type".

No ale interface naopak podporuje...
Ne že bych chtěl zrovna já obhajovat Go, jenom mě zajímalo, proč jsi po něm tak tvrdě vyjel.

Interfejsy sice podporuje, ale celkově je ten type systém dost omezený. Prakticky se to projevuje tak, že ve spoustě kódu uvidíš "prázdný interfejs" - tj. ekvivalent Object. Go je na tom prostě teď stejně jako Java před deseti lety. A i ty argumenty jsou stejné... (nejen) v tomhletom je Go trochu smutný příběh.

Jasně, i mně přijde návrh Go na hlavu (pragmatické výhody jsou, nepopírám). Teď řeší, jak udělat líp ošetření chyb, přičemž ale už v době původního návrhu jazyka muselo být jasné, že řešením je haskellovský Either. Jenže oni se rozhodli ten jazyk napsat takhle "blbě", protože takhle blbě se přece píše kód už desítky let a taky to jde.

Na druhou stranu třeba Rust má prakticky všechno správně - má algebraické typy, má pattern matching, má monadické řetězení operací, všechno krásně zapadá. Na druhou stranu je ten jazyk statický až na půdu, všechny ty abstrakce se v době překladu zapečou až pomalu do železa. Může to omezovat, ale sedí mi to dohromady.

[BaldSlattery]

Určitě? Composite type je prachobyčejný record/struct/class: https://en.wikipedia.org/wiki/Composite_data_type

No dyť jo Struct můžeš taky zneužít jako nadtyp: pokud chceš funkci, která vrací string nebo int, tak vrátíš struct se dvěma položkami, jedna string a druhá int.

Můžu, všechno se dá ochcat, ale už to není sum type.

[JS]

Tak snad nemusí být hned tak zle. Mě to jen připomělo, že občas narážím na hlasy, které obhajují dynamické typování. A já bych si někdy opravdu docela rád vyslechl v čem je to užitečné. (Čímž díky @Kiwi-mu za pokus o vysvětlení, ačkoliv to zatím nestačilo :-) )

Podle me to ma smysl u interpretovanych/skriptovacich jazyku, jejichz premisou je tvorba "lepiciho" kodu s pomerne malou mnozinou zakladnich typu. Pripadne v domenove-specifickych oblastech.

Typy se v programovani pouzivaji pro 3 ruzne ucely, a jen jeden z nich je typova kontrola. Pokud typovou kontrolu nutne nevyzadujes, pak typicky ani nevyzadujes druhy ucel, kterym je kontrola nad zpusobem ulozeni dat v pameti (coz je casto dusledek toho, ze mnozina zakladnich/vestavenych typu je mala). Zbyva tedy treti smysl typu - polymorfni dispatch - a u dynamickych jazyku se to zjednodusuje o to, ze se usetri jmenny prostor a nemusime type checkeru vysvetlovat nektere situace. Tedy vyhodou je, temer vyhradne, kratsi a prehlednejsi zapis.

Nicmene s rozvojem typove inference to prestava postupne davat smysl i v techto oblastech.

[Mirek Prýmek]

Jasně, i mně přijde návrh Go na hlavu (pragmatické výhody jsou, nepopírám). Teď řeší, jak udělat líp ošetření chyb, přičemž ale už v době původního návrhu jazyka muselo být jasné, že řešením je haskellovský Either. Jenže oni se rozhodli ten jazyk napsat takhle "blbě", protože takhle blbě se přece píše kód už desítky let a taky to jde.

Na druhou stranu třeba Rust má prakticky všechno správně - má algebraické typy, má pattern matching, má monadické řetězení operací, všechno krásně zapadá. Na druhou stranu je ten jazyk statický až na půdu, všechny ty abstrakce se v době překladu zapečou až pomalu do železa. Může to omezovat, ale sedí mi to dohromady.

Jo, mám z toho úplně stejný pocit. V Go udělali několik rozhodnutí, který vůbec nechápu. V Rustu jsem na nic takovýho nenarazil (ale znám ho málo, daleko míň než Go, ve kterým jsem psal i nějaký netriviální produkční kód).

Co jsem se koukal na návrhy ohledně Go 2.0, vypadá to, že celkem napravují většinu věcí, který v jedniččce vůbec neměly být. Možná ta dvojka bude i docela pěknej jazyk konečně

[Mirek Prýmek]

Můžu, všechno se dá ochcat, ale už to není sum type.

Ne, je to product type

[BaldSlattery]

Mě to jen připomělo, že občas narážím na hlasy, které obhajují dynamické typování. A já bych si někdy opravdu docela rád vyslechl v čem je to užitečné.

Užitečná je pozdní vazba. A užitečná je i kontrola typů při překladu. Úplně nejlépe to má asi vyřešené ObjC, které má stejný dispatch zpráv jako Smalltalk, ale překladač kontroluje typy, jsou-li uvedeny (původní ObjC mělo jen “id”). Při překladu se tedy kontrolují typy vzhledem k hierarchii (dědičnost) a konformanci. Když chci, můžu použít “id” a pak se kontrola při překladu neprovádí. Většina běžného kódu tedy může být staticky otypovaná a jen v případě nouze můžu nechat kontrolu typů až na běh. Navíc v kombinaci s instancetype a auto se typy ani nemusí explicitně uvádět, překladač si je totiž odvodí (a zkontroluje) sám. V Go je pozdní vazba také (jako v ObjC) implementovaná pomocí isa, což se používá při volání metod na proměnných deklarovaných jako interface.

[listoper]

Ano na vzdalenem produkcnim serveru mi bezi existujici aplikace. Pripojim se pomoci nREPL a hot reloadnu si co chci...
V navrhu erlangu to zrejme bylo klicove, zatimco v clojure to funguje spis nahodou, nez ze by to byl cil... ale funguje.
Samozrejme se na nejtere veci musi davat pozor.... Pokud sejdes z cesty a zacnes intenzivne pouzivat java interop, nebo atomy tak si muzes tu bezici aplikaci nakopnout. Ale pokud budes psat pure funkce tak je to bez problemu.

No vždyť já netvrdím, že to v Clojure nejde. Jenom říkám, že to neplyne z toho, že má REPL.

A ja si prave myslim, ze plyne. A koukal jsem na par prikladu jak se to dela v tom erlangu a prijde mi to velmi podobne. Neni eshell vlastne takovy REPL?
Treba java ma jshell, ale to neni (podle me) plnohodnotny REPL. A taky nevim jak udelat  v jave rozumne hot swapping. Slysel jsem o jRebel, ale nikdy jsem to nevidel v praxi.

[Mirek Prýmek]

A ja si prave myslim, ze plyne. A koukal jsem na par prikladu jak se to dela v tom erlangu a prijde mi to velmi podobne. Neni eshell vlastne takovy REPL?

Ne "vlastne takovy", eshell je REPL.

Akorat porad nezorumim tomu, proc tyhle dve vlastnosti spojujes, jsou uplne ortogonalni. REPL muzes udelat v jakemkoliv jazyce, k hot code (re)loadingu potrebujes nekolik predpokladu, ktere ne kazdy jazyk splnuje.

V JVM, co jsem se dočetl, hot reloading jde, ale nemůžeš měnit signatury ani odstraňovat nebo přidávat metody. Takže vlastně můžeš jenom měnit implementaci existujících věcí.

[listoper]

A ja si prave myslim, ze plyne. A koukal jsem na par prikladu jak se to dela v tom erlangu a prijde mi to velmi podobne. Neni eshell vlastne takovy REPL?

Ne "vlastne takovy", eshell je REPL.

Akorat porad nezorumim tomu, proc tyhle dve vlastnosti spojujes, jsou uplne ortogonalni. REPL muzes udelat v jakemkoliv jazyce, k hot code (re)loadingu potrebujes nekolik predpokladu, ktere ne kazdy jazyk splnuje.

V JVM, co jsem se dočetl, hot reloading jde, ale nemůžeš měnit signatury ani odstraňovat nebo přidávat metody. Takže vlastně můžeš jenom měnit implementaci existujících věcí.

Spojuju, protoze se domnivam, ze kdyz ma jazyk REPL tak uz ma vse co je potreba k hot swapu. Treba jde hot swap i bez nej, ale nevim jak.

Jake jsou ty predpoklady ktere myslis, ze jsou k hot swapu potreba?


A btw. taky se domnivam, ze nejde udelat (plnotucny) REPL v kazdem jazyce... Treba ta java ho pokud vim nema. Co treba C?

[Mirek Prýmek]

Jake jsou ty predpoklady ktere myslis, ze jsou k hot swapu potreba?

No napriklad musis mit moznost nejak zabezpecit, ze kod nepoleze do kodu, ktery prave reloadujes. Nebo musis mit moznost mit zaraz v pameti dve verze tehoz. Pak musis mit vubec moznost kod za behu menit. Nesmi existovat zpusob, jak se na kod odkazovat (pointerem nebo necim podobnym), nebo musis mit moznost ty odkazy automaticky updatovat. Atd. atd. těch věcí je moře.

A btw. taky se domnivam, ze nejde udelat (plnotucny) REPL v kazdem jazyce... Treba ta java ho pokud vim nema. Co treba C?

REPL není nic jiného než iteraktivní vyhodnocovač výrazů. Pokud pro nějaký jazyk není, tak spíš proto, že to u něj nedává moc smysl, např. proto, že výrazy jsou v tom jazyce podružná věc. Mám pocit, že máš nějaké mylné představy o magické podstatě REPLu

Pro Javu existuje: https://www.infoq.com/articles/jshell-java-repl