Názory k článku
Myslíme v jazyku Java

Obě knihy mám a četl jsem je, ale závěry jsem si tedy udělal jiné. Než začnu kritizovat, musím říct, že kniha je skutečně velmi dobře napsaná, jak je u Eckelových knih zvykem, a nenechte se ode mne odradit ;-)

U článku mne zarazil už perex a úvod, jednak si nemyslím, že Java je dobrý jazyk pro začátečníky (stejně jako opačný extrém, BASIC ;-) Hlavně ale programovaní v Javě na Linuxu == programování v Javě kdekoli (do značné míry), takže v Javě programujte, pokud chcete být pokud možno odstínění od Linuxu (nebo jiného OS), a ne pokud se chcete naučit programovat pro daný OS a využít jeho specifické vlastnosti.

Pokud jde o předpoklady ke čtení, tak sám autor píše ,,Struktura této knihy vyžaduje, abyste měli určité programátorské zkušenosti...``. Úvodní UML kapitola podle mne každého začátečníka vyděsí a zmate, protože se v ní rozebírá psaní programů o dva až tři řády větších, než bude teď psát on. Pak se to naštestí spraví a pokračuje normálním srozumitelným úvodem. Jinak je první kniha vlastně celá jen takový úvod, a kdo chce skutečně v Javě programovat, měl by asi přečíst obě.

Pokud jde o kvalitu překladu, tak ta je mizerná -- jak je bohužel pro změnu zvykem u českých překladů Eckelových knih ;-( Mám pocit, že je snad ještě horší než u Myslíme v C++. Text jako takový není tak špatný, ale jakmile doje na kód, je to děs. Občas je přeložený název proměnné/metody/třídy v textu a není v příkladu, občas naopak, občas není v komentářích v příkladu, občas je jenom tam, občas jedna z velmi podobných proměnných/metod/tříd přeložená je a jiná není, občas se dokonce v kódu vyskytuje přeložená i nepřeložená verze, takže by se samozřejmě nespustil.

V druhém dílu mne stále vyváděly z míry uvozovky -- obvykle jsou v kódu české a v textu pak ,,počítačové`` ;-) Ale ani to není pravidlo, občas jsou prostě náhodně -- nahoře, dole, otevírací, zavírací, české, anglické, počítačové, jak to zrovna vyšlo.

Někde jsou v překladu úplné pitomosti, jako že 1.39e-47 je 1,39 . e^-47, a některé věty musel překládat automat, protože česky nedávají smysl. Zkrátka, číst se to dá, ale kdyby se člověk držel pravidla, že při třetí chybě knihu odloží, neopustila by asi ani knihkupectví.

Na závěr jedna rýpavá poznámka -- pozorní čtenáři Eckelových knih si jistě všimli, že zatímco kniha je o jednom jazyce, tak v poznámkách pod čarou je nenápadně propagován jiný jazyk, uváděný jako příklad toho, jak by to šlo udělat ještě lépe. V Myslíme v C++ to byla Java a v Myslíme v jazyku Java to je hádejte co... Python. Myslím že tuším, o kterém jazyce bude příští Eckelova kniha ;-)

Kniha Thinking in Python uz je k dispozici:

http://www.mindview.net/Books/TIPython

Je to verze 0.1, takže se asi ještě nedá vypozorovat, který jazyk je podle Eckela ještě lepší než Python -- já tedy o žádném nevím ;-)

cccc, takovy velky chlapec a nezna perl <g>

V Perlu sice taky píšu, ale je to vhodný jazyk jen pro programy typu ,,napiš a zahoď``. I když si odmyslím, že každá verze Perlu je prakticky nový progrmovací jazyk, i když se vyvaruji konstrukcí, kde se cosi jaksi uhádne z kontextu, tak je to pořád nečitelný a neudržovatelný.

Tak tos videl perl jenom z rychliku :))

Viděl jsem Perl o hodně víc zblízka a zevnitř, než bych si přál ;-( Nevím, jestli jsem viděl Perl víc zblízka než vy, ale mně to tedy stačilo.

Spousta lidi pise programy se kterymi se nic jineho neda delat. V libovolnem jazyce. Svadet vlastni praseci naturu na jazyk je alibisticke.

JAVA IS THE MACHINE THAT GOES PING.
(Ti co videli The Monty Pythons Meaning of life pochopi.)

Este o nieco lepsi je Ruby - http://www.ruby-lang.org

Juju, preklad je kouzelnej, napriklad vykrik "servlets rule" prelozit jako "pravidla servletu" vyzaduje skutecne netrivialni usili :-)

T.

:) jo, tohodle jsem si taky vsimnul:)), cetl jsem nejdrive original a pak cesky preklad. Preklad je dobry, co neni dobre je prekladani zdrojovych kodu u prikladu - pokud nekdo neumi javu zas tak dobre, jednoduse mu 60% prikladu po `tvrdem` prepsani nebude fungovat (hloupe prelozene promenne na jednom miste, originaly zachovany na jinem).
Proto je nejlepsi stahnout si knizku z webu a priklady proste pouzit odtamtez. nehlede na to, ze je nebudete muset prepisovat rucne.

Jeste ohledne toho "zacinani programovat pro Linux": smysl to IMHO ma predevsim pro nekoho, kdo delal treba na Windows, zvykl si na jisty standard API a podobnych veci; chce zacit delat v Linuxu (pripadne pro Linux) a nevi kam slapnout. Pro toho je Java pomerne slusnou alternativou. Bohate knihovny, vyborna dokumentace, velice pekna IDE... Jiste lepsi nez se zacit s(m|n)azit treba v Kylixu.

T.

Ohledne "Zacinani programovani pro Linux" se mi libila kniha "Linux - zaciname programovat" (je postavena prevazne na "C"), original vydal WROX, v cestine Computer Press.

Varovani:
Pro kvalitu prekladu bohuzel plati nejmene to stejne co jiz vyse napsal Yeti u knihy od Bruce Eckela (a to se rika, ze Grada byva horsi nez Computer Press)...

Patrne se jedna jen o preklep, ale tvrzeni, ze v Jave nejsou konstruktory asi nikdo nemysli vazne, ze? Autor mel urcite na mysli destruktory ...

byl to skutecne preklep, za coz se omlouvam, opraveno. L.

Zajimalo by me, kde autor prisel na to, ze v C++ neexistuji vnitrni tridy? Patrne o C++ pouze cetl a nikdy si nic nevyzkousel :)

V jazyce C++ programuji profesionalne, pravda je ta, ze pravdepodobne VY neprogramujete v Jave. Mate asi na mysli *vnorene* tridy, ktere se od *vnitrich* trid z Javy zasadne lisi a to v tom, ze v pripade C++ s nimi muzete maximalne ukryvat implementaci, kdezto v Jave muzete (zejmena diky anonymnim vnitrnim tridam) vytvaret uzavery. Vnitrni trida v Jave take obsahuje odkaz na **nadrazeny** objekt a automaticky ziskavate prava i na soukrome prvky teto tridy, cehoz se hojne vyuziva pri tvorbe GUI v knihovne SWING. Tohleto se vam v C++ muze jenom zdat.

Mel jsem tedy skutecne na mysli vnitri (nikoliv vnorene) tridy. Hezky den.

Mate pravdu, Javu neznam. Proto jsem mylne povazoval vnorene tridy z C++ za vnitrni tridy Javy. Omlouvam se za jizlivou poznamku.

Omlouvam se ja, mel jsem zduraznit ten rozdil. Jedlo slovicko a uz je z toho neco jineho ;-)

Preji prijemny den

Nic proti Jave, ale je to este len "detsky" jazyk. Proste nepodporuje to niektore dolezite veci ako napr. sablony (este teraz ma trasie z kostrukcie vector.getPoint(i).toString (), uch), automaticke konverzie (priklad vyssie), definice, overloading, etc. Java je taky medzikrok, uz sa v duchu tesim na pravy OOP, ktory bude podporovat vymozenosti C++ a bude plne objektovy, taka lepsia verzia C# :).

Nemam pocit, ze by Java byla detsky jazyk. IMHO z ni byly zamerne osekany nektere veci, na kterych si vyvojari permamentne odiraji kolinka. Dost lidi si rado napise nejakou tu berlicku jako malou obet za to, ze se nemusi hodiny brodit krvi pri hledani nejake hloupe chyby.

T.

Šablony jsou krok zpět (nebo aspoň stranou). Pořádný jazyk umožňuje napsat třídy/metody, které není potřeba explicite parametrizovat. Přistupují prostě k objektům přes jejich interface, takže lze použít cokoli, co implementuje tento interface (ve smyslu Pythonu, kde implementace interface je prostě implementace interface, nikoli Javy, kde implementace interface pořád vytváří jakési vztahy dědičnosti). V jazyku založeném na C to samozřejmě nejde a šablony jsou z nouze ctnost.

Krok zpet to neni - spis dopredu ve statickem typovani. Pokud budu delat vsechny interface pres typ Object, tak efektivne o jakoukoliv kontrolu prijdu, vsecko si to krasne sedne i kdyz nekde zapomenu, ze jsem neco jinde predelal a ze do toho containeru davam jiny typ -- ale ouha, kdyz to pak spustim -- vyjimka na null. Prekladac nic neohlida, ani nemuze.

Je to pak prakticky to same, jako kdyz se v c-ku vsude cpe void *....

Ve statickém typování, tj. v C-like jazycích jistě. Problém je podle mne v tom, že při statickém typování implementace interface => vztah dědičnosti. V low-level jazyce to asi jinak nejde. Chtít plně objektový low-level jazyk je ale nejspíš blbost, takže vyjímky na NULL, přetypování na void* a coredumpy bych do toho nepletl ;-)

Java je takova jaka je (formulace a la ministr;-) prave proto, aby PRASARNY jako sablony, definice, automaticke konverze apod. nebyly potrebne. Pokud to nekomu neprijde jako dobry napad, tak at si pise v c++ a predplati si polstrovanou cimru.

V nadchazejici verzi J2SE 1.5 (Tiger) se chystaji takove veci, jako jsou parametricke kolekce (ktere by meli resit nektere problemy souvisejici s chybejicimi sablonami), atd. atp. Tiger mozna prekona velikosti skoku i prechod od 1.1 k 1.2 (tedy k tzv. Jave 2), takze bych na soudy o Jave jeste pockal. ;-) Tolik k temetu podobnemu sablonam (a souvisejici moznosti kontroly pri kompilaci zminene nekde vyse). K poznamkam o detskem jazyku asi nema smysl se vyjadrovat. :-)))

Skutecne objektovy jazyk je SmallTalk. Na ten bych se moc netesil...

tyhle knizky o jave jsem necetl, ale zato lituju dne, kdy jsem koupil za tezke penize Myslime v C++, je to naptosta katafstrova ten clovek je naprostej magor. Rozhodne bych ji tedy nedoporucoval nikomu, dale jsem kloukal Thinking
in Python, stejna blbost. Je sice pravda, ze je to lepsi nez takove ty 2 ceske zelene knizky o C/C++, ale jinak je to katastrofa.

Takové tvrzení by chtělo nějak zdůvodnit. Jinak si jednoduše všichni pomyslí, že seš fakt kokot.

Kniha Thinking in C++ je dobra. Problem je, ze je rozdelena do kapitol z logickeho hlediska, ne z hlediska jak se v C++ implementuje. To muze nekoho zmast a pripadat mu neprehledne. Napr. specialni kapitola o inicializaci a cisteni pameti. V jinych knihach se proste popise, jak vypada trida, co je to konstruktor a destruktor ale zde je to proste jinak.

Nemyslim si, ze je tato kniha (resp. v cestine knihy) vhodna pro uplne zacatecniky. Snad pro zacatecniky v Jave, kteri jsou profesionaly v jinem objektove orientovanem programovacim jazyku (nejlepe C++).

Bruce Eckel už má na svém webu třetí vydání své knihy. Vzhledem k tomu, že webová verze je autorem updatována na základě připomínek čtenářů, kteří mohou každý odstavec okomentovat, myslím, že se máme opět na co těšit