Dědičnost dnes

[Honza]

Je tu někdo, kdo už ladil program za běhu v Javě (nebo v Pythonu), a ve Smalltalku, a chce tvrdit, že Java má to ladění lepší?

Smalltalk neznám. Ladění za běhu je něco takového http://lighttable.com/?

Ano, s tím rozdílem, že Smalltalk to umí už 40 let, zatímco Lightable se tváří jako novinka...

je to otázka IDE a ne jazyka. Hodí se to jen pro některé typy programů.

No jistě, ani Java od Sun/Oracle není jediná existující implementace Javy. Ale IDE jsou hromady. Jazyk a jeho implementaci tady ale rozlišuje málokdo. Zůstávám u existujících implementací a IDE a netvrdím, že by nemohla existovat Java, kde to bude fungovat podobně... a kde se to bude hodit na všechny programy, a ne jen na některé typy...

Nikdo to nepotřebuje JRebel je ideální pro megaprojekty, které se dřív v Javě dělaly. Dnes máš malé projekty, kde to nevyužiješ. Jak psal balki, překompilování a zavedení tříd umí i Spring.

Kdyby to v Javě šlo udělat snadno, tak by to podle mě používali všichni. A nemyslím tím překompilování a zavedení nějaké Java třídy. Myslím tím např. doplnění nové chybějící metody na server, který zastavený čeká na breakpointu, zatímco si vyhozenou výjímku serializuji pro analýzu na lokální disk, a po otestování nechám server pokračovat od místa kde přestal. Java i Python mně vysype maximálně stacktrace...

[Reklama]

[javaman ()]

Ne, fakt ne. To je tak na hraní při studiu. Kdyby to někdo chtěl, tak to dávno Java má. To je maličkost to přidat do JVM.

[gll]

Pre javu je na taketo finty JRebel https://zeroturnaround.com/software/jrebel/. Uz mi to sef nukal, ale ja by som v tom nevidel pridanu hodnotu, kedze robim veci na spring boot s embednutym jetty, skusit zmenu mi netrva dlho.   Ide to, no treba na to extra platene nastroje.

To, že se ostatní programovací jazyky snaží Smalltalku alespoň přiblížit, je mi známo. Pokud ten nástroj někdo ovládá prakticky, ať se přihlásí...

JRebel je placený SW a neumí nic co by nebylo v jiných jazycích triviální. isend-mode v Emacsu umí posílat změněný kód do debuggeru už dávno.

[gll]

automatické reloadování webové aplikace považuji za samozřejmost.

[gll]

Je tu někdo, kdo už ladil program za běhu v Javě (nebo v Pythonu), a ve Smalltalku, a chce tvrdit, že Java má to ladění lepší?

Smalltalk neznám. Ladění za běhu je něco takového http://lighttable.com/?

Ano, s tím rozdílem, že Smalltalk to umí už 40 let, zatímco Lightable se tváří jako novinka...

je to otázka IDE a ne jazyka. Hodí se to jen pro některé typy programů.

No jistě, ani Java od Sun/Oracle není jediná existující implementace Javy. Ale IDE jsou hromady. Jazyk a jeho implementaci tady ale rozlišuje málokdo. Zůstávám u existujících implementací a IDE a netvrdím, že by nemohla existovat Java, kde to bude fungovat podobně... a kde se to bude hodit na všechny programy, a ne jen na některé typy...

Nemyslel jsem zrovna Javu. Light Table to umí pro Clojure, Python a JavaScript. Nezkoušel jsem to, ale asi tam budou omezení.

[Reklama]

[Honza]

Nemyslel jsem zrovna Javu. Light Table to umí pro Clojure, Python a JavaScript. Nezkoušel jsem to, ale asi tam budou omezení.

Jojo, já dávám taky Javu jenom jako příklad. Nicméně taková IDE už dnes běží i online ve webovém prohlížeči, třeba i pro assembler. Nicméně jsme asi trochu odbočili od těch obdélníků, čtverců... a kruhů! Pardon, také za to můžu.

[balki]

Pre javu je na taketo finty JRebel https://zeroturnaround.com/software/jrebel/. Uz mi to sef nukal, ale ja by som v tom nevidel pridanu hodnotu, kedze robim veci na spring boot s embednutym jetty, skusit zmenu mi netrva dlho.   Ide to, no treba na to extra platene nastroje.

To, že se ostatní programovací jazyky snaží Smalltalku alespoň přiblížit, je mi známo. Pokud ten nástroj někdo ovládá prakticky, ať se přihlásí...

Nikdo to nepotřebuje JRebel je ideální pro megaprojekty, které se dřív v Javě dělaly. Dnes máš malé projekty, kde to nevyužiješ. Jak psal balki, překompilování a zavedení tříd umí i Spring.

Hlavne uz nie je zvyk robit obrovske monolity, uz nejake to desatrocie je popularna servisne orientovana architektura. 

[gll]

Pre javu je na taketo finty JRebel https://zeroturnaround.com/software/jrebel/. Uz mi to sef nukal, ale ja by som v tom nevidel pridanu hodnotu, kedze robim veci na spring boot s embednutym jetty, skusit zmenu mi netrva dlho.   Ide to, no treba na to extra platene nastroje.

To, že se ostatní programovací jazyky snaží Smalltalku alespoň přiblížit, je mi známo. Pokud ten nástroj někdo ovládá prakticky, ať se přihlásí...

Nikdo to nepotřebuje JRebel je ideální pro megaprojekty, které se dřív v Javě dělaly. Dnes máš malé projekty, kde to nevyužiješ. Jak psal balki, překompilování a zavedení tříd umí i Spring.

nejsou malé projekty pro lopaty?

[javaman ()]

To jo, ale jde o to, že ty stavíš větší projekty z malých. Takže lopaty dělají třeba JS a nějaké CSS a ty koordinuješ vše podstatné. Všechno musí sedět, ale určitě není moc potřeba to, z čeho je tady Honza na větvi.

[ava]

Jen tak ze zajimavosti, kdyz se uz tady resi ta dedicnost, tak se zeptam. Akka actori (Scala) mi pripadaji dost podobni jako ty objekty ve Smalltalku, je tomu tak? O Smalltalku jsem videl jen kratkou prednasku, takze opravdu moc netusim, ale napr. to posilani zprav a "netypovost" actoru pusobi dost podobne.

Osobne taky preferuji staticke veci typu Haskell nebo Scala (paradoxne jsem donedavna v praci delal primarne v JS , ted alespon s tim TypeScriptem jsem se trochu priblizil statickemu svetu).

Vetsina reflexe v Jave (i Scale) je dost draha na vykon a samozrejmne jak pise Javaman(), obtizne se to ladi, udrzuje, atd.

Ne, actoři ve scale jsou asynchronni, smalltalkovske posílání zpráv je úplně obyčejné synchronní volání metody jako třeba v pythonu, akorát se to jinak (a podle mě lépe) jmenuje, tedy alespoň od smalltalku 80, je možné, že někdy předtím byla ta sémantika jiná, přeci jen smalltalk byl ze začátku hlavně výzkumný jazyk, který se dost měnil....

Jinak jasný, ladění ve smalltalku je to nejlepší co jsem kdy zažil, a teďka u ostatních jazyků šíleně nadávám když musím pouštět debugger (už to, že ho vůbec musím pouštět

[Kiwi]

A ze tim prestanes splnovat kontrakt obdelniku je ti jedno?

Člověče, vy jste si o tom někde něco přečetl, ale totálně vám chybí cit pro praktickou aplikaci. Substituční princip není žádné posvátné tele. Naproti tomu, zákaz provádět mimo objekt něco, co je v kompetenci toho objektu, nebo nepředpokládat o vnitřních vlastnostech toho objektu něco, co není explicitně specifikováno, se tomu svatému teleti blíží mnohem více.
Dovedu si představit spoustu aplikací, kde by čtverec, jakožto potomek obdélníku (a jiné analogické aplikace), měl smysl, a jiné, kde by to naopak nešlo. Že má obdélník, jakožto abstraktní geometrický útvar, dvě nezávislé strany, je jedna věc, ale že by objekt obdélník, jakožto prostředek nějakého konkrétního objektového modelu, musel mít bezpodmínečně stejnou vlastnost, to už tedy zdaleka tak zřejmé není. Jestliže někde budu chtít mít obdélníky se zaručenou vlastností, že mají poměr stran 2:1, tak se mi taková definice hodí. Protože budu mít zaručen tento poměr a přitom na takový obdélník mohu aplikovat vše, co platí pro obecný obdélník. Pokud bude obecný obdélník disponovat metodou např. pro nastavení jedné strany na základě zadaného obsahu a druhé strany, tak nastane problém. Ale tohle záleží na konkrétním modelu. Nejde o tom říci nic obecně. Snad jen kromě toho, že kdybych něco takového potřeboval, mělo by to opravdu být součástí toho objektu, ať už obecného obdélníku, nebo nějakého jeho potomka (podle potřeby), ale rozhodně bych to neměl počítat někde mimo, jak tu naznačujete, protože vztahy mezi stranami, obsahem, úhlopříčkami a dalšími vlastnosti obdélníku jsou vnitřními záležitostmi toho objektu.
A ještě jednou zdůrazňuji rozdíl mezi geometrickým pojmem obdélník a obdélníkem jakožto prostředkem objektového modelu, kdyby vás opět napadlo jak zaseklá deska blábolit cosi o porušení kontraktu obdélníku (o němž nic nevíte, protože ho tu nikdo nespecifikoval).

[Ondra Satai Nekola]

A ze tim prestanes splnovat kontrakt obdelniku je ti jedno?

Člověče, vy jste si o tom někde něco přečetl, ale totálně vám chybí cit pro praktickou aplikaci. Substituční princip není žádné posvátné tele. Naproti tomu, zákaz provádět mimo objekt něco, co je v kompetenci toho objektu, nebo nepředpokládat o vnitřních vlastnostech toho objektu něco, co není explicitně specifikováno, se tomu svatému teleti blíží mnohem více.
Dovedu si představit spoustu aplikací, kde by čtverec, jakožto potomek obdélníku (a jiné analogické aplikace), měl smysl, a jiné, kde by to naopak nešlo. Že má obdélník, jakožto abstraktní geometrický útvar, dvě nezávislé strany, je jedna věc, ale že by objekt obdélník, jakožto prostředek nějakého konkrétního objektového modelu, musel mít bezpodmínečně stejnou vlastnost, to už tedy zdaleka tak zřejmé není. Jestliže někde budu chtít mít obdélníky se zaručenou vlastností, že mají poměr stran 2:1, tak se mi taková definice hodí. Protože budu mít zaručen tento poměr a přitom na takový obdélník mohu aplikovat vše, co platí pro obecný obdélník. Pokud bude obecný obdélník disponovat metodou např. pro nastavení jedné strany na základě zadaného obsahu a druhé strany, tak nastane problém. Ale tohle záleží na konkrétním modelu. Nejde o tom říci nic obecně. Snad jen kromě toho, že kdybych něco takového potřeboval, mělo by to opravdu být součástí toho objektu, ať už obecného obdélníku, nebo nějakého jeho potomka (podle potřeby), ale rozhodně bych to neměl počítat někde mimo, jak tu naznačujete, protože vztahy mezi stranami, obsahem, úhlopříčkami a dalšími vlastnosti obdélníku jsou vnitřními záležitostmi toho objektu.
A ještě jednou zdůrazňuji rozdíl mezi geometrickým pojmem obdélník a obdélníkem jakožto prostředkem objektového modelu, kdyby vás opět napadlo jak zaseklá deska blábolit cosi o porušení kontraktu obdélníku (o němž nic nevíte, protože ho tu nikdo nespecifikoval).

Vypravej mi jeste chvili o praktickych aplikacich...

Tohle je proste skolacka chyba. (Nemluve o tom, ze dalsi skolacka chyba - pokud neni velmi double plus dobry duvod - je designovat to jako mutable. Coz kdyz clovek neudela, tak nemusi resit ani cely tenhle problem.)

A kdybys cetl poradne, tak by sis vsimnul, ze jsem tu psal o tom, ze zalezi na okolnostech davno. A jedna z tech okolnosti je prave ta mutabilita. Jak ji mas, tak proste nedelas takovou hierarchii, jako muze udelat clovek v imutable svete. (Dalsi duvod by mohly byt trebas pametove naroky, ty uz tu take padly.)

[ava]

A ze tim prestanes splnovat kontrakt obdelniku je ti jedno?

Člověče, vy jste si o tom někde něco přečetl, ale totálně vám chybí cit pro praktickou aplikaci. Substituční princip není žádné posvátné tele. Naproti tomu, zákaz provádět mimo objekt něco, co je v kompetenci toho objektu, nebo nepředpokládat o vnitřních vlastnostech toho objektu něco, co není explicitně specifikováno, se tomu svatému teleti blíží mnohem více.
Dovedu si představit spoustu aplikací, kde by čtverec, jakožto potomek obdélníku (a jiné analogické aplikace), měl smysl, a jiné, kde by to naopak nešlo. Že má obdélník, jakožto abstraktní geometrický útvar, dvě nezávislé strany, je jedna věc, ale že by objekt obdélník, jakožto prostředek nějakého konkrétního objektového modelu, musel mít bezpodmínečně stejnou vlastnost, to už tedy zdaleka tak zřejmé není. Jestliže někde budu chtít mít obdélníky se zaručenou vlastností, že mají poměr stran 2:1, tak se mi taková definice hodí. Protože budu mít zaručen tento poměr a přitom na takový obdélník mohu aplikovat vše, co platí pro obecný obdélník. Pokud bude obecný obdélník disponovat metodou např. pro nastavení jedné strany na základě zadaného obsahu a druhé strany, tak nastane problém. Ale tohle záleží na konkrétním modelu. Nejde o tom říci nic obecně. Snad jen kromě toho, že kdybych něco takového potřeboval, mělo by to opravdu být součástí toho objektu, ať už obecného obdélníku, nebo nějakého jeho potomka (podle potřeby), ale rozhodně bych to neměl počítat někde mimo, jak tu naznačujete, protože vztahy mezi stranami, obsahem, úhlopříčkami a dalšími vlastnosti obdélníku jsou vnitřními záležitostmi toho objektu.
A ještě jednou zdůrazňuji rozdíl mezi geometrickým pojmem obdélník a obdélníkem jakožto prostředkem objektového modelu, kdyby vás opět napadlo jak zaseklá deska blábolit cosi o porušení kontraktu obdélníku (o němž nic nevíte, protože ho tu nikdo nespecifikoval).

Vypravej mi jeste chvili o praktickych aplikacich...

Tohle je proste skolacka chyba. (Nemluve o tom, ze dalsi skolacka chyba - pokud neni velmi double plus dobry duvod - je designovat to jako mutable. Coz kdyz clovek neudela, tak nemusi resit ani cely tenhle problem.)

A kdybys cetl poradne, tak by sis vsimnul, ze jsem tu psal o tom, ze zalezi na okolnostech davno. A jedna z tech okolnosti je prave ta mutabilita. Jak ji mas, tak proste nedelas takovou hierarchii, jako muze udelat clovek v imutable svete. (Dalsi duvod by mohly byt trebas pametove naroky, ty uz tu take padly.)

No, tady je problemem spíš než mutabilita to, že nastavovací metody mají obdélník v negativní a getovací metody v pozitivní pozici (v tomto smyslu: https://www.schoolofhaskell.com/user/commercial/content/covariance-contravariance ), do toho samého problému se dostanu když budu mít obdélník sice immutable, ale s copySide metodami:

o = obdelnik(1, 2)
o2 = o.copyWithNewSideA(4)
o2.area == ??

(člověk by čekal že 8, ale kiwi udělal speciální obdélník, který má obě strany jednou stejné a podruhé v poměru zlatého řezu a přijde mu to v pohodě a diví se že se divíme, vždyť obdélník je jen NÁZEV (model), vůbec z toho nevyplývá, že by se měl chovat jako obdélník, který známe (GEOMETRICKÝ KONSTRUKT), a jestli jsme to očekávali, tak jsme hovada co nerozeznají implikaci od ekvivalence a neměli by nás pouštět k počítači).

[JS]

Vypravej mi jeste chvili o praktickych aplikacich...

Nevim, mne prijde, ze ma celkem pravdu. Rad bych videl realnou OOP aplikaci, ktera vsude dodrzuje LSP, mne pripada, ze je to tak silne kriterium, ze ho v praxi dodrzet moc nejde.

Samozrejme, pokud mas vsechny "objekty" immutable, tak to asi mozne je, ale pak uz to neni OOP, ale FP. Idea za OOP je, ze objekty stav skryvaji, nikoli, ze ho vubec nemaji. (Coz je IMHO spatne, viz treba https://www.youtube.com/watch?v=QM1iUe6IofM.)

Ja uznavam OOP historicky jako urcity pokus, jak zvladat slozitost aplikaci, ale IMHO FP je lepsi pokus (jak ostatne naznacujes).

[ava]

Vypravej mi jeste chvili o praktickych aplikacich...

Nevim, mne prijde, ze ma celkem pravdu. Rad bych videl realnou OOP aplikaci, ktera vsude dodrzuje LSP, mne pripada, ze je to tak silne kriterium, ze ho v praxi dodrzet moc nejde.

Samozrejme, pokud mas vsechny "objekty" immutable, tak to asi mozne je, ale pak uz to neni OOP, ale FP. Idea za OOP je, ze objekty stav skryvaji, nikoli, ze ho vubec nemaji. (Coz je IMHO spatne, viz treba https://www.youtube.com/watch?v=QM1iUe6IofM.)

Ja uznavam OOP historicky jako urcity pokus, jak zvladat slozitost aplikaci, ale IMHO FP je lepsi pokus (jak ostatne naznacujes).

Tohle je zajímavá otázka (OOP bez mutability)?, líbí se mi tahle odpověď na SO : http://softwareengineering.stackexchange.com/a/232714 - historicky naprostá většina OOP jazyku má mutabilitu, ale OOP-ness a mutabilita jsou ortogonální koncepty, které se navzájem nijak nevynucují. Ostatně, smalltalk by se taky dal považovat za FP jazyk, má triviální syntax pro closures, jen ta jeho standardní knihovna má z FP kombinátorů jen základy (map, filter, fold, jestli se pamatuju správně tak #select:, #collect:, #inject:into: v smalltalk terminologii)