Opravdu může každý programovat v Javě?

[někdo]

Můj soukromý názor je, že ve všem tom co jste popsal jste mohl úspěšně programovat i bez znalosti OOP (objektově orientovaného programování). V Javě to už ale bez OOP nejde. Takže doporučuji nainvestovat čas do nastudování teoretických základů OOP a pak půjde i ta Java, včetně JEE.

C++ bez porozumění OOP? No jedině tak, že by se v něm psalo jako v C.

Přesně tak. Už jsem takových programů bohužel viděl víc než by se mi líbilo. Ono to tak v C++ bohužel jde, to že si s sebou táhne zpětnou kompatibilitu s C je sice z jedné strany jeho síla, ale z druhé strany jeho ještě větší slabost. Podle mě je to důvod, proč se v delším horizontu mnohem víc uchytila Java, která si prostě mohla dovolit se na zpětnou kompatibilitu s problematickými vlastnostmi C vykašlat. Ukázkový příklad je například explicitní memory management (nahrazený v Javě bezpečnými referencemi a GC). Můžete stokrát argumentovat bezpečnějšími variantami v C++, ale dokud tam bude použitelné i původní malloc/free a někde v obrovské aplikaci (třeba v nějaké pomocné knihovně třetí strany) to bude způsobovat těžko laditelné memory leaky (protože v C je na heapu ve srovnání s Javou neskutečný chaos) tak to prostě je problém. Nebo třeba segfaulty (když máme štěstí) nebo rovnou zmatené chování aplikace (když máme smůlu) související s tím úžasným vynálezem jménem pointerová aritmetika...

[Reklama]

[tento]

Přesně tak. Už jsem takových programů bohužel viděl víc než by se mi líbilo. Ono to tak v C++ bohužel jde, to že si s sebou táhne zpětnou kompatibilitu s C je sice z jedné strany jeho síla, ale z druhé strany jeho ještě větší slabost. Podle mě je to důvod, proč se v delším horizontu mnohem víc uchytila Java, která si prostě mohla dovolit se na zpětnou kompatibilitu s problematickými vlastnostmi C vykašlat. Ukázkový příklad je například explicitní memory management (nahrazený v Javě bezpečnými referencemi a GC). Můžete stokrát argumentovat bezpečnějšími variantami v C++, ale dokud tam bude použitelné i původní malloc/free a někde v obrovské aplikaci (třeba v nějaké pomocné knihovně třetí strany) to bude způsobovat těžko laditelné memory leaky (protože v C je na heapu ve srovnání s Javou neskutečný chaos) tak to prostě je problém. Nebo třeba segfaulty (když máme štěstí) nebo rovnou zmatené chování aplikace (když máme smůlu) související s tím úžasným vynálezem jménem pointerová aritmetika...

Víme, známe, místo pár byte leaků máš stovky MB nenažranosti Javy runtime, místo hlášky segfault ze zabugované knihovny se uživateli vypíše naprosto neznámá výjimka se stacktrace, takže je tam kde byl.

[Kit]

jake s tim mate kdo zkusenosti?
Nepripada vam take ze J2EE je jen prostredek pro zvyseni odbytu velmi draheho serveroveho HW?

Jednu dobu jsem taky podléhal tomuto bludu, ale bral jsem to jako daň za tu pohodlnost a bezpečnost. Ovšem postupně jsem se z toho vyléčil po setkání s pár programy (jednou python jindy perl atd.), o kterých jsem si říkal, že je to „jen pár nenáročných skriptíků“ a nakonec to požralo víc RAM než JEE server a přitom to bylo bez zátěže/uživatelů.

Paměťožroutský program se dá napsat i na 3 řádcích. Je vcelku jedno, v jakém jazyku.

[Aladár]

I v Javě se dá programovat neobjektově. Dá to sice mnohem víc práce než v C++, ale znám experty, kteří to bez problémů dokáží a, bohužel, pravidelně praktikují.

[podlesh]

I v Javě se dá programovat neobjektově. Dá to sice mnohem víc práce než v C++, ale znám experty, kteří to bez problémů dokáží a, bohužel, pravidelně praktikují.

Ano, to je bohužel naprosto běžné. Teprve v takovém prostředí člověk opravdu pozná, o čem je "softwarové inženýrství" (a ztratí spoustu iluzí).

[Reklama]

[YF]

ano.

[i]

Matlá se tu několiv věcí dohromady,

Nemělo to být o javě ani o OOP,

Mělo to být o těch přidávaných bumbrlíčcích, Stále se totiž nemohu zbavit dojmu že mi nic nepřínáší, že jejich údajný přínos jsem ve všech dřívjejších projektech získal několika řádky vlastního kódu, nebo jednodouchou a přehlednou cizí knihovnou kterou bylo možné nastudovat za pár desítek minut, případně vlastní přehlednou knihovou, kterou jsem si během několik projektů postupně vypiplal.

Pokud si někdo myslí že ti bumbrlíčci jsou právě to OOP tak bych ho rád ujistil že to je omyl. OOP je jen způsob organizování kódu tak aby byl přehledný, není nic co lze realizovat v C++ nebo v javě a nelze to třeba v C, no možná snad definice vlastních operátorů, i to je ale jen skryté volání funkce které tímto zápisem jen umožňuje skrýt další chybu.

Chtěl jsem hlavně znát zkušenost ostatních s:

* Jak začínali s těmito bumbrlíčky pokud předtím opravdu úspěšně programovali i bez nich? Názory těch kteří začínali rovnou s nimi mi moc k ničemu nejsou.

* Pokud někdo dříve programoval bez nich a dnes je používá tak mé zajímalo zda to bylo dobrovolné nebo z donucení? a pokud dobrovolné tak co je k tomu vede, snažím se nalézt nějaká skutečná pozitíva jiné než to že ti kteří je používají bývají z mě zatím záhadného důvodu lépe placeni.

Možná že jsem občas i doufal v nějaký ten flame protože při něm padají občas docela slušně propracované agrumenty pro i proti ze kterých se dá ledacos odnést :-)

V každém případě díky i tak za všechny reakce.

[alef0]

získal několika řádky vlastního kódu, nebo jednodouchou a přehlednou cizí knihovnou kterou bylo možné nastudovat za pár desítek minut, případně vlastní přehlednou knihovou, kterou jsem si během několik projektů postupně vypiplal.

Problem je v slove "vlastny". Not Invented Here Syndrom.

Ked vidim springacky projekt, tak automaticky vidim dobre spravenu dependency injection, pekne pouzity navrhovy vzor template, projekt ma zaklad mat dobru hlavu a patu. (Detto JEE 5.0 - 6.0; starsie verzie su mnohyhmi ludmi povazovane za hrozu na koleckach). Zaroven to dava priestor pre inych vyvojarov, lebo ked prijde do timu iny springak, tak relativne rychlo vie, co kde je, narozdiel od badania v in-house variante riesenia tohto problemu a patrania, ze zase nejaky vyvojar vymyslel vlastnu verziu Hibernate.

Prinos vidim v momente, ked mam analogicky projekt rovnakych rozmerov a mam to spravit bez toho.

keby mne sef povedal, ze mam robit v PHPcku, tak nebudem chodit dokola a vykrikovat, ake je to uchylne, nepouzitelne, nezmanazovatelne, ako mam nanho alergiu -- jednoducho sa pokusim zmenit job. Z vasej strany to vyzera na averziu zalozenu na emociach, nie na technologickych argumentoch -- a debata typu "presvedcte ma, ze to nemam nenavidiet" je prakticky nezmyselna.

[hmmm]

Problem je v slove "vlastny". Not Invented Here Syndrom.

Ked vidim springacky projekt, tak automaticky vidim dobre spravenu dependency injection, pekne pouzity navrhovy vzor template, projekt ma zaklad mat dobru hlavu a patu. (Detto JEE 5.0 - 6.0; starsie verzie su mnohyhmi ludmi povazovane za hrozu na koleckach). Zaroven to dava priestor pre inych vyvojarov, lebo ked prijde do timu iny springak, tak relativne rychlo vie, co kde je, narozdiel od badania v in-house variante riesenia tohto problemu a patrania, ze zase nejaky vyvojar vymyslel vlastnu verziu Hibernate.

Prinos vidim v momente, ked mam analogicky projekt rovnakych rozmerov a mam to spravit bez toho.

keby mne sef povedal, ze mam robit v PHPcku, tak nebudem chodit dokola a vykrikovat, ake je to uchylne, nepouzitelne, nezmanazovatelne, ako mam nanho alergiu -- jednoducho sa pokusim zmenit job. Z vasej strany to vyzera na averziu zalozenu na emociach, nie na technologickych argumentoch -- a debata typu "presvedcte ma, ze to nemam nenavidiet" je prakticky nezmyselna.

velmi trefne poznamky v kazdom odseku

[podlesh]

Matlá se tu několiv věcí dohromady,

Vždyť vůbec není jasné, o čem je vlastně řeč. Tedy kromě toho, že někdo dva roky dělá v zaměstnání věci aniž by tušil co je jejich smyslem - na to existují jen dvě odpovědi ("změnit zaměstnání" a "držet hubu a krok") a není o čem diskutovat.

Takže jediná možnost je po hyperbole sklouznout k osvědčeným tématům flame, jako je OOP, konkrétní jazyky a podobně. Na abclinuxu.cz by se samozřejmě řešila politika.

Pokud někdo dříve programoval bez nich a dnes je používá tak mé zajímalo zda to bylo dobrovolné nebo z donucení? a pokud dobrovolné tak co je k tomu vede, snažím se nalézt nějaká skutečná pozitíva jiné než to že ti kteří je používají bývají z mě zatím záhadného důvodu lépe placeni.

Bohužel, těžko odpovědět když se jaksi nedozvím konkrétně o čem je řeč.

Obecně platí že když potřebuji například HTTP server nebo distribuované transakce, tak si je nepíšu sám. Něco jsem i (svého času) zkoušel a moc dobře to nedopadlo (v nejlepším případě zůstalo neudržované torzo).

ORM je velmi kontroverzní. Určitě je velmi užitečné mít konverzi řádku tabulky/resultsetu na objekt a opačně (včetně správné konverze datových typů), to velmi ušetří práci. Cokoliv víc (a hlavně mapování relací) už je dost "ošajstlich" a je potřeba si velmi dobře rozmyslet co potřebuju a dávat pozor co vlastně dělám. Existuje ale třída aplikací, kde je použití ORM doporučitelné (nenáročné CRUD).

Spring beru především jako velkou zásobárnu užitečných utilitek, ze kterých si můžu pěkně vybrat co potřebuji a složit. Samozřejmě, musím vědět co potřebuji a pořádně si prozkoumat zdrojáky. Na složení pak můžu použít IoC container, ale nemusím. Největším přínosem při použití smotného kontejneru je AOP - obejde se tím hlavní problém Javy, kterým je absence metaprogramování. Samozřejmě, lepším řešením by bylo použít zcela jiný jazyk... no k tomu také dojde.

[iwtu]

Dva roky na naučení Javy je víc než dost, na vysokých školách je k tomu potřeba jeden, maximálně dva semestry. Mluvím z vlastní zkušenosti, sám jsem si takto kdysi po absolvování dvou semestrů Javy na FI našel letní stáž a vcelku jsem stíhal. Nicméně zmíněné dva roky na seznámení se s celou platformou Java EE jsou velmi málo. Přeci jenom mluvíme o nejrozsáhlejší programovací platformě, která je primárně určení k provozování aplikací typu Facebook. Nicméně využít ji pro malé projekty bez problémů lze, jak již zmínili kolegové přede mnou, je jen třeba znát ty správné nástroje a nebrat kanóny na vrabce.

Podla toho co viem, Facebook chat je naprogramovany v Erlangu. Neviem, kolko kolko je spravny cas na naucenie Javy, ale prikladam zaujimavy clanok Naucte se programovat za 10 let.

[andy]

Bez toho aby som cital celu diskusiu ti (po prebrani jedneho vacsieho projektu) odpoviem - nie. Kazdy nemoze programovat a je jedno ci to je java..

[Eda Beda]

OOP je jen způsob organizování kódu ...

Todle myslíš vážně?

[praktik]

Matlá se tu několiv věcí dohromady,

Nemělo to být o javě ani o OOP,

Mělo to být o těch přidávaných bumbrlíčcích

http://discuss.joelonsoftware.com/default.asp?joel.3.219431 :-)

[klw]

Důležitý je výsledek.

Existují úspěšné aplikace/projekty napsané jak v Javě, tak v C, C++, C#, Pythonu i v jiných jazycích. S použitím všemožných "bastlů" (rozuměj frameworků a knihoven) či bez nich. A rozhodnutí zvolit určitý jazyk/technologii se tedy v každém konkrétním (úspěšném!) případě ukázalo být správným, což zároveň dokazuje, že i použité technologické prostředky jsou pro daný účel dobré. Někdy by to s jinými prostředky možná šlo lépe, s jinými by to zase zcela určitě nešlo vůbec, a to je důležité.

Programovat v jakémkoliv jazyce (a tedy i v Javě) může každý, zakázáno to není; ale až správná kombinace lidí, znalostí, rozhodnutí a technologií (+ jejich správné použití) a zároveň definování cílů a měřítek úspěšnosti a posléze i jejich dosažení – to vše teprve dává dohromady nějaký smysl.

Každá technologie byla vynalezena s určitým cílem a očekáváním. Ty, které byly nesmyslné, dávno skončily či rychle skončí v propadlišti dějin. Ty dobré se naopak uchytily a používají se. Některé z nich budou časem překonané a nahradí je jiné. Otázka, jestli má smysl používat něco, co evidentně používají a dále hodlají používat tisíce jiných lidí, není na místě. Spíše je lepší zabývat se tím, proč to používají, zdali je k tomu něco nutí, nebo zda to používají dobrovolně a rádi. V případě pochybností buďto navrhnout, najít či zavést do praxe lepší řešení, anebo se na danou oblast vykašlat a vydat se úplně jiným směrem.