The future of java (diskuse)

[Luboš Doležel (Doli)]

Pěkné. Češtinářský dotaz: esej je rodu mužského?

[Martin]

Jako maturant (zítra píšu maturitní písemku :o)) musím říct, že esej může být jak rodu mužského, tak ženského. Obě možnosti jsou správně.

[Nikola Ciprich]

uff, diky, uz jsem si malem chtel zacit sypat popel na hlavu, pac 100% jisty si tim nejsem jak tak nad tim uvazuju ;).

no hodne stesti u maturity :o)

[Martin]

Není zač. Je fakt, že já bych spíš mluvil o eseji v ženském rodě, ten esej mi zní podivně. Ale správně je obojí...

Díky moc, budu to fakt potřebovat. Ještě před nedávnem bych neřekl, že z toho budu mít docela bobky. Ale čím víc jsem přemýšlel nad tím, jaká šílená témata nám může říďa vybrat, tím víc nejistej jsem si začal bejt. Kór když jsem si pak přečetl na netu příklady naprostých šíleností, který psali jinde, to už mi začalo bejt fakt ouzko...

[Nikola Ciprich]

no jo, hruzou z maturity si prosel kazdy kdo to zkusil. a vsichni pak rikaji jak to bylo lehke. zvlaste kdyz nastoupi na vysku. to se pak pomalu kazda zkouska zda horsi nez maturita

jinak s tim ten/ta esej mate asi pravdu, ta zni lepe. no taky by mne zajimaly pripadne pripominky k anglictine, nektere konstrukce se mi zdaji celkem neohrabane, a dost casto nektere fraze opakuju, ale vzhledem k tomu s jakym spozdenim jsem to psal, tak to byla celkem rychlovka - klasika, spousta casu, ale stejne se to pak pise na posledni chvili po nocich.

no a k obsahu pripominky nikdo nema? zadna kritika, opravy a tak?

[happy barney]

k obsahu eseje?
moj osobny nazor je, buducnost javy nesie skratku rip. ono, povodne motto sa zmenilo na "write once, run on 4 platforms" (Linux x86, Solaris x86, Solaris SPARC, windos x86).

navyse, JNI ta priviaze na tu jednu konkretnu platformu. Nevraviac o tom, ze vyuzivanie action-handlerov v konecnom dosledku vedie k mnozstvu anonymnych tried.

pre mna osobne je java prilis obmedzujuca. je to jazyk pre drevorubacov.

uznavam, navrhnut vykonny jazyk s cielmi povodne propagovanymi javou je tazke, v konecnom dosledku by sa clovek dostal k MVC, kde M a V su len deklarativne, interpretovane jazyky. Skutocna prenositelnost (v mojom pohlade) znamena, ze rozne casti systemu dokazes prenasat medzi roznymi dodavatelmi, ze mas jednoznacne a otvorene definovany kazdy interface. tuna imho je velky priestore pre open-source teoretikov )

[Nikola Ciprich]

k obsahu eseje? moj osobny nazor je, buducnost javy nesie skratku rip. ono, povodne motto sa zmenilo na "write once, run on 4 platforms" (Linux x86, Solaris x86, Solaris SPARC, windos x86).

Myslim ze tak hrozne to neni, pokud zrovna nejde o veci jako zminovany JOGL/JOAL, tak minimalne Free BSD a MacOSX jsou v pohode (a na MacOSX bezi ostatne i ty knihovny a zminovany Jake. Pokud jde o cistou javu, tak myslim ze prenositelnost je velice slusna.

navyse, JNI ta priviaze na tu jednu konkretnu platformu. Nevraviac o tom, ze vyuzivanie action-handlerov v konecnom dosledku vedie k mnozstvu anonymnych tried.

ale to nepopiram, take to ostatne zminuju, ale jak rikam, pokud napisete ciste javovou aplikaci, tak na tento problem nenarazite. a aplikaci vyuzivajicich JNI opravdu zas tak moc neni...

pre mna osobne je java prilis obmedzujuca. je to jazyk pre drevorubacov.

tak k tomu nevim co bych napsal, nevim jaka omezeni mate na mysli (i kdyz spousty jsem si samozrejme vedom ;)

Skutocna prenositelnost (v mojom pohlade) znamena, ze rozne casti systemu dokazes prenasat medzi roznymi dodavatelmi, ze mas jednoznacne a otvorene definovany kazdy interface.

Ale toto je prave podle mne neco co v jave funguje docela solidne. Neni to ani tak o jazyku, jako spise o podpore tech rozhrani dodavateli, coz samozrejme vzdycky trosku skripe, protoze to nikdo z nich doopravdy nechce. Ale s javou zde myslim fakt neni problem, a ostatne pri rozumnem pouziti reflexe toto muze fungovat i kdyz treba rozhrani nejsou uplne stejna, nebo nektere komponenty implementuji i neco navic. Krasna ukazka myslim je, ze je ve vyvoji API, ktere umozni pouzivat mnozstvi pluginu jak pod eclipse, tak pod netbeans. Az tohle bude fungovat, tak to bude opravdu fajn...

[happy barney]

Myslim ze tak hrozne to neni, pokud zrovna nejde o veci jako zminovany JOGL/JOAL, tak minimalne Free BSD a MacOSX jsou v pohode (a na MacOSX bezi ostatne i ty knihovny a zminovany Jake. Pokud jde o cistou javu, tak myslim ze prenositelnost je velice slusna.

ono aj ciste C alebo C++ je prenositelne velmi slusne . nemal som na mysli teoreticku schopnost jazyka, ale realnu migraciu programov.

tak k tomu nevim co bych napsal, nevim jaka omezeni mate na mysli (i kdyz spousty jsem si samozrejme vedom ;)

ok, veci ktore mi vadili (javu od verzie 1.5 uz nesledujem, mozno sa nieco pomenilo alebo chysta zmenit)

• chybajuci overloading operatorov
• zakladne typy nie su objekty, objektove reprezentacie sa nedaju zmysluplne pouzit v algoritmoch
• chybajuca viacnasobna dedicnost. kazdy projekt, na ktorom som pracoval, trpel problemom cut&paste prave kvoli tomuto. samozrejme, da sa to vyriesit odsunutim implementacie metody do inej triedy, ale ta rezia ...)
• absencia premenliveho poctu argumentov - napriklad inicializializacia hashtable
• striktna previazanost jeden subor, jedna public trieda a opacne - v konecnom dosledku to viedlo k zdrojakom velkosti radovo desiatky kB. tu by som navrhoval moznost implementovat jednotlive metody v separatnom subore

aby som nebol len kriticky, myslim, ze samotne design patterny vznikli prave na obchadzanie a riesenie roznych obmedzeni javy

Ale toto je prave podle mne neco co v jave funguje docela solidne. Neni to ani tak o jazyku, jako spise o podpore tech rozhrani dodavateli, coz samozrejme vzdycky trosku skripe, protoze to nikdo z nich doopravdy nechce. Ale s javou zde myslim fakt neni problem, a ostatne pri rozumnem pouziti reflexe toto muze fungovat i kdyz treba rozhrani nejsou uplne stejna, nebo nektere komponenty implementuji i neco navic. Krasna ukazka myslim je, ze je ve vyvoji API, ktere umozni pouzivat mnozstvi pluginu jak pod eclipse, tak pod netbeans. Az tohle bude fungovat, tak to bude opravdu fajn...

hej? vyskusajte si pouzivat rozne J* interface z inych programovacich jazykov
to je vsak debata viac na mailing-list ako na diskusiu pod blogom (a uz by som navyse aj mohol dnes zacat pracovat)

[Nikola Ciprich]

ono aj ciste C alebo C++ je prenositelne velmi slusne . nemal som na mysli teoreticku schopnost jazyka, ale realnu migraciu programov.

jakou migraci mate na mysli? popularni javove programy se vetsinou pouzivaji na vsem moznem (windows, linux, macky), takze ani v realu to nebude tak spatne ;). i kdyz uznavam, ze existence separatnich balicku pro ruzne platformy trochu vypovida i o tom, ze to neni uplne bez problemu. i kdyz casto jde jen o ruzne instalatory atd.

ok, veci ktore mi vadili (javu od verzie 1.5 uz nesledujem, mozno sa nieco pomenilo alebo chysta zmenit)

no nektere z tech veci uz jsou opravdu resene prave v 1.5, ale to Vas uz asi nenalaka co?

chybajuci overloading operatorov

to je jedna z veci ktera podporovana neni, a myslim ze nejspis ani nebude. osobne prinos pretezovani operatoru povazuju za minimalne diskutabilni, i kdyz nekomu to asi muze chybet...

zakladne typy nie su objekty, objektove reprezentacie sa nedaju zmysluplne pouzit v algoritmoch

to je prave jedna z veci ktere v 1.5 doznaly vcelku podstatnych zmen...

chybajuca viacnasobna dedicnost. kazdy projekt, na ktorom som pracoval, trpel problemom cut&paste prave kvoli tomuto. samozrejme, da sa to vyriesit odsunutim implementacie metody do inej triedy, ale ta rezia ...)

k vicenasobne dedicnosti asi tolik co k pretezovani operatoru. v jave k tomu proste slouzi implementace rozhrani a oddelene tridy, jak jste napsal. ze by si nekdo stezoval na prilis velkou rezii vidim poprve, i kdyz nejaka jiste bude...

absencia premenliveho poctu argumentov - napriklad inicializializacia hashtable

promenne pocty argumentu uz jsou take podporovane, i kdyz jestli primo podpora v hashtables ani nevim...

striktna previazanost jeden subor, jedna public trieda a opacne - v konecnom dosledku to viedlo k zdrojakom velkosti radovo desiatky kB. tu by som navrhoval moznost implementovat jednotlive metody v separatnom subore

nevim, ja se vzdycky snazim skladat kod spise z mensich fragmentu, i kdyz vzdycky to asi taky neni mozne. ale ani obrovske tridy mi zase problemy nedelaji, ale dokazu si predstavit ze pro lidi co jsou zvykli na editory jako vim to nemusi byt pohodlne (no flame prosim, poukazuju jen na to, ze existence ruznych outline pohledu a podobne v nastrojich jako eclipse nebo netbeans tohle proste hrozne usnadnuje)

hej? vyskusajte si pouzivat rozne J* interface z inych programovacich jazykov

tak to moc nechapu, o prenositelnosti na jine jazyky jsem vubec nemluvil. i kdyz uznavam ze tohle je jedna z velkych vyhod .NET oproti jave. v jave sice existuje spousta projektu na podporu vseho mozneho, ale AFAIK pouze python se nejak vice pouziva. ale v 1.6 uz by to melo byt lepsi, zahledl jsem zminky o oficialni podpore pythonu, perlu a javascriptu (proc javascript osobne moc nechapu). nicmene v tomhle je .NET asi mnohem dal, protoze uz to bylo soucasti navrhu. jestli je to dobre nebo spatne si ale uplne 100% jisty taky nejsem.

no nic, jdu taky neco delat

[MarrLiss]

adJavaScript: 1.6 by mela obsahovat cely engine pro scriptovani v aplikacich pomoci JavaScriptu (mel by byt vyuzity engine z gecka). Tak proc toho rovnou nevyuzit.

[Michal Vyskočil]

ale dokazu si predstavit ze pro lidi co jsou zvykli na editory jako vim to nemusi byt pohodlne (no flame prosim, poukazuju jen na to, ze existence ruznych outline pohledu a podobne v nastrojich jako eclipse nebo netbeans tohle proste hrozne usnadnuje)

Příště prosím nezmiňovat vim, ale vybrat si omezenější editor . Aneb Vim outliner. Mě tedy stačí vestavěný folding (Příklad nastavení pro Javu/C/C++ ).

[happy barney]

vim/ne-vim, nejedna sa o obmedzenost editora. nikto nevravel o foldingu, a pod, to je predsa zakladna vlastnost development nastroja. osobne som mal na mysli manageovatelnost, naivne si myslim, ze sa pracuje tymovo (riesenie cut&paste sa da pouzit tiez ...)
imho, vim je prakticka ukazka, ako z vi vytvorit emacs

[Martin]

Tak, pisemka (snad uspesne) dopsana :o)

Kritizovat, opravovat bohužel nemůžu, protože Javu (zatím) neumím. Před dvěma měsíci jsem se naučil Python a asi by myslím bylo lepší ovládnout jeden jazyk dobře, a pak se pustit do dalších. Minulý týden jsem se už rozhlížel na internetu po nějaké dobré online učebnici Javy (třeba ve stylu knihy www.byteofpython.info, ze které jsem se toho o Pythonu naučil nejvíc - neznáte něco v podobném stylu?), ale pak jsem si to z výše uvedeného důvodu rozmyslel. Nevím, jestli jsem udělal dobře nebo špatně a co je lepší. Před Pythonem jsem se učil C, ale Java mi přijde taky celkem sympatická.

[bodo]

Thinking in Java, 3rd Edition, začina sa od objektov a ich principov + je k tomu aj zdrojový kód s buildami pre anta, čo viac si môže človek želať :)).

[Martin]

Díky za odkaz. Na tuhle učebnici jsem tehdy narazil, ale trošku jsem znejistěl kvůli datu vydání. Tři a půl roku mi přišlo jako docela dost stará kniha. Ale je možný, že to nehraje žádnou roli, nevím jak to kolem Javy chodí.

Taky mě napadlo, že bych si později mohl pořídit Učebnici jazyka Java od Pavla Herouta. Mám doma jeho učebnici Céčka a myslím, že jsem ho s ní zvládnul poměrně dobře (je fakt, že od tý doby, co znám Python už jsem v Céčku prakticky nic nedělal, takže jsem toho asi už hodně zapomněl). Je jeho kniha o Javě napsána stejně kvalitně? Před týdnem jsem byl v Praze a říkal jsem si, že si ji asi pořídím, ale nakonec jsem koupil dárek své milé a na tu učebnici mi nezbyly peníze. Ne, že by mi to vadilo, samozřejmě ;o)

[Nikola Ciprich]

no ja jsem od pana Herouta jeste spatnou knihu necetl, ucebnice C, ucebnice Javy, IPV6, vsechno IMHO kvalitni a ctive knihy...

[Martin]

Díky, určite si ji dříve nebo později pořídím. Ta kniha o Céčku byla opravdu perfektní, učení s ní šlo opravdu samo.

Jsem hodně zvědav, jaká ta Java opravdu je. Céčko se mi opravdu líbí, Python jakbysmet, navíc v něm můžu dělat věci, který bych buď v Céčku nezvládnul nebo by to asi nebyla taková hračka (to je důvod, proč dělam v poslední době jenom v něm). Jsem zvědavej, jestli mi Java sedne nebo ne :o)

[bodo]

Učebnica jazyka Java od Herouta je vcelku príjemna záležitosť ale má jednu nevýhodu, viac sa tam rozoberá syntax ako objekty, takže ako prvú knihu by som zvolil TIJ3. A na dátume až tak nezáleží pokial sa jedná o naučenie základov jazyka. A z vlastnej skúsenosti si myslím že je doslova nevyhnutné získat nejaký obecný základ objektového programovania, napríklad tu :)) java.vse.cz

[Martin]

O objektech už mám něco málo načteno, akorát že pro Python. Ale myslím, že princip by měl být pořád stejnej. 100% objektově jsem si zatím nedávno naprogramoval jenom hada v Pythonu (ale zato myslím, že celkem dobrýho ;o)) a myslím si, že to už trochu chápu. Alespoň minimálne ten princip teda. Nic moc složitýho bych nejspíš nezvládnul.

Tak ještě jednou dík za rady a taky za ten super poslední odkaz, pořádně si to pročtu.

[zde]

Thinking in Java je vynikající. Četl jsem 1st edition a mohu jen doporučit. Akorát Bruce Eckell napsal Thinking in Python (které jsem nečetl), a docela v něm i jinde Javu kritizoval.. Jo a taky jsem četl že Bruce kdesi napsal, že Python u něj nahradil Javu jako primární nástroj pro nové projekty

[Martin Baleja]

Interesting, but a little long for me to read it in the morning But I'm sure I'll get back later and read it all. Thanx.

[Nikola Ciprich]

Terve, kiitos!

[zde]

Je až neuvěřitelné, jak tuhý má Java život. Byla určena pro průmyslovou automatizaci, ovšem procesory co interpretovaly Java bytecode v mikrokódu byly ve srovnání s čímkoliv rozumným (RISCy) příliš pomalé a žravé, tak to po zásluze chcíplo.

SUN začal tedy Javu razit jako formát pro distribuci untrusted kódu pro applety webových browserů. Udělali ale spoustu omylů v návrhu jazyka, a programátory frustrovali chybnými knihovnamy s nestabilním API, proto je nakonec (opět po zásluze) na hlavu porazila Macromedia s Flashem. Když naleznu na webu javovský applet, je to naprostá výjimka.

SUN se ale nevzdává, a chce z Javy udělat aplikační jazyk. Po mnoha letech vývoje je konečně trochu funkční JIT, takže to opravdu běhá docela rychle. Paměťová režie a startup time jsou ale stále katastrofické, takže na desktop Java nepatří. Co zbývá? Aplikační servery mají hafo paměti, takže nabubřelost Java runtime se v tom schová, a pro dlouhodobě běžící tasky zdlouhavý startup není kritický. Java tedy nakonec domigrovala nikoliv "tam kam patří" ale "tam kde nejméně vadí" :)

Jo mám pocit že SUN se jednu chvíli snažili z Javy udělat i něco jako skriptovací a prototypovací nástroj, ale taky to selhalo- statické typování je pro skriptovací nástroje opravdu nevhodné.

Takže budoucnost vidím jednoznačně: Java opět chcípne (už popáté?). .NET nabízí krom lepšího návrhu a lepší podpory pro desktop širší výběr front-endů, takže psaní aplikací je pohodlnější. Až počet vývojářů přeroste kritickou mez, postupně vyštípou Javu i z aplikačních serverů.

PS: moc jsem nepochopil proč autor chce lepší poll() když jej Java skoro nepoužívá, protože umí docela dobrý threading. PPS: abych nenadával na něco co neznám tak jsem si nedávno zkoušel Eclipe + C Toolkit. Na 512MB RAM a 2G+ CPU to bylo skoro použitelné. Ovládání intuitivní, odezvy rozumné. Ale proč to proboha má 150MB ???

[happy barney]

hmm, ak si mam vybrat medzi zlym navrhom a este horsim navrhom, tak pri porovnani java vs .net mi o kusok lepsie vychadza prave ta java

thready? thready sux, 99,999% programatorov nevie programovat multithreadove aplikacie, takze je lepsie (a castokrat s lepsim vykonom) pouzivat oddelene aplikacie.
priklad: mam server s 1000 paralelnymi konexiami. co pouzijete? 1 thread a 1 poll s neblokujucimi socketmi alebo 1000 threadov a blokujucimi socketmi ?
neblokujuce je tazsie, tam si treba pamatat stav, treba viac osetrovaciek, narocnejsi parser protokolu ...

a tak

[zde]

1000 threadu neni na Linuxu s O(1) schedulerem zadny problem, proto kazda konexe pobezi v jednom threadu. A synchronizace je v Jave docela trivialni. Zadny stavovy automat, zadne slozite parsovani, sama pozitiva a same jistoty :)

[Nikola Ciprich]

Je až neuvěřitelné, jak tuhý má Java život. Byla určena pro průmyslovou automatizaci, ovšem procesory co interpretovaly Java bytecode v mikrokódu byly ve srovnání s čímkoliv rozumným (RISCy) příliš pomalé a žravé, tak to po zásluze chcíplo.

no jak je to s podporou prumyslovych zarizeni moc nevim, ale na mobilech se jave myslim dari v posledni dobe celkem dobre . Ja mam zkusenosti teda jenom s J2ME a se Symbianem, a musim rict ze programovani v J2ME je tezka pohoda a vykon nijak hrozny neni.

ohledne appletu asi neni moc co dodat, moc se to nerozsirilo, ohledne bugovitosti nevim, ale mozna nenazranosti java trochu taky predbehla dobu :)

ze se jave dari v serverove oblasti jen diky tomu ze tam nejmene vadije podle mne trochu nefer tvrzeni. myslim ze java je na psani takto velkych veci jednoduse docela vhodna, a to je taky duvod proc se na takove veci pouziva. co momentalne existuje v prostredi .NETu bohuzel ani nevim, i kdyz predpokladam ze minimalne MS urcite neco ma. co se tyce javy, tak je toho na vyber (i mezi free produkty!) urcite neskonale vice.

jestli chce SUN delat z javy prototypovaci jazyk netusim, ale musim rict ze ja ji takto obcas pouzivam (treba ted jsem si celkem rychle udelal prototyp mobilni aplikace, kterou jsem nasledne pouze prepsal do C++ na zminovany symbian) a nestezuju si. je to vzdycky spis o tom co komu vyhovuje a v cem je zvykly (rychle) psat...

ohledne pollu, ja jsem ho nijak nevyzdvihoval, ani neprosazoval, byla to jen ukazka k tematu, o kterem byla esej napsana. nic vice, nic mene. ale ze by nemel zadne vyuziti, to bych taky netvrdil...

jinak ze je .NET slusna platforma jsem tam ostatne psal take, ale ze by vsichni na nej s radosti presli, tomu teda moc neverim. i kdyz MS pro to dela co muze. na to uz ma java prilis velkou programatorskou zakladnu. jak v komercni sfere, tak i ve svete free sw.

k eclipse, jakych 150MB mate na mysli? jako ze to tolik zabira? no a? je to platforma, pomoci (relativne) malych pluginu se z toho da udelat celkem dost univerzalni balik (ja osobne v eclipse mam podporu pro C/C++, javu, webove sluzby a python). v dnesni dobe mi 150MB prijde opravdu nic. zvlaste kdyz se takove visual studio dodava na nekolika DVD... (tim ovsem vubec nechci porovnavat eclipse a visual studio, vim ze je k nemu pribaleno mnozstvi dokumentace, a mnoho lidi na nej neda dopustit. i kdyz ja k nim teda po svych zkusenostech s nim rozhodne nepatrim...)

[zde]

> ale na mobilech se jave myslim dari v posledni dobe celkem dobre

Jo, souhlas. Na mobily jsem uplne zapomel, tam se Java chytla docela dost. Mobily jsou ale hardwarove dosti specificka zarizeni. Maji docela vykonna CPU, ale relativne malo pameti. Java ma docela kompaktni bytecode, takze se na ne hodi. A taky nevim jestli se Java Micro edition (nebo jak se to orezane API jmenuje) da jeste nazyvat Java :)

> ohledne bugovitosti nevim

No ja kdysi (pred 10+ lety) napsal pro jeden web nejake trivialni applety nad awt.*, a na kazdem browseru a kazde verzi Javy to behalo jinak nebo taky vubec ne.

> myslim ze java je na psani takto velkych veci jednoduse docela vhodna

stejne vhodny by byl libovolny jiny jazyk, ktery umi spravne oddelovat jmenne prostory svych komponent, a poskytuje pametovou bezpecnost. A dulezite pravidlo: Velke projekty = stare projekty. Dnes se Java pouziva na serverech hodne i ze setrvacnosti; kdyby se podobne veci delaly znova, dost mozna uz nebudou v Jave ale treba v Pythonu. :)

> co se tyce javy, tak je toho na vyber (i mezi free produkty!) urcite neskonale vice.

Jo, souhlasim, objemen nastroju Java jasne vede. Ale mystlim ze na desktopu je .NET lepsi, proto tam poroste vyvojarska a uzivatelska baze, a prehoupne se to i do serveru.

> je to vzdycky spis o tom co komu vyhovuje a v cem je zvykly (rychle) psat...

Presne. A taky (zejmena) externimi rozhranimi, a zda je na ne ve zvolenem nastroji vhodny binding. Ale postupem casu jsem prisel na to ze casto je lepsi tohle omezeni ignorovat, a binding si pak dopsat dodatecne; kdyz mas pevne API nebo protokol na obou stranach, jde napsat adapter velmi rychle a ciste.

> na to uz ma java prilis velkou programatorskou zakladnu. jak v komercni sfere, tak i ve svete free sw.

To neni vubec jiste. Bylo by zajimave videt jeji vyvoj. Drive se lidi Javu ucili, protoze (opravnene) chteli pryc z C++ a Java se jim libila. Dnes se Javu uci uplne z jinych duvodu- kvuli inzeratum firem, ktere shaneji cerstve maso do svych J2EE kafemlejnku.

> v dnesni dobe mi 150MB prijde opravdu nic.

Nejde o absolutni cislo, 150MB je opravdu nic. Jde o pomer funkcnosti k velikosti, ktery povazuji za jiste (uznavam ze velmi hrube) meritko kvality, a ktery je u Eclipe velmi nevyhodny. Ono to toziz neumi o mnoho vice nez treba 10x mensi Code::blocks. Jo a Visual Studio se mi taky docela libi :)

[Vinicius]

Nikdo tu nezminil vhodnost Javy pro vyuku programovani. Sam jsem ji ocenil, protoze mi pomohla soustredit se na jadro problemu/algoritmu. psal jsem treba svuj prvni prekladac a ocenil jsem hodne hotovych trid (mapy,kolekce,spojove seznamy). Zadne honeni segfaultu...

A velkym trumfem je podle me SWING. To je GUI toolkit, se kterym se da tvorit pekne GUI doslova na kolene (EDIT + JAVAC, z doby kdy jsem mel procesor K5), proste jen pridavate komponenty do kontejneru... (proti QT (QT designer je odporny),GTK,FLTK jsem si pripadal jako v pohadce) Proste toolkit meho srdce.

[Nikola Ciprich]

no ke swingu zas tak vrely vztah nemam, ale co se tyce vhodnosti javy k vyuce, tak to souhlas. na VSB se java pouziva ted uz od sameho zacatku studia IT a myslim ze to je dobra volba...

[zde]

Coze? Jste sadisti? Jak to chcete ucit prvaky, kdyz to nema ani interaktivni shell!

[Nikola Ciprich]

myslim ze to opravdu nikdo moc nepostrada. ja osobne treba v pythonu pouzivam shell tak leda kdyz potrebuju kalkulacku

[DjAARA]

bean shell, bean shell ...