Mivel tudnek gyorsabban es jobban fizetett helyre kerulni?

"Nekem a legnagyobb gondom vele, hogy lomha, RAM pazarló, CPU terhelő szoftvert lehet benne alkotni. "

Az én véleményem szerint nem az a baj, hogy lomha. Ugyanis a Java szerintem a leggyorsabb nyelvek közé tartozik.

A gond az hogy fejleszteni benne lomha. De nagyon. És emiatt drága is pénzügyileg.

Lásd a fenti érveim.

Annyit tennék hozzá, hogy a Java fejlesztők 90+%-a nem tud objektum-orientáltan programozni. Ha mindenki tudna, akkor a Java kb. ugyanannyira jó nyelv lenne, mint mondjuk a Python, és nem csak mesterséges körülmények között lehetne szép kódot mutatni. De mivel, az emberek általában nem tudnak és nem is akarnak objektum orientáltan programozni, ezért a Java csak egy nyűg.

És ráadásul úgy nyűg, hogy nem is tudnak róla! Ugyanis a nagy többség leragad egy nyelvnél, és nem tanul olyat, aminek más a szemlélete. Ha több szemléletet is megismersz, akkor átlátod a különbségeket, és ráérzel arra, hogy mi redundáns, mi költséges feleslegesen. Egyik megközelítés sem tökéletes. Jelenleg a vegyes megközelítéssel lehet legjobban kódot fenntartani

"Kérdés: miért írnál Java-ban például egy webes applikációt 2000 kódsor felhasználásával úgy, hogy 80 darab class van a kódodban, továbbá legalább 100-120 fájl, amikor ugyanezt Python vagy Ruby segítségével megteszed 6 class használatával, mindössze 25 fájllal és 400-600 kódsorral?"

Mert valójában mégiscsak a Java-ban kell kevesebb kódot írnod, mivel nagyságrendekkel több open source library áll rendelkezésedre.

"A Java fejlesztők rendszeresen osztálynak álcázzák például webes alkalmazások esetén az egyes adatbázis táblákra mappelt modelljeiket. Ilyenkor raknak bele n darab privát adattagot, n darab gettert és n darab settert. Objektum-orientált lett ettől a modelljük? Megvalósították az egységbezárást? Lóp1kulát. Nem 10 soros, 3 másodperc alatt értelmezhető kódjuk lett, hanem 300 soros, pontosan ugyanazt csináló, de értelmezhetetlen, és nehezen kezelhető katyvaszuk."

Mi a nehezen értelmezhető egy entity bean-ben? Nem a rövidségétől lesz valami könnyebben értelmezhető. Na meg nyilván az egyszerűbb gettereket, settereket a programozó nem megírja, hanem az IDE generálja. Az összetettebbeknél meg eleve szükséges valamilyen ellenőrzés. A Java-nál fejlettebb nyelveken, pl. C#, property-k vannak, ami sokkal elegánsabb megoldás, ami viszont még hosszabb, ez esetben még átláthatóbb kódot eredményez.

"Mert valójában mégiscsak a Java-ban kell kevesebb kódot írnod, mivel nagyságrendekkel több open source library áll rendelkezésedre."

Úgy érted, hogy Java-ben kell többet nem írnod? :D Amúgy attól, hogy a library, amit használsz, Java-ban van írva, attól még nem kell Java-ban írnod a saját kódodat! Például a többit írhatod Python-ban!

Bár, az esetek 99%-ban van alternatívája a Java-s library-nek, úgyhogy én ebből az indokból nem használnék máris automatikusan Java-t. A másik ami nem mindegy: a minőség. Attól, hogy van rengeteg library, még nem feltétlenül jobb is. Amit szintén hozzá kell tenni, hogy például webes dolgokban a Rails már lazán kenterbe veri ilyen tekintetben is a Java-t.

"Na meg nyilván az egyszerűbb gettereket, settereket a programozó nem megírja, hanem az IDE generálja."

Nagyon okosnak hangzik fölösleges, funkcióval nem rendelkező kódot generálni a programodba. :D

A Java egyébként azért lett class-first, hogy kikényszerítse az OOP használatát. Nos

1) Ha OOP-t használsz, akkor miért generálsz getter-settert? Hiszen az OOP-ben nincs publikus adattag, validálással sem. Ha getter-settert generálsz, akkor nem OOP szemlélettel programozol.

2) Ha nem akarsz OOP szemlélettel programozni, akkor meg eleve butaság olyan nyelvet választani, ami rá akar kényszeríteni az OOP használatára.

"A Java-nál fejlettebb nyelveken, pl. C#, property-k vannak, ami sokkal elegánsabb megoldás, ami viszont még hosszabb, ez esetben még átláthatóbb kódot eredményez."

Miért eredményezne hosszabb kódot? És főleg, miért eredményezne átláthatatlan kódot?

A Java "egy osztály - egy fájl" megkötését én személy szerint mindig is gyermekbetegségnek tartottam. A Java rengeteg gyermekbetegséggel küzd, és ezekből keveset nőtt ki. Túl sok mindent erőltet, közben sok sebből vérzik és rengeted tervezési mintát nem lehet benne hatékonyan megcsinálni. Asztali alkalmazásra, webes appletre már csak a megőszült elvetemült Java félistenek használják. Van amire viszont nagyon jó, és ez a szerver oldali fejlesztés; magyarul a Java EE. A többi már csak bohóckodás. Nézzük csak meg mit tett az Androiddal a Java.

A Python jóval újabb, modernebb nyelv, dinamikus és multi-paradigmás. Számomra azonban egyetlen hátránya az "önformázó" identálás, amit egyszerűen fáj olvasni. Sohasem látom miden van a scope vége és az eleje. Szörnyen bosszantó és buta; egy több soros komment esetében még a komment kezdete sorkizárt kel hogy legyen, ez iszonyatosan debilis dolog.

Léteznek sorzárás nélküli nyelvek amik valahogy tudnak jól működni; például van bennük end kulcsszó.

Az igazság valahol a kettő között van. Az állandóan 0% értékelt válaszoló sok szemszögből érett dolgokat állított, a Java nyűgjeivel kapcsolatban, azonban én sohasem tekintetem a Python-t jó nyelvben, sajnos nálam megrekedt az "egy fura script nyelv" szinten. Bár el kell ismerni hogy bizonyos megoldásai és maga a nyelv előretörése előtt meg kell emelnem a kemény karimás kalapomat.

"Számomra azonban egyetlen hátránya az "önformázó" identálás, amit egyszerűen fáj olvasni. Sohasem látom miden van a scope vége és az eleje"

Scope vége és eleje? A Python-ban függvényenként és modulonként van scope, egy for ciklus vagy egy if statement például nem alkot scope-ot. Tehát nincs mit látni. Ezért hagyták el többek között ezt a jelölést! Az pedig, hogy mi függvény, az elég egyértelműen látszik, de erre a PEP8 által javasolt kódolási stílus még rá is erősít.

Másrészt pedig, engem akkor tör ki a frász, amikor Java, C vagy C++ nyelven azt látom, hogy a fél képernyőmet ez tölti ki:

}

}

}

}

}

}

}

(Indentálással, csak azt a gyakori itt nem engedi).

Vagyis mondjuk egy névtéren belüli classon belüli metóduson belüli ifen belüli for cikluson belüli switch statement lezáró vége például :D

A Python eleve arra hangolja a fejlesztőt, hogy ne is szervezze így a kódját. Ha ennyi indentálás van, akkor már eleve rosszul van szervezve a kód. És a Python esetén ez látszik is. Egyértelmű, hogy rosszul megírt kódot Python esetén is kín nézni. Egy szépen formázott Python kódban indentálás lényegesen kevesebb van, mint egy átlagos Java kódban. Tehát itt pont az az elképzelés, hogy az az ideális, ha a lényegi rész az nem a képernyő jobb szélére van kihúzva, hanem bizony ott van a bal szélen. A lényeg mindig az, hogy a logika szemléletes legyen, és aközött legyen asszociáció, ami ténylegesen összekapcsolódik.

"Szörnyen bosszantó és buta; egy több soros komment esetében még a komment kezdete sorkizárt kel hogy legyen, ez iszonyatosan debilis dolog. "

Én dolgoztam már 50.000 sor fölötti Python projektben, a felmerülő problémák között viszont semmire nem emlékszem a kommentekkel kapcsolatban. Nem vagyok benne biztos, hogy pontosan értem, hogy mi a probléma, amiről itt beszélsz. Tudsz mutatni egy konkrét példát?

"Léteznek sorzárás nélküli nyelvek amik valahogy tudnak jól működni; például van bennük end kulcsszó. "

pl. Ruby. De, én soha nem hiányoltam az end kulcsszót. Jellemzően egy üres sort ütök a helyére függvényen belül, vagy egymás alatti statementek esetén. Maguknál a függvényeknél pedig eleve 2 üres sort ír elő a PEP8. (Tehát egy üres sor az end helyett, egy meg térköznek)

" sajnos nálam megrekedt az "egy fura script nyelv" szinten."

De hogy került oda? Hiszen nem script nyelvről van szó.

A furcsaság pedig vélhetően annak köszönhető, hogy mint minden mást, ezt is meg kell szokni. A Java, C++, C#, C, JavaScript, PHP, sőt még egyéb társaik között is nagyon sok grammatikai hasonlóság van. Erre rááll az ember agya, ebben tud navigálni, ezt látja át. Amikor először kezdtem Pythonozni, akkor nekem sem állt rá azonnal a szemem. Viszont, olvasgattam szépen megírt kódokat, és sokat gyakoroltam. Aztán olvasgattam nagyon csúnyán megírt, több tízezer soros monstrumokat is. Azóta nekem ez már legalább annyira természetes, mint a C-stílusú grammatika.

"Úgy érted, hogy Java-ben kell többet nem írnod? :D Amúgy attól, hogy a library, amit használsz, Java-ban van írva, attól még nem kell Java-ban írnod a saját kódodat! Például a többit írhatod Python-ban! "

Ami nem mindig igaz, meg gyakran nem a legegyszerűbb, leghatékonyabb megoldás.

"Bár, az esetek 99%-ban van alternatívája a Java-s library-nek, úgyhogy én ebből az indokból nem használnék máris automatikusan Java-t."

Ja, csak általában ha valami olyat fejlesztesz, amire szükség is van, mert nem áll rendelkezésre 10 ezer kész alternatíva, akkor pont az 1%-ba fogsz leggyakrabban belefutni.

"A másik ami nem mindegy: a minőség. Attól, hogy van rengeteg library, még nem feltétlenül jobb is. "

Nem feltétlenül, csak akkor neked kellene bizonyítanod, hogy annyira kevés a jó minőségű Java library, hogy más platformra abból több van. Valószínűbb az, hogy Java-ra több rossz és több jó minőségű is van.

"Amit szintén hozzá kell tenni, hogy például webes dolgokban a Rails már lazán kenterbe veri ilyen tekintetben is a Java-t. "

Melyik Java keretrendszert? Az összeset?

1) A getter/setter, de az annál fejlettebb property nem azt jelenti, hogy publikus az adattag. A getter és a setter csak a legegyszerűbb esetben nem csinál semmit az értékadáson, értékátadáson kívül, és a validálás egyetlen példa volt, de pl. van amikor alapból nem is létezik az, amit get-el lekérsz, mert mögötte teljesen más adatstruktúra van, de mondhatnám példának azt is, mikor konkurens szálak érnek el egy erőforrást.

"Miért eredményezne hosszabb kódot? És főleg, miért eredményezne átláthatatlan kódot?"

Egy property-nél ugyanúgy megírod a gettert és a settert a legtöbb esetben, ezért nyilván mivel property-t is deklarálsz, ezért hosszabb. Miért lenne átláthatatlanabb, én pont azt írtam, hogy még hosszabb, de átláthatóbb.

"A getter/setter, de az annál fejlettebb property nem azt jelenti, hogy publikus az adattag. A getter és a setter csak a legegyszerűbb esetben nem csinál semmit az értékadáson, értékátadáson kívül, és a validálás egyetlen példa volt, de pl. van amikor alapból nem is létezik az, amit get-el lekérsz, mert mögötte teljesen más adatstruktúra van, de mondhatnám példának azt is, mikor konkurens szálak érnek el egy erőforrást.

"

Félreérted! Adattag az, ami adattagként viselkedik. Ha valamit getterrel le tudsz kérni, és setterrel be tudsz állítani, az adattag. Nem számít, hogy mi a mögöttes megvalósítás. Az objektum-orientált elképzelés nem arról szól csupán, hogy az adattárolás módját kell elrejteni, hanem arról is, hogy soha nem úgy kezeled az objektumokat, hogy azok belső adataihoz hozzáférsz, hanem mindig metódusokon keresztül veszed rá az adott működésre. Objektum orientált modellben soha nem azon van a fókusz, hogy adatokat megtudj egy adott objektumról. Néha nem kerülhető el, hogy legyen publikus adattagod (getter-setter, vagy public kulcsszó, ha nem kell validálás), de általában igen. Például ha egy Utánfutú akkor csatlakoztatható Normál kamionhoz, ha a rakomány összsúlya nem haladja meg a 20 tonnát, akkor nincs semmilyen publikus adattagod sem a kamion, sem az utánfutú osztályán. Hanem, az utánfutún van egy canAttachTo(TructType type) metódus, ami ellenőrzi a type-hoz tartozó súlyfeltétel meglétét. A Truck osztályon pedig van egy attach(Trailer trailer) metódus ami a trailer.canAttachTo(this.type) && this.attached_trailer == null feltétellel ellenőrzi, hogy lehet-e csatlakoztatni, és ha nem, akkor Exception-t dob. Tehát, nincs itt sehol semmi publikus adattag (tehát getter-setter sem).

Jó ellenpélda például a Dátum osztály. Azt soha nem fogod objektum-orientáltan elkészíteni. A megvalósítástól függetlenül, lesz year, month, day, etc. publikus adattag. Máshogy nem tud működni, legalábbis hatékonyan biztos nem.

"Az OOP sokkal jobban működik object-first megközelítéssel, mint class-first megközelítéssel, különösen ha multi-paradigm nyelvről van szó."

Problémája és projectje válogatja. Az említett adatbázis táblás megoldásod esetén pl. kifejezetten osztályról van szó. Ezért nincs igazad ebben. Egy tábla minden sora önálló objektum. Ráadásul logikai értelemben véve kategorizálhatók, tehát van értelme az osztály fogalomnak. Hovatovább mindegyik sor csak annyi és nem több attribútummal kategorizálható, mint amennyit már az osztályban definiálni tudsz és meg is teszel.

A function objectes kritikád az áll. Igen, vannak olyan esetek, amikor bizonyos objektumok függvényként kategorizálhatók. De ettől azok még objektumok.

"Gyakorlatilag tehát csak egy hash tábla jön létre. Ez, egy sokkal homogénebb megvalósítás."

Egyben el is érkeztünk oda, hogy miért is memória és órajelpazarlóbb ez a megoldás. De filozófiailag is. Ha nekem van harmincmillió (igen, vannak rendszerek, ahol még ennél is több van) sorom, amiről én hiába tudom, hogy mind ugyanolyan szerkezetű, csak az adatok mások bennük, mégis eltárolom a struktúra információt is, akkor igen csak rossz szoftvert írtam ennek kezelésére.

"Tehát a különbség annyi lesz, hogy a paramétereket minden függvénynek külön-külön kell megadni, nem pedig példányosításkor."

Nem igazán látom be, hogy mondjuk jó pár tucat referenciát miért kellene folyamatosan belepakolnom a verembe úgy, hogy egyébként egy egész hívási fában konstans az értékük. Azt meg végképp nem, hogy miért lenne egyszerű a dolgom programozóként.

"Ha getter-settert generálsz, akkor nem OOP szemlélettel programozol."

Nagy tévedés ez. Ráadásul rohamosan terjed.

"hogy soha nem úgy kezeled az objektumokat, hogy azok belső adataihoz hozzáférsz, hanem mindig metódusokon keresztül veszed rá az adott működésre"

Egy más kérdésnél való hozzászólásom nyomán tőled is megkérdezem. Ha mondjuk emberek életkorával számolsz és különböző értékeik között kell statisztikai célokból különféle származtatott adatokat kiszámolnod, akkor a "személy" entitás/objektum "getAge" (mindegy, hogy property, vagy közvetlenül field, vagy akármi) műveletének eredményeivel való számolás helyett miért egyszerűbb az, ha a "személy" entitásba rakom az összes számítási metódust, meg még a jövőbelieket is? A való életben sem miért így csináljuk?