Vlákno názorů k článku Java je tu 30 let: všestranný jazyk formoval moderní informatiku od Dushino - <Nadsázka> Pozitiva - Naučil jsem se uklízečku nazývat lépe znějícím...

<Nadsázka>
Pozitiva
- Naučil jsem se uklízečku nazývat lépe znějícím Garbage collector.
- Slevnily RAM.

Negativa
- Zrušení vícenásobné dědičnosti a nahrazení (pro mě pouze na pohled koncepčnějšími, ale ve skutečnosti jen opruzujícími) interface.
- Vývojáři si zvykli na použití knihoven, které řeší "všechno", ale já dodávám, že jen na 95%.
- Uživatelé si zvykli, že program je pomalý, zabere (se svými knihovnami) spoustu místa na disku, vyžere "všechnu" RAM a chování (časové prodlevy) se mezi jednotlivými spuštěními téhož programu mohou lišit. Z pohledu pokročilého uživatele tímto zmizely pozorovací instinkty, kdy když nějaké čtení z disku nebo zápis drvá déle než jindy, znamená to, že HDD se s námi loučí.
- Opět se ukázalo, že když nebyl naplněn původní záměr a projekt totálně selhal (záměr použití Java byl pro jednoduchá domácí zařízení typu pračka nebo mixér), může silná firma projekt podržet natolik, aby se z něj stal celosvětově využívaný ekosystém. Viz VHS.
</Nadsázka>

No flame, please. Nebudu argumentovat k dementi výše napsaného, protože to vyjadřuje mé osobní pocity před X lety. Poté, co jsem kdysi napsal svůl první a poslední komerční program (prý se s vyřešením jedné chyby používá dodnes), nechci mít s Java nic společného. Naštěstí nemusím.

*Komerční program v Java.

Ohledně násobné dědičnosti by se ale dalo hezky diskutovat (nebo hádat) :-)

Jojo. :-D Právě kvůli tomuto bodu jsem napsal No flame. :-D

"Zrušení vícenásobné dědičnosti a nahrazení (pro mě pouze na pohled koncepčnějšími, ale ve skutečnosti jen opruzujícími) interface" - to je možná na místě otázka, jestli vůbec koncept dědičnosti je dobrý nápad :-)

Tak mě v té době (cca 2000) v C++ vícenásobná dědičnost umožnila (pro mě elegantně) vyřešit timeouty v komunikaci, tehdy po sériové lince. Jedna třída Timer, druhá třída obecného zařízení a třetí třída timeoutovaného zařízení podědila obě. Buď přišla událost od časovače nebo od zařízení a dokázal jsem ve stavovém automatu (další třída jako potomek timeoutovaného zařízení) řešila komunikacní protokol a fungovalo to. Tím neříkám, že je to nejlepší řešení a třeba v Java to nejde (jde pomocí interface).
Tak jaký koncept, když ne dědičnost? Nejsem teoretik, ale tahle myšlena mě zaujala.

Mozno https://gigamonkeys.com/book/object-reorientation-generic-functions

Jiný koncept, než třídní hierarchie: skládání tříd, traity (viz Rust) a dependency injection (přímo Java). Nebo jít funkcionální cestou.

https://codeburst.io/inheritance-is-evil-stop-using-it-6c4f1caf5117

Díky. Nějaký smysl to dává, i když už jsem asi příliš nepružný, abych považoval argumenty uvedené v článku za problém koncepce a ne konkrétního návrhu. Ale možná, že právě o to jde. Tak dík ještě jednou.

"Vícenásobná dědičnost" v Java nyní částečně je protože interface může mít default metody.

Java fakt není pomalá, spíš naopak, maximálně její spuštění nebo použité frameworky, ale i to se nyní dá řešit pomocí AOT nebo CDS.

V době, o které mluví ovšem pomalá byla. A to dost brutálně. O paměťové náročnosti ani nemluvě. V tomhle ohledu má pravdu.