Meghal-e, vagy totál átalakul-e a JAVA (hosszabb távon)?

Közösségi kerekasztal

Sziasztok!

Egy pár helyen úgy olvasni hogy a JAVA "az új Cobol", meg hogy "Ó a JAVA meg fog halni" mások szerint a JAVA túléli csak átalakul.

Tudtok erről valami biztosat? Tény, hogy sokmindent .NET-el meg lehet csinálni, nomeg mit kezdjen a sok RAM gyártó ha nem lesz JAVA? :)

Vélemények? Érdekel, mert az ember nem tanul pl. SBS szervert (és vele együtt Exchange-et) hogy ha nemrég óta már úgysincs forgalomban, csak hát ugye 2004-ben ezt még sokan nem gondolták ugye.

Hmm? Köszi :)

  • 30762 megtekintés

( Hevi v | 2014. 11. 01., szo – 22:02 )

Hát, Enterprise környezetben elég brutál sok helyen használják a Java-t, szóval jelenleg nem úgy tűnik, hogy megszűnne/meghalna. Meg amúgy .NET-en kívül van bármilyen konkurenciája, toolokat, libeket, best-practiceokat tekintve? Mármint komoly fejlesztéshez, a Node.js-t meg az ilyen komolytalanságokat hagyjuk...

Nameg szerver oldalra nem alternatíva a .net azokon a helyeken ahol nincs Windows szerver, és az elég sok hely. Aztán ott az android is..

Valamiféle erodálódás azért talán megfigyelhető, illetve egyre több kritika is éri a Javát, de nem gondolom hogy rövid időn belül nagy változásoknak néznénk elébe (mármint a megszűnése kapcsán).

Pl. erős/gyenge, statikus/dinamikus típusosság. Nem árt, ha nem futásidőben derülnek ki a turpisságok, hanem már fordítási időben is ott a jelzés, hogy "ez így nem lesz jó". Sokkal egyszerűbb erősen és statikusan típusos nyelvben kódolni, már csak azért is, mert pontosan meg van határozva, hogy mi a paraméter, mi a visszatérési érték, nem kell olyanokra is figyelni, hogy az ember futásidőben ellenőrizze, hogy vajon jó típusú adatot kapott-e.

Meg szerintem attól is lehet "komolytalan" egy nyelv, ha nincsenek kialakult konvenciók hozzá, amihez nagyjából mindenki tartja magát. A JavaScript esetén (nyilván a saját szintemen megítélve) azt látom, hogy teljesen ötletszerűek a konvenciók projectektől függően.

Erről valami statisztika? Mennyivel több helyen használják, milyen projectekre, kódbázis mérete, karbantartás költsége, stb?

Arra nyilván nem fog az ember összeröffenteni egy Java env-et, hogy összedobjon valami PoC-t, arra bőven megfelel egy tetszőleges script nyelv (PHP, JS, Python, Ruby). Viszont, ha arról van szó, hogy Enterprise környezetben kell millió kódsorban turkálva hétről-hétre szállítani a feature-öket, akkor azért egy "komoly" nyelv, mint a Java, vagy a C# irgalmatlan előnyökkel rendelkezik.

Szerk: azt szeretik felhozni a Node mellett, hogy egy nyelv, szóval a frontendes is tud backend kódot, illetve a backendes is tud frontend kódot írni, ha szükséges. Na, aki dolgozott már úgy, hogy a backendes a frontendbe, a frontendes a backendbe turkált bele, az tudja, hogy finoman fogalmazva nagyon nem ideális.

Abszolút nem a node.js-re gondoltam, ennél sokkal gonoszabb voltam.

Hiába a sok enterprise, a nagy részük előtt ugyanúgy lesz valami JS, mert 2014-ben ezzel kell prezentálni a customernek a tartalmat. És az enterprise-on kívül a Zinternet csilliárdnyi weboldalán muzsikál a JavaScript.

Azért mert olyan jó? Nem. Azért mert ez az egyetlen nyelv ami fut a browserben (TM).

Szerveroldalon viszont többtíz másik nyelv is labdába rúg.

Az, hogy milyen a UX, az nem igazán releváns abból a szempontból, hogy mennyire karbantartható a kódbázis, mennyire egyszerű benne hibázni (mert hibák voltak-vannak-lesznek, és ha ennek elkerülésében a nyelv a segítségedre van, az jó), mennyire egyszerű debugolni, stb

Például az egyik legcsúnyább dolog, amit nagyon nem komálok a JS konvenciókban az a függvény paramétereként definiálunk egy másik függvényt, aminek a paraméterében létrehozunk egy objectet, aminek van egy tömbje, természetesen az is helyben definiálva, stb. Na azt mire kibogarássza az ember, hogy ki-kivel van, az nem egy leányálom (lehet csak nekem).

A típusosságot meg leginkább ehhez tudom hasonlítani:

http://www.javacodegeeks.com/2014/10/the-dsl-jungle.html

Én pedig nem választottam külön a kliens- és serveroldalt. Csak annyit mondtam, hogy a JavaScript mindenhol ott van, hiszen a végeredmény az lesz, hogy a böngészőben valami megjelenjen.

Nyilván nemcsak webből áll a világ, de közben azt látni, hogy a Qt-től kezdve a Win8-on át a Gnome-ig mindenhol a JavaScriptet használjuk már appok szkriptelésére. A napokban kérdezte pont egy kolléga, hogy "miért?? OMG MIÉRT?!?!?! Hiszen ott a Lua!". Erre volt az a válasz, hogy a Lua gyors, kicsi, modern, de JavaScript-programmerből (khm) pármillióval több van => párezer$ral olcsóbb a team.

Hogyhogy mire gondolok szerver oldalon? Hát természetesen (nonexhaustivelist):
- PHP (facebook)
- Python, Django (pinterest)
- Perl (omfg booking.com)
- Ruby, Rails (régi twitter)
- Node.js (paypal)
Ezek elég nagyok, nagyobbak, skálázhatóbbak, mint a legtöbb belső enterprise rendszer, és mégsem Java van mögöttük. Persze emellett még lesz egy-két C++-os vagy Yesodos őrület, de azokra így fejből nem tudok semmit mondani.

Ahogy mondtam, PoC-nak, startupnak a tetszőleges scripnyelv tökéletes, hiszen brutál gyorsan, az alapok bebetonozása nélkül lehet gyorsan működő eredményt elérni. De ahogy látjuk a lentebbi commentből, a Twitter is áll át JVM alapra.

A Facebook se pure PHP-t használ már, nagyon komoly fejlesztéseket tettek bele, ha jól emlékszem pl. statikus type-chekcet (hirtelen nem találom az előadást).

Foglalkoztam én is egy picit RoR-ral és bár tényleg kellemes rendszer, meg a Ruby-t is nagyon komálom, de ha nekem abban kellene dolgoznom egy akkora rendszeren, amekkorán most Java-ban dolgozunk, azt hiszem hamar megőszülnék.

A Booking cégcsoportnál legalább két cég is Java-t használ.

Hagy kérdezzem meg, hogy hány programozó is dolgozi kezeknek a cégeknek, és ebből hánynak az a teljes idős elfoglaltsága, hogy alternatív megoldásokat fejleszt ezekhez a programozási nyelvekhez? Arra akarok ezzel kilyukadni, hogy mindent lehet, mert a Google is használ MySQL-t, csak annak gyakorlatilag nem sok köze van ahhoz, amit letöltesz a netről, szóval hacsak nincs több tucat programozód, aki aládolgozik a production teamnek, akkor máris más a kép, akkor máris ezek a nyelvek kevésbé produktívak.
-
Groovy funkcionális eszközök

Sry, ne vedd támadásnak, de ez a "Hagy" az egyik leg... mondjuk úgy olvasatlanabb kifejezés, amit le lehet írni. Hadd. Jegyezze fel mindenki.

Szerintem a mai JS fejlesztés _SOKKAL_ nagyobb overhead, mint Javaban. Egy bizonyos pont után. Majdnem maintainelhetetlen a nagy JS kódbázis. Ezért ezek a programozók - még nagyobb overheadet generálva - nekiállnak a saját JS libjük fejlesztésének. Aztán így lesz Backbone. Meg Angular. Meg még kitudja mennyi egyéb. (BTW. ez az egész webes világra jellemző, nem korlátozódik a JS-re, lásd Bootstrap)

Szóval hadd válaszoljak: szerintem igazad van, túl sok az alternatív megoldások fejlesztője. Egy bizonyos szintig ez normális, hiszen ettől fejlődnek a módszerek, technikák. És mivel a JS-re sok fejlesztés ráfér, értelemszerűen tényleg sokan is próbálkoznak.

Köszönöm a nyelvtani korrekciót, reménytelen eset vagyok és ha kell szerzek papírt is róla ;)

Én nem a "Majdnem maintainelhetetlen a nagy JS kódbázis"-ról beszélek, hanem arról, hogy ha a csapatodban csak production programozó team van, akkor az általad említett platformok (PHP, Javascript, ...) nem biztos, hogy a legjobb lehetőségek. Mint ahogy a példa mutatja nagy cégek is alkalmazzák sikerrel, csak nekik dedikált csapatuk van a gyíkságok átalakítására. Nézd meg a FB-nak mennyi nyílt forrású vacka van, amivel megpróbálják jobbá tenni a PHP-t, és mondhatod, hogy ezek egy része elérhető és ha akarom akkor én is használhatom, csak egy kissebb projektnél az achitektúrát bonyolítja, és több magasan képzett szakemberre van szükség emiatt. Éppen ezért ha hosszú karbantartási idejű és skálázódó alkalmazást akarsz "házilag" készíteni, akkor kifizetődőbb lehet pl. a Java.
-
Groovy funkcionális eszközök

"csilliárdnyi weboldalán muzsikál a JavaScript" egyfelöl nagyrészük mögött Java dolgozik a háttérben, és Java oldalon, ahol az üzleti logika van bizony erősen tipusos a dolog. Másfelöl pedig egy példát mondanék. készítettünk egy storyboard készítőt, ahol a user összekattintgatja milyen tréning anyagot szeretne, mi meg elkészítjük neki a végleges html5 tréninget. Kliens oldalon Angular, szerver oldalon Spring (99% REST). Mikor felhecceltek a kollégák, hogy ez a projekt 80% frontend és csak 20% backend megszámoltam a sorokat, és 4800 sor Java kód dolgozik 1800 sor Js (+800 sor HTML) alatt. Nem azt mondom, hogy kliens oldli Js programozás smafu, mert főleg amióta nem Jquery + ajax + DOM manipulációból áll az egész, igen is komoly tervezést igényel az egész, de végül szerver oldalon történik a lényeg, és a szerver oldal felel az üzleti logika helyességéért, és az adatok konzisztenciájáért.

-
Groovy funkcionális eszközök

Szóval te is megerősítetted, hogy hiába elterjedt a Java szerveroldalon, továbbra is hatalmas mennyiségű JavaScript dolgozik a Java-s cuccok előtt.

Sajnos ebben a szálban már vannak ilyen ősjavahuszárok, akiket semmi nem érdekel, de ettől a tények még tények maradnak. Én sem rajongok a jelenlegi formájában a JavaScriptért, mi több, "tisztelem" a teljes Java ecosystemet, de ez nem indok arra, hogy ignoráljam a tényt, hogy inherently ott a JS és naponta fut többmilliárdnyi gépen, többmilliárdnyi embert "kiszolgálva".

Szerk.: Vigyázz, ha jön a jéeshuszár, elkezd szőrszálhasogatni, hogy "na jó, de abból a 4800 sorból legalább ezer import, ami JS-ben nincs!!4!!!!"

"hatalmas mennyiségű JavaScript dolgozik a Java-s cuccok előtt" ezt sosem vitattam. Én csak annak adtam hangot, hogy szerintem is a url=http://hup.hu/node/136443?comments_per_page=9999#comment-1799284]"komolytalan"[/url] kategóriába tartozik a . Megvan a maga helye és szerepe pont.

-
Groovy funkcionális eszközök

Hát, RoR-ban gyakorlatilag rögtön tudok fejleszteni, míg ugyanannyi idő alatt a Java-t csak konfigurálgatom :)

Persze mondjuk Spring Roo-val egyszerűbb picit a helyzet, de ott is ütköztünk már korlátokba. Amíg a konvenciót követed, addig tök jó, ha el akarsz tőle térni, akkor már küzdeni kell vele (mondjuk ez kb 2 éves tapasztalat, azóta lehet változott a dolog).

+sok

Pont ugyanezt akartam írni. Ok, nekem java-ban van legnagyobb tapasztalatom, de akár egy php, akár nodejs akár couchdb, de írhatnék bármilyen környezetet hosszabb idő és nehezebb volt összerakni mint egy java-sat.

Java-hoz windowsra, linuxra van klikk-klikk-klikk installer, de ha akarod akkor letöltöd együtt IDE-vel (netbeans) összeconfigolva minden: jdk, +web server (ha akarom, apache tomcat), +java-ee (ha akarom glassfish). Mindezt hozzáértés nélkül úgy, hogy az ide-ből lehet indítani leállatani, deployolni, logot nézni, debuggolni, profilozni.

"incsenek kialakult konvenciók hozzá" szerintem itt van a kutya elásva. Java-ho van gyakorlatilag official guide line, Js hogy áll? Ahány keretrendszer annyiféleképpen oldották meg az öröklést pl. Van aki prototypeot használ, vagy aki Object-eket extendelget, vagy olyan is akad, aki keveri a kettőt. Js nagyon jó példa erre, mert ahány ház annyi szokás, és mindenkinek van valami trükkje, ahogy megold valamit, mert úgy tartja fancy-nek. Átvettünk most egy projektet, mer taz előző csapat nem fejlesztette tovább, és az én feladatom volt megállapítani, hogy újraírjuk-e vagy folytatjuk a fejlesztést. Megnyitottam a forrást, és azonnal tudtam mit hol találok benne, hogy hol milyen patternt használtak, én is azt használtam volna. Természetesen a folytatás mellett döntöttünk, mert egy "standard" alkalmazást vettünk át. Ezzel nem azt mondom, hogy minden Java alkalmazás ilyen, de én elvárom mindenkitől, hogy kövesse a konvenciókat, és ennek, illetve az erős tipusosságnak hála a munkaerő jól skálázható minden projekten.

-
Groovy funkcionális eszközök

A kifejezesi erejetol. Mennyire konnyen tudsz absztrakciokat letrehozni, azokkal dolgozni (osszekombinalni a mar letezoket), es az absztrakcioidra epiteni ujabb absztrakciokat. Ez talan a legfontosabb.

Persze a tamogatottsag, elterjedtseg, fuggvenykonyvtarak, stb is fontosak, de azok idovel valtozhatnak. Az absztrakcios kepesseg is valtozhat, de joval nehezebben, nem veletlenul pisiltek vert a Java 8 fejlesztesenel...

"he Expression Problem is a new name for an old problem.[2][3] The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts)."

https://en.wikipedia.org/wiki/Expression_problem

Probalj meg versenyezni olyan koddal, amely bizonyithatoan helyes...

Egyebkent javascriptben is elerhetok ezek a tulajdonsagok (de celszeruen nem javascriptben kell irni - csak erre forditani):

"Many tools allow programmers to develop applications in highlevel languages and deploy them in web browsers via compilation to JavaScript. While practical and widely used, these compilers are ad hoc: no guarantee is provided on their correctness for whole programs, nor their security for programs executed within arbitrary JavaScript contexts. This paper presents a compiler with such guarantees. We compile an ML-like language with higher-order functions and references to JavaScript, while preserving all source program properties. Relying on type-based invariants and applicative bisimilarity, we show full abstraction: two programs are equivalent in all source contexts if and only if their wrapped translations are equivalent in all JavaScript contexts. We evaluate our compiler on sample programs, including a series of secure libraries."

http://research.microsoft.com/apps/pubs/default.aspx?id=176601

( atomheart v | 2014. 11. 01., szo – 22:20 )

"a JAVA "az új Cobol", meg hogy "Ó a JAVA meg fog halni""

A ketto ellentmond egymasnak.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

( Hevi v | 2014. 11. 01., szo – 22:29 )

Amúgy, ha az a kérdés, hogy érdemes-e belevágni a Java-ba, akkor a válasz: igen :)

Irgalmatlan nagy igény van jó Java fejlesztőkre, gyakorlatilag folyamatosan képez a cég Juniorokat illetve átképez egyéb területről Java-ra embereket.

Ld. a videót, picit én is látszódom, ahogy elsétálok :)

http://epam.blog.hu/2014/09/25/epam_academy

( kmARC v | 2014. 11. 01., szo – 22:56 )

Ahhoz, hogy megértsük, mi történik a Java-val, kicsit távolabbról kell vizsgálni a kérdést. Hogy mi folyik most a programnyelvek világában, érdekes, és régóta várt esemény; két vonulat kezdett közeledni egymáshoz:
- a hardver felől építkező, imperatív (proceduláris, majd egyre magasabb szintű objektumorientált) nyelvek
- a formális logikai, matematikai megfogalmazáson alapuló, főleg funkcionális nyelvek

Ennek oka egyszerű (vigyázat, demagóg állítás jön): a mai gyors processzorok végre emberi időben tudnak futtatni LISP kódot (Scalá-t, Haskellt, helyettesíts be amit akarsz).

Közben a funkcionális nyelvek alkalmassá váltak nagy szoftverek megalkotására (Hevinek tökéletesen igaza van, az enterpriseban nagy szükség van a statikus típusbiztosságra, néhány távolkeleti nagybank már boldogan Haskellezik emiatt). Viszont ezek a nyelvek hoztak magukkal egy könnyen olvasható és karbantartható kódolási stílust (is), amit aztán a nagy öregek próbálnak kisebb-nagyobb sikerrel implementálni.

Érdemes ránézni a C++11, 14, 17-re. Vagy inkább nem. Én több év C++-ozás ellenére nem is nagyon tudom értelmezni az új kódokat, de ránézésre legalábbis hányingert keltő. Mindenesetre megjelentek a lambdák, funkcionális interfészek, még akár a lazyness is, mitöbb, Milewski úr még monádokat is vár a 17-es szabványba.

És elérkeztünk a Javához. Véleményem szerint ők _JÓL_ implementálták a más nyelvekből tanult funkcionális elemeket, olvasható maradt a kód, és szépen kivitelezték a teljes collection API megduplázását (hogy aztán streamekkel is működjön minden). Mi több, ez utóbbi kifejezetten jó húzás volt, mert lazy evalt behozták úgy a nyelvbe, hogy a plain-old-java-collection-jeink nem szenvedték kárát.

Szerintem a kérdés egyértelműen az, hogy most egy nyelv alkalmazza-e a másik "táborból" vehető tapasztalatokat, és ha igen, milyen módon teszi (könnyű érthetőség, szép szintaktika, stb.) A Java úgy tűnik jó irányban halad (nem marad le), mert amellett, hogy egyértelműen nem a halála felé tart, közben nem is "totál átalakul"

Talán ez válasz a kérdésre.

És a Scalanak hány évre visszamenőlegesen kell kompatibilsnek maradnia? A Groovy-ban is megoldották a Closurekat (pofon egyszerűen), mégsem vette át a Java a megoldást, mert nem valami megkerülő dologra volt szükség, hanem a nyelv egészét átjáró megoldásra, ami nem töri meg a visszafelé kompatibilitást.

-
Groovy funkcionális eszközök

Forrás szinten nem töri a visszafele kompatibilitást*, pontosabban nincs is különbség, bytecode szinten szintén nem, mert egy nem tail recursive kódot miért ne futtathatnál egy tail recursiont is tudó vm-en, illetve még az se szükséges, hogy bytecode szinten különbség legyen, a jit compiler is optimalizálhatna.

*: na jó de, ha azt valós requirementnek tartjuk, hogy egy infinite recursion szálljon el StackOverflowError-ral

Sry, az "implementáció" szó nem volt a legjobb. Nem a valós "leprogramozásra" értettem, hanem a módszerek, elképzelések "alkalmazására".

Az a kissebb baj, hogy a tailcallopt jelenleg nem optimális; a későbbiekben kijavíthatják. A lényeg, hogy a szintaxis emészthető maradt; a karbantartható szoftverek világában (enterprise) pedig ez a lényeg.

Természetesen nem a leggyorsabban fejlődő platform a Java, hiszen 100 meg 100 dolgot kell számításbavenni, de én pont ezt szeretem benne, hogy számíthatok a tudásomra, és ahelyett, hogy napról napra alkalmazkodnom kéne az épp aktuális trendhez, el tudom mélyíteni a tudásomat.

-
Groovy funkcionális eszközök

( Nyosigomboc v | 2014. 11. 01., szo – 23:12 )

Nagyon sok helyen nincs alternativa. (ha Androidra akarsz fejleszteni, vagy ha platformfuggetlen kell, hogy legyen)

Egyebkent Star Trekben nem latsz Javas programokat, szoval idovel biztosan kihal. De az nem most lesz. :)

Ha mar ismersz egy par programozasi nyelvet, egy ujabbat megtanulni valamilyen szinten nem nagy dolog. Szoval ha most kezded a programozast, legfeljebb mire elhelyezkedsz, megtanulod, hogy az epp aktualis nyelven a substr a Stiring metodusa, vagy az n. parametere csak (vagy megnyitva tartod a doksit, vagy tobbet nyomogatod a ctrl+space-t). Aztan majd idovel egyre konnyebben megy. (ok, kicsit leegyszerusitettem a dolgot)

--
What's worse than finding a worm in your apple?
Finding a U2 album on your iPhone.

Persze, de ez most irreleváns. :)

A lényeg, hogy a Java sem mindenható, ha valaki nem tud mondjuk C++-ban olyan kódot írni, ami minden jelentősebb rendszeren lefordul, akkor Javában sem tud. Ez nem feltétlenül negatívum, egyébként.

Én is rengetegszer csináltam olyat, hogy egy egyszerű C# kódot, amit a Mono is képes lenne egy az egyben futtatni Linuxon, hazavágtam egy rakás P/Invoke-kal, mert úgy volt egyszerűbb.

Akkor átfogalmazom, hátha jobban átmegy az üzenet:

A Java sok dologra jó választás, arra speciel már pont nem, amire eredetileg kitalálták (write once, run everywhere). Ez független attól, hogy a kód minősége milyen; az az állítás, hogy ahol van JVM, ott elfut minden Java-nyelven írt szoftver _nem_igaz_.

Lehet, hogy régen igaz volt, manapság viszont már nem.

Értettem eddig is, de továbbra is úgy látom, hogy a Java-féle keresztplatformos megoldás egyre inkább "kimegy a divatból", egyre kevésbé működik.

Mennyivel egyszerűbb Javában olyan kódot írni, ami egyszer lefordítva mindenhol működik, mint bármi másban olyat, amire ugyan rá kell engedni a cross-compilert, de az elő tudja állítani az összes célplatformra a futtatható fájlokat? (Semennyire, ahogy a példán is látszik.)

A kliens oldali java kezd kimenni a divatból (bár http://docs.oracle.com/javase/8/javase-clienttechnologies.htm), ennek ellenére mi még bőszen fejlesztünk kliens oldali alkalmazást, bár lassan majd fordulunk a webes kliensek felé is, sajnos nem lehet mindent átírni. Webre kliens és szerver oldalon is java-ban dolgozunk, kliens oldalon GWT-vel.

Az önmagában nagyon jó, hogy egy nyelven fejlesztünk, és mondjuk kliens oldalon linux/windows alatt is teljesen jó megy a programunk, maga a nyelv is nagyon kényelmes (jó, van hozzá 10+ év tapasztalatunk is), de ami a legerősebb, az az ecosystem. Ezt aki nem java fejlesztő, el sem tudja képzelni: mindenhez van könyvtár, ezek jó része pedig commercial kompatibilis (általában apache) open source. Ez nekünk nagyban megkönnyíti és felgyorsítja a fejlesztést, mondhatni évekkel.

Illetve még egy dolog: vagy tíz éve volt olyan fejlesztésünk, hogy egy brutál nagy SUN-os gépen futott az alkalmazásunk, a kis windows-os gépen lefejlesztettük, majd az összecsomagolt jar file-t felmásolva a Sun-os gépre már futott is az alkalmazás. Ez most lehet, hogy nem tűnik nagy számnak, de igen komoly fegyvertény volt, nagyban megkönyítette a fejlesztést.

> Az önmagában nagyon jó, hogy egy nyelven fejlesztünk,

Ugyanez a node.js. Irj javascriptben mindent:)
Tok objektiven: a javascript all nyeresre.

> de ami a legerősebb, az az ecosystem

Nezz fel egyszer az npmjs.org-ra.
Total Packages: 103 782 (2014. 11. 03.)

Erdekessegkeppen:
20140104: Total Packages: 53 362
20121229: Total Packages: 19 886

> Ez most lehet, hogy nem tűnik nagy számnak, de igen komoly fegyvertény
> volt, nagyban megkönyítette a fejlesztést.

Most mar ez nem nagy szam.:)

Egyebkent minden elismeresem a tieteke. 10 eve, az akkori viszonyok kozott hoztatok egy elorelato dontest: java-val lesz a szerver oldalon a legkevesebb szivas.

Most, igy 2014-ben, ha valakinek (tfh hozzaertonek) feltenned a kerdest, hogy az elkovetkezo 10 evre milyen programnyelvet kellene valasztania, akkor szerinted mit valaszolna?

((
Egy kis segitseg:
- Szerver oldal (programlogika, adatbazis, replikacio)
- kliens oldal (weboldal, guis program, mobiltelefon)

Meg egy kis adalek, van olyan nativ guis program, ami belul egy webbongeszo becsomagolva. Lasd a fentebb linkelt atom.io-t.
))

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Akkor:
Szerver oldal (programlogika, adatbazis, replikacio)
programlogika: ha folyamatkezelés akkor valamely bpmn. aszinkron kapcsolattartásra mqueue
adatbázis: milyen adatok lesznek? adattárház jellegű, adatgyűjtő, általános rögzítő/lekérdező alkalmazás?
replikáció: mit kell replikálni?

kliens oldal (weboldal, guis program, mobiltelefon)
weboldal, gui vagy mobiltelefonos app kell? esetleg mindegyik?

Egyébként meg abban írnám amiben az adott cég infrastruktúrája épül.

Androidra mindig próbálkoznak (C++/#, keresztfordítók stb.), változhat még. Az elv viszont igaz, és csak nyerhet a megismerésével, és amúgy is vannak elterjedő trendek (pl. tervezési minták már olyan nyelvekbe is beszivárogtak megismerésre ajánlottként ahol korábban ez nem volt divat).
A Java mint nyelv talán még nem bicskatörő, viszont mire valaki az egész köré épülő architekturális és egyéb összefüggésekkel képbe kerül, az idő, energia. Ez az aminek a konvertálhatósága kérdéses (keretrendszerek, j2ee megoldások stb.) - mármint a megszerzett tudásé, nem a technikáé.

Ok, igazabol a C++ szepen megy Androidon, de ott is kell egy Javas reteg, ami JNI-n oda-vissza athiv, ha valami csak a masikon elerheto.
C#-os Android fejlesztesre viszont nem alapitanek ceget. :)

--
What's worse than finding a worm in your apple?
Finding a U2 album on your iPhone.

> C#-os Android fejlesztesre viszont nem alapitanek ceget. :)

Lehet, hogy neked van igazad, és a Dow Jones, a Tesco, a Microsoft, a Bosch, a Siemens, a Sennheiser, a National Instruments, a GitHub, a Foursquare és a Trello téved.

Meg persze az is lehet, hogy nekik van igazuk, és te tévedsz abban, hogy C#-ban fejleszteni Androidra nem okos dolog. :)

"Ha mar ismersz egy par programozasi nyelvet, egy ujabbat megtanulni valamilyen szinten nem nagy dolog."

Lyully.
Javaslom neked ezt a kurzust:
https://www.coursera.org/course/proglang

Es akkor meg nem is neztunk egzotikusabb nyelveket, mint pl. Prolog. Van elet a PHP es Java univerzumon kivul is...

SML-t ismerem, Prologot szinten. Teny, hogy kicsit mas gondolkodasmodot igenyel, de nem lehetetlen megtanulni.
Ha ismersz 1-2 imperativ nyelvet, egy par scriptnyelvet, valamilyen leironyelvet, meg egy funkcionalis es deklarativ nyelvet, olyan nagyon nem lesz ismeretlen egyik sem.

(egyebkent irtam, hogy kicsit leegyszerusitettem a dolgot)

--
What's worse than finding a worm in your apple?
Finding a U2 album on your iPhone.

SML-t, Prologot mi is tanultunk, nagyon jó programozási nyelv mind a kettő adott célra, és tényleg másfajta gondolkodásmódot is tanít, amit nagyon szerettem. Ettől
eltekintve mind a Prolog, mind az SML-lel az volt a bajom, hogy nem igazán láttam, hogy lehet bennük programot tervezni és nagy alkalmazást fejleszteni, ráadásul
szerintem a legtöbb problémára, amivel egy átlag fejlesztő találkozik, nem ezek a nyelvek a legjobb megoldások. (sőt, mondhatni ezek rossz megoldások)

OO es tervezhetoseg:

"We observe the various interpretations of overriding and overloading in object oriented languages. With the description of an intend, represented as the following UML diagram, we have "naively" implemented in 15 different languages the same piece of code... and obtenained 11 different results."

http://public.enst-bretagne.fr/~beugnard/papiers/lb-sem.shtml

Ahogy mondani szoktak, a closure a szegeny ember objectje. Helyesebben mondva, az object a szegeny ember closureje (javascriptesek, szevasztok!).

Lasd meg: lexikalis scope es first class functionok. Neked is tudom ajanlani a belinkelt courseras proglang tanfolyamot.

Illetve azon erdemes meg elmelkedni, hogy miert nem hivjak funkcionalis nyelvnek a C-t, holott first class functionokkel (oke, function pointerekkel) rendelkezik.

"az volt a bajom, hogy nem igazán láttam, hogy lehet bennük programot tervezni és nagy alkalmazást fejleszteni"

Tehat foglalkoztal veluk par orat, eljutottal egy kozepes kezdo szintjere, es ennyibol levontad a kovetkeztetest, hogy "rossz megoldasok". Mennyi idot toltottel azzal a programnyelvvel, amit most napi szinten hasznalsz?

Van egy pont, amig el kell jutni a megertesben, es utana tudod csak igazan ertekelni, hogy mi az, ami jo, es mi az, ami nem annyira. Azert furcsa, hogy eggyel kellett volna csak tovabbgondolni pl. az SML-t, es maris kilyukadtal volna az OCAML-nel (lasd: Jane Street Capital), vagy az F#-nal (lasd: Microsoft), mint modern, professzionalis platformoknal -> nalunk sokkal okosabb emberek jutottak arra a kovetkeztetesre, hogy a ceguket ilyen nyelvekben irt szoftverekre alapozzak. Es nem halnak ehen...

"a legtöbb problémára, amivel egy átlag fejlesztő találkozik, nem ezek a nyelvek a legjobb megoldások." -erre nem is tudok mit mondani, annyira altalanos. Az jut rola eszembe, mekkora fizikai fajdalmat okoz pl. egy olyan nyelv utan, amelyben van pattern matching (je, SML!) egy olyat hasznalni, amiben nincs (Java/C#/JS.... etc). Kulonosen szomoru, hogy az "atlag fejlesztonek" eszebe sem jut, hogy barmit hianyoljon, hiszen olyasvalamirol van szo, aminek a letezeserol sem tud (lasd meg Paul Graham esszeit).

De a legjobb, hogy ha a tenyleges munkadban nem is hasznalhatsz mondjuk Clojure-t vagy Haskell-t, szamos olyan dolgot vehetsz at ezekbol a nyelvekbol, amitol minosegileg oriasit javulhat a Java/C# kodod is (pelda: ahol csak lehet, immutable objektumok hasznalata) -> ha ezt nem erted meg (es lesoprod az SML-t azzal, hogy "rossz megoldas"), akkor sajnalom.*

Szia,

végignyomtunk egyetemen egy félévet, tehát azért a pár óránál egy kicsit talán többet kellett vele foglalkoznunk.

Nekem a funkcionális programozással alapvetően nagy bajom nincs, értem mire jó, látom, hogy egyre több elem kerül át a tradicionális oo nyelvekbe.

Mégis, valahogy mégsem ezek a nyelvek terjedtek el, valami oka azért kellett, hogy legyen. Nekem a tervezhetőség az, ami az OO nyelvekben tetszik (a syntactic sugar annyira nem érdekel), és ezt nem látom itt.

Meg mindig nem ertem.

Mindennek, amit felsoroltal, megvan a funkcionalis alternativaja (raadasul sok esetben flexibilisebb/hatekonyabb formaban), meg design patternek is vannak. De mi koze ennek a "tervezhetoseg"-hez?

UML azt hiszem, nincs, legalabbis osztalydiagramnak megfelelo diagram, de nyilvan a tobbi resze ugyanugy relevans marad.

Es persze tesztelni is ugyanugy szukseges.

Ez a pattern matching hasznos valamire? Erlangban láttam ilyesmit, és akkor már egy kicsit húztam a számat; és nem mernék komolyabb refactort csinálni egy ilyen programban, de még egy egyszerűbb átnevezőset sem. De nem is használok ilyet napi szinten, ezért kérdem, ez tényleg annyira jó dolog?

Más: az ilyen interface nélküli nyelvekben hogy oldasz meg egy pluginszerű architektúrát? Most én meg tudom mondani, hogy ezt az interface-t kell implementálni, és aki tudja, az jöhet. Egy ilyen 'valami'-t váró nyelvben honnan tudod, hogy mit kell megírni? Nekem mindig az a bajom, hogy nem tudom csak úgy meghívni a karika metódust xy paraméterrel, mert el kell olvasnom a karika metódus implementációját ahhoz, hogy megnézzem, hogy a paramétereken milyen metódust hív; csak akkor tudom meg, hogy pontosan milyen paramétert is vár.

Egyébként most hogy ez a lambda téma bejött a java-ba, szerintem a kód éppen hogy kezd kevésbé olvashatóbb lenni. De azért használom, hátha megvilágosodom, hogy mitől lett az egész olvashatóbb; de tényleg egyelőre csak tömörebb lett az egész, és nehezebben olvasható.

"Ez a pattern matching hasznos valamire?"

Mi napi szinten használjuk éles projekten, szóval valamire biztos jó. :)

"Más: az ilyen interface nélküli nyelvekben hogy oldasz meg egy pluginszerű architektúrát?"

Ha típusos a nyelv, akkor továbbra is elég egyértelmű. Van típusa a tuple-öknek, függvényeknek, stb. Ez a probléma fennáll egyébként javascript esetén is.

"Egyébként most hogy ez a lambda téma bejött a java-ba, szerintem a kód éppen hogy kezd kevésbé olvashatóbb lenni."

A java8-as lambda kifejezések lényegében olyan anonim osztályok, amik egy metódussal rendelkeznek. Innentől kezdve csak a felesleges sallangot dobták ki. Példa (ami áthúzott, az nem kell, ami aláhúzott, az eddig nem kellett):

Runnable r = new Runnable() {
@Override
public void run() -> {
System.out.println("Hello, World!");
}
};

Just for the record: ha egy utasítás van akkor nem kell a {} pár, illetve ha vissza kell adni valamit és elhagyod a {} párt, akkor nem kell a return kulcsszó sem. Ha a lambda kifejezésnek egy paramétere van, a paraméter köré nem kell kirakni a () párt, illetve a paraméterek típusa elhagyható. Vannak metódusreferenciák is, ezt már inkább nem írom le csak linkelem.

Ja és most nézem elszúrtam, az utolsó ; természetesen marad. :)

Köszi szépen. Azért örülök ennek a java 8-nak, mert bármennyire is kitekintgetek a hobby projekteim miatt más nyelvekre, azért a heti 40 óra javában megy évek óta.

A pythont nézegettem pld (hát igazából csináltam django webappot, meg pár egyszerű dolgot az arduino+raspberry robotomra), és az elvileg egy típusos nyelv, csak ugye a duck typing miatt bármilyen paramétert megadhatsz. Nekem ezzel volt ilyen tapasztalatom, hogy mindig el kell olvasni a hívott kódot is, hogy tudjam, hogy mit is vár. Vagy beleprototype-olni parancssorból. Meg az IDE sem tud hozzá úgy refactorolni, mint egy java forrást. Szóval egy többezer fájlos projektnél, amilyeneken dolgozom, ott számomra ez iszonyat kényelmetlen lenne. Fejben tartani képtelenség, de ha mindig annyit kéne olvasni/prototypeolni, akkor mikor fogok dolgozni?

De gondolom megvannak ezeknek is a trükkjei, amit az ember főleg akkor ért meg, ha nyomja pár évet.

A konstruktor hasznos valamire? A pattern matching pont ugyanaz, csak forditva. A refactoringot eppen hogy megkonnyiti, static typingnel a fordito rogton szol, ha egy uj tipuskonstruktorod van, es barhol a programban hianyzik hozza egy match case.

Minden altalam ismert nyelvben van modul tamogatas (vs "plugin"), az OCAML-ben peldaul first class. Az interface tulajdonkeppen csak egy tipusleiro, sok nyelvben a type inference is onmagaban garantal egy csomo mindent, ha lefordul a programod, Clojure-ben meg ott vannak a protokollok es a multimetodusok... Erlangot sajnos nem nagyon ismerem.

( asch v | 2014. 11. 02., v – 00:36 )

Hol lehet ilyeneket olvasni? Én azt látom, hogy egyelőre csak egyre több dologra lehet használni a Java-t, és teljesen jó irányba fejlődik.

( BaT | 2014. 11. 02., v – 02:37 )

Érdekelne hol olvastál ilyeneket. :)

Szerintem különbséget kell tenni a java mint platform és a java mint nyelv között. Pl. kezdenek népszerűvé válni egyéb jvm-re forduló nyelvek, és a platformon is megjelentek olyan változások amik ezt segítik elő, ezért nem hiszem, hogy ebből a szempontból a java a halálán lenne. Ugyanakkor a java nyelv szerintem nem fejlődik elég gyorsan, még úgy se hogy a java 8-cal azért elég sok újdonság jelent meg benne. De az még hosszú idő, mire ennek hatására a nyelv kihalna, addig pedig akár annak fejlődése is felgyorsulhat.

Így van. Valamikor volt egy cikk, hogy több nagy webes cég is jvm-re/java-ra áltak át a teljesítménye miatt.
http://www.wired.com/2013/09/the-second-coming-of-java/
Lényeg:
"Originally, Twitter was one, monolithic application built with Ruby on Rails. But now, it’s divided into about two hundred self-contained services that talk to each other. Each runs atop the JVM, with most written in Scala and some in Java and Clojure."

( hory v | 2014. 11. 02., v – 14:13 )

Total atalakul. A java8 mar annyira uj, hogy konkretan az ecosystem nem tud lepest tartani vele, a lambda+stream tamogatas hianyzik szinte mindenhonnan. Az obscure-abb feature-okrol ne is beszeljunk, mint a VM-be integralt javascript engine vagy a java9-ben jovo GPU-tamogatas meg modularitas.

Az egyetlen hiba (szerintem), hogy nem dobjak a regi szirszar tamogatasat. Alapvetoen opensource, szoval akinek Vector meg Hashtable,... kell, az szepen hasznal 1.5-os JRE-t, mi a szoszert hagyjak ezt benne a mai napig? Meg a visszafele kompatibilitas is kicsit tul van lihegve; megintcsak, opensource, szoval nyugodtan fordithat + futtathat barki egy 1.5-os jdk egy mai szerveren, ergo tokmindegy, hogy nem 100%-os a kompatibilitas, kell hozza nemi munka.

A valasz roviden: java marad, ahol van, de durvan atalakul lassan. Melle jonni fog vagy a javascript, vagy egy javascript-utod (mivel a JS elegge atgondolatlan es bovithetetlen). Sokan mar ma is full-JS -t hasznalnak: szerveren node.js, kliensen egy kover JS-kliens. Igy a koderek teljesen a JS-re tudnak fokuszalni (design, best practice, patterns, library-k, ...), ami jobb/minosegibb kodot eredmenyez.

Vannak kommerciális mammut szoftverek, amiket ügyesen Java-ban sikerült írni. Mivel a behemót multi nem frissíti úgy a kódot - amit azóta amúgy is átírtak .NET-be - ezért kénytelen vagy régi, lukas java-t telepíteni a gépekre, hogy fusson. Ha kell az új, akkor fizess 600 milliót. Lassan olyan érzés már, mint régen, amikor DOS kellett néhány célszoftvernek.
A backward compatibility néha azért jól jön...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

De ki akar JS-t programozni kezzel? Pont olyan kinszenvedes, mint Javat, csak maskepp.

Az biztos, hogy a Java es a Javascript nyelv is atalakul egyfajta VM-es assembly-ve, tekintettel arra, hogy JS VM es/vagy Java VM gyakorlatilag barmilyen platformon elerheto. Es a kovetkezo lepcsofok azok a nyelvek, amelyek Java-ra (bytekodra vagy forrasba - vegulis nincs nagy kulonbseg) vagy JS-re fordulnak. Esetleg mindkettore: lasd Clojure.

JS kezzel? siman. node.js, bower, grunt, nomeg tobbtucatnyi JS lib all rendelkezesre. A nyelv kicsit fura valoban, de olvasd el az 'OO javascript' konyvet es van megoldas szep, ertheto kodot irni ra. Unit test, selenium test szinten van.

Kliens mindenhol, es hala a JIT-compileres VM-eknek, es persze az egyre durvan erosebb desktop-nak, igen-igen erosek, nyugodtan lehet rajuk hagyni, amit csak lehet.

"Igy a koderek teljesen a JS-re tudnak fokuszalni (design, best practice, patterns, library-k, ...), ami jobb/minosegibb kodot eredmenyez."

Egyszer (minden irónia nélkül) úgy megnéznék egy Szépnek mondott JS projectet. Tudtok egyet ajánlani, amiből meggyőzhető lennék, hogy lehet JS-ben is olvashatóan fejleszteni?

+sok... az egyik nagy kedvencem, amikor van egy library, ami publikus interface-n keresztül visszaad egy objektumot, de a doksiban természetesen nincs leírva, hogy annak az objektumnak milyen metódusai és milyen változói vannak... viszont hogy használni tudd a libet, szükség van rá.

Aztán amikor library-t updatelsz, az eddig működő kód hirtelen nem megy - persze csak futási időben derül ki.

Ezek után a typescript nem is egy akkora hülyeség...

Azert node.js-nel ott az npm, ami ezt az egeszet eliminalja is.

Vagy azt akarod allitani, hogy javanal soha semmilyen jovobeni inkompatibilitas miatti bug nem johet be, mert forditasi idoben mar kiderul?

Es akkor eljutottunk oda, hogy egy java program csak egy adott verzioju jvm-mel fut....

De ettol meg crossplatform a jvm (crossplatform = windows+macosx+linux+solaris) :)
Az hogy verzio erzekeny, az oracle-os java es az openjdk koszono-viszonyban sincs, az senkit se erdekel.

En ertem, hogy szerver oldalon baromi kenyelmes, rengeteg beepitett konyvtara van (bar ha belenezel a forrasaba, akkor assemblyvel vetekszik a java kod).
De szerver oldalon mindenki azt hasznal, amit akar. Max adsz neki egy virtualis gepet, ha tenyleg valami egzotikum.

Ettol meg a java rengeteg sebbol verzik.
Es eddig en csak a hatranyait lattam elonykent beallitva.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Már bocs, de az npm hol is oldja meg nekem ezt a problémát? A probléma a javascriptben, mint nyelvben van (nincs igazából class).

Egy java program általában egy adott fő verziójú jvm-mel (pl. 7), vagy annál újabbal fut.

Oracle java és az OpenJDK az a 7-estől (vagy 8-astól???) kezdve tök ugyanaz, mivel az a referencia implementáció.

Assemblyben kódoltam, java-ban 10 éve kódolok, nem összehasonlítható.

Már bocs, de az npm hol is oldja meg nekem ezt a problémát? A probléma a javascriptben, mint nyelvben van (nincs igazából class).

Lehet, hogy a problemat latjuk ketfele keppen.

* Te azt mondod, hogy egy nyelv nyelvi szinten adjon megoldast arra, hogyha egy library jovobeni verzioja inkompatibilis a programoddal.

Ebbol kovetkezik, mivel a java halom builtin lib-bel jon, hogy a programod kvazi csak adott java/jvm verzioval fut.

* Erre a node.js haza tajan az a megoldas, hogy van egy csomagkezeloje az npm.
Magyaran, amikor irsz egy programot, akkor listazod a fuggosegeidet a package.json fajlban, es ott konkret verziot irsz bele (ez a best practice, a *-ozast el kell felejteni:).
A verziokovetesre (magyaran egy libbol van-e ujabb), arra van megoldas.

Egy java program általában egy adott fő verziójú jvm-mel (pl. 7), vagy annál újabbal fut.
általában... Ezt akkor hagyjuk is ennyiben: általában.

Assemblyben kódoltam, java-ban 10 éve kódolok, nem összehasonlítható.

Sajnos nem. Ez egy pejorativ kifejezes volt.
Arra akartam utalni, hogy ahhoz, hogy a java ertelmes sebesseggel futhasson, rengeteg builtin konyvtarat olyan kriksz-krakszosan irnak meg, hogy egy normal java programozonak assemblykent hat.
Magyaran ugy megeroszakoljak a nyelvet, hogy szinte serto:)

Persze nem assembly. Az assemblyben sokkal szebben lehet programozni:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Szerintem elbeszélünk egymás mellett.

1, Én azt mondom, hogy ezzel van itten a probléma:

var x = myLib.getData();

ezután honnan a szent tehén tőgyéből derül ki, hogy az x-nek milyen változói vagy metódusai vannak,
hogy a könyvtár írója a következő verzióban nem vesz-e el 2 változót, és ad hozzá 3 metódust?

Ez az, ami csak futási időben derül ki. Az égadta világon nincs semmi garancia arra, hogy ha csak egy minor verziót is vált a könyvtár, akkor a kettőnk között definiált interface is ugyanaz.

2, azért általában, mert voltak olyan változások, amik inkompatibilissé tették a verziók között, de ezen változások csak nagyon kevés alkalmazást érintettek (átnézve a saját 10+ éves kódbázisunkat, nálunk nem volt ilyen).

3, most a külső könyvtárakról, vagy a belsőkről beszélünk? A belső könyvtárak rommá vannak optimalizálva, de azokba nem kell nézelődni, mert minek. Van egy jól definiált interface, egy nagyon jó dokumentáció, használni kell. De ha esetleg konkrét példával jönnél elő, úgy lehet, hogy érthetőbb lenne, hogy neked mivel volt bajod....


var x = myLib.getData();


ezután honnan a szent tehén tőgyéből derül ki, hogy az x-nek milyen változói vagy metódusai vannak,
hogy a könyvtár írója a következő verzióban nem vesz-e el 2 változót, és ad hozzá 3 metódust?

1. Erre a megoldas az, hogy a programodat ugy irod, hogy megadod, hogy milyen verzioju libekkel fut.
2. A libeket ellenorzod (automatikusan), hogy a legujabbak-e.
3. Teszteket irsz (travis-ci.org/com pl.), es amikor a libbel verziot ugrasz, akkor rogton kibukik ha inkompatibilitas van.

Szerintem a fenti problemara (magyaran egy library fejlodik), sokkal jobb megoldas, amit most a node.js nyujt.
Ettol persze igazad van, a javascript nyelvi szinten erre megoldast nem nyujt. De nem is a dolga, mivel van ra jobb megoldas.


2, azért általában, mert voltak olyan változások, amik inkompatibilissé tették a verziók között, de ezen változások csak nagyon kevés alkalmazást érintettek (átnézve a saját 10+ éves kódbázisunkat, nálunk nem volt ilyen).

Ez a szerveroldal. Most vegyel elo egy random kliens oldali java programot 10 evvel ezelottrol es probald futtatni.

3, most a külső könyvtárakról, vagy a belsőkről beszélünk? A belső könyvtárak rommá vannak optimalizálva, de azokba nem kell nézelődni, mert minek.

En a belsokrol beszeltem, es hoztam fel peldanak.

Az egesz Hevi hozzaszolasabol jott, ahol o ezt irta:
Egyszer (minden irónia nélkül) úgy megnéznék egy Szépnek mondott JS projectet.

Erre megjegyeztem (ironikusan), hogy a java belso konyvtaraitol (ami alapban jon, tehat annak kellene a legszebbnek lennie:)) kifolyik az ember szeme:) Kb. mintha assembly-t olvasna.

Erre mondtad, hogy az assemblyre nem is hasonlit:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

> Téged tudlak idézni: "Es akkor eljutottunk oda, hogy egy java
> program csak egy adott verzioju jvm-mel fut...."

Csakhogy a node.js-nel a libek kulon csomagkezelovel letolthetoek, projektenkent.
Nincs bundle, mint javanal.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Es a JS runtime? Egy V8 update elronthatja az egeszet (ha mar JVM-rol volt szo a Java oldalon).

Az ECMAScript 5, 6 es 7 kozott jelentos nyelvi kulonbsegek vannak, es ott is megy a "hogyan legyen a nyelvben olyan uj funkcio, ami nem tori el a regi kodokat" dolog, lasd peldaul a use strict; hasznalanak modjat.

Az egyes libek Javaban pedig reg megoldott problema, lasd Maven.
Az npm a CPAN-bol meritett, amikor letre lett hozva, nem a Node.JS talalta fel azt a dolgot, hogy csomagkezeles.

Meg kene kulonboztetni a VM, VM-hez adott default runtime es az egyes 3rd party library fogalmakat, es akkor lehetne beszelni kompatibilitasrol.
Masreszt fontos dolog (ez JS-nel nem letezik) a binaris/forras kompatibilitas.
Egy app lehet forrasszinten kompatibilis, akkor is, ha binaris szinten nem kompatibilis. Stb.

> Es a JS runtime? Egy V8 update elronthatja az egeszet (ha mar JVM-rol volt szo a Java oldalon).

Mivel tipikusan forrasfajlod van .js oldalon, igy nem egy .jar jvm binarist kell eletrekelteni.

Az ECMAScript 5, 6 es 7 kozott jelentos nyelvi kulonbsegek vannak, es ott is megy a "hogyan legyen a nyelvben olyan uj funkcio, ami nem tori el a regi kodokat" dolog, lasd peldaul a use strict; hasznalanak modjat.

Ez egy erdekes dolog, hogy fobb nyelvi valtozasok hogyan fognak lecsapodni library oldalon. (szerintem nem gond, mivel adott verziora dependelsz). De ez a jovo zeneje.

Az egyes libek Javaban pedig reg megoldott problema, lasd Maven.
Az npm a CPAN-bol meritett, amikor letre lett hozva, nem a Node.JS talalta fel azt a dolgot, hogy csomagkezeles.

A node.js nem talalt fel semmit ami azelott ne lett volna.
Kb. ugy, ahogy a github.com sem talalta fel a git-et.
De nepszerusegi listat vezet mindketto, es jol korulhatarolo oka van.

En az egesz szalban csak arra reagaltam,
hogy javascript igenis alkalmas nagy rendszerek osszekalapalasara.


Meg kene kulonboztetni a VM, VM-hez adott default runtime es az egyes 3rd party library fogalmakat, es akkor lehetne beszelni kompatibilitasrol.

Mivel a node.js konkretan nulla libbel jon, igy ez a kerdes nem olyan eros, mint java eseten.
(Bar igaz, hogy node.js add nehany default objektumot, de az nem library).
Egy sima telnet szerverhez is tcp library-t toltesz le node.js-nel.

Az, hogy a kodod fut-e ujabb V8 runtime-nal, szerintem eroltetett hasonlat, mivel itt forraskodban vagy tipikusan. A library-ket meg frissitik, ha valami olyan lenne (ha meg nem, akkor valtasz library-t).

Masreszt fontos dolog (ez JS-nel nem letezik) a binaris/forras kompatibilitas.

Es ez egy fontos fegyverteny.


Egy app lehet forrasszinten kompatibilis, akkor is, ha binaris szinten nem kompatibilis. Stb.

Ez a problemakor fel se merul.

Persze en nem azt mondom, hogy a node.js a mindenhato, es minden mas eltunik a sullyesztoben.

En mindosszesen ezeket allitottam:
- node.js-ben igen komoly (vallalati, ha ugy tetszik) rendszereket ossze lehet hozni.
- van nagyon eros "ecosystem", library tamogatas. Barmit meg akarsz oldani, valoszinu, hogy van mar ra library a 100k kozul.
- "beepitett" csomagkezelo, ahol a verziozas problematikaja megszunik.
- terjed, mint a futotuz
- alkalmazhato ugyanaz a nyelv mindenhol (szerver, kliens), mindenfele programhoz (akar guis programot is lehet irni vele).

Ettol meg rengeteg programnyelv letezik, es fog letezni a jovoben, es nem kell egyiknek se kihalnia.
De teny, hogy a node.js legalabb akkora buzzword most, mint 10 eve volt a java.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

"van nagyon eros "ecosystem", library tamogatas. Barmit meg akarsz oldani, valoszinu, hogy van mar ra library a 100k kozul."
Nem ettol eros egy ecosystem. Hanem attol, hogy X+k ev mulva is lesz a projekt mogott valaki.

Csinalunk mi is JS alkalmazast (egy elegge durva in-house SPA), es csomo library mar outdated, nem fejlesztik, az uj futtatokornyezetben nem mukodik (a HTML/CSS/JS enginek akar havonta valtozhatnak...).
Ket opcio van: keresni egy masikat (hatalmas ido atallni ra) vagy forkolni es karbantartani (nincs ra eroforras).

Mig mondjuk az Apache Software Foundation fobb cuccai mar nagyon sok eve leteznek es letezni is fognak.

Az nem ecosystem onmagaban, hogy mindenre van otezerfele megoldas.

Igazad van. A node.js nagyon fiatal, ezek a dolgok ki fognak alakulni korulotte. (amiben lehetoseg van, oda ceg is szuletik).

Az, hogy a library-k jonnek-mennek, hat az egesz webre igaz ez.
Fejlodik mint a fene, sokan lemorzsolodnak.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Az npm a java világban a maven vagy gradle-nek felel meg, amit itt leírtál azt egy java projecten is össze lehet hozni. Viszont a java typesafetyje ad egy olyan plusz védőhálót, amit javascriptben nem kapsz meg. De mi van akkor, ha a projekten belül kezdesz el refaktorálni? A gyakorlatban a 100% coverage nemhogy nem jellemző, gyakran inkább a kivitelezhetetlen kategória. És persze olyan sincs, hogy egy teszt nincs elszúrva... Sőt, eleve könnyebb egy refaktor után úgy utánahúzni a teszteket, hogy nem is fordul a kód amíg hozzá nem nyúlsz az érintett tesztekhez.

"Oracle java és az OpenJDK az a 7-estől (vagy 8-astól???) kezdve tök ugyana" 7es verzióval jártam már úgy , hogy lassan ment az app, meg az IDE is a gépemen, vagy úgy, hogy az app amit fejlesztettem exceptionnel elszállt, aztán kiderült, hogy egy frissítés a java defaultot átállította openjdk-ra.

-
Groovy funkcionális eszközök

> A probléma a javascriptben, mint nyelvben van (nincs igazából class).
Hűha, kezd magas szintre emelkedni a diskurzus.

Ez önmagában nem indok. Sok probléma van a JavaScripttel, de ha a nagyok érvelését megnézed ellene (vagy mellette), ilyen butaságokat nem fogsz látni köztük. Nagyon sok nyelvben "nincs igazából class", és mégis milliárddolláros üzletek alapulnak rajta.

Egyik kedvencem 204 sor. Az az arguments, na az honnan jön és mi van benne. Amíg ilyet lehet csinálni, és csinálnak is kedves Js fejlesztők, addig köszi nem köszi! Ráadásul ez a Addy Osmani nem is olyan hülye gyerek, yeoman meg chrome dev tools fejlezstő többek között.

-
Groovy funkcionális eszközök

> Egyszer (minden irónia nélkül) úgy megnéznék egy Szépnek mondott JS projectet. Tudtok egyet ajánlani,

https://github.com/atom/atom

> amiből meggyőzhető lennék,

Erosen ketlem, hogy teged barmilyen kod meggyozne...
De egy probat meger... Magas labda volt.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( Dwokfur v | 2014. 11. 02., v – 14:29 )

Érdekes felvetés. Mondjuk a Cobol a maga idejében nem terjedt el okostelefonokon és routereken.
Örülök, hogy a C++ kicsit kezd visszajönni.

Egyébként meg:
http://www.youtube.com/watch?v=XHosLhPEN3k

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( haspokember | 2014. 11. 02., v – 14:33 )

Java mint nyelv?
Java mint JVM?
Java mint ecosystem (az elerheto libraryk, programozasi nyelvek a jvm-en, stb)?

Backend, frontend? Android? stb.

Tehat a kerdesedre a valasz egy hatarozott IGEN.

( VincentV | 2014. 11. 02., v – 15:46 )

Bevallom én csak kliens oldalon és felhasználói/üzemeltetői szinten találkozom a Javaval, de ott hányok tőle, és nem ismerek senkit aki hasonló cipőben jár és ne hányna.

Ha a kezem ügyébe akad egy vas, aminek a management felületét megnyitva azt látom hogy jön egy java applet, már szorul is ökölbe a gyomrom, és érzem hogy itt nem lesz érdemi munka/konfigurálás a következő fél órában, mert Java kompatibilitási és sceurity hibaüzenetek után kell majd guglizni.

Hányok a netbank java appletjétől, hányok a szerverek KVM és management felületétől, a storagek hasonló javas szarjaitól szintén. Folyton hackelni kell kliens oldalon a jvm-et, ha csak egy 1-2 évvel régebbi random appletet akarok futtatni, mert éppen azt tolja az arcomba egy blade management szarja. Értetlenül nézzük ezeket, és napi szinten szopunk velük, Windows XP-ket kell tartani virtuális gépben régi java-val, hogy egy régebbi fibre channel switchhez egyáltalán hozzá tudjunk nyúlni, vagy éppen az amúgy jól működő és "csak ezért nem cserélem le 2 millióért (tm)" sok portos KVM-hez. És még sorolhatnám.

A Java fejlesztők leírták fent, hogy miért szeretik, miért jó, el is fogadom, lehet hogy én is szívesen fejlesztenék Java-ban ha úgy hozná az élet. Szóval nem akartam senkit megbántani, a fenti kifakadás inkább csak amolyan "blog". Felhasználói oldalon szerintem ez a Java legnagyobb baja, még a nyomorult Flashben is több konzisztenciát, kompatibilitást és következetességet érzek/tapasztalatok, pedig az se egyszerű eset.

+sok
Üzemeltetőként pont ugyanigy érzek. Kész katasztrófa, ha egy java-s frontenddel kell bármilyen interakcióba lépni, szinte garantált a szopás. Minden egyes java frissitésnél azon kell izgulni, hogy mit csesz szét.

Bár én fejlesztőként is csak a hátrányait látom, nagyon-nagyon kevés előnnyel.

Kedvenc sztorim az, amikor volt még SUN, és került hozzánk valamilyen opetronos Sunfire, nem emlékszem már hogy melyik. Természetesen beépített Javas KVM felülettel. Az aktuális Javaval nem ment, firmware frissítés meg nem volt. Na mondom ez jó buli lesz, mert hát a vas pár napja került a piacra, felhívom őket :) Mondtam nekik, hogy minden a legfrissebb mindenhol, és hogy nem tudok a mellett elmenni szó nélkül, hogy TI ADJÁTOK az összes szoftvert ami ebben a problémában részt vesz, tán akkor csak van valamiféle megoldás :)

Végül hosszas levelezgetés és pár telefon után megszületett a válasz: ha van standalone IP KVM-ünk, akkor használjuk azt :D

Ja, az az ág remélhetőleg hamar kipusztul. Mondjuk én nem is arról beszéltem, sose írtam még appletet (na jó, talán egyszer, még suliban), de nem is kell. Én rögtön szerver oldalra asszociáltam, mert Java backend + bármimás frontend sokkal elterjedtebb, mint az appletek.

Flash/Flex nagyon jó volt, kár, hogy kipusztult weben (ezért sem szeretem a JS-t, nagyon hozzászoktam az ActionScript3-hoz, ami szintén ECMAScript).

Hát, túl jó hírem nincs.
- az appletek valóban szarok
- a flash is
- a google elkezdte a GXT/GWT-t, ami java-t javascript-re fordít. Az elképzelés nem rossz, de a megvalósítás még utoljára amikor használtam csapnivaló volt
- a javascript az assembly-re kísértetiesen hasonlít

Eddig ezekkel a web framework-ökkel találkoztam, egyik bénább volt, mint a másik. Nekem talán a GXT/GWT tetszett a legjobban, 10-es skálán 3-at adnék neki, a többi alatta van.

Egy matematikai arányról van szó: befektetett munka / kód minőség.

Minden szaron lehet jó minőségű kódot írni hatalmas munkával.

A kérdés ugye az idő és ez az ami a Nokia vesztét jelentette. Az arányszám Symbian esetén minimum 3-4-szerese volt az Android-nak. Mialatt a Google megírt 3 alkalmazást, a Nokia 1-et. Ez az igazi versenyhátrány, amit képtelen volt a Nokia lefaragni. A fejlesztők utálták a Symbiant, kevés ember ment arra a munkára, ezek többe is kerültek, emellett lassabban is haladtak.

Teljesen egyetértünk, csak amire reagáltam az volt, hogy ha valaki appletet ír, és emiatt a felhasználóknak fel kell tennie egy plugint, ami meg lehet hogy csak bizonyos böngésző bizonyos régebbi verziójával működik, és még azon sem adja meg "native desktop érzést", akkor azt a felhasználók okkal fogják rühelni.

Amúgy
- GWT: elég jó, csak nagyon el lett bonyolítva pl.: az MVP része. Meg a fejlesztéshez kell böngésző plugin, amit ráadásul a Firefox 26-os verziójátol nem is támogatott, a Chrome plugin, meg egy bugos lassú szar (ez a GXT-t és a SMARTGWT-t is érinti)
- GXT: Jól indult a fejlesztés, de mostanában igen belassultak a fiuk a Sencha-nal (talán személyi okai lehetnek). Nem történik semmi azon a környéken
- Smart GWT - ezt használjuk mi a fejlesztéshez (nem az ingyenes verziót) - nagyon hatékonyan lehet benne alkalmazásokat fejleszteni, egyetlen gondom vele, hogy javascriptben vannak írva komponensek, emiatt a kliens oldali debugolás néha problémás, valamint a mobilos része béta

A superdev mód, hát próbáltam de nem nagyon jött be.

Más: közben eszembe jutott az abevjava, és vissza szeretném szívni amit az appletekről írtam :). Bár vegyesek az érzelmeim, mert azért valahogy csak sikerült beküldeni vele a bevallásomat. :)

Szia,

haha, mi is kb. pont ugyanezt csináljuk. GWT az jó, viszont superdev módon kívül máshogy már nem lehet használni, nekem viszont - SSD-vel - nagyon bejött,
teljesen jó. Az új GWT-ben ráadásul sokkal-sokkal gyorsabb lesz az egész, illetve vissza fogják hozni az ide integrációt is.

SmartGWT-vel pontosan ugyanez a tapasztalatunk, mint nektek (amikor a bazi nagy javascript vackukat kellett debuggolni, az nem volt vicces).
A mobilos rész mennyire használható? Én most azon gondolkozom, hogy lehet, hogy le kéne váltani valamire, de még nem igazán találtam meg
a megfelelő megoldást. Nyitottam is egy topicot a témával kapcsolatban:

http://hup.hu/node/136532

A mobilos részével szívás van, bár mi sem használtuk túl komoly dolgokra, de változatos hibákkal lehet vele számítani, és szerintem a közösségi támogatása (megtalálod fórumokban a megoldást), sem túl erős. Szóval óvatosan vele!
A Smartgwt-ben nagyon szeretem a SmartClient Developer Consolt ami a control-q bill. kombinációval jön elő.

( mhmxs v | 2014. 11. 03., h – 09:45 )

Ha meg is hal a Java ebben a szent pillanatban, 10-15 évig még lesz igény Java fejlesztőkre, és az idő múlásával egyre több fizut is remélhet a delikvens :) így én a mgelévő Java tudásommal nem parázok ezen. Ha most kezdenék nulláról, valószínűleg akkor is a JVM alapú megoldásokat preferálnám (biztos fanatizmus), mert a JVM jó dolog, és létezik rá egy csomó nyelv.

Memória fogyasztásra reflektálva architektúrájából kifolyólag több memóriát emészt fel (szerver oldalon értem, mivel ezt érzem a legerősebb területének). Egy terheletlen PHP szerver memóriafogyasztása elég alacsony, mígy egy terheletlen Java szerver memóriafogyasztása igen magas (főleg ha min és max memória ugyanarra az értékre van állítva, ami nem mellesleg best practice). A kérdés az, hogy terhelés mellett mi történik. Persze nem gazdaságos, ha a vállalat 300 nem terhelt Java alkalmazást hostol, hiszen mindegyik megeszi a neki szánt memória 100%-át (erre lehet megoldás pl közös konténer használata).

Úgy gondolom, hogy hosszú karbantartású, nagy terhelésű, skálázható alkalmazások fejlesztésére az egyik legalkalmasabb platform. Főleg ha nincs külön részleg a produkciós csapat és az általa használt platform támogatására.
-
Groovy funkcionális eszközök

( NevemTeve | 2014. 11. 03., h – 09:54 )

Mi az, hogy vagy? Lehet, hogy mindkettő megtörténik. Manapság a nyelvek 'kacsasünpáva' alapon fejlődnek (avagy: 'mindentbele'), még pár év, és a C++ részhalmazként fogja tartalmazni a LISP-et.

( ssikiss | 2014. 11. 03., h – 15:36 )

Ez valami flametopic?
Mert másra nem jó.

Minden topik, ami a Java-ról szól, flame topik, mert:

  1. Előjön, hogy a Java lassú, a C++ meg gyors
  2. Előjön, hogy a Java memóriazabáló, a C++ meg nem
  3. Előjön, hogy a Java mégsem platformfüggetlen, mert a C++...izé.
  4. Előjön, hogy a Java OOP, az OOP meg szar, mert csak a funkcionális a jó
  5. Előjön, hogy a Java nem jó, mert ma már mindenki webre fejleszt

Az Abevjava Magyarország államaparátusának programozói teljesítménye.

Ha még ők se tudják normálisan megírni, akkor biztos a javaval van a baj!

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( kmARC v | 2014. 11. 05., sze – 15:28 )

Valahol lejjebb a node.js, vagy úgy általában a JavaScript jósága/elterjedtsége/akármije volt vita tárgya, nem tudom hova illessszem be, így ide teszem:

http://githut.info/

Ezen a linken jelenleg az látható, hogy a világ legelterjedtebb kódmegosztó oldalára (gyakorlottabbak kedvéért: github) feltöltött legtöbb kódsor JavaScriptben íródott.

Ez persze nem cáfol, és nem is támaszt alá semmit, csak úgy idekopiztam.

Marmint a publikus kodok legtobbje JS :)

Nyilvan nem cafol es nem tamaszt ala semmit, de azt azert jo tudni, hogy felmeresek szerint a kodok 95%-a in-house fejlesztes.

Meg egy Java szopas, amit a Java 5-ben javitottak: Memory Model (ez volt az elso nyelv, ahol ez definialva lett), illetve mindenfele szinkronizacios primitiv. Ugyebar van a java.util.concurrency es tarsai packageben levo josagok, meg vannak a regi dolgok (synchronized).
Persze lehet sokat szopni legacy Java koddal (amikor meg nem volt generics, stb.) de a kompatibilitas miatt sajnos a legacy cuccok (azaz amiket 1993-ban terveztek) meg mindig resze a publikus API-nak.
Ami egyszer API resze lesz, az az is marad.

En a google mindenfele kapcsolatat a programozassal akkor utaltam meg, amikor megszuntette a codesearch.google.com-ot.
Kellett egy 3 ev, mire ezt az urt a github be tudta tolteni.
Bar a github keresoje elegge egyszerusitett. Nem lehet fajlnevre, es fajl tartalomra keresni egyszerre...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( Csab | 2014. 11. 05., sze – 16:21 )

Fordítva is fel lehet tenni a kérdést. Vajon a C# lesz-e a következő COBOL?

- mai trend: a PC szegmens drámaian szűkül
- a telefon/tablet szegmens Android-ot használ, amin java származék fut
- szervereken a .NET meg sosem volt vezető helyen

Szerinted a C# sikeressege valaha is kerdeses volt?

Vagy ugy altalaban a MS altal lekoppintott es windows-onlyva tett dolgok valaha befutottak?

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( franklin | 2014. 11. 05., sze – 22:41 )

Hiába, csak döntöttem, és elkezdem tanulni és belevágtam a melóhelybe ahol használják is.

Kissé átláthatatlannak tűnik most így elsőre. Gondolom amit a memory leak-ekről olvastam az nem véletlen. Van pár dolog amit nem értek még, de majd olvasgatok (D.I.Y. research).

És amúgy is. Steve Jobs összeveszett a JAVA-sokkal, nem támogatja, most tessék mi történt és ugye hol jár az Apple. Meg lehet nézni. Bezzeg akik maradtak a JAVAnál! ;)

Ezek után azért egy kis viccet is hozzá:

http://www.youtube.com/watch?v=Mk3qkQROb_k

Na ez aztán a LOL ahogy mondanák a fiatalok (mondom ezt én, egy még 35 körüli "öregúr" ;) )