Tapasztalatod szerint a Scala már alkalmas nagy projektekhez?

 ( szniki | 2012. május 1., kedd - 10:11 )
Természetesen, miért ne lenne az?
13% (17 szavazat)
Igen az, de csak nem teljesítménykritikus alkalmazásoknál
5% (7 szavazat)
Igen az, de csak nem skálázódó alkalmazásoknál
3% (4 szavazat)
Erősen ellenjavallt
11% (15 szavazat)
Egyéb
68% (91 szavazat)
Összes szavazat: 134

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

http://www.scala-lang.org/node/1658

----------------------
while (!sleep) sheep++;

Ez az az információ ami pont nem segít semmit sem, mert az ilyen írások csak a marketingről szolnak, az árnyoldalról semmit. Említhetném például a kritikán aluli IDE támogatást ami ritkán van hirdetve. Hogy van-e ezen kívül más is, arra remélem jön pár válasz.

Esetleg a negatívumokról érdekes lehet az alábbi cikk: Yammer Moving from Scala to Java, vagy David Pollack (egy Scalas web framework -lift- elindítója) véleménye:Yes, Virginia, Scala is hard, Scala use is less good than Java use for at least half of all Java projects, illetve ez a kérdés: Is the Scala 2.8 collections library a case of “the longest suicide note in history”?. (Nem feltétlen ezek a legfrissebb vélemények.)
Szerk: még egy - David Pollak and Dick Wall Discuss Barriers to Scala Adoption/szerk.

Mindemellett én ajánlani tudom a megtanulását, igen sokat fejlődhet közben az ember. Hogy egy nagyobb projekthez alkalmas-e? Persze, ha a projektnek nincsenek ellentmondó feltételei. :) Mindenesetre részleteihez szerintem alkamas lehet. (Például ha csak kezdetben a teszteléshez használják a programozók -JVM-re fejlesztést feltételezve-, már akkor is sokat adhat, elég csak a ScalaCheckre gondolni. Gondolom a Groovy is hasonlóan jó lehet erre a célra, de ott a refactor kissé problémásabb lehet.)

Én arra is kíváncsi lennék, hogy hányan ismerik, illetve használják? :-)
Természetesen itt a Hup tagokra gondolok.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

POC projektre mar hasznaltam. Elkepeszto szep kodot lehet gyartani vele, irritallo ha debugolni kell.

Tapasztalatok eddig:
- dokumentacio hianyos
- syntax-ot szokni kell, foleg java utan
- egy komolyabb library source szintu ertelmezese gyakorlatilag feler egy kodfejtessel (twitter open source cuccokat hasznaltam, csak alap doksi van, minden mast source-bol kell(ene) kiturni. kb mint zuzu petas-al beszelgetni)
- kezdeti energiabefektetes igenye magas a nyelvnek (i.e.: nehezebben tanulhato pont a kulonbozo vilagok - oo/funkcionalis - keverese miatt) elvileg ez kesobb ez megterul, meglassuk. (java _es_ python ismerettel ez jelentosen egyszerusodik)
- IDE egesz hasznalhato manapsag (ez hetrol-hetre valtozik, ha fel eve lattad utoljara akkor erdemes ujra megnezni)
- sbt: no comment. typesafe is rajott mar, lesz alternativ build tool amit supportalnak.
- par ceg azert hagyta ott a scala-t mert ha "scalasan" kodolsz (vagyis erosen funkcionalisan) akkor sokkal lassabb lesz az eredmeny mint java-ban.

Kicsit kettos erzeseim vannak a nyelvvel kapcsolatban, fejleszteni hihetetlen jo, debugolas kozben pedig mar tobbszor majdnem kivagtam a monitort az ablakon. Alapvetoen jo iranyba halad a dolog, ha lesz stabil debugger IDE-ben akkor valoszinuleg egy nagyon jol hasznalhato nyelv lesz belole.

tfe, erről az sbt vs typesafe vonalról van valami további infód? én még nem láttam sehol h kukáznák.

voltam hivatalos trainingen, typlesafe-es eloadotol kerdeztem hogy mi a helyzet az sbt-vel. annyit mondott hogy a jovoben varhatoan valami egyeb build toolt is tamogatnak majd mert erzik az ellenallast az sbt-vel szemben.
amugy probaltam buildelni sbt/maven/gradle harmassal scala kodot, gradle-nel maradtam. nagyjabol eg es fold a kulobseg sbt-hez kepest hasznalhatosagban.

zuzu petals

Vagyis csunya, olvashatatlan a kod, es nehez debugolni.

Mivel egy adott kodot nagysagrendileg tobbszor olvasnak, es hosszabb ideig tartjak karban, mint irjak meg eloszor, ezert "erosen ellenjavalt" kategoria.

Ha ehhez meg hozzavesszuk, hogy a funkcionalis resz nincs rendesen optimalizalva, igy mar csak egy nyelv az ut szelen. Igazabol, mivel statikus tipusos, Haskell meg Clean kozeli sebesseget lehetne elerni.

,,Vagyis csunya, olvashatatlan a kod, es nehez debugolni.''
Hmm, ez a kép nem tudom, hogy mi alapján alakult ki benned. A kód szerintem igen kellemes az esetek többségében. Nem feltétlen kell a Scalaz-vel kezdei az ismerkedést. ;) A nehéz debuggolni résszel egyetértek, bár épp nemrég jelent meg a ScalaIDE 2.1 M1 verziója, melyben már erre is elkezdték a gyógyírt fejleszteni. :) (Természetesen ha a funkcionális szárny hívőjét kérdezed, akkor valószínű, hogy a következő kérdéssel válaszol: Te szoktál debuggolni? Ha a nagyon párhuzamos, többszálú oldalról keresel valakit, az biztosan a logolást ajánlja, a debuggolás helyett, úgysem valószínű, hogy a kódját pont olyan állapotban találod, ami érdekes lehet. Természetesen a normál imperatív programozáshoz jól szokott jönni a debug.)

,,a funkcionalis resz nincs rendesen optimalizalva''
Ez így van -részben. Nincs minden részletében optimalizálva, bár ezt inkább az imperatív részen szokták észrevenni a felhasználók (a ,,for ciklus'' esetében a leggyakrabban). Erre a makrók jelenthetik majd a megoldást. Természetesen a leginkább kritikus problémákra már most is vannak külső compiler pluginek. (Például ha nincs kedved lencséket (lens) gyártani, akkor ott a Lensed.) Mindenesetre szerintem az aktuális funkcionális (perzisztens) adatszerkezetek már most is kellően optimalizáltak. (Alioth: clean, GHC. Nem feltétlen funkcionális megoldások versenyeznek itt a Scala oldalról, de talán ez is a lényeg... Választhatsz.)

> Vagyis csunya, olvashatatlan a kod

Nem. Sokkal expresszivebb tud lenni, mint pl. a Java. Egyszeruen tobb eszkozod van. (Erdemes pl. megnezni, hogy a C# mennyivel bonyolultabb nyelv, mint a Java, megis mennyivel olvashatobb, tomorebb tud lenni, a lambdak, Linq, delegatek, stb. miatt.)

> Mivel egy adott kodot nagysagrendileg tobbszor olvasnak, es hosszabb ideig tartjak karban, mint irjak meg eloszor,

Vagy igen, vagy nem. Helyzettol fugg.

----------------------
while (!sleep) sheep++;

engem már az is pozitívan meglep h a kérdés felmerült.. :) ilyen sokan scalaznak itthon? van levlista/fórum is esetleg?

A nyelv része már nagyon rég alkalmas "nagy projekthez", a fejlesztői környezet részével voltak inkább gondok.

+1
pont a fejlesztői környezet része miatt nem foglalkozok vele már egy ideje

csekkold ujra. iszonyat utemben fejlodik

legutóbb szeptemberben néztem. Nyárra van beütemezve a következő megnézés :)

pedig minden milestone build tele van új featurekkel + stabilabb mint az előző release.. shameless plug :)

Ennek ellentmond, hogy több fórumon 5 évvel ezelőtt is siralmas állapotról számolnak be és ma is (ami egyezik a saját tapasztalattal). Nemhogy a Javát, a C-t sem közelíti meg sajnos.

Nem allitottam hogy tokeletes. Eclipse plugint hasznaltam, messze nem nyujtja azt mint a beepitett java support, viszont pl. sokkal jobb mint a python plugin es olyan utemben fejlodik mint nagyon keves mas tool.
Lenyeg hogy elert egy *hasznalhato* szintre, amikor mar inkabb segiti a napi munkat mint gatolja.

Ezt sosem értettem. Nagyon sokan meglepődnek, amikor mondom, hogy a millió soros kódbázisunkat semmiféle IDE nem támogatja, ki gedittel, ki vimmel, ki emaccsal fejleszti. Fordítás makefileokkal. A rendszer működik, nem túl bonyolult, és ugye nincs IDE függősége (korábban megszívtam egy legacy cuccal, ami kizárólag VS 6 alatt fordult, mert a többi verzióban nem volt meg valami beállítás).

Szóval miért olyan fontos a fejlesztői környezet?
----
Hülye pelikán

Hogyan kezelitek a függőségeket (pl.: 3rd party libek)? Hogy oldjátok meg, hogy az adott szerkesztő eszköz is fel tudja dolgozni és ajánlani a bennük található osztályokat/procedúrákat, meg a fordító is megtalálja őket fordításkor?

Egyébként a komolyabb javas projektek nem egy-egy ide függőek. Ha pl.: maven-t használnak, akkor a developer tetszőleges IDE-be (eclipse, intellij, netbeans) beránthatja és a build is azt használja. Mondjuk én semmilyen komolyabb javas projektre nem tudnám elképzelni, hogy a fejlesztők gedittel meg vimmel vagy notepad++-szal tartanák karban. Nem tűnik produktívnak (mert hát jó az a content assist, a különböző kód analizálók, a mentésre formázás/code clean up, meg a VS integrációk, meg a debug támogatás,...).

Ez C++ projekt, szóval nyílván vannak komoly eltérések a Javas tapasztalatoktól.

Függőségeket makefile lekezeli, külső, belső, tökmindegy, verziófrissítés akkor van, ha valami nem működik.
Mivel a gedit és társai nem támogatják az intellisense-t, ezért a következő kérdésednek nincs értelme. Nem oldjuk meg sehogy. Lehet enélkül is hatékonyan fejleszteni.
A fordító meg mint említettem, makefile. Minden bele van írva, ami kell neki.
----
Hülye pelikán

Oke, egyezzunk ki abban, hogy a Java vilag _nagyon_ masabb mint a C++, oks? Kulonben oldalakat tudnek irni, hogy ez miert nem jo modszer Java fejleszteshez.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Azt én tudom, hogy így gondoljátok, van Javas ismerősöm, felőlem akár igazatok is lehet, de itt most nem Java, hanem Scala fejlesztésről volt szó, vagy méginkább általános programfejlesztésről.
----
Hülye pelikán

Sosem értettem miért kell egyáltalán magyarázni, hogy a fejlesztés minőségét miért javítja egy IDE.

Javíthatja. De ez nem szükségszerű, sőt, gyakran több vele a szívás, mint a haszon. Főleg nagyobb, több platformra többféleképpen készülő projekteknél. Főleg indiaiakkal és kínaiakkal.
----
Hülye pelikán

Szerintem te erősen kevered a hozzáállást (IDE támogatás) a meglevő implementációkkal (szarazEclipse).

Programnyelvtől függetlenül nem tudom elképzelni, hogy egy több 10000 forrásfájlból álló projekt esetén hatékony lehet a fejlesztés normális ide nélkül. Már egyetlen osztály megírásánál hasznos lehet egy rakat funkció, amit az ide nyújt. A refaktorálást meg egyenesen el sem tudom képzelni, mert a search&replace ritkán hozza a várt eredményt. Több nyelven is fejlesztek, de az Eclipse Ctrl+Clikk szolgáltatása minden esetben gyorsabb volt, mint a fájlt keresgetni, amibe a hivatkozott dolog van.
-
Könyvajánló: Java fejtörők

A kommunikacios gondok nehogy mar az IDE-k problemaja legyen, lecci-lecci.

Egyebkent en is azon az allasponton vagyok, hogy egy helloworld alkalmazasnal bonyolultabb dolgot nem hiszem, hogy komolyabb tamogatas nelkul hatekony fejleszteni. Nem allitom azt, hogy nem lehet, lehet, mindent lehet, butterfly modszerrel is lehet kodolni... csak eppen nem biztos, hogy ez a legjobb ut a jol szervezett, jol karbantartott kodbazis fele.

Amikor van 5000 fuggvenyed, akkor azt mind fejben tartod? Amikor egy kb. ismeretlen objektummal kell dolgozni mi a hatekonyabb, allandoan doksit bujni, vagy az intellisense-szeru funkcionalitassal a fuggvenyeken vegiglepkedve rogton latni egy summary-t hogy az adott fgv. mire is jo? Vagy tenyleg, amikor refaktoralas van, kodkiemeles, intelligens atnevezes... es meg hosszasan lehetne sorolni.

Az megint mas kerdes, hogy egy IDE rosszul valosit meg dolgokat, es emiatt szivas van. De ez megint nem az IDE, mint elv hibaja, hanem az adott megvalositas problemaja (vagy ahogy felettem talaloan mondtak: szarAzEclipse).
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Szerintem azert irja, hogy folosleges az IDE, mert nem letezik jo C++ IDE.

A VS nem rossz, de alkalmatlan cross platform fejlesztesre. (Jo a Windows portra.)

NetBeans?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Van aki eskuszik ra, van aki nem szereti.

C++-ban altalaban az a jo megkozelites, ha IDE fuggetlenre van megcsinalva a build system. A legtobb C++ project multi-platformos. Legalabbis amikkel en dolgoztam :)

Pl. CMake, mint meta build rendszer, csinal neked Visual Studio solution file-t, de csinalhat linuxos Makefile-okat is. Termeszetesen lesznek file-ok, amik csak az egyikben, vagy csak a masik leteznek.

Ebbol aztan az kovetkezik, hogy egyetlen IDE sem lesz a teljes project birtokaban. Tehat az IDE altal vegzett automatikus refaktort sajnos teljesen kizarhatjuk.

Java-ban, .NET-ben egy platform van, ezert lehet jo IDE-t csinalni.

Amugy Visual Studio intellisense-e C++-ra sokkal gyengebb, mint a C#-os. Az Eclipse ilyen jellegu megoldasa nekem hasznalhatatlanul lassu volt (ket eve probaltam egy nagy bloated projecten). Netbeans-rol nincs tapasztalatom, QtCreator mondjuk ugy egyszeru.

En egy kisebb projektnel neztem a NetBeans-t, eleg jo volt.

Raadasul C/C++ -nal azok az IDE-k vannak elonyben, amelyek flexibilisek, vagyis kepesek a CMake vagy a Qt konfig rendszerenek fajljait alkalmazni, mint projekt descriptorok, es a sajat metaadataikat rakjak csak a kodfaba. Nyilvan ez jar bizonyos megszoritasokkal, de szerintem nem tobbel, mint ha ugyanezt maven-nel adjuk elo.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Az indiai/kínai nem a kommunikáció miatt jön ide, hanem a multiság miatt. Több platform, rengeteg féle ember különböző (és mind valid) szokásai és fejlesztési platformja. Amikor a terméked többféle rendszerre többféleképpen jelenik meg, akkor előjön az, hogy bonyolultabb egy IDE konfigurációját előállítani és fenntartani, mint amennyi a haszna.

5000 függvényt miért akarnék fejből tudni? Ha jól van szeparálva és struktúrálva logikailag a program, akkor nem kell bűvölni az intellisense-t (eleve honnan tudod, hogy melyik objektumon akarsz függvényt hívni?), mert abban a mikrokörnyezetben nincs meg az a bonyolultság. Ha van 2 millió sor kódod, és ehhez akarsz hozzáírni párszázat akkor valószínűleg a környezetből fogsz építkezni, meglévő példát fogsz leutánozni (figyelem: ez nem kopipészt). Ebben az intellisense nem segít.
----
Hülye pelikán

"eleve honnan tudod, hogy melyik objektumon akarsz függvényt hívni?"
Egy static typed nyelvben? Mar, hogy a viharba ne tudna az ide, hogy egy adott objektumon mit lehet meghivni.

Itt arról beszélek, hogy az intellisense nem segít abban, hogy megmondja, most épp az adott dolgot, amit szeretnél, melyik objektum tudja neked megcsinálni. Ehhez ismerni kell a kód szerkezetét.
----
Hülye pelikán

Egyreszt ez attol fugg. Ha jol van dokumentalva a kod, akkor eleg csak az adott scope-ban ervenyes objektumokat tudnod, ami azert nagysagrendileg kevesebb. Viszont egy kb. ismeretlen objektumon belul azert neha nem trivialis megmondani, hogy melyik fuggveny fogja neked azt csinalni, amit szeretnel. Ez foleg akkor igaz, ha az adott objektum nem is a te rendszeredbol szarmazik, hanem valamely kulso rendszer biztositja szamodra.

Vegyuk peldanak (csak hogy C++ legyen) a Qt-t. Eleve rengeteg objetumot biztosit a konyvtar magatol, ezen felul a nevkonvencioja neha eleg erdekes tud lenni. Lehet, hogy abszolut nem is illeszkedik a kod altal hasznalt konvenciokhoz. Ilyenkor meg tudja gyorsitani a kodolast, ha mar eleve van egy listad a fuggvenyekrol, es az autocompletion tooltipben melle tudja irni, hogy az adott fgv megis mi a rakot csinal, milyen objektummal ter peldaul vissza - amin ismet lehet fuggvenyeket hivni.

De szerintem nagyon elmentunk az autocompletion iranyaba, holott ez az IDE-knek csak egy - kikapcsolhato - szolgaltatasa. A debuggolasnal peldaul szerintem iszonyuan jol tud jonni egy IDE, ahol az adott breakpoint-hoz hozza tudja kapcsolni az adott forrast, alapbol kiirja neked az epp ervenyben levo - vagy watchlist-en levo - valtozokat, etc. Sokkal gyorsabba, hatekonyabba teszi a muveletet, mintha ugyanezeket kezzel iratnad ki.

De kiemelhetnem a kulonbozo forraskezelo funkciokat, azt, hogy sok IDE akar meg naplokimenetekhez is tud forraskodot csatolni neked. Ezek apro dolgok, osszessegeben azonban tudnak annyit adni a fejleszteshez, ami miatt _szerintem_ megeri befektetni az IDE konfiguráció összeállításába.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Abban igazad van, hogy ha tooltipek ki lennének töltve, akkor gyorsabb lehetne az IDE-s fejlesztés (de nem feltétlenül, mert ha logikátlan a rendszer, akkor úgyis a hülyeségei miatt meg kell nézni a konkrét kódot, a doksit karban kellene tartani, ami nem mindig reális stb.). De nincsenek, mert amikor elkezdték még nem is voltak IDE-k.

Én olyan rendszeren dolgozom, ahol a debuggolás nem megoldható így. Nem tudod csak úgy önmagában futtatni a programot. Debuggolni a tracelogokkal lehet, és core fileok alapján. Itt nem segít az IDE.

Én nem azt mondom, hogy az IDE rossz, már csak okos szövegszerkesztőként is hasznos tud lenni, csak nem mindenhol ésszerű. Nálunk speciel pont nem az, bár szerintem soha senki nem próbált ráhúzni még IDE-t a kódra, de jobb is így, mert csak újabb "így szoktuk tehát így kell" faszság lenne az eredménye, kötnének platformhoz, kötnének minden körülményhez.
----
Hülye pelikán

Debuggolni a tracelogokkal lehet, és core fileok alapján. Itt nem segít az IDE.

De, segít, méghozzá rengeteget. Persze aki nem akarja, annak nem.

Debuggolni a tracelogokkal lehet, és core fileok alapján. Itt nem segít az IDE.

ilyet utoljara telkos cegeknel hallottam, amikor a vegtelen spagetti c++-ban mar nem is akartak, nem is tudtak volna normalisan debugolni :D

Talált, süllyedt :)
----
Hülye pelikán

Ahol normalisan meg van oldva a debuggolas, ott meg a gdb-t is hozza tudod csatlakoztatni egy adott PID-hez, nem kell, hogy az IDE inditsa a programot.
Plusz, jobb helyeken a core file-t is meg lehet etetni.

De tenyleg nem akarok beleszolni. Mindenki ugy fejleszt, ahogy akar. Csak azt az egyet kerem, hogy ne altalanositsunk. Nem mindig, mindenhol, minden projektnel szar az IDE.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nézd, abből indultunk ki, hogy én azt állítottam, hogy nem mindig érdemes IDE-t használni. Ez pontosan azt jelenti, hogy van olyan projekt, ahol nem érdemes IDE-t használni. Hogy TE miért gondoltad úgy, hogy én azt állítottam, sehol nincs értelme a használatuknak, azt nem tudom, ezt magaddal tárgyald meg.
----
Hülye pelikán

Viszont elmegy az ido a peldakeresesre. Egy... ne nevezzuk intellisense-nek, nevezzuk egyszeruen okos autocompletion-nek, szoval egy okos autocompletion rendszer hasznalata mellett nincs szukseg arra, hogy egyaltalan peldakat keress a kodban arra nezve, hogy ezt vagy azt hogyan kell csinalni, csak leulsz, es elkezded irni a kodot.

Az IDE konfiguracio eloallitasa pedig nem feltetlen a te feladatod. Ha a kod esszeruen van szervezve, es jol van dokumentalva - nem csak a felhasznaloi, de a fejlesztoi dokumentacio is friss es pontos - akkor a jo fejleszto ki tudja talalni, hogy mi kell a kodhoz, hogy az altala hasznalt IDE kornyezetben mukodjon. Aki nem tudja kitalalni, az vagy nem kepes hasznalni a sajat fejlesztoi kornyezetet, vagy pedig rossz a dokumentacio. Az elso ot minositi, es egy sima szovegszerkesztos rendszert is el fog rontani, a masodik pedig egyertelmu.

Tegyuk hozza, hogy en nem kodolok aktivan, inkabb csak hobbibol, de nagyon sok esetben az a tapasztalatom, hogy minel bonyolultabb egy kod, annal nehezebb sima szovegszerkesztokkel kezben tartani. Meg akar azt mondom, hogy a vim is ezek koze tartozik. Egyszerre dolgozni az osszes felhasznalt konyvtar fuggvenyeivel/konstansaival/osztalyaival/objektumaival plusz a sajat kod hasonlo elemeivel - ez szerintem hosszu tavon eroteljes hibaforras.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"szoval egy okos autocompletion rendszer hasznalata mellett nincs szukseg arra, hogy egyaltalan peldakat keress a kodban arra nezve, hogy ezt vagy azt hogyan kell csinalni, csak leulsz, es elkezded irni a kodot."

Ez gyiksag :)

Mert? :-)
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Mert mindig erdemes megnezni egy peldat, hogyan hasznaltak egy funkciot korabban. Sok esetben ez nem trivialitas, ami kijon az auto-kiegeszitesbol.

_Neha_ erdemes. Mivel a normalisabb autocomplete mellett ott van a Javadoc/Doxygen dokumentacio is, ha az illeto funkcio dokumentalva van, akkor nem kell a kodot bongeszned. Ha mar bongeszni kell, akkor valami mar _nagyon_ rossz. Meg ugy eleve, ha egy fuggvenyt nem trivialis hasznalni, akkor ott mar nagyobb bajok is vannak.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Hat ez nem igy van.

Rengeteg megoldas sokkal komplexebb, mint egy fv hivas.
Mondok egy peldat. Tfh, hogy nem ertesz a Qt-hez.

Probalj meg osszepakolni ket objektumot, amik signal-slot hivasokkal beszelgetnek, csak intellisense alapjan.

Sok sikert hozza.

Eloveszem a designert/QtCreator-t es osszekotom oket? :-)
Oke, tudom, csaltam.

Nyilvan igazad van. De ha megforditom a kerdest, mibol van szerinted egy kodban tobb, signal/slot osszekotesbol, vagy fuggvenyhivasbol? En a hajamat tepnem, ha minden fuggvenyhivashoz at kellene talloznom a kodot, hogy ugyan ki, hol, hogyan alkalmazta az adott fuggvenyt.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem látom, az autocompletion mennyiben segíti a példakeresést. Bonyolult, felerészt összegányolt rendszerről beszélünk. Hiányos (nem nagyon létező) dokumentációval. Ez egy olyan körülmény, ami létezik, kőkemény, és nem változik magától, a menedzsment meg nem rak bele effortot, mert így is megy a szekér.
----
Hülye pelikán

"Bonyolult, felerészt összegányolt rendszerről beszélünk" nekem úgy tűnt általánosságban beszélünk fejlesztésről és IDE hasznosságról, de mintha te most konkrátan gondolnál valamire :) Egyébként az autocompliter nem a példakeresésben nem segít, de mondjuk a call meg type hierarcy (egyik igen hasznos feature eclipsben is meg netbeansben is)?
-
Könyvajánló: Java fejtörők

Arról volt szó, hogy létezik olyan helyzet, amikor az IDE nem segít. Ezt úgy is tudom bizonyítani, ha hozok egy konkrét példát. Az sosem volt állítás, hogy az IDE SOHA nem jobb, saját kisebb projektjeim mostanában QtCreator alatt készülnek például.
----
Hülye pelikán

Én világ életemben mcedit-et használtam és útálom az ide-ket. Viszont egy nagy project esetén, az utálatom ellenére, de vannak olyan dolgok, amikhez elengedhetetlen egy normális ide használata

Azért mi elengedjük. Még senki nem halt meg.
----
Hülye pelikán

látom hogy úgy sem tudlak meggyőzni. Ehhez előbb az kell, hogy egy normális, kiforrott rendszerben dolgozz, aztán fognád a fejed, hogy dolgoztál eddig;)

Ehhez csak az kell, hogy megtanuld rendesen a magyar nyelvet. Az elengedhetetlen szót használtad, ezt cáfoltam. Egy szóval nem állítottam most, hogy nem lehetne kényelmesebb (amúgy szerintem itt speciel pont nem, ez több helyütt ki van tárgyalva ebben a topikban), annyit írtam csupán, hogy lehetséges dolgozni nélküle, méghozzá hatékonyan.
----
Hülye pelikán

ha már a magyar nyelvet hoztad fel, a vessző előtti részt sikeresen ignoráltad (vannak olyan olyan dolgok).
Lehet dolgozni nélküle, a hatékonyan szót viszont ebben az aspektusban szerintem elfelejthetjük. A hatékony teljesen relatív

"Viszont egy nagy project esetén, az utálatom ellenére, de vannak olyan dolgok, amikhez elengedhetetlen egy normális ide használata"

A mondat szőröstül-bőröstül. Vesszővel vagy anélkül, azt állítottad, hogy az IDE elengedhetetlen. Ha most feltételezzük, hogy az "olyan dolgok" alatt speciálisan csak IDE funkcionalitást értettél, pl autocomplete, akkor igazad van, de ennek így sok értelme nincs, ez olyan, mintha azt mondanád hogy a közlekedésben bizonyos dolgokhoz elengedhetetlen a benzines autó, pl benzingőz égéstermékének előállításához. Autós hasonlat, talán megérted.

Ha valami általános dologra gondoltál olyan dolgok alatt, mint pl hatékony fejlesztés, akkor meg áll a cáfolat.
----
Hülye pelikán

Igen, konkrétan a fejlesztésre gondoltam, nélküle úgy hívják: gányolás.
Sajnos csak példákat tudok mondani, ellenpéldát nem

Lehet jobban körbe kéne nézned a világban :)
A kód amiről beszélek, csak jobb lett, mióta dolgozunk rajta, IDE nélkül. De lehet a te ismeretségi köröd csak gányolni tud IDE nélkül, Javasoknál ez nem példanélküli, ők IDE-vel is sokszor csak taknyolnak.
----
Hülye pelikán

Szerintem ne legyél az igénytelenségre túlságosan büszke, bár tudom, telkónál ez a menő. Meg a vi :)

Szerintem meg akinek csőlátása van és CSAKAZIDE az maradjon csöndben amikor felnőttek beszélgetnek.
----
Hülye pelikán

Elhiheted, láttam már eleget a világból;)
Igen, vannak emberek akik képesek IDE nélkül jól kódolni, bár idehaza nem sok van (de ahogy elnézem a te munkahelyeden mindenki űber expert)
Mindezek ellenére továbbra is tartom, hogy az ide használata nem a programozót javítja fel, taknyolni mindenben lehet.
A nagyobb baj, mikor az ember nem ismeri fel hogy mivel taknyol (pl ez csak egy apróság, hogy a 10 szerkesztőben 30 féle képpen néz ki az indentálás, függően kinek a kódját nézzük), ráadásként próbál meggyőzni másokat arról, hogy ő bizony nem taknyol.
Az meg hogy nagy rendszerben taknyolnak, van rá nagyobb, publikus példa is (fizetősben is), számomra ez így inkább a pistike effektus.
De nyugi, megbocsájtom neked, ez csak annyit jelent, nem láttál még jól működő projectet

Nézd, te úgy tartod, hogy én beszélek hülyeséget, mert neked akkora tapasztalatod van, én úgy tartom, hogy neked mégsincs akkora tapasztalatod, mert nap mint nap látom a cáfolatát. Nincs miről beszélni, még ha itt lennél sem biztos, hogy belátnád amit mondok. Csak próbáld meg néha elképzelni, hogy a saját világodon kívül is létezik még valami. A lentebbi fonálba adott +1-ed is nagyon jól mutatja, hogy halvány lila gőzöd nincs róla, miről írok, csak kiragadod a kulcsszavakat, és nyomod a default válaszokat.
----
Hülye pelikán

nem, csak azt látom, hogy próbálsz meggyőzni arról, hogy kalapáccsal és csavarhúzóval ugyanolyan gyorsan és hatékonyan raksz össze egy autót, mint 100 ember egy gépesített gyártósoron. Mivel ez a lényeg, csak egy szemléletesebb példával, számomra a te oldalad sántít továbbra is. Tőlem barkácsolj nyugodtan tovább

Miért érzem úgy, hogy te vagy a harmadik ember, aki nem fogta föl, hogy az állításom nem az, hogy "IDE nélkül minden esetben hatékonyabb a fejlesztés"?
----
Hülye pelikán

mert arról próbálsz meggyőzni mindenkit, hogy márpediglen nálatok hatékony az, hogy 10 ember kalapács/csavarhúzó/reszelő segírségével tökéletesen elboldogul.
Ne csodálkozz rajta, hogy ha 3 ember szkeptikusan néz rád

Nem, arról próbállak meggyőzni, hogy NÁLUNK nagyobb effort lenne bevezetni ÉS karbantartani egy IDE-s megoldást, mint amennyi a haszna.
----
Hülye pelikán

Ez olyan magyar kisvállalkozós szöveg.
--
http://naszta.hu

Szerintem ez teljesen világos, egy már meglevő rakat custom rendszerbe amit soha nem terveztek IDE-re, betolni egy IDE-t nem kétnapos munka, teljes elkötelezettséget igényel mindenkitől és igen, erősen esélyes, hogy tényleg keveset profitálnátok belőle az árához mérten.

Amit inkább szóvá tettek, hogy a meglevő trutyi is pontosan az ilyen hozzáállás miatt lett olyan amilyen. Mivel azt hangoztattad, hogy aki IDE-t akar az nem tud programozni, illetve erősen kevered az IDE koncepciót az egyes megvalósításokkal, a szándékos mellébeszélés azt hiszem mindkét oldalról bőven megvolt.

Egy jól összerakott IDE környezet igenis produktívabb, mint egy jól összerakott cli-tool-integrált környezet a millió editorával, a kérdés, hogy miért nem erre van törekvés, de ezt a szálat már lezártuk.

Én ilyesmit nem hangoztattam. Azt mondtam, hogy aki nem tudja elképzelni az életét IDE nélkül (volt ilyen hozzászólás), az nem jó programozó.
És még azt is állítottam, hogy nem minden esetben hatékonyabb az IDE, és hoztam egy példát. Ti meg folyton elméleti helyzetekkel jöttök, hogy de ha ez meg az. Oké, de az élet nem így működik, az életben azt kapod, amit kapsz, nem amit szeretnél.
----
Hülye pelikán

Kicsit túlmisztifikálod a "nem gondolkoztak előre, most azzal szopunk ami van"-t :)

1. Amikor ez kezdődött, még nem volt elterjedt IDE fogalom.
2. Ha lett volna is, van, amihez igen, még mindig nem praktikus az IDE. Nem mindenhol nyújt akkor előnyöket, hogy megérje karbantartani több platformon, sok éven át. Nem jó kötni magadat egy eszközhöz, ha sok évre tervezel előre.
----
Hülye pelikán

Kizarolag a masodik pontra valaszolok.

Vannak olyan dolgok, amikre valoban nem jo az IDE, de az IDE nem egy olyan dolog, hogy mellette ne lehessen mast is hasznalni. Nekem is van olyan fejlesztesem, hogy ugyan IDE-ben fejlesztek, de CLI-ben is mokolok hozza, mert az kell. Egy IDE elsosorban egy ultimate programmer editor, erre pedig altalaban mindig alkalmas, ha az epp aktualis projekt nyelvet ismeri a szerkesztoje. Ha nincs... na az mar esetleg gaz, de egy masik IDE biztos ad olyan highlightot ami neked kell...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

ez a magyarazkodas mar kinos, kerem kapcsolja ki :)

Nezd, ha ilyen az a rendszer, akkor az IDE hasznalatanak a mellozese a legkisebb baja annak a projektnek.
Eloszor is, a legtobb fuggvenyt vagy trivialis hasznalni, vagy ha valamiert nem az, akkor van folotte egy pici dokumentacio, hogy mit akar ez a fuggveny, es egy pelda - kommentben. Ha jol van beformazva ez a komment, akkor az autocomplete meg tudja jeleniteni. Orakat tudsz ezzel sporolni.

Egyebkent pedig nekem is volt hasonlo, nem dokumentalt projektem, menet kozben, amikor hasznaltam dolgokat, es talaltam nem trivialis eseteket, akkor ledokumentaltam. Lehet, hogy eleg ket jol megfogalmazott mondat, hogy ertheto legyen, hogy az a cucc ott mit csinal. Ennyit az ember elverne egy rossz kodra is.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"leutanozni"?

WAT?

2M sor kodnal normalis fejleszto nem utanozgat, eleve nem fog mindent atlatni, tehat azt se fogja tudni, hogy mit kellene utanoznia. mindenfele patternekben lehet gondolkodni, de gondolkodas nelkul utanozni csak azert, mert nagy a kod? inkabb azert, mert "a faszombaismar', hogy a hulye ide nem segit". ja, hogy nincs ide. ja, hogy te ugy irsz kodot, hogy kinyitsz masik ot ablakot, mert nem segit az intellisense/akarmi abban, hogy milyen metodusaid vannak egy objektumon, meg abban se, hogy milyen szignaturaju egy metodus. ja. hat jo szorakozast ;)

Mint fentebb kiderult, spagettikodot irnak. Ez altalaban a kodok masolgatasabol all, ahelyett, hogy refaktoralnak az ismetelten hasznalt dolgokat, egyszerusitenek vagy bovitenek a nem trivialis eseteket. Az a projekt amirol tetra ir, az nekem elsosorban konstans szopasfaktornak tunik, semmint ertelmes projektnek, de ez mar teljesen privat velemeny.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Az utánzás nem ugyanaz, mint a másolás, persze ezt is leírtam már. Utánzás amikor megnézed egy működő, tesztelt kódon, hogy hogy kell bánni ezzel az osztállyal, mit kell csinálni ezzel az adattal. Másolás amikor 1-1-ben átrántod a kódot. Ilyet is láttam, durvát, most épp ilyenen dolgozom, de amiről beszélek az nem ilyen.
----
Hülye pelikán

igy terjednek a borzasztoan rossz mintak es no a spagetti. rossz irany.

Nem, nem így. Olvasd újra.
----
Hülye pelikán

+1

Problema inkabb ott kezdodik, hogy van 5000 fuggvenyed, amibol ismersz 1000-t es neked olyan funkcio kellene, amit a maradek 4000 kozul valamelyik jo esellyel implemental.

----------------
Lvl86 Troll - Think Wishfully™

Hogyan refactoráltok? Teszem azt át kell nevezni egy classt vagy metódust vagy át kell rakni másik namespacebe.

Mondjuk mi CMake-kel dolgozunk. Így megvan a Visual Studio kényelme és a makefile rugalmassága is.
--
http://naszta.hu

sub

Elvi problemaim vannak a java revival projektekkel.

A C se attol lett nepszeru, hogy COBOL environmenteken gyonyoruen futott.

A meglevo java rendszerekre max egy REST-feluletu webservice-t szeretnek epitve latni, es elfelejteni, hogy a JVM valaha is letezett, ha nem startbol ujrairni az egeszet.

Idézet:
A C se attol lett nepszeru, hogy COBOL environmenteken gyonyoruen futott.

ja, csak valszeg néhány nagyságrenddel kevesebb legacy cobol rendszer volt a c megjelenésekor, mint most legacy java rendszer.

Idézet:
A meglevo java rendszerekre max egy REST-feluletu webservice-t szeretnek epitve latni, es elfelejteni, hogy a JVM valaha is letezett, ha nem startbol ujrairni az egeszet.

miva'?:D

Személy szerint már eleve a mostanság egyre több helyről előkerülő "RESTfull webservice", mint csodaszerrel úgy vagyok, hogy zseniális. Végre valaki elolvasta a HTTP specet és tovább jutott a GET kérésnél. Aztán most kellett rá egy divatos buzzword.

----------------
Lvl86 Troll - Think Wishfully™

Ettől függetlenül nem rossz dolog.

Nem rossz, de a http protokoll sem erre való igazából. Egy stateless protokoll elég sokmindent be tud határolni

:D

----------------------
while (!sleep) sheep++;

A második részt kifejtenéd bővebben? :)

valszeg jobb ha nem teszi

Nezd, en anno abbol irtam a diplomamunkamat, hogy a SOAP barmennyire szep is, le fogjak valtani. Akkor a bizottsag huledezett, meresz kijelentesnek tartottak. Ma mar a java forumok is teli vannak ezzel.

Nem szeretem a javat, azt gondolom, a java egy rossz megkozelites, egy olyan valami, aminek minden eleme egy hibas hipotezisbol indul. Ez nyilvan egy velemeny, es itt most nem errol beszelunk, itt most arrol beszelunk, hogy van a JVM, ami a java futtatokornyezete (virtualis gepe), es efelett mas nyelveket is lehet implementalni, tobbek kozt a scala-t.

Azt remelik ettol, hogy majd nem kell kidobni a java-rendszereket teljesen, mert nyilvan emberek azert irnak Scala kodot, mert ok se szeretik magat a java nyelvet.

De en a stack tobbi reszet se szeretem, a JVM-et kulonosen nem, akkor mar inkabb a nyelv maradna (A CLR ezerszer ertelmesebb otletekre epul, bar nem .NET-ezem).

A JVM jelenleg mar csak egy helyen van jelen a vilagon (az androidban ugye dalvik van), szervereken, ahol igazabol minden mas nyelv is eppugy multiplatform. Szidhatjuk a PHP-t, a Python-t a Go-t, a Dartot, a D-t, a mittomisenmit, kozos jellemzojuk, hogy mivel szerveroldalon vannak, es igazabol socketeken latnak ki a vilagbol, edesmindegy, milyen nyelven vannak irva felhasznaloi szemszogbol. Tovabba ezen nyelvek barmelyike elfut mindenen, amin az OpenJDK / JRE elindul.

Mint ahogy anno az EJB 2.1 abban latta a megoldast, hogy a legacy rendszereket Bean-managed Entity Bean-ek moge rejtjuk, es fokozatosan kivaltjuk, en abban latom a megoldast, hogy REST-alapu protokollok (vagy mas nyelvfuggetlen, pl. Thrift) moge rejtjuk ezeket, ideertve a java rendszereket is.

A java a nyelvek szent gralja szeretett volna lenni, az a nyelv, amin minden problemat megoldunk. Meg is oldhatunk vele, de nyakatekert.

A JVM a VM-ek szent gralja akart lenni, egy olyan VM, amin minden nyelv fut.

En nem szeretnek ilyen szent gral rendszereket.

En azt gondolom, minden problemara megvan a legalkalmasabb nyelv, platform, es azt gondolom felelos architect magatartasnak, hogy egy olyan rendszert hozzunk ossze, ahol ezek a nyelvek, platformok szabadon cserelgethetoek.

Ehhez pedig nyelvfuggetlen protokollokra van szukseg, nem pedig egy uj JVM nyelvre.

Ugy kene megprobalni a kovetkezo alkalommal, hogy az 'architect' szo ne szerepeljen a posztban :).

----------------------
while (!sleep) sheep++;

A "filozofian/marketingen" kivul milyen konret bajod van a JVM-mel?

Az, hogy csak annak gyors, aki hisz benne, amikor barmilyen JVM-es kodot elinditok, akkor hirtelen a gyakorlatban lassu, es ha merem, akkor se lesz gyorsabb.

Aztan belenezek, hogy pontosan mit csinal a HotSpot JVM, megnezem a bytecode-ot, es rajovok, hogy hat eleve az otlet nem jo; vagy a megvalositas, en nem tudom, de nem eleg jo a JIT benne.

Biztos masnak mas szamok jottek ki, nyilvan mi itt JRuby-t, Jython-t, Quercus-t (PHP over JVM), Rhino-t (JS) vetettunk ossze mas implementacios kornyezetekkel (akar .NET-es megfeleloikkel), esetleg LLVM-et neztunk, vagy adott feladatra masban implementalt kodot (pl. ant vs pythonban irt buildsystemek), szoval nem az volt a cel, hogy hol tudunk java kodot jol futtatni, es nyilvan ezek nem voltak reszletes, tudomanyos meresek, hanem feladatspecifikusak mindig, nekem meg mindig az jott ki, hogy jobb ha nem JVM, hanem alternativa.

De biztos masnak mas jott ki, annyira nem erdekel, tobb eves tapasztalat, 1.6-os OpenJDK-val meg mindig sebessegbajok vannak, ugyanarra a celra irt mas szoftver gyors, JVM-es valtozat nem az, ezt neha mertuk, neha erzesre ment ugymond.

Mindig jovo-kompatibilisebnek ereztuk kozos, dokumentalt adatformatumok, szerver-kliens protokolok hasznalatat, mintsem a kozos runtime-ot, plane ha maga a feladat-vegrehajtas lassabb.

Nyilvan mindig az a cel, hogy adott mernoki korulmenyek kozott a leheto legjobb megoldasokat hasznaljuk, amik leheto legkevesbe fuggenek az alattuk levo retegektol, es hacsak nem voltak epp java-fanatikusok a csapatban, az jott ki hogy a JVM nem jo.

Egy VM futtatoplatformnak harom dolga van:
- futtatni, minel gyorsabban
- elrejteni az alatta levo retegeket minel jobban
- kozos interfeszeket definialni a kulonbozo nyelven irt rendszerek kozott

Az elsoben rendszerint alulmaradt, a masodikat hozta az is, ha a kulonbozo cuccok egyesevel rejtettek el ezeket a retegeket, a kozos interfeszt meg meg lehetett oldani mashogy. Ennyi.

Nyilvan hinni sokmindenben lehet.

Latom sokeves Java papolas utan kiprobaltad a C++-t ;-)

Ezen kuncogtam.
----
Hülye pelikán

Erre valaszolok, mert ebben van valami morzsanyi konkretum a vegtelen blabla kozott.

"nyilvan mi itt JRuby-t, Jython-t, Quercus-t (PHP over JVM), Rhino-t (JS) vetettunk ossze [...], tobb eves tapasztalat, 1.6-os OpenJDK-val..."

Az a kozos az altalad felsorolt nyelvekben, hogy mindegyik dinamikus. Valamit is a temahoz konyito szakember tudja, hogy a JVM-be a 7-es elott (amibe bekerult az invokedynamic) nem volt semmilyen dinamikus nyelv tamogatas. Ugyhogy teljesitmenyigenyes feladatokra nem is valasztott senki dinamikus nyelvet JVM-en (zarojelben megjegyzem, hogy szemelyes tapasztalatom alapjan dinamikus nyelvet sehol nem valasztanak teljesitmeny specifikus feladatra, sot nagyobb cegnel/projektben semmire - ha tehetik).

Egy ellenpelda a JVM lassusagra (most csak ennyire van idom) disruptor opensource java lib honlapjarol: "LMAX aims to be the fastest trading platform in the world." Es javaban irjak. De ok biztos tudatlanok.

csitt, nekik nincs ilyen szuper architectjuk, mint nekunk!!11 nem erthetnek hozza!1!

Engem qrvara idegesit ez a direct motherf*cking, nem lehetne mellozni?

nem :(

En se csesztetlek hogy IBM-nek dolgozol, pedig kivalo ceg, kivalo, mindenki altal imadott termekekkel (nem.) :P

Na de milyen csinos lányok vannak ott!
----
Hülye pelikán

Igen? :)

ez max akkor lenne jo riposzt, ha minden postomban szerepelne az "IBM kivalo termekeket gyart" mondat. remelem erzed, hogy elsosorban a stilusoddal, masodsorban azzal van bajom, hogy a levegobe beszel a postod 99% -a, es maradek 1% -ban sincs konkretum. sosem fenyeztem az IBM termekeit egyik posztomban sem, te viszont mindig fenyezed "brillians" megoldasaidat, "architect ur".

amikor leirjak neked, hogy hulyeseget mersz, akkor meg jossz azzal, hogy "hat kimertuk, es lassu volt11!". (dinamikus tipusos nyelvek a JVM-en esete).

Bocs hogy NDA-t kellett alairnom arrol, mit csinalok, es nem irhatom azt le egy forumban hogy pontosan mit merek ki es miert, csak utalhatok ra.

Remelem te is sejted, hogy legszivesebben a meresi eredmenyek fenn lennenek githubon, es akkor nem jonnel ilyen hulyesegekkel.

Most abba hogy a python egyebkent tipusos ebbol a szempontbol peldaul es nem kell neki invokedynamic, nem megyek bele.

Nyilvan eletedben nem hasznaltal "dinamikus" nyelveket, mivel eletedbe nem lattal mas nyelvet a javan kivul, ill. azok fiatalkori kalandok voltak, eleted vegeig abban szeretnel programozni.

Ez olyan mint az agile, tudod, akinek nem megy az biztos elb.szta, hat egy francot.

Szeretnem, ha az embereknek nem vallasa lenne hanem szamaik, de sajnos ugylatszik ez itt nem megy, mert te se veszed a faradtsagot arra, hogy elobb merj es aztan dumalj.

A mi use case-einkben az jott ki, hogy a JVM altal forditott kod nem olyan gyors mintha mas technologia forditana. (Mindezt egy dinamikus JVM alapu nyelv alatti kommentben)

Ez egy fuggetlen meres, marhara nem tud erdekeli a Spring honlapjan a kijelentes hogy a Spring szerintuk mennyire gyors.

De ha ennyire se vagy kepes, mert el nem tudnad kepzelni hogy barmi mast hasznalj, akkor mit keresel ebben a szalban?

hat ez nagyon melle ment :( meg gyurj ra. hint: pythonozok masfel eve kb aktivan (is).

az en use casemben az jott ki, hogy oldalakat tudsz csak irni, ide-oda ugralva, ertelmetlenul, es ha nem fenyezed magad, szerintem remeg a kezed. de igazad van, mivel erveket ill technologiai megfontolasokat toled ugyan nem fogunk hallani, igy nincs is mit keresnem itt :)

Milyen erveket szeretnel? A java tul bobeszedu, milyen mas megoldas van?

Technologiai megfontolast? Portabilis kod, ne legyen baj egy szoftverupdate.

Ha meg pythonozol akkor tudod, hogy nem ismer implicit castolast, ergo relativ jol statikusan analizalhato nyelv. Sajnos type hintinget se ismer, de amiota a dynamic compiler technologia eljutott odaig, hogy je, statikusan elemezhetoek a dinamikus nyelvek, azota vannak jobb otleteink mint az InvokeDynamic, ami leginkabb a 'passzolom a tipust' kategoriaja.

Azokhoz a postokhoz, ahol meg nem szemelyesen kotsz belem, nem szolsz hozza, igy nem latod, hogy valaszolok en 'fenyezes' nelkul is. Itt egy nyelvi vita van, en azt mondom, a JVM nem hozta a teljesitmenyt, az InvokeDynamic-nal elobbre tart a nyelvtechnologia (tracing compiler) es amekkora overhead, nincs ertelme beiktatni (helyette forraskodi terjesztes es garantalt kornyezetet javaslok), te meg jossz hogy menekuljunk.

Statikus java is volt osszehasonlitva sajat runtime-jukon es jvm-en futo dinamikus nyelvekkel, azok feletti webes keretrendszerekkel, ill. Az ant volt osszehasonlitva rhino es python alapu buildekkel.

Szempontunkbol lenyegtelen hogy volt-e InvokeDynamic, egyfelol leteztek ezek a megvalositasok,, masfelol manapsag ez nem ennyire egyszeru kerdes (a python szinte statikus, a js-t pedig statikusra forditja a v8)

Keves olyan elterjedt megoldas van, ami nem java, multiplatform es statikus...

Nem fogok c++-ban webframeworkot irni ha nem muszaj.

Szemelyes tapasztalatod valoszinuleg az, hogy nagy cegekben alt. 95% java vagy c# esetleg c++ programozo van, aki meg se nezi, mit hoznak a dinamikus nyelvek az adott taszkon.

"Statikus java is volt osszehasonlitva sajat runtime-jukon es jvm-en futo dinamikus nyelvekkel, azok feletti webes keretrendszerekkel, ill. Az ant volt osszehasonlitva rhino es python alapu buildekkel."
Hat ebben semmi konkret nincs.

"Szempontunkbol lenyegtelen hogy volt-e InvokeDynamic, egyfelol leteztek ezek a megvalositasok"
Mint mondtam, ha teljesitmenyt mertetek, akkor ez egy fontos szempont volt, amit figyelmen kivul hagytatok (mertetek amirol mindenki tudta, hogy lassu).

"a python szinte statikus, a js-t pedig statikusra forditja a v8"
Szerinted letezhet olyan fordito, ami egy dinamic typed programot le tud forditani ugyanolyan sebessegu nativ kodra, mint egy static typed programot? A google valasza az, hogy nem: ezert szeretnek nyomni a dart-ot a js helyett, ami opcionalisan static typed, mert nagyot gyorsult ugyan a js, de meg mindig messze van a valahonnan. Es ezen nem segit, hogy nativra fordul. Egyszeruen nincs ott a tipus informacio es enelkul a fordito nem tud eleg okos lenni.

"Szemelyes tapasztalatod valoszinuleg az, hogy nagy cegekben alt. 95% java vagy c# esetleg c++ programozo van, aki meg se nezi, mit hoznak a dinamikus nyelvek az adott taszkon."
Szemelyes tapasztalat alatt nem csak azt ertettem, amit a sajat munkam soran megtapasztaltam (bar alatamasztja), hanem azt ami a mediabol atjon: Facebook: php to c++ compiler (halottnak a csok). Google: gwt, closure, dart.

De jo hogy ilyeneket egy Scala post ala irsz, hogy dinamikus nyelvu kodot lehet-e statikusan ertelmezni, mert pont ettol mukodik a scala, tudod, A-> A' -> A' es tarsai.

A Google-nel van 25000 mernok, ezek kozul soknak vannak hulye otletei, amik kikerulnek: ilyen volt a GWT is (remelem, ma mar senki nem hasznalja), ilyen a dart is azok szerint a meresek, elemzesek szerint amik kikerultek (en ugyan nem mertem rajt semmit, de nehany volt munkatars igen, azok szerint inkabb irnak javascriptben).

A mediabol azt olvasol ki amit eleve akarsz latni.

Ez a nagy Dart szidás kicsit meglep, főleg érdekes dolog a már sok éve fejlesztett és optimalizált JavaScriptet összehasonlítani egy éppen csak elindult nyelvvel szemben.

Teljesen természetes hogy alig (ha egyáltalán) optimalizált a Dart jelen pillanatban és hogy sok idő lesz mire valóban optimalizált lesz. Az is érdekelne miért annyira gáz az opcionális típusosság amit a Dart ad.

Nem értem miben segít egy dinamikus nyelvekről szóló vitában a Scala, ami nem dynamic hanem static typed nyelv (mint a C, C++, Java meg a C#). Fejtsd ki légy szíves.

Tetszik ez a hozzáállás a részedről, hogy ha valamit nem tudsz megmagyarázni, akkor azt elintézed azzal, hogy akik máshogy gondolják azok hülyék. Most éppen a Google 25k mérnökei közül sokak. Szakmai vitában nekem még ezt szokni kell, főleg olyantól aki sorban bizonyítja, hogy nem ért a témához.

A dart célja (wikipediaról): "Dart is intended to solve JavaScript's problems [...] while offering better performance". Mondják ezt azok, akik eddig már dollármilliókat költöttek a js sebességének javítására és ezzel gyakorlatilag újraindították a böngészők közötti versenyt. Csak, hogy egyértelműbb legyek: nem azt mondom, hogy a dart le fogja váltani a js-t (mert van itt ebben politika is bőven), de szakmai szinten, teljesítmény szempontjából jobb lenne, mint a js (pont azért mert lehet static typed).

A gwt (egyik) célja (szintén wikipédia): "GWT [...] is a general set of tools for building any sort of high-performance client-side JavaScript functionality." Ezt megint ugyanaz a google készítette, aki a V8-at fejleszti. És megint egy tool azért, hogy workaroundolják a js-t.

A closure célja (wikipedia): "The Closure Compiler is a JavaScript optimizer that rewrites JavaScript code to make it faster and more compact." Megint egy tool a google-től a dynamic typed js teljesítményének javítására (a closure pl.: lehetővé teszi, hogy spéci formázott js kommentbe beírd a típust, azaz, hogy static typed-ként használd a js-t).

Biztos csak beleképzelem, de én látok itt egy mintát.

Azt latod, hogy a google a weben van, marpedig a weben kizarolag javascriptben lehet dolgozni.

En meg hozza tudnek adni 1-2 dolgot a listahoz, ahol ezt a helyzetet megprobalja par ember "megoldani", van ilyen LLVM-szeru kezdemenyezes is pl. a google-nel.

Hadd idezzek Eich-tol (JS feltalaloja, a TC39 (JavaScript jovojeert felelos bizottsag) tagja:

Here is something that the Google leak about Dart (née Dash) telegraphs: many Googlers, especially V8 principals, do not like JS and don’t believe it can evolve “in time” (whatever that might mean — and Google of course influences JS’s evolution directly, so they can put a finger on the scale here).

They’re wrong, and I’m glad that at least some of the folks at Google working in TC39 actually believe in JS — specifically its ability to evolve soon enough and well enough to enable both more predictable performance and programming in the large.

A google nem egy darab ember: a google egy rengeteg irodaban, egymassal kapcsolatban nem, vagy alig allo team-ek osszessege. Ha dolgoztal mar nagyvallalatnal, akkor tudod, hogy az ilyen technologiai dontesek nem vallalatszinten dolnek el, hanem egyszeruen az egyik iroda release-el egy ilyet, adnak hozza kis PR -t es kesz.

A trukk az, hogy ahogy Scala-ban is ki tudod ertekelni forditasi idoben ezeket az A-<A' dolgokat, pont ugy lehet kiertekelni JS-ben is, es pont ez az osszes ujgeneracios "dinamikus" VM-nek a trukkje.

En hiszek abban, hogy ez menni fog.

"A trukk az, hogy ahogy Scala-ban is ki tudod ertekelni forditasi idoben ezeket az A-<A' dolgokat, pont ugy lehet kiertekelni JS-ben is, es pont ez az osszes ujgeneracios "dinamikus" VM-nek a trukkje."

Citation needed.

"En hiszek abban, hogy ez menni fog."

A vallasi nezet magan ugy, szakmai vitaban nincs helye.

A generikus típus fordítási időben kiértékelődik, azaz statikus. Az arra tervezett nyelvekben sem működik 100%-osan a type inference néha kézzel kell megadni a típusokat (különben nem fordul! - ettől statikus az ellenőrzés).

Mivel a Pythont nem is tervezték type inference támogatásra ennek ellenére sosem kell kézzel megadni a típusokat: látatlanban ki merem jelenteni, hogy a fordítási időben nem dől el benne az összes típus...

A pythonban ertekadasi pillanatban dol el, viszont nincs implicit casting (ekkor kezzel adod meg a tipust), illetve van benne hivatalos class construct.

Ezzel a kettovel mar elegge meg lehet gyorsitani a dolgokat, ha vegiggondolod, hogy a Scala-ban hogy megy a generikus tipus kiertekelese, akkor rajossz, hogy tulkepp ezt meg lehet am csinalni dinamikus nyelveknel is, es ez a megoldas gyorsabb lesz, mintha InvokeDynamic-et hasznalnal. Na, ebbol lett a V8.

A technologia meg nem kiforrott, de en ebben latom a jovot, nem a statikus nyelvekben.

A statikus típusellenőrzésen alapuló nyelvekben/technológiákban is hatalmas potenciál van, szóval a jövőben ugyanúgy ott lesznek azok is - efelől ne legyen kétséged. ;)

Nem egeszen ertem, miert probalsz teljesitmenybeli kovetkezteteseket levonni a bytekod alapjan. Fejben futtatod a JIT compilert? A bytekod nem teljesitmenyre van optimalizalva, hanem leginkabb csak a kodban levo algoritmus reprezentacioja AST-kent, bizonyos statikus optimalizaciokat vegrehajtva rajta (pl. nyilvanvaloan nem elo kodreszletek eltavolitasa, literal inlining, stb.).

A teljesitmeny optimalizacio nagy resze a JIT compiler feladata aminek a bytekod az inputja nem az outputja!!! Emellett pedig rengeteg profiling es egyeb (pl. a tenyleges architektura alapjan optimalis elvegzese valamely primitiv muveletnek) informaciot figyelembe vesz, amit a statikusan forditott nativ kod nem tehet meg.

Emiatt egy JIT compiler-es futtato kornyezet garantaltan legalabb ugyanakkora sebesseget erhet el mint egy statikusan forditott kod, mivel vegrehajthatja ugyanazon optimalizaciokat mint a statikusan forditott (ergo ugyanazt a kodot eredmenyezne), de emellett meg tovabbi informaciok is rendelkezesre allnak ami alapjan lehetseges, hogy meg jobb eredmenyt er el.

A VM altalad definialt feladataival sem tudok teljesen egyeterteni:

> - futtatni, minel gyorsabban.

Egyetertek.

> - elrejteni az alatta levo retegeket minel jobban

Nem feltetlenul ertek egyet. Igenis, lehetseges, hogy a hardver vagy az operacios rendszer vagy a szoftverkornyezet valamilyen funkcionalitasa nem elerheto a VM vagy az osztalykonyvtar altal biztositott absztrakciokon keresztul. Ekkor jobb szeretnem ha ez a funkcionalitas nem teljesen rejtett es teljesen hozzaferhetetlen lenne.

> - kozos interfeszeket definialni a kulonbozo nyelven irt rendszerek kozott

Most mirol beszelsz tulajdonkeppen?

Egy (J)VM-ben futo tobb kulonbozo nyelven irt rendszerrol, ertsd library-krol? Ez esetben igen, nem art ha kompatibilis a generalt bytekod egymassal minel kisebb overhead-del.

Tobb (J)VM-ben vagy adott esetben nem is JVM-ben futo rendszerek kozti kommunkaciorol? Ez megis MIERT lenne a VM feladata? Ez egyertelmuen az osztalykonyvtare.

Idézet:
Ekkor jobb szeretnem ha ez a funkcionalitas nem teljesen rejtett es teljesen hozzaferhetetlen lenne.

JNI?

Alapvetoen altalanossagban beszeltunk a VM feladatairol, nem pedig pedig egy konkret problemarol (nativ kod futtatasa) amire tortenetesen van megoldas.

Egyebkent jobb szeretnem, ha nem kene folyton ide-oda lepkednem nativ es Java kod kozott, szoval a JNI se egy tokeletes megoldas.

Par dolog van (illetve nincs) Java-ban aminek a hianya irrital. Ezek egyike a kenyelmes direkt es strukturalt memoriakezeles hianya (pl. struct-ok, es struct-okbol allo egyeb struct-ok es tombok...) es az abbol adodo tul sok objektum peldany letezese, valamint a kotelezo bound check tomboknel.

Nyilvan az lenne az elonye jvm felett futtatni nem java nyelvet, hogy hozzaferj olyan modulokhoz amit nem az adott nyelven (hanem pl. javaban) irtak, a masodikhoz nincs ertelme a kozos vm-nek.

Az elrejtest pedig ugy ertettem, ha holnaptol solaris-t, freebsd-t vagy akar csak egy felfrissitett ubuntut akarok (esetleg windows-t), ne legyek meglove

> Nyilvan az lenne az elonye jvm felett futtatni nem java nyelvet, hogy hozzaferj olyan modulokhoz amit nem az adott nyelven (hanem pl. javaban) irtak, a masodikhoz nincs ertelme a kozos vm-nek.

Itt egyszeruen nem ertettem hogy melyik lehetosegre gondoltal, azert kerdeztem vissza. De itt nagyjabol egyetertunk.

> Az elrejtest pedig ugy ertettem, ha holnaptol solaris-t, freebsd-t vagy akar csak egy felfrissitett ubuntut akarok (esetleg windows-t), ne legyek meglove

Ezt inkabb az operacios rendszer es a fizikai kornyezet felett egyseges felulet biztositasanak mondanam, ugy nem annyira ketertelmu. De igen, ez igy tenyleg a feladata.

Az egy dolog, hogy a jvm-mel neked vannak gondjaid, és hogy akár még az is lehet hogy tényleg szar, nem tudom, mivel nem fejtetted ki (vagy esetleg a szentgrál-rinyálás lett volna a kifejtése a problémáidnak? mert akkor főleg facepalm). Az pedig egy egészen másik dolog, hogy kell-e támogatni és továbbfejleszteni. Az a lényeg, hogy a felhasználónak mi a baja a programmal. Ha a felhasználói problémák nem indokolják a platformváltást és a teljes újraírást, akkor nem szabad újraírni, mert (remélem nem árulok el nagy titkot) kurvadrága... vagy ha mégis újra lesz írva egy alkalmazás, vagy esetleg nem lesz támogatott és továbbfejlesztett egy platform/technológia (ezzel térünk vissza eredeti hozzászólásodhoz) egyes vélt vagy valós hamis hipotézisek miatt, akkor ott már nagyon nagy baj van.
Másképp mondva: ha szerinted a Java platformot egy az egyben le kéne cserélni és minden erre írt alkalmazást újraírni ahelyett, hogy a mostani platformot továbbfejlesztenék (pl. ebben az esetben modernebb nyelvvel) akkor rossz, eltorzult perspektívából látod ezt az ipart.

Megmondom, mi a baja a felhasznalonak a programmal: az ember egysegnyi valtozaskent nagysagrendileg egy 200-300 milisecundomos idot kepes kezelni, 1 masodperc (1000 milisec) az awkward silence also hatarerteke, fel perc a tuti qrvaanyazase.

Magyarul az a program, ahol nem jelenik meg kb. negyed masodpercen belul egy lekattintott menu vagy egy autocomplete, lassunak tunik, ha egy keresesi valasz nem jon meg 1 masodpercen belul, az emberek jelentos resze kezd el frusztraltnak lenni, 30 masodperc utan pedig mindenkiben gurgulazik az ideg.

Ezek nem az en szamaim, ezek Norman kutatasai, ezek masok kutatasai, osszefoglalva mondjuk szepen ott vannak a Designing The Mind in Mindban: http://bit.ly/IwBSzv - de hozhatnam a Design Of Everyday Things-et, a 100 dolog amit minden tervezonek tudnia kell-t (Kiskapu, 2011), vagy be lehet ulni mondjuk BME szofterg-re, ezek iparagi szamok, hadd ne zuditsam ide a fel tudomanyagat, higgyuk el hogy nem a TV-ben hallottam, es azok se a hasukra utottek, akiktol tudom.

Namost ezt, ha eleve a VM lassu, nem tudom biztositani. Szorri, nem megy. PHP-vel igen, JS-sel igen, java-val nem tudom kihozni springbol, tudom, szarra lehet cache-elni, tudom hogy mukodik a memcache, tudom mi az az Oracle Coherence, meg vegyek erosebb gepet, CDN-t, jobb browser-t, ne browserbe fusson, tudomisen, de ha ez JVM nelkul, mas nyelvekkel megy nekem egyetlen geppel anelkul, hogy egy fel vilagot fel kene huznom, akkor szamomra a vita eldolt.

Itt van vege a sztorinak. Vannak emberek, akik foglalkoznak kodszepseggel is, meg azzal is hogy az ugynevezett normalis embereknek (vegfelhasznalonak) tenyleg jo legyen, de egyelore torpeminoritasban vagyunk. Na en ebben a torpeminoritasban azt a remelem nem egyelemu halmazt kepviselem, aki szerint sokat dob ha eleve nem egy lassu runtime-mal kezdunk, ami a sajat mereseinkben keptelen hozni a kuszobszamokat.

"Namost ezt, ha eleve a VM lassu, nem tudom biztositani. Szorri, nem megy. PHP-vel igen, JS-sel igen, java-val nem tudom kihozni springbol, tudom, szarra lehet cache-elni, tudom hogy mukodik a memcache, tudom mi az az Oracle Coherence, meg vegyek erosebb gepet, CDN-t, jobb browser-t, ne browserbe fusson, tudomisen, de ha ez JVM nelkul, mas nyelvekkel megy nekem egyetlen geppel anelkul, hogy egy fel vilagot fel kene huznom, akkor szamomra a vita eldolt."

Valamit nagyon elrontottál... nálam egy egész portál főoldal lejön a kliens oldalig átlag 380ms alatt, és EJB van JPA-val különösebb cache nélkül, és ez nem egy combos gép, hanem egy több éves Sun x2100M2, amin egy csomó egyéb dolog is fut még, ezért ingadozik a válaszidő... hogy ne a levegőbe beszéljek: http://www.netdiag.hu/wdList_daily_HU.asp?d=120502&i=1481#08

Szóval én azért tolnék egy profilert a problémáidra, mert könnyen kiderülhet, hogy nem a JVM a lassú...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ne haragudj, de ennek szerintem semmi koze a Javahoz vagy a felsorolt egyeb technologiakhoz.

Java-ban is lehet szar es jo teljesitmenyu programot irni.

Az hogy olyan technologiakkal dobalozol, amik ebben a problemakban nem feltetlenul tudnak segiteni, az szamomra azt valoszinusiti, hogy nem a teljesitmeny problemat tenyleges okat probaltad kikuszobolni.

Gondolom, azt nem vitatod, hogy Java-ban lehet ugyanolyan gyors, sot gyorsabb programot is irni, mint PHP-ban. Magyarul, ha PHP-val megy valami eleg gyorsan, akkor azt Java-ban is meg lehet csinalni, valoszinuleg gyorsabbra is.

Sajnos a Java ecosystem tele van mindenfele raadas technologiaval, ami szep es csicsa viszont lassu. Ezeket nem kell hasznalni, es hogy ezek leteznek, ez nem mond semmit arrol hogy a Java nyelv jo vagy nem jo, gyors vagy lassu. Es persze megvannak a jol megtervezett es jol hasznalhato/teljesito Java alapu technologiak is.

A Spring valamilyen szinten mindket csoportba tartozik (jol megtervezett es jol hasznalhato, de van egy kis overheadje, kulonosen startupkor), bar nem okozhat onmagaban tobb szaz milliszekundumos problemakat, szoval ne keverd bele.

A CDN-ek, a memcache, az Oracle Coherence (igen, en is tudom, mi ez, szinte biztos, hogy sokkal jobban ismerem mint te, es eppen ezert nem ertem miert hoztad be a temaba) egyike sem fog neked segiteni, ha a dinamikus kereseket kiszolgalo infrastruktura bemeno pontja van szarul megtervezve/megirva/skalazva (pl. sorba allnak a kereseid hogy kiszolgaljak oket).

A browser sem lehet a problema oka, ha php-ban irt rendszer ugyanazon bongeszovel elfogadhato volt.

Szoval legy szives, probalj ne vakon vagdalkozni a Java, vagy az egyeb technologiak iranyaban, hanem probald a problema tenyleges okat megtalalni.

Miert gondolod hogy sokkal jobban ismered mint en?

Szerinted en mivel skalaztam fel website-okat?

Az osszehasonlitasi alap itt Springhez hasonlo kepessegekkel (nem feltetlenul azonosakkal, elegendoekkel) rendelkezo dinamikus nyelvi frameworkok.

Es hasonlitottunk mi build systemeket is, nem csak webeseket, egy anton hol a csicsa?

Azert gondolom hogy jobban ismerem az Oracle Coherence-t mint te, mert valoszinuleg sokkal regebben es sokkal melyebben dolgozom vele nap mint nap, mint te (vagy szinte barki mas Magyarorszagon... feltetelezem hogy Magyarorszagon dolgozol).

Nem tudom, mivel skalaztal fel website-okat, de ha azok PHP-ban voltak irva, akkor valoszinutlennek tartom, hogy ezzel.

> Az osszehasonlitasi alap itt Springhez hasonlo kepessegekkel (nem feltetlenul azonosakkal, elegendoekkel) rendelkezo dinamikus nyelvi frameworkok.

Ezt kifejtened kicsit bovebben? Tekintettel arra, hogy melyik kepessegekrol beszelunk es hogy befolyasolja az adott kepesseg egy rendszer futaskozbeni teljesitmenyet.

> Es hasonlitottunk mi build systemeket is, nem csak webeseket, egy anton hol a csicsa?

Build system: hogy is befolyasolja ez egy rendszer futas kozbeni teljesitmenyet? Egyebkent abban a postban amire valaszoltam, szo sem esett build eszkozokrol.

Az ant-ra es csicsara vonatkozo megjegyezesedet nem egeszen ertem.

Ja oke, hamis feltetelezesbol barmi kovetkezhet.

Nem Magyarorszagon csinaltam ezeket, vagy nem magyar ugyfeleknek, ezek ismert cegek ismert webalkalmazasai, ahol a skalazasi kovetelmenyek az itthoni szint tetejen (iwiw/bloghu) kezdodnek, es globalis a reach, ergo CDN.

Coherence-t valoban nem hasznaltam, javas peldanak hoztam fel, de PHP-ben se csak kispistike website-ja fut.

Spring-ben irt taszk-specifikus hello world webalkalmazas osszehasonlitasa mondjuk rails-ben irt ugyanilyen webalkalmazassal, tehat nem azt hasonlitva, hogy a servletek hogy viszonyulnak a mindentegybe php kodhoz.

Volt hogy az volt a kerdes, egy amugy nem javaban irt parszazezer soros alkalmazast mi rakjon ossze, ant vagy python vagy rhinojs. Az ant lassu volt. Azert hoztam fel peldanak mert a build egy relativ egyertelmu, csicsamentes dolog, nem lehet ra azt mondani, azon vitatkozunk a spring vagy rails vagy symfony-e a jobb es hogy ki hogyan configolta.

> Coherence-t valoban nem hasznaltam, javas peldanak hoztam fel, de PHP-ben se csak kispistike website-ja fut.

En pedig konkretan az Oracle Coherence-re mondtam hogy szinte biztos, hogy jobban ismerem mint te. De ott egyebkent igazan szinte mindegy, hogy szukitjuk-e a kort Mo-ra vagy sem. Szoval lenyegtelen hogy a feltetelezes hamis-e vagy sem.

Azt nem allitottam, hogy a tobbi emlitett technologiahoz jobban ertenek.

Nem allitom, hogy PHP-n csak kispistike fut, viszont hogy Coherence-t hasznaltal volna PHP-bol tobb website-on is az szinte kizarhato volt anelkul is hogy kozolted hogy nem hasznaltal Coherence-t...

Tovabbra sem ertem, hogy hogy egy task specifikus hello world webalkalmazas Spring-ben mennyire ad relevans informaciot a JVM illetve a Java nyelv sebessegere, merthogy ezt szidtad a post-ban amire valaszoltam. Egyebkent szerintem a fejlesztes sebessegere sem igazan relevans, mert azert egy hello world-re a Spring overkill.

Ha pedig konkretan egyes lapok fejleszteserol beszelunk, akkor a Spring elohozasa megint csak nem relevans, mivel a Spring pont hogy nem egy web lap fejlesztesi technologia, tehat a PHP-val nem egyenesen osszehasonlithato. A relevans technologiak inkabb a JSP/Velocity szintu technologiak. Ezek pedig azert sebessegre nem rosszabbak mint a PHP egy rendesen bekonfiguralt rendszeren.

A rails-t direkt nem hasonlitgatom, mivel nem ismerem, igy nem tudom konkretan minek felel meg.

>Volt hogy az volt a kerdes, egy amugy nem javaban irt parszazezer soros alkalmazast mi rakjon ossze, ant vagy python vagy rhinojs. Az ant lassu volt. Azert hoztam fel peldanak mert a build egy relativ egyertelmu, csicsamentes dolog, nem lehet ra azt mondani, azon vitatkozunk a spring vagy rails vagy symfony-e a jobb es hogy ki hogyan configolta.

Ezt a kerdest eddig ebben a forum szalban nem lattam felbukkanni, ezert nem ertem mi koze a Java sebessegehez egy konkret rendszerben amit peldanak hoztal fel.

Ezenkivul nem egeszen ertem, pontosan hogy akarsz osszehasonlitani egy build tool-t egy programozasi nyelvvel (python) es egy Javascript futtato kornyezettel.

Az en szemszogembol nezve, egy build tool-al ossze tudok rakni egy build-et eleg gyorsan, de ha egy darab python interpreterbol kellene mondjuk egy Java alkalmazast osszerakjak, valoszinuleg tovabb tartana (kellene keresnem egy python-ban irt build eszkozt, ha nem akarom megirni). Javascript-bol detto, tovabb sulyosbitva azzal, hogy nem egeszen ertem miert kene Javascript programoknak a winyomon turkalnia. Ha scriptelni akarok, akkor arra vannak tisztesseges shellscript nyelvek.

Valoszinuleg nem konkretan igy gondoltad a peldat, de ismetelten nem latom hogy almat hasonlitanal ossze almaval.

(a Coherence-rol masikon)

Van egy feladat. Epitsen olyan weboldalt amely. Ahhoz, hogy eldontsuk, ez melyik platformon fog futni, tobb variacio is letezik.

Az elso, es amit a legtobben csinalnak, hogy hat hasznaljuk azt, amelyiket ismerjuk. Ez az, amit az emberek 95%-a csinal.

Van meg aztan a hasznaljuk a legujabb buzzwordot. Maradek 4.9%.

Aztan van, hogy csinalsz egy prototipust, ami bizonyos szempontbol jol jellemzi az alkalmazast. Ez lehet annak egy modulja, egyszerusitett valtozata, esetleg egy szoveges konzolra firkalo mockup.

Ezeken elvegzed mindazokat a mereseket, amelyek ahhpz szuksegesek, hogy eldontsd, mit hasznalsz, ez lehet sebesseg, lehet API kezreallosaga, lehet featureset, sokminden.

Felallitasz esetleg 1-2 hipotezist, teszteled oket (mittom, hogy a java a te esetedben tenyleg annyival gyorsabb lenne, mint amit a framework oldalan irnak).

Ezek alapjan eldontod, melyikkel fogsz tovabbmenni.

Jott egy request arra is, egysegesitsuk antra a buildsystemet. Lemertuk, mennyivel lenne jobb. Az alkalmazas tortenetesen javascript, innen a rhinojs... (igen, js-t is kell buildelni nagyteljesitmenyu weboldalaknal)

De ehhez poliglot teamek kellenek. A java programozok jelentos resze, legalabbis lelekben, soha nem lepett ki a java buvkorebol, ha hasznalt is mas rendszert, azok egyejszakas romancok, futo kalandok voltak csak, eme egyetem ota mukodo hazassagot nem adnak fel rendszerint.

Szoval igy jon ossze itt a lassusag, a jvm, az ant.

Bocs, nem birtam igazan kovetni.

Ha azt mondjak tervezzek egy rendszert, legeloszor is kivancsi vagyok az osszes use case-re hogy ki tudjam valasztani a legnagyobb eroforrasigenyu use case-eket es megnezem azt mivel lehet hatekonyan leimplementalni.

Ez nyilvanvaloan nem a bongeszoben futo resz lesz.

Erre kell valami prototipust csinalni, es itt nem az a lenyeg, hogy mit ismerunk, hanem hogy milyen technologiak leteznek. Erre vannak a contractor-ok es pre-sales-esek hogy POC-t csinaljanak.

Majd ha van tobb olyan technologia ami mindegyike meg tudja csinalni, majd akkor lehet valasztani. Ha csak egy van, akkor valasztani se kell. Ha meg egy sincs, akkor valtoztatni kell a requirement-eken.

A bongeszoben futo reszek megvalosithatosaga teljesen fuggetlen kene legyen a szerver oldali technologiatol. Azokat a HTML lapokat es JS artifactokat barmilyen technologiaval ki kell tudni adni a bongeszonek. Persze ez nem mindig biztosithato, vegul is nem kene nekiallni push technologiat irni nullarol ha hasznalhatunk lightstreamer-t vagy hasonlo dolgokat, es ez valamilyen szinten korlatozza mi lehet a szerver oldalon.

De eloszor a server oldali technologiat kell jol megcsinalni, vegul is az az ami a vegfelhasznaloi elmenyt befolyasolja, raerunk build toolt utana valasztani hozza. Egy build instruktor rendszert mindig konnyebb osszehozni meg nullarol mint egy nagy rendszer teljes architekturajat tehat nem a build rendszer alapjan kene donteni, azt majd valasztani vagy nullarol irni kell a rendszer eszkoztarahoz illeszkedoen.

Ez ket kulon pelda volt, a weboldal es az ant, nem illenek ossze ugymond.

Nyilvan ez mar az a fazis, ahol a fo use case-eket tudjuk, foleg, mert heterogen rendszer volt itt ez a webes valami, es a kulonbozo feature-ok futhattak kulonbozo rendszreken, mert nagy volt a letrehozo szervezet, igy nem egy teljes rendszer osszes use case-erol beszelunk.

Nem nyilvanvalo viszont, hogy a main use case-eid nem a bongeszoben futnak, sot: ha megnezel egy atlagos consumer app vcs logjat, azt latod, hogy a legtobb change request a feluletekre, ill. feluleti viselkedesekre megy. A legkevesebb valtozast a szerveroldali business logic szenvedte el azon az appon amit epp ket hete neztem.

Mindig arra szoktam embereket kerni, kepzeljek el azt, hogy az alkalmazas mint olyan a felhasznalo gepen fut (a bongeszoben), es a szerveroldal pusztan domain-szintu koherenciat biztosit az adatok felett. Ez sokmindent megmagyaraz. A felhasznalo szamara A program az, amit lat, marpedif az a UI.

De nyilvan a szerveroldal (is!) tud bottleneck lenni, es a kerdes az, milyen gyorsan hajtja vegre a sok felhasznaloi kerest az adatok modositasara, mikozben biztositja ezt az alkalmazas-specifikus koherenciat. Ezt mertuk le altalaban

A Coherence-rol meg annyit, hogy javas peldanak is kicsit felresikerult, mert ezerszer tobbet tud mint a memcached amivel ekvivalens Java alapu peldanak hoztad.

A memcached se csak get/set, de hozhattam volna redis-t vagy couchdb-t, van ahol azt hasznaljak memoriaban futtatva...

Nyilvan feladatfuggo, de abban gondolom egyetertunk,a coherence-t arra hasznalod, hogy egy nagy es kompley alkalmazas sebesseget feltornazd.

Nem ertunk egyet.

Dolgoztam mar olyan alkalmazason is, ahol az egesz alkalmazas alapja volt Coherence es erre epitettunk ra mindent, es alapbol kaptuk a hibaturest, a horizontalis skalazhatosagot, a kommunikaciot es az esemeny kozvetitest a rendszer reszei kozott es emellett lassu sem volt, nem pedig csak utolagosan hozza lett csapva egy rendszerhez, hogy lassu dolgokat cache-eljunk vele.

Jo, erre en nem hasznalnek coherence-t, ezek nalam kulonbozo komponensek lennenek, kulonbozo nyelveken irva, aminek ugyan a horizontalis skalazasat a kozos, horizontalisan skalazodo memoria es permanens tarai adnak, de ez nem jelentene feltetlenul egyetlen technologiat.

De ez valoszinuleg izlesbeli kulonbseg is, faznek ha ezt mind egy komponens csinalna.

En meg nem szeretem ha sok kulonbozo komponens lehetseges hibaitol mind fuggok es emellett meg a koztuk levo adatmasolgatas koltseget is meg kell fizessem.

Itt nem masodperc koruli valaszideju rendszerrol beszelunk. A mi jellemzo end-to-end valaszidonk 10-30 ms korul volt, jellemzoen kozelebb a 15-hoz mint a 30-hoz. Az end-to-end itt azt jelentette hogy tobb gepen futo tobb alkalmazason atmeno kliens kezdemenyezte request teljes kiszolgalasat merte a request beerkezesetol a response kikuldeseig.

Ebbol egy alkalmazas volt Coherence alapu a fent emlitett architekturaval, de itt a request feldolgozas ideje ebben az alkalmazasban altalaban 5ms vagy kevesebb volt (request az alkalmazasba erkezesetol a valasz uzenet kikuldeseig). Ez tortenetesen egy komplett kereskedesi rendelesmenedzsment rendszer volt, szoval nem kimondottan a "szolgaljunk ki valami lenyegtelen adatot, es ha lehalunk, majd adunk egy hibauzenetet hogy probalja ujra" tipusu rendszer. Jo, nem kellett csicsa UI-t irni hozza, a bemenet egy uzenet volt a kimenet meg egy vagy tobb es az adatbazisba is irkalt, de semmi tobb.

Kulonbozo komponensek kulonbozo nyelveken kulonbozo technologiakkal irva csak a kommunikacios lepesek, a hibalehetosegek es a felesleges adatkonverziok szamat novelik. Koszi szepen, de ilyesmire nem igazan van szuksegunk egy alkalmazason belul. Eleg ha kulonbozo alkalmazasok kozt kell dragan kommunikalni, egy alkalmazason belul szeretnek atadni egy objektumot, es biztos lenni hogy at tudom venni.

Ha pedig azt a horizontalisan skalazodo memoriat tavolrol ered el (ertsd masik process-bol put/get-szeru keresekkel), az adott esetben mar tul lassu tud lenni. Nekunk az volt.

"alapbol kaptuk a hibaturest"

Vagy a csoportos mely repulest, ha sikerul triggerellni egy lockolassal usszefuggo bugot bene.

Es, ha proglamolok sok erdekes dolgot gyurnak ossze - atgondolt java frameworkokben :) - varatlan lehet egy ket NotSerializableException is..


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Turul,

te most tudod hogy mirol beszelsz vagy vagdalkozol agyba fobe?

Szerinted ?
Nekem is volt szerencsem, es ismerek par konkurens megoldast is. Es komoly ketsegeim vannak afelol, hogy az osztalybol a Coherence vizsgazna a legjobban.
Egyebkent csak subscribe. (nincs sajat meresem)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

> Nekem is volt szerencsem, es ismerek par konkurens megoldast is. Es komoly ketsegeim vannak afelol, hogy az osztalybol a Coherence vizsgazna a legjobban.
> Egyebkent csak subscribe. (nincs sajat meresem)

Magyarul csak vagdalkozol.

Csak viszonyitaskepp, egy olyan termekrol beszelsz ami 12 eve van a piacon, folyamatosan fejlesztik es javitjak, es a vilag legnagyobb befektetesi bankjai mind hasznaljak (esetleg a kinaiak kivetelevel).

Ha ilyen "ha csak nem futsz bele egy deadlock-ba" hibak lennenek benne javitatlanul (ertsd ha zur van nem javitjak ki nagyon gyorsan), akkor nem hasznalna mindenki.

En majdnem 7 eve hasznalom (es nem put/get stilusban), es nem volt olyan gondom vele ami akkora problemat okozott, hogy ne tudtam volna kijavitani a rendszert hogy ne legyunk kiteve a hibanak.

Ez nem a jgroups/jboss kategoria... ott vannak olyan problemak hogy valamilyen esetet szandekosan figyelmen kivul hagynak, mert tul bonyolult lenne.

Ami meg a mereseidet illeti... a Coherence mint termek fejlesztesenel nem a leggyorsabb, hanem a legmegbizhatobb es a legskalazhatobb a ket legfontosabb cel. Ezzel egyutt meg gyors is, de nem fognak belehalni ha egy megbizhatatlan versenytars 10%-al gyorsabb...

> ... NotSerializableException...

Igen, volt par gond ilyesmikkel korabban... ugyanakkor ez nem olyasmi ami nem jonne elo teszteles kozben, es nem lehetne a sajat kodban levo hiba kijavitasaval orvosolni. Es szerintem ezek mar javitva vannak a friss release-ekben es patch-ekben.

Alternativakent van eleg framework/library/compile-time-tool ami az osztalyok (de)szerializalasaval foglalkozik.

"Csak viszonyitaskepp, egy olyan termekrol beszelsz ami 12 eve van a piacon, folyamatosan fejlesztik es javitjak, es a vilag legnagyobb befektetesi bankjai mind hasznaljak (esetleg a kinaiak kivetelevel)."

- A referalt bug amirol tudok hogy javitottak nehany eves volt, en csak egy nagyon hasonlo jelenseget lattam 1-2 eve. Ugyhogy nem erdekel, hogy 12 vagy 3 eve van.
- Az vegkep nem erdekel, hogy milyen multi-milos cegek fejlesztik, meg veszik, mert lattom, hogy ez SEMMIT sem jelent minosegi oldalrol, sot... (mellesleg a mutimilios ceg sem olyan regen vette.)

- Ep a minap volt ujra inditva egy rendszer (mind a "KET" egesz node :) ), mert az oszhang nem volt tokeletes, network vagy a coherence a gyanus elem (network elemeket gyarto ceget is szidtam mar itt, volt olyan hogy elfelejtette mi a multi-cast :) , bar az 4 firmwarrel ezelott volt ), mivel evente kevesebb, mint 2x van ilyesmi es rendszer sem anyira kritikus nem firtattam most.

FYI: a jgroups az egy alacsonyabb layer es tobb mas eszkoz is hasznalja, a jboss konkurens magasabb retegenek a neve: infinispan.

Teljesitmenyben nem az egyetlen ami akkar joval tobbet verne ra, mint 10% masok meresei alapjan.

"hogy valamilyen esetet szandekosan figyelmen kivul hagynak, mert tul bonyolult lenne."
p2p stulusban replikalni bizony bonyolult, remelm nem arra celzol, hogy szandekosan instabil mukodest ideznek elo, hanem arra , hogy lehetne meg gyorsabb is nehany esetben.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

> - A referalt bug amirol tudok hogy javitottak nehany eves volt, en csak egy nagyon hasonlo jelenseget lattam 1-2 eve. Ugyhogy nem erdekel, hogy 12 vagy 3 eve van.

Konkretan mi is volt a hiba? Jelentettetek az Oracle-nek? Kaptatok ra workaroundot? Feldobtatok legalabb a forumra?

Tudod hogy hany tobbeves hiba van a Jgroups-ban?

> - Az vegkep nem erdekel, hogy milyen multi-milos cegek fejlesztik, meg veszik, mert lattom, hogy ez SEMMIT sem jelent minosegi oldalrol, sot... (mellesleg a mutimilios ceg sem olyan regen vette.)

En meg azt latom, hogy sokkal minosegibb es megbizhatobban uzemeltetheto termek mint sok mas... Nem azt allitom hogy hibatlan, csak azt hogy ha esszel hasznalod akkor megbizhato.

> Ep a minap volt ujra inditva egy rendszer (mind a "KET" egesz node :) )

Esetleg a hasznalati utasitast is el kene olvasni. A recommended minimum fizikai gepszam 4 (a witness protocol maximalis megbizhatosaga miatt), a balanced particio-elosztas eleresehez szukseges fizikai gepszam 3.

A 2 fizikai gepes cluster eseten nem biztosithato hogy a rendszer mindig egyenletesen osztja el a particiokat, es problemat okozhat az is hogy ha kommunikacios problema van a ket box kozott, akkor mindketto azt hiszi hogy o maradt eletben egyedul (mas neven split-brain) (nincs tovabbi resze a clusternek ami alapjan el lehetne donteni hogy a vesztes vagy nyertes felben van...).

Emellett ajanlott meg egy halom dolgot betartani (minden Coherence node azonos switchen es azonos subneten legyen, pl.), ne swappoljon a rendszer, es persze elotte bemerni a halozatot a vele adott tesztprogramokkal, stb.

> FYI: a jgroups az egy alacsonyabb layer es tobb mas eszkoz is hasznalja, a jboss konkurens magasabb retegenek a neve: infinispan.

Tudom mi a jgroups es az infinispan. A jgroups alapu dolgoknak (pl. JbossCache) volt tipikus hibaja az, hogy bizonyos esemenysorokkal olyan helyzetbe lehetett kergetni a rendszert amit az nem kezelt le.

> p2p stulusban replikalni bizony bonyolult, remelm nem arra celzol, hogy szandekosan instabil mukodest ideznek elo, hanem arra , hogy lehetne meg gyorsabb is nehany esetben.

Nem, en arra celoztam, hogy az egyeb termekek (nem a Coherence) tervezesenel eleve nem vesznek figyelembe minden eshetoseget, akkor sem ha tudnak rola, mondvan hogy ez ugysem tortenik meg, ugysincs szuksege ra senkinek, stb.

Es mellesleg egy data-grid eseten nem csak arrol szol a dolog, hogy p2p stilusban replikalsz, hanem arrol is hogy meg veletlenul se viselkedhessen a rendszer nemdeterminisztikus modon, ami egy p2p filecserelo rendszernel toleralhato, de egy data-gridnel altalaban ellentmond az elvart konzisztencia garanciaknak, es emellett minel kevesebb felesleges forgalmat generalj a halozaton, tehat ne tologasd az eppen hasznalt adatodat ide-oda feleslegesen.

"Konkretan mi is volt a hiba? Jelentettetek az Oracle-nek? Kaptatok ra workaroundot? Feldobtatok legalabb a forumra?"

Javitva lett tudomasom szerint. Nem az Oracle-tol kaptuk, egy termekkel egyutt erkezik.

"Tudod hogy hany tobbeves hiba van a Jgroups-ban?"

Miben nincs ? Attol meg, hogy valminek nem publikus az issue trackere nem jelenti azt, hogy hibatlan.
High severity, confirmed ?

A gyarto mas (joval regebbi :) ) termekinel nem nehez tobb eves javitatlan hibakat mutogatni, ez miert lenne mas ?

- A coherenct (itt) nem mi valasztottok, jott egy termekkel egyutt.

Nincs igazan "nagy" mennyisegu adatrol szo. Csak inkabb redundancia miatt van ket node.
(Az esszerusege valoban megkerdojelezheto, regi dolog ez)

Volt hasznalva coherence mulitcast testere, az mutata ki, hogy megdoglott multicast a halozati eszkozon anno.

"Nem, en arra celoztam, hogy az egyeb termekek (nem a Coherence) tervezesenel eleve nem vesznek figyelembe minden eshetoseget, akkor sem ha tudnak rola, mondvan, hogy ez ugysem tortenik meg, ugysincs szuksege ra senkinek, stb."

Ez rendkivul sullyos vad.
"ugysem tortenik meg" race condition ...

Nem hiszem, hogy aki igy gondolkozik ilyesmi kozelebe engedik.
Na jo, mar reg nem vagyok ennyire naiv.

"Coherence" -nel miert hiszed azt, hogy nem igy tortent ? Ha nem te fejlesztetted szemelyesen es nem bizonyitottad formalisan, akkor nem lehetsz bene biztos.

Es miert hiszed azt, hogy a tobbinel veletlenul sem probaltak minden lehetoseget figyelembe venni ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Egyetertek crystal88-cal, illetve szerintem vagy eltulzod a JVM problemait, vagy pedig a szemelyes velemenyedet kevered az objektiv ervekkel, mindketto rossz iranyba viszi a dolgokat.

Amit tisztan kell latni, hogy a Java nagyon regota a piacon van. Rengeteg rendszer epul ra, rengeteg rendszer hasznalja. Meg ha lenne is egy jobb JVM, az se valtoztatna az egvilagon semmit, mert mint azt architektkent nyilvan nagyon jol tudod, mukodo rendszer gyokereit nem igazan piszkaljuk. Mint ahogy egy haz alapozasat sem csereljuk ki azert, mert ujabban mennyivel jobb alapozasi technikak vannak.

Lehet a Javat szeretni es nem szeretni, ugyanigy lehet a JVM-et szeretni es nem szeretni, de a Java/JVM sosem lesz olyan mertekben levaltva, mint a SOAP. Errol meg csak beszelni sem erdemes.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nyilvan, ma is futnak Cobol rendszerek, sot, vannak nyitott Cobol fejlesztoi poziciok.

En csak szeretnem a Java-t hasonlo tortenelmi keretben latni vegre tehat legacy platformkent, amit inkabb wrappelunk semmint projektet inditunk benne.

Erdemes beszelni rola, mert amig nem kezdunk el arrol beszelni, hogy gyerekek, ez a cucc otletszinten nem koser, es nem biztos hogy azok az emberek, akik ezt kitalaltak, tenyleg jo otlettel alltak elo, ami kiallja az idok probajat, addig nem fogunk elorejutni.

Nyilvan keverem egy picit erzelmekkel. A runtime meresek objektiv kijonnek, de utana a csomo vakbuzgo javassal leulni vitatkozni qrvaszar, tudod? Plane egy javas cegnel, ahol a fejlesztok el se tudjak kepzelni azt a helyzetet hogy a java nem a vilag legjobb nyelve (ill. van egy halvany felelmuk, hogy mivan, ha megiscsak a C#.NET az, de az a sotet oldal muve), a dinamikus nyelvek nem jatekszerek, a felhasznalo pedig nem az az idiota aki igy-is-ugy-is utalja a gepet, hanem aki ha nem elegedett, akkor b.szhatjuk az egeszet, nem tettuk jobba a vilagot, barmilyen szep is a program.

Sz'al nem allitom hogy nem keverem bele az erzelmeket. De a JVM-et ettol meg a hatam kozepebe se kivanom, es a mereseimben sem teljesitett jol.

Hat, tudod a mérések is olyanok, mint a Biblia. Az ember azt olvassa ki belőle, amit szeretne. Erre szoktam azt mondani, hogy a Bibliaban ez áll: "Ajándékaikat a kisded elé tevék" tehát akkor most beszéljünk a tevékről...

Volt szerencsem latni hihetetlenul nagy Java alkalmazast gyakorlatilag a PHP-val megegyezo valaszidovel, es volt szerencsem (?) latni olyan PHP alkalmazast is, ami annyira lassu volt, hogy folyamatosan kapargattam szegeny, sokat szenvedett falamrol a tapetat.

Szoval, sajat tapasztalatomra alapozva, en eroteljesen ketlem, hogy akara Java, akar a JVM teljesitmenyproblemakkal kuzdene. Egy P2-P3 vason, esetleg. Meg talan ha nagyon keves memoriat adok neki. Vagy egy rosszul megvalasztott framework-kel. Nem veletlen, hogy szegeny java-listas tagokat is azzal nyuzom, hogy ne azt mondjak el nekem, hogy a Spring hogyan mukodik, hanem hogy a JSP meg a JSF egyaltalan. Mert ha megismerem az alapveto technologiakat, amiket maga a gyarto kinal - kvazi beepitetten -, akkor arra mar lehet epitkezni. De persze en sok szempontbol kulonc vagyok.
Amire viszont ki szeretnek lyukadni: nagyon sokszor azt latom, hogy az eszkoz valaszt maganak celt, illetve emberek olyasmire akarnak hasznalni bizonyos eszkozoket, amire azokat soha nem terveztek, meg kevesbe keszitettek fel. Egy projekt lassusaganak jo reszet (sot, donto reszet) ez adja, es csak nagyon kis szazalekban az, hogy az adott nyelv/VM lassu.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Aki "ha úgy adódik", PNG-ben akar bytestreamot továbbítani, szerintem ne papoljon "felelős architect magatartásról". Köszi.

----------------
Lvl86 Troll - Think Wishfully™

Bocsanat, hogy erre van C-sebessegu API a bongeszokben, es bocsanat, hogy a vilag smartphone-jainak es desktop gepeinek 100.00% -an van hozza tamogatas.

Igazan sajnalom, hogy gondolkodom, nem csak vagyok.

De hogy megnyugtassalak, most epp ezzel jatszom: https://github.com/mapbox/mbtiles-spec/blob/master/1.1/utfgrid.md - kb. ugyanarra jo mint a mi PNG-s megoldasunk ( http://www.patrick-wied.at/static/heatmapjs/ - ezen alapul) csak mondjuk a PNG mondjuk megcsinalja a tomoritest is, meg akkor nekunk pont negy bajt-tipusu adatot kellett eltarolni (es bongeszon visszahivni) egy-egy pontrol, igy pont passzolt. Meglatjuk, mit hoz egy sebessegteszt a ketto kozt kulonbozo bongeszokben...

Bocsanat, azert, mert szar (hianyos) az API, azert hadd ne udvozitsek egy nyilvanvaloan workaroundot.

----------------
Lvl86 Troll - Think Wishfully™

Az ertelmetlen udvozites es a felesleges leszolas kozott a hallgatas tagas birodalma terul el.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

OMFG

Aadaam mar megint eszt oszt, menekuljunk!

Nekem a Scalaról mindig az amigás teletext és feliratozó progi jut eszembe.
Aztán 10sec és leesik, hogy nem. De minden esetbe beszopom. Hiába vén vagyok..

pch
--
http://www.buster.hu "A" számlázó
--

Ész a Scala-Coop? ;)

Nekem meg egy könyvelő program valamikor a 90es évek derekán, már persze ha jól emlékszem az időpontra.

Ja, hogy itt nem errol van szo? :D

--
Fedora, RHEL, CentOS, virtualizáció, SELinux: http://sys-admin.hu

Nem vagy egyedül.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Nekem igy elso blikkre mondjuk... Scala... aztan mondjuk... Skála. De persze en is venulok mar...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A hozzászólások nagy része nem a scala-ról szól, úgyhogy talán nem feleslegesen bővítem ezt a topicot, hisz lassan egy éve ebben fejlesztek.

A jó: a koncepció tetszik, egy erősen típusos nyelv, funkcionális ficsörökkel, minimalizálandó a kód hosszát. S mindez JVM-re, szóval nem kell vadászni a libeket, ha valamire szükség van, könnyen lehet használni bármit. Jó a REPL, nem sok kellene ahhoz, hogy konzolon alapból az fusson, ne a bash :)

A rossz: sok mindent újra írtak scala-ban, amit én megkérdőjelezhetőnek érzek. Pl, miért nem kompatibilis a scala-s List/Map/Set a java-sokkal, pláne, hogy van mutable és inmutable változat is belőle. Az sbt hasonlóan feleslegesnek tűnik. A nyelv nagyon flexibilis, sőt túlságosan is az. Pl, olyan triviális dolog, mint a package deklarációval és más osztályok beimportálásával is hosszasan el lehet szívni. Megfejelve az implicit függvényekkel, már ember legyen a talpán, aki első blikkre meg tudja mondani, pár sornyi scala kódról, hogy az mit csinál - s ha azt az 5 sort átmozgatja egy másik fájlba, akkor miért nem fordul le hirtelen. Másik nagy probléma, hogy az előre-hátra kompatibilitással nem nagyon foglalkoznak, ami 2.8-ban simán lefordult, az 2.9-ben nem biztos hogy működni fog. Bináris kompatibilitásról meg ne is álmodjunk.

A csúnya: az IDE. Az katasztrófa, még ha fejlődik is. Az inkrementális fordítás - az ami mentéskor elindul - 10-30 másodpercig lefagyasztja az eclipse-t, ráadásul rendszeresen kell clean buildet nyomni, mert annyira megbolondul... Auto-complete működik, ide-oda ugrálni lehet a kódban - kivéve, amikor úgy gondolja nem - viszont java-nál megszokott fejlettebb funkciók hiányoznak, mint pl osztály vagy mező átnevezés, vagy akár csak a call-hierarchy megmutatása.

Azzal mi a tapasztalatod, hogy mennyire könnyű egy nagyobb projektet átlátni benne? (Nekem, mivel IDE támogatás zéró, már kis projektnél is elég gáz élmény volt.)

A másik ami valszeg el van baltázva az az Akka actorok közötti üzenetek, ugyanis semmilyen specifikációt nem találtam, amivel szűkíteni lehetne hogy egy-egy csatornán mik mehetnek, ami pedig egy nagyobb kódnál lényegében katasztrófa kategória.

Az átlátást nagyban segítené, ha a call-hierarchy működne. Így sem mondom nagyon átláthatatlannak, de ebben benne van, hogy ezt látom nap mint nap, úgyhogy sejtem mi merre hány méter :)
Pár dolgot deklaráltan nem használunk, egyik ilyen az aktorok, úgyhogy erről nem tudok nyilatkozni. Az biztos, hogy az össze-vissza üzenet küldés nem lehet nyerő :)

Melyek azok a jellemzői a Scalanak, melyek kifejezetten előnyösek annál a projektnél? Vagy szimplán abban kezdték el és úgy maradt? :)

> Az biztos, hogy az össze-vissza üzenet küldés nem lehet nyerő :)
Itt arra utalsz, hogy a típustalan aktoroknál lényegében castolnod kell? (Pattern matching) Úgy sejtem, hogy az Akka aktoroknál ez elkerülhető a TypedActorral. Az össze-vissza üzenet küldés pedig szerintem az OO alapja. ;) Elég csak a SmallTalkra gondolni mint a legOObb nyelvre, bár az Erlang megalkotója szintén szeretne ugyanerre pályázni épp az üzenetküldés lehetősége miatt. (A metódushívás egy üzenetküldés az objektumnak, nekünk legalábbis még így tanították, bár elsőre azt hiszem nem értettem, hogy ez miért fontos, miért érdemes így tekinteni erre. Hiába elég lassú felfogású vagyok.)

A rosszhoz:

  • automatikus ; posztfix operátorokkal (pointfree zero-arg method call)
  • némely projekt túlzásba viszi a szimbolikus neveket, a DSL-ek néha kompromisszumokra kényszerülnek
  • kezdők gyakran felejtik el, hogy ha egy metódus :-ra végződik, akkor a következő kifejezésen hívódik meg az előzővel paraméterként, nem pedig az előzőn a következővel paraméterként
  • az impliciteket szintén túlzásba szokták néha vinni
  • elég lassú a fordítási sebesség (de egy Turing-teljes típusrendszernél ez sajnos velejárhat, illetve folyamatosan igyekeznek ezen javítani)
  • a tömbök kissé mostoha gyerekek
  • XML kezelés a nyelven belül - ezt talán sikerül majd kiszervezniük
  • a _ elég sok mindent jelent
  • hiányzó syntactic sugar a type projection-re
  • a Java interface -a láthatósági szabályok miatt- nem feltétlen az, amit a Scala definíció alapján elvárhat a programozó, ez lehet biztonsági probléma
  • vacak (na jó más) enum kezelés, ez remélem a makrókkal változhat

Ami a te rossz részedet illeti:

  • a libek szerintem egész jól megalkotottak, ha inkább a Java-s/guavas collectionöket szeretnéd használni megteheted, bár szerintem nem érdemes (esetleg érdekelhet a Mirah programozási nyelv...)
  • forrás szintű kompatibilitásra valamelyest figyelnek a 2.x szomszédos verziói között, de kétségtelen, hogy ha szükséges akkor változtatnak (leggyakrabban az experimental részeken, illetve elavulási (deprecation) időszakkal); bináris kompatíbilitás pedig már jelen van a 2.9.x óta az egyes változatokban, bár kétségtelen, hogy a hivatalos builden -egy JVM váltás miatt a build szerveren- előfordulhat serialization probléma ezek között is.

A jó:

  • pattern matching
  • continuations
  • funkcionális programozás lehetősége (funkcionális adatszerkezetek, for comprehensions, magasabb rendű függvények, ...)
  • objektum orientált programozás lehetősége (kiegészítve a sealed opcióval)
  • egyszerűbb párhuzamos programozási API (az aktor model nekem tetszik)
  • helyes és fejlett típusrendszer (nincsenek ClassCastException-ök futtatáskor, hacsak nem castoltál, Java-ra ez nem igaz)
  • type inference
  • traits, objects
  • nagyon finom láthatósági opciók
  • nagyszerű nyílt forrású projektek

IDE: Nem tudom, hogy melyiket használod, de talán segít ha leírom a tapasztalatomat az eclipse-szel és az IDEA-val:
eclipse (3.7, ScalaIDE 2.0; mavennel akadhatnak kisebb gondok, anélkül használhatóbb, persze lehet, hogy csak én vagyok a béna):

  • van incremental compilation, de a függőségkezelése lehetne egy picivel jobb (helyes, de néha túl sokat fordít), érdemes az sbt build managert használni
  • van osztály, mező, metódus átnevezés
  • call hierarchy volt néha :), ebben épp nem működik

IDEA:

  • nincs incremental compilation, de használható az fsc - fast scala compiler, ami jelentősen lerövidítheti a fordítási időt (bár kétségtelen, hogy ez a rész is kerülhet inkonzisztens állapotba)
  • van osztály, mező, metódus átnevezés
  • call hierarchy szépen működik
  • build toolok jobb támogatása

Igen, a kettőspont kezelés kicsit meglepő - jó, az is megérdemli, aki kettőspontot rak metódusa nevébe, de néha ez van az operátorban. Ahogy az is elsőre meglepetést tud okozni, hogy a következő kód mit csinál :

val Pi = 3.14
val e = 2.71
val x = 1.5

x match {
case Pi => println("Pi")
case e => println("e")
case _ => println("valami")
}

Oké, logikus ha tudjuk az összes szabályt, de azért a kevesebb jobb lett volna.
Én a json lib-jében találtam inkompatibilitást a 2.8 - 2.9 között, egy konstruktor szignatúra megváltozott, annyira nem core dolog, de nem örültem neki.
Ezt a Mirah-t megnézem, én eddig az Xtend-det próbálgattam, ami szintén nem tűnt rossznak, és még eclipse plugin is van hozzá.
Amúgy Eclipse-ben próbálok programozni, sbt build managerrel, van 8 projekt, egymásra hivatkoznak, s gyakran kell a clean-t nyomogatni. Lehet el vagyok átkozva, mert nekem az átnevezésnél internal error-okat dob, úgyhogy arra jutottam, hogy ez valójában még nincs :)
Most nem jut eszembe egy példa sem, de hogyan tudsz előidézni ClassCastException-t java-ban cast-olás nélkül? Most csak NPE jutna eszembe, ha az autoboxinggal trükközünk.

Ó, igen, a pattern matchnél nagy kezdőbetű kell (hasonlóan a Prologhoz, ha nem csal az emlékezetem), vagy aposztrófok.
Igen, 2.8 és 2.9 (vagy 2.9 és 2.10) között is voltak/lesznek inkompatíbilitások, bár forrás szinten azért igyekeznek működőképesek maradni. A JSON könyvtáruk -mostanra saját bevallásuk szerint is- inkább csak prototípus jellegű, kb. jé ezt is meg tudjuk csinálni felkiáltással készült. Szerintem előbb-utóbb kiveszik a könyvtárból, de már most is mást javasolnak helyette.
CCE: a fő ok, hogy Java-ban (vagy C#-ban) a tömb nem invariáns (hanem kovariáns):
Object[] arr = new String[1];//covariance
arr[0] = Integer.valueOf(1);//CCE

Természetesen így könnyű látni a hibát, de ha ez már egy függvényhívás mögé van rejtve, akkor nem biztos, hogy előtte eszedbe jut lemásolni a String tömböd egy Object tömbbé.

Amúgy a NullPointerException-ök sajnos Scalaban sem automatikusan kikerülhetőek, oda kell figyelni, de az Option típus azért segíthet a kezelésében. :)

Az interfesz implementalasok JRuby-ban is erdekesek, a mai napig nem vagyok kepes olyan com.sun.net.httpserver.HttpHandler -t implementalo osztalyt csinalni, ami faszan beillesztheto lenne egy HttpServer ala.

Szerk: jeee... ugy nez ki, a sracok fixaltak valamit, most a legujabb JRuby-val mintha menne...
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ah, végre egy nem fröcsögő, értelmes hozzászólás. Köszi.