Tapasztalatod szerint a Scala már alkalmas nagy projektekhez?

NetBeans?
--

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

"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.

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 

"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 ;)

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™

Igen? :)

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?

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.

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...

> 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 meg annyit, hogy javas peldanak is kicsit felresikerult, mert ezerszer tobbet tud mint a memcached amivel ekvivalens Java alapu peldanak hoztad.