A Google szerint túl bonyolult a Java és a C++

A Google szerint túl bonyolult a Java és a C++
2010-07-27T02:56:49+02:00
2010-07-30T17:50:27+02:00
2022-10-27T11:45:33+02:00
  • Így van.
    Mutasd a teljes hozzászólást!
  • Inkább meg kéne sütni őket.
    Mutasd a teljes hozzászólást!
  • Bizony, de ha nehez ertelmes kacsat talalnunk, akkor megprobalunk ertelmesebb vizet eloallitani a buta kacsak szamara!
    Mutasd a teljes hozzászólást!
  • Azt azert megjegyeznem, hogy ha a kacsa nem tud uszni, nem feltetlen a viz am a hulye.
    Mutasd a teljes hozzászólást!
  • "HPC az smafu? Vagy szimulációk? Kutatások?"
    Az ilyesfajta fejlesztések költségigénye közel egy súlycsoportban van az AAA játékprogramokéval.
    Hazánkban talán a kutatásra valamivel kevesebb pénz jut... sajna
    Mutasd a teljes hozzászólást!
  • Lol mindenki csak AAA játékban és 3d engineben tud gondolkozni... HPC az smafu? Vagy szimulációk? Kutatások?

    Persze a grafika és a hpc olyan terület, ahol mindig is maxon kell pörgetni a hardvert, de az már megint más téma...
    Mutasd a teljes hozzászólást!
  • Az a minimális gyorsulás nem éri meg azt az iszonyatos többlet költséget amely csak azért keletkezik mert C++-ban kell fejleszteni.
    Egy AAA típusú játékprogramnál ahol tengernyi pénz áll rendelkezésre megéri, de egy ügyviteli alkalmazásnál nincs értelme.
    Mutasd a teljes hozzászólást!
  • Gyors lesz, de én ügyvitelt írtam. Ott mi lesz a gyors? Gyorsabban a GDI ablak nem fog kirajzolódni, a WPF meg ugyanúgy dx-et használ max az interopolásra megy el egy kis idő. Picit kevesebb FPS-el forog a torta diagram, nem gond. Az adatbányászat se a nyelven múlik, hanem a db motoron. Olyan szuper algoritmusok meg egy ügyvitelben nincsenek, az üzleti logikát meg a C#/Java is simán elbírja.

    Viszont a nyelvbe ágyazott lekérdezés, reflection/újabban dynamic, egyéb fejlesztést segítő dolgok a fejlesztési idő gyorsítják. a fejl idő és a futási sebesség ált fordítottan arányos akárhogy is ragozzuk.

    Ügyvitelt QT-ben bohóckodni C++ al, meg WPF-ben C# al az ég és föld. Editor program írása az más tészta, arra lehet hatékony az első megoldás is.
    Mutasd a teljes hozzászólást!
  • Szerintem azok akiről te beszélsz nem fognak dolgozni a szakmában, nem is akarnak.


    False. Jelenleg rá vannak kényszerülve a cégek, hogy milliókat öljenek a pályakezdők tanításába az első egy-két évben, különben nem lenne utánpótlás. Nyilván vannak kivételek, talán éves szinten 10-12 ember az egész országban, akik már egyetem alatt is dolgoztak.
    Mutasd a teljes hozzászólást!
  • Szerintem azok akiről te beszélsz nem fognak dolgozni a szakmában, nem is akarnak. Remélem legalábbis.

    Aki itt íratja meg az egyetemi feladatokat úgysem fog soha önállóan megoldani semmit. Aki "nem ér rá" majd a mekdonalcban ráér felszolgálni.

    Ezek nem fognak tanulni, márpedig a google nyelvét is meg kéne, még ha egyszerű is.
    Mutasd a teljes hozzászólást!
  • Szerintem nézz körül nyugodtan. Nem "lesz", hanem van...

    (lásd pl: a progmat szakra felvettek középiskolai matek átlaga (HVG tavaly); valaki itt elvárja másoktól a kötprogramja elkészítését, mert "nem ér rá"; mennyiben arányos a hardver fejlődésével a szoftverek színvonala; mekkora a "valódi programozás" aránya azonos feladat százezredik megoldásával szemben, ...)

    A google szerintem általában jól látja a helyzetet, és tudja mit csinál (bizonyára szorgosan elemzi a saját adatbázisait). Ha be akarja etetni a Pistikéket, akkor tuti, hogy bőven elég van belőlük.
    Mutasd a teljes hozzászólást!
  • Nagy Tesó jellemzően a "long tail" híve


    Ez azt jelentené hogy a programozók legnagyobb részének bonyolult a java / c# és csak kevés kivétel van akivel nem foglalkoznak?

    Szép világ lesz itt
    Mutasd a teljes hozzászólást!
  • Feleslegesen ragozzuk, az adatbányászat csak példa volt, körülötte olvasható a lényeg.

    Az a nem mindegy, hogy mennyi időt kell szöszmötölni automatizálható feladatok megoldásával (karbantartásával, tesztelésével, javításával) a valódi tennivalók rovására (bármilyen projektben). Egyébként nálam a felesleges dolgok közé sorolódik egy "yet another language" és környezet megtanulása is, ami ráadásul új, és a kedves kibocsátó várhatóan még tekergetni fogja (GWT...)

    Értem én, hogy a google szeretne a programozók halmazából is kiszakítani egy csak tőle függő darabot, de ezzel a "túl bonyolult" szlogennel eléggé az alját célozza... bár, a Nagy Tesó jellemzően a "long tail" híve ( a million flies can't be wrong? LC )
    Mutasd a teljes hozzászólást!
  • A c++ nem csak 3d enginekre való :) .

    Amúgy miért nem, abban mindent meg tudsz csinálni. És legalább gyors is lesz.
    Mutasd a teljes hozzászólást!
  • Szerintem egy olyan cég van, amelyiknek van olyan platform a kezében, hogy legyen esélye ilyet elérni.

    Microsoft (már meg is tette: C#).
    Mutasd a teljes hozzászólást!
  • Olyanra, ami kifejezetten erre való. Mondjuk van benne linq to sql, reflection, szerializáció, databindigs, csupa olyan dolog, amit nem 3d engine-ben használnak.

    Ha szerinted a C++ ügyvitelre való 2010-ben, akkor egészségedre.
    Mutasd a teljes hozzászólást!
  • Milyen nyelvekre gondolsz?
    Az adatbányászó programot írnak java, c++, c# nyelven is mindegyik tökéletes rá.
    Mutasd a teljes hozzászólást!
  • Adatbányászatra már megvannak a megfelelő nyelvek/rendszerek, ez nem az lesz. Ugyanilyen alapon lehetne ezekre nyelvekre mondani, hogy nincs inline asm, most milesz.
    Mutasd a teljes hozzászólást!
  • Nos, várhatóan egyik sem.

    Viszont minden olyan kód, amely egy környezet által biztosított, megfelelő használat esetén hibátlan automatizmus helyett kézzel megírandó, és minden változás esetén karbantartandó, valójában állandó hibaforrás.

    Egyszer futottam bele saját projektnél (adatbányászat) abba a helyzetbe, hogy egy objektumhalmaznál kézzel csináltam külön copy-t és serialize-t. Amikor egy hónapnyi, nem kis agyalást igénylő fejlesztés után ellenőriztem a kódokat, számtalan eltérést találtam közöttük (és néhányat az osztály tartalma és a kódok között is...) - pedig csak én nyúltam bele, és tudtam, hogy mindenhol frissíteni kéne.

    Gondolom erre vonatkozott az a kitétel, hogy a "mórickás konzolos appokon" túl kicsit érdekesebb világ következik.
    Mutasd a teljes hozzászólást!
  • Ezen hangosan felröhögtem.
    Mutasd a teljes hozzászólást!
  • Én csak annyit tennék hozzá, hogy kiba++-ul hiányzik belőle a pontosvessző. Komolyan azt kell benne keresni, hogy hol van vége egy értelmezhető résznek. Például ha egy sorba írnék 5 különböző értékadást, akkor kb. jojózna a szemem tőle... Valami olyan hatást kelt, mint a BASIC: azaz szörnyű. Én olyan maradi vagyok, hogy pontosvessző hiányát igen nehezen tudnám megszokni.
    Mutasd a teljes hozzászólást!
  • A tér-idő kontinuum megtörik, elpusztul a világegyetem!
    Mutasd a teljes hozzászólást!
  • Jajj mi lesz velünk szerializáció nélkül!!!!
    Mutasd a teljes hozzászólást!
  • Szvsz ez a Goo ott halott, hogy nem van benne objektum.


    Ezt most nem értem. Hagyományos értelemben vett objektum tényleg nincs benne, de struct van, azt meg lehet szerializálni, mint a szél (amennyire én felfogtam a nyelvet).

    Hagyományos ojjektum meg azért nem van benne, mert a Google-ék nem szeretik a sok explicit deklarált interfészt, inkább a duck typing-ot próbálják keverni a statikus típuskezeléssel. Kis kódoknál egyértelműen kényelmesebb a dolog, aztán majd meglátjuk, hogy nagy rendszerekben lesz-e sok "véletlen implementáció" (azaz nem szándékos névegyezés okozta probléma).
    Mutasd a teljes hozzászólást!
  • Jávába' mindent lehet!!!

    Szvsz ez a Goo ott halott, hogy nem van benne objektum. Kíváncsi vagyok, hogy a Google hogy oldja meg a szerializálást ebben az izében. Ha egyszer eljutnak odáig, hogy a mórickás konzolos appokon kívül - mondjuk - webszolgáltatásokat akarnak írni Goo-ban, akkor igen nagy problémák lesznek a produktivitás terén.
    Mutasd a teljes hozzászólást!
  • getterrel, setterrel, kutyafülével

    Ezeket lesporolhatod...


    Persze, de a hardcore Java hívők egyből rádszólnak, hogy public mező nincsen és kész...

    A hívó egyből hívás után szétcsomagolja

    Valami ilyensmi:

    a, b = kettesTupletVisszaterit()

    ?


    Igen. Szerinted nem világos ez a kódsor?

    Onmagaban a tuple nem nagy elorelepes egy tombhoz kepest...


    Nyilván nyelvtől is függ, de mondjuk a Pythonban a tuple nem módosítható, ezért hash-elhető adattípus. Innentől kezdve triviális mondjuk egy koordináta-párokhoz értéket rendelő dict létrehozása. Akkor most számoljuk meg, hány sorból jönne ki ugyanez egy Java Map-pel... (Ugye a saját pár típushoz kell egy equals(), egy hashCode(), a konstruktor, meg persze a getterek.)
    Mutasd a teljes hozzászólást!
  • Igen, erről van szó. Persze, meg lehet oldani tömbbel is, mint ahogy külön osztállyal, ahogy korábban említetted.

    Én azt mondanám, hogy ez nagyobb szemantikai szabadságot jelent. Tömbbe hasonló dolgokat teszel. Ha nincs közös ősük, akkor csomagolhatod Objectbe őket, ha tömbözni akarsz. Ez egy olvasható és egyszerű megoldás többszörös visszatérési értékek kezelésére.
    Mutasd a teljes hozzászólást!
  • getterrel, setterrel, kutyafülével


    Ezeket lesporolhatod...

    A hívó egyből hívás után szétcsomagolja


    Valami ilyensmi:

    a, b = kettesTupletVisszaterit()

    ?

    Onmagaban a tuple nem nagy elorelepes egy tombhoz kepest...
    Mutasd a teljes hozzászólást!
  • Hát azért elő szokott fordulni, hogy két értéket szeretnél visszaadni, mondjuk azért, mert csak olyan algoritmusod van, ami mind a kettőt egyszerre tudja kiszámolni, külön-külön nem. Ilyenkor a lehetőségeid:

    * Kiszámolod mindkét értéket, és az egyiket eldobod. Ha a másik is kell, dupla számolás.
    * Deklarálsz egy ad-hoc osztályt az "eredménypár" tárolására, getterrel, setterrel, kutyafülével. Kb. 10-20 programsor a semmiért.
    * Kimenő paramétereket használsz, a visszatérési érték void lesz. (Javában nem játszik, mert nincs kimenő paraméter. C#-ban így megoldható.)
    * Tuple-t adsz vissza a két értékkel. A hívó egyből hívás után szétcsomagolja, és a kód olvasható marad. (Javában ez sem játszik, Pythonban és Go-ban igen.)

    Szerintem ez bizony hiányosság a Java nyelvben.
    Mutasd a teljes hozzászólást!
  • És ezért van az, hogy egy átlagos feladatra a java forrás x százalékkal hosszabb. A függvénypointer/delegate is azért maradt ki, mert bármikor definiálhatsz egy osztályt egyetlen metódussal, hogy annak a példányát használd erre a célra...
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd