A Google szerint túl bonyolult a Java és a C++
 |
A Google egyik vezető mérnöke a napokban meglepő kijelentést tett. Rob Pike ugyanis egy szoftverfejlesztői konferencián közölte, hogy szerinte az olyan "ipari programozási nyelvek", mint a C++ és a Java túlságosan bonyolultak, és ezért leváltásukra van szükség.
"Szerintem ezeknek a nyelveknek a használata túl nehéz, körülménye.. »tovább... |
Így van.  |
| Inkább meg kéne sütni őket. |
Bizony, de ha nehez ertelmes kacsat talalnunk, akkor megprobalunk ertelmesebb vizet eloallitani a buta kacsak szamara!  |
| Azt azert megjegyeznem, hogy ha a kacsa nem tud uszni, nem feltetlen a viz am a hulye. |
"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 |
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... |
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. |
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. |
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. |
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. |
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.  |
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 |
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 ) |
A c++ nem csak 3d enginekre való :) .
Amúgy miért nem, abban mindent meg tudsz csinálni. És legalább gyors is lesz. |
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#). |
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. |
Milyen nyelvekre gondolsz?
Az adatbányászó programot írnak java, c++, c# nyelven is mindegyik tökéletes rá. |
| 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. |
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. |
| Ezen hangosan felröhögtem. |
É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. |
| A tér-idő kontinuum megtörik, elpusztul a világegyetem! |
| Jajj mi lesz velünk szerializáció nélkül!!!! |
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). |
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. |
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.) |
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. |
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... |
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. |
| É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... |
|
