Názory k článku Programovací paradigma založené na tocích (dat) a knihovna goflow

No vetsina Javistu, co mluvi o immutable strukturach, vlastne ani nevi, o cem mluvi, to je zajimave. Tak reknete napriklad, jak by se v Jave resil (kdyz to "Java ma dlouho") napriklad takovy zakladni problem, jako immutable seznam nebo klidne i immutable pole (vektor). A ani nechci, aby to umelo structural sharing.

V Javě to je velice snadné, napíše se to v Haskellu a použije JNI :)

Tos zabil :-)

To je obecný nešvar nejen javistů, spousta script kiddies nezná ani základní terminologii, jedou si svůj pseudojazyk (JS nebo Python) s klapkami na očích. Člověk je ani nestíhá vyhazovat od pohovorů :)

Isteze Java typicky pouzivaju script kiddies, je to iba pseudo jazyk a uz buduci tyzden sa Erlang stane mainstream.
Hned potom sa citite ako lepsi ludia?

Java není pseudojazyk, nauč se číst (doporučuju výčet v závorce — JS a Python). Java je v rámci průměru celkem v pohodě.

Ked preexponujete vy jednym smerom mozem ja druhym.

Neplanujem studovat co si ludia od Erlangu myslia o immutable, ak sa zhodneme na takejto definicii: Immutable data structure are data structures, like lists, arrays, sets etc., which cannot be changed, meaning that the values inside them can't be added, removed, moved or swapped.
Tak potom java.util.Collec­tions:
unmodifiableCo­llection(...)
unmodifiableLis­t(...)
unmodifiableMap(­...)
unmodifiableSet(­...)
unmodifiableSor­tedMap(...)
unmodifiableSor­tedSet(...)

Praveze vubec, beru z dokumentace*:

Note that changes to the backing collection might still be possible, and if they occur, they are visible through the unmodifiable view. Thus, an unmodifiable view collection **is not necessarily immutable**

* https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Collection.html#unmodview

Ak nerozumiete tomu ako funguje Java tak je to potom dost komplikovane. Ak vam z volania metody vratim immutable list nemate sa ako dostat k backing listu. To je iba upozornenie akym sposobom pracuje ta wrap vrstva ktora vam obali normalny list. Takze pokial si ho drzite u seba (ecapsulation) alebo ten smernik 'zabudnete/za­hodite' nie je sposob akym sa da dostat k tomu backing listu.
Takze stale plati ze vrateny list je immutable.

Ono je možná dobré si to vůbec nekomplikovat a říct si "vytisknu objekt - jeho hodnotu". Pokud po sérii dalších operací při tisku dosanu odlišnou textovou reprezentaci, není objekt immutable.

(mimochodem ty unmodifiable "pohledy" toto nesplňují, proto se tam taky slovo "immutable" nepoužívá)

- ta definicia je nezmyselna
- preco to tie 'pohlady' nesplnaju
- myslim ze v Jave dokazete bez problemov napisat take immutable aby splnali akukolvek definiciu immutable si vymyslite, existujuca implementacia v JVM je proste prakticka a postacujuca na pouzitie, to neznamena ze by sa v Jave pre pripad potreby nedala napisat aj uplne striktna implementacia immutable

Zkusím to vysvětlit. Zaprvé na "immutability" se musíme dívat jako na potenciálně velmi užitečnou vlastnost, nikoli jako na absenci "mutability".

Je to skutečně užitečná vlastnost, která nám mj. zaručuje, že se nám stav objektu pod rukama nezmění. A nejenom to, dokonce je zaručeno, že stav objektu můžeme číst bez zámků atd. - čím dál tím důležitější vlastnost, řekl bych. Prostě - máme objekt a můžeme s ním bez problémů a bez ohledu na okolní svět provádět všechny povolené operace.

A pokud je povolenou operací "získání podstavu", tak to opět můžeme udělat a interně se to může zajistit sdílením struktury, tedy obecně velmi rychle (jak jste zmínil někdy předtím: řetězce z toho velmi těží, protože spousta operací nad nimi se může obejít bez kopie/klonování).

A toto pohledy nemohou splnit ze dvou důvodů:

1) někdo může přidat/ubrat/zpře­házet prvky v té bázové kolekci
2) mohou se změnit stavy objektů ve vlastní kolekci

A současně to plně nesplňují ani immutable kolekce v Guavě:

1) mohou se změnit stavy objektů ve vlastní kolekci

To není jen takové "no a co, to je nějakej okrajovej příklad", protože to vlastně ničí všechny předpoklady, které o kolekcích máme. Například ten SortedSet - když změním objekt v kolekci, přeskládají se objekty v ní uložené? Pokud ano, není to immutable. Pokud ne, není to sorted set.

Dtto pro HashSet/HashMap - když změním objekt tak, že bude mít stajný klíč jako objekt jiný, bude se z kolekce vyhazovat? Nebo dostanu kolekci se dvěma objekty s totožným klíčem?

OK takze immutable chapeme rovnako. V com spocitava ta magia implementovat tu vasu rozsirenu definiciu immutable tak ako chcete. Neviem ako sa ma chovat ten immutable sortedset, zadefinujte si to a implementujte si to tak.
Ak chcete maj objekty immutable tak si ich tak urobte. Nie je to iba zakladna vlastnost 'bezneho' objektu v Jave ale implementovat to ide uplne jednoducho.

Ah chapu, takze to "Java to davno umi" vlastne znamena "kdyz si to programator zaridi a DODRZI, tak tomu budeme rikat immutability". To ale umi i assembler nekdy od praveku :-)

"UMI" tak ze to postacuje. Ak akademici pozaduju ine exaktnejsie spravanie da sa to dorobit. V skutocnosti je ta existujuca implementacia absolutne postacujuca a robi presne to co je zadefinovane. Vratena strukura je immutable.

To cemu Pavle rikas "immutable" ale neni immutable. Pouzivas zde pohled javisty, ktery prevzal termin bez pochopeni toho, co skutecne znamena. Obzory muze rozsirit toto video https://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey/ (doporucuji, i kdyz budes dal psat v Jave, je to proste IMHO soucast obecneho IT vzdelani, i kdyz to muze znit akademicky. akademik vsak nejsem, jen prosta, ale dosti technicky znala namezni sila neboli human resource v zahranicni firme :/)

Nemusite sa obavat o moje teoreticke znalosti. Ja uplne presne chapem co je identita aj imutabilita aj co myslite 'svojim' immutable. Ibaze moj rozhlad je ale dalej nez je vasa akademicka definicia a dokaze pochopit aj kompromis ktory musite urobit aby sa to dalo aj prakticky vyuzivat.
Od vas je to trochu kratkozrake tvrdit ze MOJA immutabilita je ta prava a ta vasa je zla. Naviac ak do Erlangu bola akosi nutene namontovana pretoze prva implementacia bola postavena na Prologu a vlastne nepodporovala mutable struktury takze z nudze sme urobili top feature z funkcionalneho jazyka. Ak chcete definiciu immutable asi treba chapat a mat rozhlad, potom by ste sa dozvedeli ze "In some cases, an object is considered immutable even if some internally used attributes change" - si predstavte.
V konecnom dosledku potrebujete dat iba nastroje do ruk programatora a to ci potrebuje striktne immutable alebo iba 'read-only' alebo nejaky hybrid alebo ... nechat na neho. Ja tvrdim ze java ma absolutne postacujucu implementaciu immutable ktora je prakticky velmi dobre pouzitelna a pri pochopeni ako to funguje je to krasne pouzitelne aj pre rozne hybridne 'neakademicke' pristupy.
Vieme kde skoncili vsetky jazyky ktore sa pokusali o extremny purizmus.

Dunning-Kruger zdraví ;) Stejně jako toho pseudopythonistu odvedle :)

On diskutuje s lidmi, kteri Javu znaji. Ja diskutoval s ignoranty, kteri Python neznaji.

" Vieme kde skoncili vsetky jazyky ktore sa pokusali o extremny purizmus."

Java je extremne puristicka, jen v jinem smeru. A mate pravdu, byla to slepa cesta, je postupne nahrazovana pragmatictejsimi jazyky jako Kotlin.

Ja s Vami souhlasim, ze mutable datove struktury jsou nekdy treba, ale vetsinou jen na low level veci, na ktere se JVM jazyky stejne nepouzivaji.

Podle me Erlang moc neznate, immutable datove struktury dovoluji vetsinu featur, ktere tu byly zmineny. Napriklad bezpecne prepinani kontextu v procesech (coroutinach) bez explicitniho await.

Nevim, jestli chapete, jak napriklad immutable mapy vnitrne funguji. Pri pridani prvku se nevytvori skutecna kopie, ale sdili se prvky z puvodni mapy. Vykonostni penalizace je mensi, nez na prvni pohled vypada.

To je jen jiná úroveň kódu, Haskell a podobné jazyky mají různé backendy (do C, JS, LLVM IR apod.). Kdyby někdo hodně chtěl, tak ten vygenerovaný kód může upravit a měnit datové struktury. Tomu zabránit nejde. Je to pak v Haskellu skutečně immutable? (řečnická otázka)

Před pár lety, kdy jsem ještě pracoval na JVM, tak jsem měl docela dlouhou debatu na téma "immutable" v Javě. Nakonec jsme si myslím dobře vyjasnili (což je nejlepší vysvětlit na SortedSetu a SortedMapě nebo na prioritní frontě) terminologii a všimni si, že v Java docu prakticky nikde slovo "immutable" není (tedy kromě prázdných kolekcí, které jsou immutable jaksi z toho důvodu, že toto Java jako programovací jazyk ještě dokáže zaručit).

Raději se teď v Java docu používá slovo "unmodifiable", což má tu výhodu, že nemá až tak přesný význam :)

Btw ta debata nakonec byla v pohodě, protože poměrně hodně lidí, co se motalo okolo JVM, jsou ex-zaměstnanci Symbolicsu, takže Lispaři, takže rozumní lidé (i když z Oracle :-)

Zajímavé, Java je tedy zkřížený výplod lidí ze Symbolicsu a (stejně rozumných lidí z) Lighthousu?

Tam byla zajímavá sorta lidí, co přešli (tedy byli koupeni) ze Sunu. A ti ze Sunu zdá se předtím dělali v Symbolicsu (tedy ti, co jsem znal).

Právě, stejná situace jako s lidmi z Lighthousu, ale ti dělali původně v ObjC. Někde na webu je článek jednoho z nich o tom, jak ObjC ovlivnilo Javu (protože tam tito lidé přenesli mnoho myšlenek z ObjC). Java například původně neměla mít rozhraní. Taky některé třídy ve standardní knihovně jsou jen přepisem z ObjC.

Zajimave. Zrovna rozhrani jsou IMHO jednou z tech lepsich vlastnosti Javy :-)

Pravda. V ObjC taky původně nebyla, do Coxovy verze jazyka je přidal až Jobsův NeXT (akorát se tam jmenují protokoly, odtud protokoly ve Swiftu).

Tak iste, jedno slovo moze mat viac vyznamov, dolezite je aby pri komunikacii bolo kazdemu jasne co sa tym mysli. Ak ale trvate na immutable tak mozte pouzit Guava ImmutableList, tam sa vsade spomina immutable ;-).

Já immutable v Javě nepotřebuji, ono to totiž moc zajistit zatím nejde :-) Jen jsem Toma upozorňoval, že to nepochopení důsledků termínu immutable mezi vývojáři existuje.

Ale důvod, proč jsem to tehdy řešil s Oraclistama je ten, že jsem jakožto jeden z lidí okolo JVM (a tedy i dokumentace okolo JVM - tudíž i standardních knihoven) potřeboval zajistit kvalitu a jednoznačnost dokumentace. A nějaké házení termínem "immutable" například u takové struktury, jako je zmíněná SortedSet, SortedMap nebo prioritní fronta, by jen vedlo ke zmatení - a co hůř, k logickým chybám v aplikacích.

Ostatně zrovna v dokumentaci té Guavy to píšou alespoň v poznámce, když už ne v první větě, co se myslí tím "immutable" v Javě.

Za me, immutable struktury spojuji efektivitu struktur predavanych odkazem a bezpecnost struktur predavanych hodnotou (kopirovanych).

> Transformace dat za běhu je cool, na druhou stranu když se na to podívám inženýrsky, tak ve většině situací je přijatelnější službu prostě restartovat, než psát migrace (navíc) a řešit jejich QA.

Když máš 800klientů (klidně i víc, toto je z praxe), které dobíhají měsíce?

Tak je to v té menšině :-)

NASA takhle opravila souběh (race condition) v Deep Space 1, za běhu a téměř 100 milionů kilometrů od Země. Tam to ale byl Lisp.