Akik szeretik a Java nyelvet, azok mit szeretnek benne?

""Ahhoz képest, hogy nem sokkal magasabb szintű a C++-nál, indokolatlanul lassabb"

Ezt nem rétem. Persze, hogy lassabb. Nem elég, hogy magasabb szintű, virtuális gépben fut. Cserébe a bytekód révén platform független lesz, nem kell minden rendszeren újra fordítani. (Plusz azért lehet ebben is gyors kódokat írni és akár használható natív, platform függő kódrészlet is, amit lehet optimalizálni.) "

Az érveidet nem értem. A virtuális gép használatával hogyan lesz lassabb egy nyelv? Ha maga a nyelv jól van megtervezve, és a fordítóprogram implementációja megfelelő, akkor csak a virtuális gép implementációján múlik a sebesség. Tekintve, hogy C++ esetén például pont a nyelv _futási_ sebességének növelése érdekében kísérletezgetnek virtuális gép használatával, ez önmagában nem kell, hogy indokolja a lassabb futásidőt.

A Java virtuális gép is csak egy gép, ugyanúgy, mint a többi. Olyannyira, hogy hardveres implementációi is léteznek. A gép matematikai definíciójából még a JVM sem tud kitörni, ennélfogva a kódja sem lesz hordozhatóbb, hiszen a kódja ettől még nem lesz kompatibilis más gépek kódjával. Tehát maga a kód nem hordozhatóbb. A Java esetében ezt úgy oldották meg, hogy a virtuális gép hordozható. Mert egy hordozható nyelven van megírva, hordozható implementációval. Ebből definíció szerint következik, hogy nem ér el nagyobb hordozhatóságot, mint az a nyelv, amin a virtuális gép implementációja meg van írva, kivéve, ha ez több nyelven is megtörtént. Egyébként nem nehezebb egy platformra C/C++ fordítót készíteni, mint Java virtuális gépet.

Tehát szerintem ez a hordozhatóság a Java nyelv esetén picit félre van értelmezve, vagy túl van értékelve. Ezzel a képességgel a legtöbb elterjedt programozási nyelv rendelkezik, pedig jó részük általában nem használ virtuális gépet sem.

"WTF? Senki nem mondta, hogy kell getter/setter, ha publikus adattagot akarsz, akkor azt csinálsz. A getter/setter arra jó, hogy kordában tarthatod, ki hogyan fér hozzá az adattagjaidhoz, esetleg konvertálhatsz, stb. Getter/setter meg minden OO nyelvben jelen van, tehát ha ezt szidod, nem csak a Java-t szidod, hanem az említett 21. századot. "

Ha publikus adattagot akarok, akkor azt csinálok. Kivéve, ha egy interface kikényszeríti, hogy legyenek getter/settereim. Vagy ha egy típusparaméter/generikus osztály kikényszeríti ugyanezt. Általában megteszi. Egy konkrét osztálynál, ami valamilyen más által írt kóddal kell, hogy együttműködjön, általában rákényszerülsz arra, hogy a publikus adattagot getter-setterek segítségével hozd létre. Ez egy forró pont a Java nyelvben, napi szinten találkozol vele, mégsincs szintaxis a probléma megoldására. A property szintaxis pedig már a legtöbb, hasonló problémával rendelkező nyelvben alapfelszereltség. Gyakorlatilag kézenfekvő megoldásnak számít.

Az pedig egyszerűen nem igaz, hogy getter/setter minden OO nyelvben van. Az OO programozást támogató nyelvek jelentős részében nem szoktak ilyet használni a fejlesztők. Persze, a legtöbben lehet használni ilyet, csak általában nem él túl egy code review-t.

Tehát egy részről nem az OOP-t szidom (bár azt is lehetne kritizálni), másrészről 21.század != objektum orientált programozás. Nagyon nem. Meg lennék lepve, ha 60-70 év múlva az objektum orientált programozás olyan elterjedt lenne, mint ma. Ma is nagyon sok más programozási paradigmát használnak. Az OOP talán népszerű, de csak egy kis szelete a paradigmák tortájának.

"""rengeteg elnevezés 3-5 szóból álló összetett szó"

Azért van, hogy a kód öndokumentáló lehessen, hogy a kommenteket nem tartalmazó kód olvasásával megértsd, mit csinál a program. ""

Hát igen. Az öndokumentációhoz nem elvárás, hogy hosszúak legyenek az elnevezések. Ahogyan buta szokás egy jól olvasható elnevezés helyett kommentet használni, úgy buta szokás komment helyett gigantikus függvénynevet használni is. A Java programok viszonylag jól teljesítenek általában olvashatóság szempontjából, de ehhez nem elvárás, hogy legyen egy GenericCodeReadibilityFeatureFactory-d. Az esetek többségében a gigantikus elnevezés nem a jól olvasható, hanem a rosszul szervezett kódot jelzi. Ugyanis moduláris felépítés használatával az esetek többségében elkerülhető az ilyesmi, és helyette lehet CodeReadibility.FeatureFactory.Generic, amit a moduljaidban mondjuk importálhatsz, és a hosszú minősített név helyett használhatod a FeatureFactory.Generic alakot, ami továbbra is teljesen egyértelmű, nem rontja a kód olvashatóságát.

"Erre van kitalálva a dokumentáció. Minden nyelvről elmondható, hogy IDE és/vagy doksi nélkül fogalmad sincs milyen modulok vannak. Ha a doksit nem tudod használni, az nem a nyelv hibája. "

Hát, nekem azért van fogalmam doksi nélkül is, hogy milyen modulok vannak az egyes nyelvekhez. Legalábbis a legfontosabb, hétköznapi (tehát nem specializált) modulokról van fogalmam. Nagyon egyszerű: egy jó nyelvhez ilyenekből pont olyan van, mint a többihez. Nem nehéz megjegyezni.

Legfeljebb a nevüket és a használatukat nem tudom. Persze, ha már fluent vagyok egy nyelvben, akkor tudom. Csak előtte nem. De erre van a dokumentáció. Ahogy írtad. Ha a doksit nem tudom használni, akkor az pedig csak a nyelv, vagy pedig a dokumentációt készítő fejlesztők hibája lehet, mivel normálisan elkészített dokumentációt tudok olvasni. Egyébként semmilyen dokumentáció nem helyettesíti a kód megértését.

Ahhoz, hogy dokumentációt tudj olvasni, ahhoz pedig nem szükséges, hogy integrált fejlesztői környezeted legyen. Sőt, nekem integrált fejlesztői környezet használatára más nyelvek esetén soha nem volt ingerenciám, csak a Java és a C# használatához kellett eddig nekem. Az oka: úgy vannak felépítve a nyelvek, hogy integrált fejelsztői környezet használata nélkül a kódot olvasni, és írni is körülményes. Más nyelvek jól megvannak IDE nélkül is. Ha például a programodhoz sokszor az IDE használatával kell kódot generálnod, hogy kényelmesebb legyen a kódolás, akkor nagy valószínűséggel vagy a nyelvedből hiányzik egy alapvető feature, vagy pedig te nem használod jól a nyelvet. A fejlesztői eszközökön keresztül történő kódgenerálás alapvetően egy ritka dolog kell hogy legyen, mivel azt, amit gyakran kell automatikusan generálni, azt a nyelv maga is meg tudja oldani, ha jól van megtervezve.

"Barátkozz meg a Reflection API-val. Ronda, de megoldható vele. Egyébként tudtommal fejlesztik már az ilyen függvény átadásokat a következő verziókban."

Ronda és körülményes. A Reflection API nem újdonság számomra. A legalapvetőbb dolgok leírásához is több soros kódra van szükség, ráadásul a Reflection API is csak korlátozott funkcionalitással bír.

"De lehet, sőt van akinek kell is. Volt az egyetemen konkrétan olyan óránk, ahol IDE nélkül kellett dolgozni vele egyszerűbb programokon. Hidd el, van benne logika és használható. "

Nekem is volt egy ilyen kurzus az egyetemen. Azon a kurzuson rendkívül egyszerű és rövid programokat kellett írni, amik általában 1-2 modulból álltak. De már így is többszáz sorosra duzzadtak időnként.

""A típusparaméterezés lehetősége nagyon korlátozott."

Generikusok? Neked lehet az OOP-vel magával vannak gondjaid. "

Generikusok a Java nyelvben 2005 óta vannak, holott a nyelv akkorra már hatalmas népszerűségnek örvendett. A tapasztalt Java programozóknak tehát egy jelentős része már akkor is Java-val dolgozott. Ez tehát nem válaszolja meg az eredeti kérdést, hogy mit szeretnek benne. Hiszen amikor elkezdték használni, még nem volt ilyen lehetőség a nyelvben.

Egyébként generikusok használatával is vannak komoly hiányosságai a típusparaméterezésnek. Például instanceof mennyire használható típusparaméteren?

"Láttál már Objective-C kódot, vagy valamilyen iOS-es program kódot?

Ez nézőpont kérdése hogy rossz vagy jó. Hosszabb névvel sokkal jobban érthető, hogy az adott dolog mit is csinál.

Hol csökkenti ez a "kód felxibilitását"? "

Attól, hogy valaminek hosszabb a neve, még nem lesz érthetőbb, sőt, esetenként ronthat is a helyzeten. Lásd a másik válaszra adott kommentem.

"Nem veszítesz azért azzal annyira sokat, könnyedén megoldható minden feladat enélkül is. (Függvény túlterhelés van.) "

Persze. Sőt, maga az operátor szintaxis nélkül is megoldható bármi... Elvégre az csak egy fölösleges syntactic sugar. Ugye szép, jól olvasható, OOP (ez ahogy hallom nagyon fontos) kódot csak így írhatunk:

Humidity(5).add(Humidity(7)).scale(10).add(Humidity(7)).equals(Humidity(127))

Ugye, milyen szép, olvasható kód? :)

""Kód duplikáció kód duplikáció hátán"

Ha rosszul tervezed és kivitelezed a programot az a te bajod, nem a nyelvé. "

Nos... De, a nyelvé is. Főként a kivitelezési oldalon. Például, ha a jól megoldott kivitelezés 10-szer annyi időt vesz igénybe, akkor csekély az esély, hogy a jól megoldott kivitelezést fogom választani, kivéve, ha egy nagyon fontos modulról van szó. Oka: határidő.

A rosszul megtervezett programnak több oka lehet. Néhány:

- Határidő

- Tapasztalatlan programozók

- Fejlesztési stratégia hiánya

- Körülményesen használható programozási nyelv

- Kényszer a rossz API-kkal való együttműködésre. (Egy wrapper api készítése esetleg túl nagy költség lenne)

Tehát nagyon is lehet a nyelv hibája. Például, gondolom láttál már C/C++ programokban előfordítónak szánt makrókat. Az például jó példa, hogy hogyan teheti tönkre a kódbázisod az, ha egy körülményesen használható programozási nyelvben írod. Persze általában a te hibád, ha olyan nyelvet választasz, ami rossz. Például azért nem választok én Java-t.

"Privát adattagok nem véletlenül vannak és nem véletlenül lehet ezekhez csak gettereken és settereken át hozzáférni. A pulikusokat meg simán meg lehet hivatkozni ezek nélkül is. (Plusz amúgy ha kell 2 gombnyomás bármilyen IDE-ben a getterek és setterek generálása...) "

Lásd a másik válaszra adott kommentem.

""Nincs property szintaxis."

Kicsit bővebben? Mit hiányzik neked? "

Lásd a másik válaszra adott kommentem.

""Nem lehetséges mixin classokat készíteni, ami kód duplikációra kényszerít"

Ott vannak a generikusok továbbra is. "

Hogy jönnek ide a generikusok? A mixin classokat inkább kompozícióval lehet helyettesíteni, ami egyébként általában (de nem mindig), jobb gyakorlat is. (Ugye ha már OOP, akkor composition over inheritance). Hiszen nincs többszörös öröklődés. Ott válik körülményessé a dolog, hogy egy kompozíció természetesen privát adattagokon keresztül kerül megvalósításra. Erre találták ki a Java-ban az interface-eket. Csakhogy ahhoz, hogy egy interface-t megvalósíts, az alábbiak közül az egyikre szükséged lesz nagy valószínűséggel:

- nagy kód duplikáció

- kis kód duplikáció és utility methodok hada

- boilerplate metódusok egy privát adattaghoz (kompozíció)

"Hidd el használtam Java-t, C++-t, PHP-t, Python-t, Javascripte-t, Go-t, Haskell-t és még egy halom más nyelvet is.

Egyik sem jobb vagy rosszabb a másiknál. Minden feladatra a neki megfelelő nyelvek kell választani. "

Nevetséges elgondolás szerintem, hogy egy nyelv nem lehet rossz. A PHP például hihetetlenül rossz. Egyetértek, hogy különböző célokra különböző nyelveket lehet érdemes használni. Most nem azt vitatjuk, hogy a Java egy programozási nyelv-e, hanem azt, hogy a Java milyen célra jó úgy, hogy nincs nála jobb alternatíva ugyanolyan célra. (Leszámítva az olyan mesterséges eseteket, amikor valamilyen céges policy, meglévő kódbázis, vagy platform elvárás kényszeríti ki, hogy azt a nyelvet használd)

"Attól, hogy valaki nem tud jól használni egy nyelvet, nem a nyelv lesz a hibás."

Pontosan. Például a C++ is egy remek nyelv, mármint arra a célra, amire nem használhatsz helyette egy magasabb szintű nyelvet. De magas szintű nyelvnek pocsék. Ha például egy website backendjét C++-ban akarod megírni, akkor nem tudod jól használni a C++-t. Mert nagyon nem erre való. Azt egyértelműen el tudom fogadni, hogy egy bizonyos szűk felhasználási körben a Java nagyon jó választás. Csak annak az okait nem értem, hogy miért van manapság már a szartól a repülőig mindenben Java? Olyan helyeken, ahol egyértelműen rossz, és túlzottan költséges is Java nyelvet használni.

"Operátor overloading: nem érzem a hiányát Java-ban, sőt nem is mindig triviális, hogy a + jel v. a << épp mire használatos. Persze ott a dokumentáció, de akkor már egy beszédes függvény elnevezés hatékonyabb."

Amikor nem triviális, akkor egyértelmű, hogy nem kell operátor túlterhelést használni. Például a * jellel is csinálhatsz mondjuk összeadást, csak nettó baromság. Viszont az = operátor, vagy a (), esetleg netán a [] operátorok túlterhelhetőségének hiánya nagy érvágás.

"Én azt szeretem benne, hogy fél év Java alapok tanulása után egy kicsit hozzátettem és futam formos alkalmazásokat készíteni, adatbázis kezeléssel. Egy kicsit hozzátanultam és nem volt probléma mobilra fejleszteni (MIDP és Android) még egy kicsit utánanéztem és nem okozott problémát egy webes alkalmazás elkészítése.

Ezzel szemben tanultam félévig C-t, fél évig C++, aztán c++-t kicsit haladóbb szinten és nem tudnék összerakni egy ablakos programot, ami mondjuk használ egy adatbázist.

(C#-al már kicsit más a helyzet, ott azért ez könnyebben megy, de mivel az MS atyáskodik felette, inkább kerülöm)"

Szerintem azért, mert sem a C, sem a C++ nem rapid developmentre való. Esetenként jó ötlet lehet grafikus felületeket C++-ban csinálni, máskor meg nem az. De szerintem a Java sem rapid fejlesztésre való. Egyébként a Java felett meg az Oracle atyáskodik.

"Persze ez a lényegi különbség számomra a Java és mondjuk a C++ között nem feltétlenül a nyelvből fakad, lehet, hogy az oktatás volt más, lehet, hogy egyszerűen az agyam jobban ráállt a Javara. "

Szerintem a nyelvek célja a más. A C/C++, vagy azok alternatívái bizonyos célokra elengedhetetlenek. Nyilván van, amire a Java is elengedhetetlen, bár szerintem elég kevés ilyen van. Például a legtöbb webes alkalmazás esetén idiótaság lenne C++-t használni, és minden eséllyel a Java használata is ugyanúgy felesleges költségekkel járna.