Java, c++ vagy php?

Közösségi kerekasztal

Sziasztok!

Tanácsot szeretnék kérni tőletek a következőben:
Jelenleg a Java-t tanulgatom, nagyjából haladó szinten vagyok. Hobbi szinten tanulom, nem programozással foglalkozom. Kíváncsi lennék a véleményetekre, hogy a címben lévő nyelvek közül, melyiket a legérdemesebb tanulni?

Foglalkozzak tovább a Java-val, hogy minél jobb legyek benne? Vagy inkább kezdjem el az alapjaitól a c++-t vagy a php-t? Ki melyik nyelvet találja a "leghasznosabbnak" ? Tudom, hogy ez a "leghasznosabb" attól is függ, hogy milyen fronton szeretnék fejlesztéssel foglalkozni, de nincsenek konkrét elképzeléseim.

Legfőképp a címben szereplő nyelvek érdekelnek, de ha van másik, aminek a jövőben nagy hasznát venném, azt is szívesen meghallgatom.

Köszönöm a válaszaitokat.

  • 21940 megtekintés

( Hevi v | 2014. 07. 15., k – 13:11 )

Mit szeretnél csinálni?

Enterprise webhez Java.
Gányolós webhez PHP.
Cross-platform desktophoz vagy beágyazott rendszerekhez C++.
Scripteléshez, webhez Ruby, Python

stb. stb.

Konkrét tervem nincs, hogy melyik részével szeretnék foglalkozni. Szeretek programozni, ennyit tudok :)

Már csak azt kell eldöntenem, melyik lenne a leghasznosabb. Sok negatív kritikát olvastam annak idején a Java jövőjéről az Oracle felvásárlása miatt. Érdemes manapság még Java-ba belefektetni? Ha igen, akkor csak a Java EE-be? Nem igazán tudom hogy alakul mostanság a piac, melyik nyelv fest úgy, hogy hosszútávon van jövője. Úgy gondolom itt elég sok ember dolgozik ebben a szakmában, ezért is bátorkodtam itt feltenni a kérdést :)

A Javanak semmi baja, koszoni szepen, jol van. Rengeteg Javas allast lehet talalni a junior programozotol az enterprajzi architectig es nem csak EE temaban. Raadasul, ha egy kicsit elvonatkoztatunk a Javatol, akkor a JVM-mel valo munka sok iranyba nyithat kaput (Scala, JRuby, Jython, Clojure, Groovy, stb.) amik tovabbi fejlodesre adnak lehetoseget, viszonylag kenyelmesen.

Velemenyem szerint akkor erdemes elkezdeni a C++-t, ha van valami kulonosebb erdeklodesed a nyelv irant vagy az altalad megalmodott celteruletnek ez a dominans nyelve. A legnagyobb kihivas a C++ fejlesztesben nem az, hogy hogyan programozz benne, hanem hogy hogyan programozz helyesen, azt pedig meglehetosen sok ido megtanulni.

Egy biztos: semmikeppen se add a fejed PHP-ra.

És mégis miért nem hasznos tudni PHP-t (persze nem árt mást is mellette)?
Csak azért meg voltak biztonságilag kényes napjai?
Miért olyan szar nyelv az, amiben a web jelentős része íródott? Csak azért mert, alapszintű dolgok megírásához már akár pár nap alatt is be lehet tanulni?
A PHP attól, hogy egyszerűen használható, tud nagyon komplex is lenni, és biztonságilag is bővel fel tud érni egy java rendszerhez, csak tudni kell benne programozni. Az meg nem a nyelv hibája, hogy tudás nélkül is lehet benne programozni, az inkább az erénye.

Azt mondják, hogy gányolás benne dolgozni. Én inkább azt mondom, hogy amit ők csinálnak gányolás ezek szerint.
És hogy miért beszélnek ellene? Egyszerűen csak szép emberi szokás szidni valamit...

-------------
Command line Russian roulette:
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*

Winben blogja

Reklámmentes képfelt

Sokmindent nem szeretek. Nem szeretem pl. a Pythont, vagy a Rubyt, vagy a Clojure -t. Nem azért mert rosszak. Sőt, egész jók szerintem. Csak nem passzolnak a stílusomhoz, nem kényelmes bennük dolgozni _nekem_. Nem is szidom őket.
A PHP nem ez az eset. Ez egyszerűen csak... Rossz. Nem rosszindulatból szidom, hanem mert segíteni akarok annak, aki még nem találkozott vele, hogy legyen esélye jó messziről elkerülni, aki meg szereti, annak meg felhívni a figyelmét arra, hogy vannak jobb választások.

Bővebben: http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

*sohaj*, Imadom mikor emberek ekeznek egy nyelvet azt gondolva hogy attol lesz jo a szoftveruk mert valami magikus mindehato masik nyelvet hasznalnak, es mar attol kivalo minosegu es felepitesu alkotasaik lesznek mert milyen csodas nyelven kodolnak. Maradjuk annyiban hogy minden nyelven lehet vacak kodot irni, neha meg akkor is ha koveted az adott platformhoz tartozo "so called best practice"-eket. (btw ha mar java akkor inkabb c sharp, de ez megint csak nezopont kerdese)
Egy jo php fejleszto ugyanugy kepes php alatt jo minosegu kodot irni mint egy jo java fejleszto java alatt, es mindketto kepes borzalmasat is, a kulonbseg annyi hogy javanak (sokkal) merdekebb a learning curve-je kezdetekben mint a phpnak, phpnak meg a vegen meredekebb kicsit mikor mar szamitanak a nyelv "sajatossagai" vagy mondjuk azt furcsasagai, plusz erossen bejatszanak design megfontolasok is es nem csak sima kodolas.

Es akkor hogy ne legyunk off-topicok meg ne csak flame-eljunk:
Miutan keves informacionk van az eredeti posztolotol hogy megis mit szeretne csinalni pontosan igy nehez a kerdesre erdemben valaszolni, mint ahogy o is emlitette az elejen nagyon helyesen, attol fugg mire akarja haszanlni.

"jo php fejleszto ugyanugy kepes php alatt jo minosegu kodot irni" Jó munkát jó eszközökkel lehet végezni, kérdezd meg bármelyik köművest. A php meg egy szar eszköz, és ha figyelmesen elolvastad a linkelt cikket, akkor neked is rá kell jönnöd, hiszen objektíven le van írva mi a baj a php koncepciójával. Pl nem lehet benne különbözőséget vizsgálni tipusbiztosan, vagy az egyenlőség nem transitív, csak, hogy a 2 legmegkérdőjelezhetetlent mondjam. Ettől még egy jó php programozó, aki ismeri a nyelv gyíkságait, tud elfogadható minőségű kódot írni, de az eszköz hemzseg a viselkedésbeli és implementációs hibáktól. Tehát minek megtanulni, főleg hobbi célból, mikor csak a szívás van vele, és bármely másik random nyelv is alkalmas a leváltására.
-
import groovy.transform.Immutable

Szokás szerint ezzel fikázza a php-t "== is useless." tehát innentől kezdve nevetséges az egész iromány. Hozzáértő tudja kezelni. A hülye meg még a php-t sem...

"Pl nem lehet benne különbözőséget vizsgálni tipusbiztosan"
Aha. Az 123 === "123" nem lesz igaz.

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

"== is useless." van még 30 másik, elolvastad te a cikket?
"Hozzáértő tudja kezelni" szépen nézünk ki, hogy a programozónak kell gondoskodnia, hogy transzitív legyen az egyelőség vizsgálat!
"Az 123 === "123" nem lesz igaz." és kissebb e vagy nagyobb?
-
import groovy.transform.Immutable

Például a Wikipédia motorja (MediaWiki) sem PHP-ban íródott? (de bizony abban!).
Ja hogy nem a PHPPistike szintjén, hanem rendesen megtervezett OOP lett? Ez tényleg különbség.

Üzleti-kritikus a Wikipédia? Döntést rád (olvasóra) bízom.

PHP-ban lehet PHPPistike módjára gányolni? Igen lehet.
Sok PHP programozónak önmagát nevező a gányolás szintjén reked? Sajnos igen.

Típusazonos elemek vizsgálatánál tranzitív. Annyival többet tud - és annyival többre kell figyelni -, hogy eltérő típusú elemeket is össze tudsz hasonlítani. Deal with it.

A másik 30-ról... van, amiben igaza van, cserébe ha javítanák, akkor meg arról picsogna, hogy jaj, mert megtörték a visszafelé kompatibilitást pl. azzal, hogy egységes nevezéktant vezettek be (afaik 6-ra tervbe is van véve). Meg van közte egy sor picsogás, hogy miért a Java OO-ját vették alapul. Meg hogy miért ismeri pl. az absztrakt osztály fogalmát, mert a többi scriptnyelvben elég az, hogy a konstruktorban dobsz egy kivételt. Meg minek kell new kulcsszó, miért működik a nem-statikus metódusok statikus formájú hívása is példánymetódus-hívásként ha egy példány metódusából hívják (visszafelé kompatibilitás, mert a 4-esben nem volt static method, mert ott még nem másolták le a Java-t, de végülis télleg minen ennyi új kulcsszó, fúj - önellentmondás?) stb.

Ez amúgy nagyjából ugyanaz a kategória, mint a Systemd is broken by design cikk, mindenki linkeli fogalom nélkül orrba-szájba, vannak benne (fél)igazságok, de a nagyrésze ízlésbeli kérdés (pl. a teljes OOP-s szakasz), egy részét már javították is (elég sok helyen látni a cikkben is a "najó, ezt PHP X.X-ben javították" mondatot), egy része meg olyan edge case-ket mutat, amikre a célközönség nem fog ráfutni... és ilyen információkból von le következtetést.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

" egy részét már javították" Engem ezzel nem győztél meg, mert számomra csak tovább tükrözi az elképzelés nélküli implementációs problémát, ami az egész nyelvet átjárja. Az egy résézt már javították, azt jelenti, hogy sz@r volt, és sokszor visszafelé nem kompatibilis módon történik a fix, aztán meg mindenkinek csak fáj a feje verziófrissíéskor. Tervezetlen, összekalapált, inkonzisztens, kupac, és ha a négyből csak kettő igaz, én már komoly munkára nem használnám, hiszen 1000 értsd ezer alternatívája van.
-
import groovy.transform.Immutable

Ez tipikusan ugy hangzik mint aki csak es kizarolag technologiai okokbol valaszt valamit es keves koze van ahhoz hogy a valo vilagban a szempontok felenek (sot lehet hogy nagyobbik felenek) a vilagon semmi koze nincs ahhoz hogy mennyire erzed coolnak a technologiat. Mind a munkaado mind a munkavallalo szempontjabol van egy csomo minden aminek semmi koze ahhoz hogy hany egyenloseg jelet akarsz hasznalni, megjegyzem az is latszik ezekbol a kommentekbol hogy alapbol elutasitasz barmilyen nem tipusos nyelvet, mert azert kritizalni egy nem tipusos nyelvet mert nem olyan mint egy tipusos nyelv elegge abszurd.

"alapbol elutasitasz barmilyen nem tipusos nyelvet" ezek szerint a szavaim egybahangzanak az érzéseimmel és ez jó :D DE! nem vagyok kategórikus, és misem bizonyítja jobban, hogy időm nagy részét groovy programozással töltöm (persze ahol tehetem kiírom a típust, de nem kapok hisztériás rohamot ha nincs meghatározva) mindennek megvan a maga helye és felhasználási területe

"egy nem tipusos nyelvet mert nem olyan mint egy tipusos nyelv elegge abszurd" ez valami félreértés, én amellett próbálok érvelni, hogy miért nem jó választás a php sem hobbiból tanulásnak, sem komoly munkára.

-
import groovy.transform.Immutable

szerintem meg igenis hasznos, nem csak a php hanem barmelyik, de ha csak a phpnal akarsz maradni akkor is boven igaz ez. Van rengeteg szempont amit egyszeruen nem veszel figylembe, mert ahogy nezem csak es kizarolag technologiai szemszogbol nezel a kerdesre.
Nekem vannak mas szempontjaim is, mint peldaul piackepesseg, vagy koltsegesseg.
Itt jonnek be a munkaltatoi szempontok, phpban fejleszteni gyors, olcso, es hatekony. Igen, mikor mar vagy egy tobbszaz fos ceged es megengedheted magadnak hogy tel legyel product ownerekkel meg minden a nagykonyv szerint menjen akkor mar joval kevesebb elonye van ez szamomra is teny, amig azonban el nem ered ezt a pontot addig a ceges szempontok joval inkabb a funkcionalitas, mukodes, es koltseghatekonysag, mint a tehcnologiai coolsag, tekintve hogy ceg fogja adni a fizetesedet, igy a te elsoszamu erdeked szinten a ceg sikeressege kellene hogy legyen, ha ez neked nem tetszik akkor alapits sajat ceget es csinald mashogy.

Idéznék a kérdező szavaiból: "Hobbi szinten tanulom, nem programozással foglalkozom" tehát továbbra is kitartok amellett, hogy pl java tanulással többre megy, mert:
- Egy megtervezett (dokumentált) programozási nyelvet tanulhat (vagy legalábbis a vetélytárshoz képest biztosan)
- Van hozzá normális IDE támogatás
- Ha mégis később megélhetési programozó szeretne lenni nagyobb bérre számíthat, és nem feltétlen kell neki a webes területen megmaradni, hiszen Java-val a cuda-tól a kenyérpirítóig bármit lehet
- Egy Tomcat + JSP + MySql tanulási görbéje nem számottevően nagyobb, mint egy LAMP-é

"tekintve hogy ceg fogja adni a fizetesedet" tudod az a cég, amit én választottam, mert a leginkább megfelel a szakmai céljaimnak ;)
-
import groovy.transform.Immutable

az elképzelés nélküli implementációs problémát, ami az egész nyelvet átjárja.

Az elképzelés nagyjából az, hogy tartaniuk kell a visszafelé kompatibilitást és ezért lesz inkonzisztens - régóta és "organikusan" nő. A legnagyobb gond, hogy pl. egy Java-val ellentétben (ahol azért szintén ott van rengeteg szemét a korábbi JDK-kből, és ugyanúgy sok mindenre van 5 beépített gyári megoldás a standard library-ben [triviálisan: I/O - Stream-ek, Readerek, NIO és NIO2 - mind a standard library része], amiket mindenféle wrapper osztályokkal tesznek átjárhatóvá - ahol lehet) a legelső verziók nem voltak tervezettek, one-man-show volt az egész. Viszont pont a backward kompatibilitás miatt (egyébként ha nem már az akkor is taknyolósnak számító register_globals és magic_quotes és satöbbi szutykoktól mentes kódról van szó, akkor egy PHP 4-re készült könyvtár/program gond nélkül futtatható a legfrissebb verzión is) ezeket nem dobhatják ki.

És erre írtam, hogy ha ezeket javítanák (inkonzisztencia) abból az lenne, hogy a) menne a picsogás a bwc megtörés miatt vagy b) menne a picsogás, hogy "dehát minek ennyi alias/wrapper osztály/..." a standard libraryba.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"És erre írtam, hogy ha ezeket javítanák (inkonzisztencia) abból az lenne, hogy a) menne a picsogás a bwc megtörés miatt vagy b) menne a picsogás, hogy "dehát minek ennyi alias/wrapper osztály/..." a standard libraryba."

kimondom helyetted, tehát nem jó, és nincs rá jó megoldás sem.

-
import groovy.transform.Immutable

Oks, nézzük a vetélytársakat:

Java és a JVM-re épülő összes nyelv: kivétel nélkül mind erősségnek hozza a Java standard könyvtár elérhetőségét. Ami ugyanígy tele van "valójában deprecated de nem rakjuk rá, mert stroke kapna az IDE minden projektben" osztállyal/metódussal/..., amik szépen rétegesen jöttek be - és a mai napig mindent támogatják. Aztán ott van az EE, ami 1) ugyanez, mert nem dobunk ki semmit, hanem csal ráépítünk és az egyre népszerűbb alternatív nyelvek és keretrendszerek, amik az EE overengineered, generációk óta épített API-jait próbálják elfedni (triviális példa: Servlet [9 verzióval, btw.], JSP [4+ verzióval], Faces [6 verzió], de desktopon sem jobb a helyzet, ott van az AWT, a Swing, az SWT meg persze az össze GUI toolkit Java bindingja. Vagy a gyűjtemények, amikből van egy raklap őskövület a JRE-ben [amik afaik amúgy is már csak wrapperek az újabb verziók körül], aztán vannak azok, amik az 1.5-el generikusak lettek, aztán ott van pl. az Apache Commons collections stb.)

C (és egy kalap alatt asm): Aki alkalmazásfejlesztésre használja vagy arra ajánlja, mondjon le és költözzön be a legelső barlangba, ahonnan szabadult. Fucking dinosaurs. :)

C++: a választási lehetőségek mekkája, az öntökönéslábonlövésé szintén.

C# és a CRL-re épülő összes nyelv: a Java-val ellentétben MS-ék gondolkodás nélkül megtörik a visszafelé kompatibilitást, amikor új API-t vezetnek be (így csinálhatták meg pl. a nem type-erased generikusokat), úgyhogy biztos, ami biztos egy standard Win7-re a Windows Update önszántából felbassza a .NET 3.5, .NET 3.5 SP1, .NET 4.0 és .NET 4.5-öt. Egyszerre. Desktop API-k: WinForms, WPF, istentudjamilyenapivanamodernui-hoz. Webes legalább túl sok választási lehetőséged nincs, csak hogy az ASP.NET 6 különböző verziójából melyiket használd.

ECMAScript/ActionScript/JavaScript: nincs két ugyanolyan futtatókörnyezet, ráadásul a dialektusban is vannak különbségek még a nyelven, nemhogy a nyelvcsaládon belül. Cserébe grafikus alkalmazásokra is használható (pl. nodejs qt bindingja, urambocsá Flex/Flash stb.), fixált futtatókörnyezet mellett akár még kényelmes is lehet.

Az összes többi scriptnyelv (Perl, Python, Ruby, Lua, ...) a minden mástól (így egymástól is) eltérő szintaxis miatt okoznak szívást, első nyelvnek semmiképp nem jó (egy C-szintax [curly braces, operátorok stb.] nyelvvel nagyobb részt fed le a prognyelvekből, mint bármelyik "rohadjonmegacurlybrace"-scriptnyelvvel.

------------

Összefoglalva: nincs tökéletes nyelv/platform, mindegyiknek megvan a maga összes hülyesége, az más kérdés, hogy mennyire kell leásni (akár platform-kód szinten, akár történelmileg, akár mindkettő), hogy megtaláljuk. Elvetni viszont egy nyelvet nem kéne, különösen, ha gyakorlatilag az egyetlen platform, amire bárhol lehet értelmes hostingot és egymással összegyúrható kész, open source rendszereket találni (CMS-ek, fórumok, webshopok, akármik)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ez inkább olyan, minthogy teljesen nyilvánvaló, hogy dohányozni gáz. Magát mérgezi vele az ember, potenciálisan rákos lesz, mondhatjuk, az ő dolga. A körülötte levőknek ugyanezt okozza, erre már nincs mentség. Valaki ezeket tagadja, vagy épp ezek ellenére mégis dohányzik, mert szereti. Hát ezzel nem tudok mit kezdeni.

Php ugyanez.

Most hiába mondjuk, hogy mondjuk tejivásnak, vagy tojás, vagy vörös húsok evésének is van egészségügyi kockázata, nem ugyanaz a kategória.

Azért ez az érvelés elég rendes facepalm... egész pontosan másokat hogy bántasz azzal, hogy X nyelven programozol le valamit? Ilyen érveléssel nem tudok mit kezdeni.

Mert hiába mondjuk, hogy az első bekezdés igaz (kulturált dohányosként, aki igenis figyel mások egészségére a leereszkedő és sértő hangnemet kikérem magamnak), a második egy logikai bukfenc, nem ugyanaz a kategória.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ok, nem akartam a kultúrált dohányosokat bántani. Mindenesetre nem ismerek (személyesen) kultúrált dohányost. Elnézést.

> egész pontosan másokat hogy bántasz azzal, hogy X nyelven programozol le valamit?

Hát az emberek akiknek aztán a későbbiekben bármit kell csinálniuk a kóddal? A végfelhasználók akik ennek az egésznek a levét isszák? Lásd facebook, minden rosszul működik rajta. Oké, tudom, a php ellenére elvben lehetett volna úgy csinálni hogy működjön. De én azért látok erős összefüggést.

A maintenance kóderek esete jogos, ha az ő döntéseik ellenére készült PHP-ban a cucc. Saxus egy-két kirohanása jó példa erre. - viszont ez gyakorlatilag mindenre igaz, a használt technológiáktól függetlenül a megörökölt kód mindig szívás :) [esettanulmány: gyakorlatilag mindegyik Daily WTF cikk, személyes vélemény: bármikor szívesebben öröklök PHP kódot, mint mondjuk VBScript-et - "úgyis csak egyszer kell"-felkiáltással készült, aztán mission criticallá ért rendszerek gyakori vendége mindkettő]

A Facebook-nevű okádmányt meg ja, PHP-ban is meg lehetett volna írni értelmesen, és más nyelven is ugyanígy el lehetett volna cseszni, a követelmények rossz elkészítése nem eszközfüggő :) UX szempontjából meg kb. mindegy, hogy a szerveren mi fut (ha megfelelően skálázhatóra van elkészítve) - nagyjából mindegy lenne, hogy a HUP ezen az ősrégi Drupalon, vagy a legújabb Umbraco-n (kugli első találat az ASP.NET CMS kifejezésre, úgy tűnik még Ghostery-vel is tudja, hogy preferálom az open source cuccokat :( ) fut, ha a témát trey átörökíti, nem lenne különbség.

Disclaimer: ismerem a PHP-t [urambocsá, kedvelem is - csak nem webre, inkább shell scriptek helyett], úgyhogy tapasztalatból tudom, hogy mekkora hülyeségei vannak [kiváltképp a régi verzióknak], de valamiért a nagyon-enterspájz Java web fejlesztés soha nem fogott meg, a Play framework már pl. határozottan tetszik.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nem vagy semmi :D

Teljes melszélességel védelmezed a php-t, és ajánlod dNi-nek, hogy tanulaja mert milyen jó, miközben:
- Te magad is elismered, hogy egy tákolmány
- Te magad nem szereted webre (amire kitalálták, és leginkább használják)

nem érzed ezt ellentmondásosnak egy hangyányit?

"enterspájz Java web fejlesztés soha nem fogott meg" JSP + JDBC és máris lehet szép spagettit írni, mint php-ban szokás (mármint elsőre) Ez a szép benne, hogy a felhasználás mértékétől függően lehet bonyolítani az architektúrát, de itt legalább vannak eszközök (JMS, JPA, JTA, EJB) ha növekszik/változik az üzleti igény, akkor van lehetőség az alkalmazást is bővíteni.

"Play framework már pl. határozottan tetszik" Ami megfejeli a (szar) Java-t egy kis funkcióorientált Scalaval, és wrappereli, a hitvány wrapperelt Javas libeket (kisarkosítva). Kicsi önellentmondást vélek felfedezni

-
import groovy.transform.Immutable

Nem védem teljes mellszélességgel, csak a FUD, ami szerint használhatatlan és az egész egy szar, ellen küzdök :) Nem nagyobb tákolmány, mint mondjuk az összes shell script nyelv - azokról mégse hallani, hogy jujnehasználd, illetve ahol hallani (lásd a systemd), ott meg jön mindenki, hogy dehát az init scriptek annyira jók, és igazából szeretjük őket (valamiért mindig a családon belüli erőszak áldozatai jutnak eszembe az ilyen kommentek alapján "nem tökéletes, de azért még szeretem..." - és most jobban belegondolva ez magamra is igaz ebben a szálban :D )

Ellentmondás azért nincs, mert nincs másik alternatíva, amibe könnyen be lehet ugrani: ha nulla tudásról akarsz valamit Java-ban összewebépíteni, akkor első körben a Java nyelvnek, az OOP szemléletnek, a Java standard libnek, a Java Servlet/JSP dolgoknak kell utánanézned, ahhoz, hogy egy "Hello World"-ig eljuss. Az alacsony belépési feltélek miatt itt nyer a PHP, mert ott egy echo-val elintézed. Ha meg már el is jutottál oda, hogy meg van a Hello world, rövid úton bele fogsz futni a concurrency issuekba, egyszerűen azért, mert vannak - PHP nagyon nagy hátrányaként írják a fenti linkelt cikkben, hogy nincsenek szálak. Oh. Stb.

"enterspájz Java web fejlesztés soha nem fogott meg" JSP + JDBC és máris lehet szép spagettit írni, mint php-ban szokás (mármint elsőre) Ez a szép benne, hogy a felhasználás mértékétől függően lehet bonyolítani az architektúrát, de itt legalább vannak eszközök (JMS, JPA, JTA, EJB) ha növekszik/változik az üzleti igény, akkor van lehetőség az alkalmazást is bővíteni.

Pont ezt mondom: nem ugyanarról a célcsoportról beszélünk. A JSP+JDBC kombót (ami tényleg egy out-of-the-box PHP-nak felel meg) azonnal lespagettikódozod, leginkább azért, mert egész más rendszerekben gondolkodsz - a Java LEFELÉ nem skálázódik, pont annyira nem, mint ahogy a PHP felfelé. Nem teljesítményben, eszközökben, bonyolultságban stb. Viszont az átlagos PHP projektre az EE összes entrspájz cucca masszív overkill lenne (pl. maradva a JMS-nél: szép és hasznos, hogy akármilyen implementációt mögé rakhatsz, én meg csinálok ugyan ezzel egy vendor lockint, de fogok egy amqplib-et és mondjuk egy RabbitMQ-t, oszt problem solved - nincs szükség arra az absztrakcióra, amit még a JMS ad efölött).

Ami megfejeli a (szar) Java-t egy kis funkcióorientált Scalaval, és wrappereli, a hitvány wrapperelt Javas libeket (kisarkosítva). Kicsi önellentmondást vélek felfedezni

Wrappeli a hitvány Java-s libeket (meg az alkamazás szervert, a build process-t stb.), és innentől kezdve nekem nem kell azzal foglalkoznom, hogy akkor melyik EE kiadással, alkalmazás-szerverrel, ... lesz kompatibilis. Mert nem érdekel, mert azoknál az alkalmazásoknál, amiket írok vele, nincs olyan business requirement (akár teljesítmény, akár skálázódás, akár...), ami megkövetelné, hogy tudjam. Van olyan feladat, ahol ezekkel mind számolni kell, ott majd jöhet az összes J[A-Z][A-Z] betűhármas; A másik irányba lefelé skálázva, amikor meg az kell, hogy egy kenyérpiritón is elfusson és egyszerű fájlmásolással üzembe helyezhető legyen - marad a PHP.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Amit leírtál az mind igaz, egy nagyon lényeges különbséget leszámítva. Php-nál már a nyelv és a standard library agyfaszt okoz a fejlesztőknek, a többi nyelv/platform esetén általában sem a nyelvvel*, sem a platform adott verziójával szállított standard library-vel nincs gond. A problémák ott jönnek be, hogy ezekből különböző verziók lesznek, amit valahogy kezelni kell, amire nincs igazán jó megoldás (megjegyzem, php-ban sincs, ahol minor verzió simán api breaket okoz).

*: javascript sokszor társa a php-nak ezekben a vitákban, de a javascript inkább azért, mert teljesen más szemléletmóddal készült, mint a korábbi strukturált vagy oo nyelvek.

Az elképzelés nagyjából az, hogy tartaniuk kell a visszafelé kompatibilitást és ezért lesz inkonzisztens - régóta és "organikusan" nő.

Ez akkor működhetne, ha lett volna agyuk, amikor elkezdték csinálni. Mivel nem volt, nem értettek hozzá (ahogy a hozzászólásokból leszűröm, még most se nagyon), ezért először ultranagy szart alkottak, majd most ehhez a szarkupachoz ragaszkodnak, ill. szépen, apránként próbálják letolni a közönségen egyik-másik fostalicska "feature" megváltoztatását.
Szerintem ez nem vezet sehova, sokkal-sokkal hatékonyabb lenne egy komplett tabula rasa. De persze akkor megintcsak előjönne, hogy meg kéne tervezni, és hát a hozzáértés megintcsak...

Nem olvastam végig.

C++-szal szopok egy sort, amiket PHP-ben 5 perc alatt. Persze, ennek egyik oka az, hogy kezdő vagyok C++-ban. De néha még Javaban is könnyebben dolgozom, mint C++-ban, pedig Java-ban kezdőbb vagyok. Ennek ellenére én nem szidom sem a C++-t, sem a Javat.

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

Azert nem hasznos, mert a PHP onmaga is annyira inkonzisztens es rozoga takolmany, hogy szamtalan rossz programozoi gyakorlatot sajatithat el belole az, aki PHP-n "no fel", amit kesobb nagyon nehez kijavitani. Volt szerencsem par evig felveteliztetni es oktatni olyan PHP fejlesztoket, akik Java fejlesztore szeretnek magukat atkepezni es igen siralmas tapasztalataim vannak.

Tobb helyen is lattam linkelve a PHP: Fractal of bad design c. iromany, mindenkeppen ajanlom vegigtanulmanyozni, eleg jo leirast ad arrol, hogy milyen is a PHP.

Az hogy a web jelentos resze ebben irodott, semmilyen modon nem alapja a minosegnek. Mint ahogy arra sem vagyunk buszkek, hogy Budapest jelentos resze koszos. Ja, hat igen, koszolni mindenki tud, takaritani meg senki sem akar.

Tovabbi kotelezo olvasmany: https://medium.com/message/81e5f33a24e1

Ha programozó vagy, akkor jó a Java, mivel ugyanazt a webes feladatot 5 vagy 10x annyi munkaidővel lehet megoldani, mint PHP-ban. Ha megfizetik, akkor neked jó, válaszd a Java-t. (Csak közben a munkáltatódnak emlegesd közben, hogy mennyire "hókuszpókusz enterspájz" programnyelven dolgozol, így nem fáj neki annyira a horribilis költség. Banki projektek előnyben, azok már megszokták.)

Már nem 2.1-es EJB-ket használunk, azóta eltelt 15 év ;) Adott feladatot ~ugyanannyi idő megírni Java-ban (ugyanis nem a gépelés sebessége a szűk keresztmetszet), csak mélyebb programozói ismeretek szükségeltetnek hozzá (autómatikus tranzakciók, ORM, Többszálúság, JVM ismerete, Input/output streamek, stb), és ezért kerül többe a munkaerő. Mi Grails-t használunk ha gyorsan
változó üzlezti igényekre gyorsan kell az alkalmazásnak is reagálnia, és semmivel sem lassabb benne dolgozni, mint mondjuk egy hasonló (Laravel) php keretrendszerben.
-
import groovy.transform.Immutable

Igen, Javara is igaz. Meg a legtobb programozasi nyelvre is igaz. Azonban a C++ es a Java nem egyforman absztraktak a fejleszto szemszogebol, gondolok itt az unasig ismetelt memoriakezeles, oroklodesi rendszer, templatek, security es optimalizalasi temakra. Ezeknek az alapos ismeretet elsajatitani szerintem kevesebb ido Javaban, ahol a JVM es a nyelv leveszi ennek a tehernek a jelentos reszet a fejleszto vallarol (az, hogy ezt milyen hatekonysaggal teszi nem resze a kerdesnek).

Ehhez kapcsolod olvasmany: https://medium.com/message/81e5f33a24e1

Függetlenül attól, hogy kinek a hozzászólására nyomtam a választ (találomra nyomtam egyet a PHP ellentáborra):
aki azt meri mondani a mai világban, hogy termékkel nem kell jelen lenni a Facebook-on, az húzza le a rolót. A Facebook SDK támogatottan létezik iOS-re, Androidra, Javascriptre, Unity-hez, PHP-ra. Az összes többi csak harmadik féltől származóan, garanciát nem vállalva rá.
A PHP piacképessége ezzel azt gondolom, hogy bizonyítva van (bármilyen minőségű is belül az egész).

( dejo v | 2014. 07. 15., k – 13:14 )

Ha platformok között egyszerűen hordozható dolgokat akarsz készíteni akkor Java.
Ha az a fontos, hogy minél gyorsabban fusson a programod akkor C++.
Ha webre akarsz programot készíteni akkor php.
Ha arra vagy kíváncsi, hogy melyik nyelvre van a legnagyobb igény, azt elég nehéz megmondani, mert az álláshirdetésekben mind a hármat keresik.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

( gmoore | 2014. 07. 15., k – 13:22 )

Mármint mire a leghasznosabb?
A leghasznosabb nyelv a C.

Ezt kérdeztem én is, hogy mire?
Ha általánosságban nézem a hasznosságát, akkor C. Nyilván ezer olyan feladat van, aminek megoldásához nem C-t választanék, és csak miután napokat szoptam a "magasabb" nyelvvel, jönnék rá, hogy ennyi idő alatt akár C-ben "nulláról" is megírhattam volna jól, működőképesre, ha nem szopom be a marketing bullshitet.

Programming is terrible—Lessons learned from a life wasted

Ez így első ránézésre igaz.

Második belegondolásra meg aszondanám, hogy leghasznosabb min. egy gyors kódra fordító nyelv + min. egy gyors prompt fejlesztést/gányolást lehetővé tevő szkriptnyelv + min. egy jó fícsörkészlettel rendelkező, nekünk kézreálló editor jó ismerete.
Ezek aztán szépen ki fogják egészíteni egymást, illetve ott mutatják a legjobb oldalukat, ahol kell.

Murphy szerint: ne erőltesd! ... keress nagyobb kalapácsot!

( radix | 2014. 07. 15., k – 13:24 )

Attol fugg hogy milyen teruleteken akarsz dolgozni.

Ha webes alkalmazasfejlesztesben gondolkodsz, akkor a kovetkezot ajanlom:
Frontend oldalon Angular JS. Azaz 1 darab javascript-es alkalmazas, minden fuggoseg egyszerre betoltve.
Ha mar elsajatitottad a javascriptet, akkor talan erdemes ugyanazt a nyelvet hasznalni szerveroldalon is.
Ezt ugy hivjak, hogy MEAN stack. Mongo-Express-AngularJs-NodeJs
Szoval szerintem a Javascript-re fekudj ra, ha webes teruletre keszulsz.

Nehez olyan programozot talalni, aki megfeleloen ert a Javascripthez.
Itt ertem ezalatt azt, hogy barki, aki jo javascriptes, Pesten a logMeIn-nel, avagy a Prezinel millios fizetessel barmikor alkalmaznak oket, vagy itt Londonban evi £60k+ fizetesert egy het alatt talalnanak allast.
Ezek utan valszeg a Javascript-es programozod nem fog erteni a Rubyhoz, vagy a Javahoz - szoval backend-en mas embernek kell hogy dolgozzon, mint frontend-

Par project utan a frontend developerek panaszkodni fognak, hogy sokat kell varniuk a backend developerekre, es ez a szeparacio nem jo. Felmerul az igeny a full stack projektekre. Mivel Ruby es java nincs kliens oldalra (a bongeszok nem tamogatjak nativan), a javascript-et kell a szerver oldalon.

A szerver oldali javascript ebben az esetben kimerul szinte a restful apikban. Azaz nem az van, mint a PHP-nal, hogy a szerver generalja a HTML kodot, vagy ott tortenik a templating, ez a logika atkerult a bongeszokbe - ahol egy egesz szofisztikalt alkalmazas fut - ezeket Single Page Application-oknak hivjuk, es a szerverrel csak adat-kommunikacio zajlik.

Nem hiszem, hogy a problémára ez az ideális megoldás, bár kis projecteknél lehet hasznos. De nagyobb rendszereknél, egy frontend fejlesztő általában katasztrofális backend kódot készít. Más a két terület megközelítése, szaktudása, stb... . A problémát úgy oldják meg általában, hogy frontend fejlesztők mock/szimulációs interface-ekkel dolgoznak addig amíg nincs kész a backend, a felület teszteléséhez nem kell hogy valós adatok legyenek. Mostanában megint divat a gyurjunk össze mindent egybe, mert az jó lesz, nem kell ide vékony kliens. Attól, hogy valami a böngészőben fut attól még lehet vastag kliens. Aztán majd mindenki vakargatja a fejét, ha a funkciót mondjuk webserviceben/MQ-n is ki kell ajánlani, és kiderül hogy a logika nagy része kliens oldali js-ben van.

A mockos interface-en felul eljon egy pont, mikor integralni kell az alkalmazast, es akkor derul ki hogy esetleges tervezesi hibak vannak a kliens oldalon. Avagy a web service-k teljesen random modon halnak el, hasznalhatatlan hibauzenetet adnak vissza. Kommunikalni a hibat, ticketet nyitni, a kurulmenyeket leirni, majd mikor 2 nap mulva a backend fejleszto kijavitotta, es ujbol teszteled az API-t, egy mas ok miatt nem ad vissza ertelmes adatot...
Ezek a fuggosegek igen is tudjak a frontend developereket frusztralni.
A kliens oldalra elvileg uzleti logikanak nem szabad hogy keruljon. Az elkeszult restful api-t meg barmilyen kliensbol lehet aztan hasznalni.

Jelenlegi projektjeinknel mar meglevo SAP alapu alkalmazasokhoz irunk uj HTML5-os klienseket. A Js app az egy Java-alapu middleware-el kommunikal, a middleware meg a SAP-pal. Ehhez kepest mikor Node-js-ben fejlesztunk, sokkal relaxaltabban, gyorsabban haladunk.

-1 a frontend-backend keverésre

Nyilván nem az egyszemélyes hobbiprojektekről van szó, de nagyon rossz gyakorlat keverni a kettőt. Nem a nyelv az akadálya, hiszen arra már megvannak a módszerek (még ha szvsz szarok is, de ez csak személyes vélemény), hanem a teljesen eltérő gondolkodásmód, ami szükséges hozzá.

És nem is a full stackre. :P

Most tegyük félre, hogy én személy szerint nem szeretem a JavaScriptet, de az tény, hogy már van szerveroldalon is. Viszont az, hogy egy nyelvet/ökoszisztémát használ a kettő, nem jelenti azt, hogy feltétlenül ugyanannak az embernek kell dolgoznia frontenden és backenden is.

haha :)
Elfelejtenem a full stack gondolatat is, ha normalisan dokumentalt es stabil API-t nyujtananak itt nalunk a backend developerek. Az kommunikacios overhead tul nagy:

Ime valami ami a mult heten tortent:
1. Teszter nyit egy ticket-et, mert valami nem megy, hozzam assignolja
2. Tesztelem, a backend 500-as hibat dob. Kimasolom a requestet, bemasolom a Jiraba, hozzaasignolom a Backend developerhez
3. 1 nap mulva commentel hogy fixed a #32342-es verzioban, vissza-assignolja a ticketet hozzam
4. Varok kovetkezo reggelig, hogy a #32342-es verzio a szerveren legyen. Tesztelem megint, most 403-as hiba. Kommentelem, vissza a backend developerhez.
5. 1 nap mulva ujabb komment, hogy fixed in #32532-es verzioban, visszaassign nekem
6. Varok kovetkezo reggelig, tesztelem, es bumm, ujra 500-as hiba. Request kimasol, beilleszt, visszaassign a feladonak.
... s itt tartunk most - demo holnap. :-)

Épp ezért ezt nem JIRA-ban rendezzük le passzív-agresszív módon (de szerintem kész, szerintem nem, szerintem igen, szerintem nem), hanem írunk egy e-mailt vagy chatelünk a tényleges fejlesztővel és megmondjuk neki, hogy ugyanmár, légyszíves teszteld le a cuccot, mert nálam még mindig nem megy.

( ssikiss | 2014. 07. 15., k – 13:24 )

A C++ után a többi sokkal könnyebben megy.

( sz332 v | 2014. 07. 15., k – 13:33 )

Java: rendszerfejlesztéshez, PHP: weboldalak egy adott méretig szerver oldalon, C++: embedded fejlesztés, javascript: kliens oldali fejlesztés, illetve mostanában jött divatba a szerver oldali
javascript, nem tudom, hogy nagy terméket mennyire lehet benne normálisan megcsinálni, typescript nem véletlenül született meg...

"javascript, nem tudom, hogy nagy terméket mennyire lehet benne normálisan megcsinálni,"

Mostanság - amikor elvárás, hogy a sejhaj törlésére is legyen webes megoldás - olyan, mint az angol: ha nem beszéled, halott vagy; ha csak azt beszéled, még mindig halott vagy, ha azt IS beszéled, akár élhetsz is.

Túlzás included.

( mudlee | 2014. 07. 15., k – 13:38 )

Amig nem dolgozol barmelyik nyelvvel legalabb 1-2 evet elesben, addig hidd el, barmi lehetsz, de halado biztos nem.

Innentol fogva meg nem a nyelv a kerdes, hanem mit akarsz csinalni, hol akarod csinalni, es mennyiert akarod csinalni.

( haspokember | 2014. 07. 15., k – 13:49 )

Az igazi programozo barmilyen nyelven bir FORTRANban programozni!
(lasd: http://www.caesar.elte.hu/progmat/kultura/humor/igazi.html)
Leforditva: ne nyelvet tanulj, hanem programozni tanulj, nyelvek hasznalataval.

Kezdesnek en biztosan Rubyt, Pythont javasolnek, ezekkel nagyon gyorsan produktiv lehetsz, vagy ha erzed magadban az erot, akkor assemblyt, C-t (ami csak egy assembly makrokkal), es onnan mondjuk Perlt. Ha Javat szeretnel, akkor inkabb a C#, egyebkent meg Scala, egyertelmuen a Coursera tanfolyama miatt (https://www.coursera.org/course/progfun).

Ha tokos ficko vagy, akkor mehet valami LISP, peldaul Clojure, de tenyleg csak akkor, ha nagyon kitarto vagy, vagy van, aki tanit. Esetleg Haskell, poenbol ;)

C++, Java ipari szornyetegek, nem programozast tanulni valok. Javascript nem olyan rossz, csak nagyon sok hujesege van, ami masik nyelvekben tipikusan nincs, vagy nem ugy van, es emiatt sok olyat tanulhatsz, aminek "semmi ertelme", egyszeruen tortenelmi okok miatt van ugy. Viszont Javascripthez van jo konyv, szerintem kezdonek is, ugyhogy vegulis miert ne.

Ha meg akarsz tanulni programozni, akkor jó kezdet a Java, legyél abban nagyon jó, és onnan kalandozz el a kevésbé szigorú, más koncepciójú nyelvek felé(Scala,Clojure, scriptnyelvek). Eleve egy lazább nyelvet tanulsz akkor, lehet hogy gyorsan elérsz valamit, de rossz szokások rögzülhetnek be.

( uid_15480 v | 2014. 07. 15., k – 17:45 )

Attól függ mit szeretnél csinálni. Én a C#-ot ajánlanám, nagyon sok jó Microsoftos anyag van hozzá, illetve rengeteg kiváló magyar és angol könyv/ebook.

Üdv. bnv

( lajos22 | 2014. 07. 15., k – 20:25 )

php-ból nem fogsz megélni. Pikk-pakk megtanulható, lehet vele rendesen programozni. De a pistikék úgyis 20 ezerér gányolnak egy oldalt, ezért nem fogsz megrendelést kapni.

C++ és Java nehezebb, ezért nincs annyi pistuka. Én is ezért álltam rájuk, de én php után.

PHP jó arra, ha szeretnél saját weboldalt csinálni. Ha megtanulsz rendesen bánni vele és akként kezeled, amire kitalálták, akkor nem lesz vele gondod.

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

( uid_952 | 2014. 07. 15., k – 20:58 )

Menj el néhány közösségi vagy céges előadásra, vagy nézz bele az egyes közösségek fórumaiba, és ahol szerinted a legkevésbé gáz arcok vannak, -vagy esetleg neked szimpatikus emberek-, azt válaszd.

( endi123 v | 2014. 07. 15., k – 23:43 )

Attól függ milyen ember vagy

PHP: ha téged elsősorban az eredmény érdekel, viszont nem szeretsz vacakolni, töprengeni kérdéseken, rendezgetni, elemezgetni, pláne ha most épp egyébként is működik.

Java: ha szeretsz rendezett, elméleti konstrukciókat kitalálni és megvalósítani, amennyire csak lehet a számítástechnikai eszköz sajátos korlátaitól függetlenül gondolkodni. Elemző, rendszerző készséggel megáldott embereknek ajánlott. Itt elvárhatod hogy a segged alá tesznek mindent, mindenre van egy kitalált praktika, jól dokumentálva. Később haladóbb szinten jórészt abból áll (sajnos arra szűkül) a tudás bővítése, hogy ezeket a már kész, letisztult praktikákat megismerd és összedrótozd. Kevesebb vesződség mint C++-ban, ami persze kevesebb önállóságot, kevesebb változatosságot is jelent.

C++: ha szeretsz a dolgok mögé gondolni, hajlamos vagy a bonyolultabb, nehezebbnek látszó részekben a kihívást meglátni, nem áthághatatlan akadályként tekintesz rájuk. Ötletesség, önálló felderítő hajlam és kitartás kell ide. Később, haladóbb szinten is sok felfedezés vár rád, csupa különböző felfogásban megírt programrészek, hála a C++ 1000 arcának.

Binary
Which programming language are you?

01101100 11001100 11110000 10001000 11100000 10010010 10111011 01110111 11101110 11101111 11100000 11110000
YOU ARE BINARY.
YOU ARE NOT HUMAN AND GO TO GREAT LENGTHS TO PROVE IT. YOU ALWAYS KNOW WHERE YOU ARE AND HOW YOU GOT THERE, BUT NO ONE ELSE DOES EVER.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( utpKabel | 2014. 07. 16., sze – 00:32 )

Java. Sok hülyeség van benne, de a többi még ennél is rosszabb.

A PHP gány, ha nem muszáj, ne használd.

C++ azoknak van, akik szeretik szopatni magukat. Többé-kevésbé elviselhető, ha egy problémát másodszor oldasz meg, de másodszorra is csak akkor használj C++-t, ha a teljesítmény nagyon fontos. Ha egyszerűen tanulni szeretnél arról, hogy milyen alacsony szinten programozni, akkor a C-t ajánlom, abban legalább kevesebb a sugar-coated death trap.

( BaT | 2014. 07. 16., sze – 01:54 )

Már írták mások is, de szerintem nem érdemes csak egyet ismerni. Az általad felsoroltak mindegyike más világot képvisel, a java az erősen típusos erős oop managed vm világot, a c++ a natív világot, a php a gyengén típusos, gyakran nem is oop szkriptelést. Mindnek megvan a maga helye, az más kérdés, hogy ezeket a nyelveket olyasmire is használják amire volna jobb.

Ha már itt tartunk, szerintem érdemes alaposan körbejárni a nyelveket, pl. ha ismered a javat akkor nézd meg a .net világot is pl. c#-pal, ha a c++-t akkor az objc-t vagy a d-t, ha a php-t akkor a pythont vagy a rubyt. Ez azért jó, mert minél többet látsz, annál inkább fogsz megérteni és értékelni egy-egy feature-t, érteni fogod hogy mire jó vagy épp hogyan van borzasztóan elszúrva az adott környezetben. Illetve ha munkát keresel, nem vagy egy adott nyelvhez kötve, az algoritmikus gondolkodás mindben ugyanaz, az meg még jobbá is tesz ha egy feladatot több szemléletben is meg tudsz oldani. Továbbá az eddig felsoroltakon kívül ha a web érdekel akkor mindenképp érdemes ismerni a frontend nyelveket (html, css, javascript), ha a natív akkor egy kis assemblyt, illetve bármikor jól jöhet egy shellscript nyelv (bash, powershell) és egy funkcionális nyelv (lehet akár a javascript is, de inkább scala vagy erlang).

Én jelenleg hivatalosan java fejlesztőként olyan 6-8 nyelvet kell, hogy ismerjek, abból olyan 2-3-at komolyabb szinten. Ezen kívül még olyan 4-5 nyelvet ismerek és használok is időnként, feladata válogatja.

Persze ez nem fél-egy év munka, amire én ki akarok lyukadni az az, hogy nem érdemes bebetonozni magad egy technológiára. Ha így teszel, és az ipar elfordul az általad preferálttól, akkor borzasztóan nehéz lesz váltani, míg ha az évek alatt megismersz több nyelvet és technológiát, akkor mindig rá tudsz gyúrni arra, amivel a legszívesebben foglalkoznál és igény is van rá.

Bírom az ilyen grafikonokat, mert érdekesek, de őszintén szólva nem alapoznék rájuk ilyen döntést.

Szélsőséges példa: a COBOL sehol nincs ezeken, de nem egy olyan céget tudok, ahol aktívan használnak COBOL-t, és a belátható időn belül (minimum 10 év) nem is tervezik leváltani. Nyilván kevés embert tud felszívni a COBOL fejlesztés 2014-ben, de akit igen, az betegre keresheti magát vele.

( Andrei | 2014. 07. 16., sze – 15:38 )

A felsoroltak kozul a c++-t nagyon ismerem a tobbit kevesbe. Ebbol sejtheto, hogy erosen objektiv lesz a velemenyem.

Szerintem (amennyiben lehetoseged van ra, hogy a "fun-factor" alapjan valassz, akkor erdemes a c++-ba idot invesztalni.

- Elkepesztoen jol vegiggondolt nyelv. Igaz, hogy barokkos, de ha moge nez az ember, kiderul, hogy minden egyes logikatlannak tuno resz valamilyen nagyon erdekes megoldast rejt. Eleg keves olyan furcsasaggal talalkoztam, aminek az lett volna a magyarazat, hogy "bocsi de ezt elb*sztuk"....

- Lehet hozza talalni jo konyvtarakat (pl. boost, folly, Qt, libcppa, OpenSceneGraph), amikkel eleg szeles alkalmazasi terulethez lehet igazitani.

- Bar nem vitatom a GC erejet, de az explicit eroforraskezeles jo programozasi stilusra tud tanitani. Nincs ilyen, "hogy lefoglalom ezt a 100 mega memoriat, meg megnyitok 10 adatbazist, majd a GC takarit utanam". A C++-ban szerintem az a jo, hogy majdnem elerheted vele a GC-szintu kenyelmet, de minden folott donthetsz, ha akarsz. Sajnos a c a masik veglet, ott neked kell minden felett diszponalnod, akkor is, ha nem lenne szukseges.

- Szerintem kivalo irodalma van. Meyers, Sutter, Alexandrescu es a tobbi fontos szerzo jot es jol ir. Hosszu honapokat lehet -szerintem- hasznos tanulassal tolteni a fontosabb C++ konyvekkel.

- A C++ szabvany eleg sokaig keveset es ritkan valtozott (2010 elott), de azota masodik reneszanszat eli a nyelv, folyamatosan fejlodik, szoval nem fasul bele az ember egy 30 eve nagyjabol valtozatlan nyelvbe (a c-nek ez elonye, de szerintem hatranya is).

- A *jo* c++ programozo nagy ertek, nem veletlenul. Az ipar szerintem anyagilag eleg jol honoralja, akinek van rutinja.

Szemely szerint en eleg poenosnak tartottam hobby celokra a Ruby-t (a metaprogramozas eleg kiralysag benne) is, de a konkret megvalositasai a nyelvnek nem tunnek betonbiztosnak....

Azért az elég nyilvánvaló, hogy én soha nem is állítottam, hogy értek hozzá, viszont nincs is akkora arcom, hogy az Alagútba is csak akkor fér be, ha kicsit megbontják előtte a falakat. :DDD
(és az ugye elég nyilvánvaló, hogy te sem értesz hozzá, csak a pofád nagy)

upd: félreértések elkerülése végett jelezném, fogalmam sincs, windows-ban van-e akár egyetlen sor C++ (azt közben megnéztem, hogy a linuxban nincs :D), csak arra próbáltam utalni, hogy nem kicsit röhejes, mikor "szakértő úr" megmondja a tutit. :D

Szerintem nem viccnyelv a c++, illetve, ha az, akkor nagyjabol minden mas nyelv is az.

Altalaban azok szoktak ilyen kijelenteseket tenni, akiknek fogalma sincs a c++-rol, meg talan altalaban a programozasrol sem. Itteni hozzaszolasaid alapjan megkockaztatom, hogy fogalmad sincs, hogy mirol beszelsz. Valoszinuleg olvastal valamit, vagy hallottal valamit egy neked szimpatikus, de hasonlokeppen fogalomnelkuli embertol, es azt szajkozod. Ha hoznal erveket, nyilvan keptelen lennel kifejteni vagy megvedeni oket. Marad a vagdalkozas.

Felreertes ne essek, nem kell mindenkinek szeretnie. Nagyon sok ismerosom van, akinek nem a szive csucske a C++ (pedig ertenek hozza). Van egy csomo nyelv, amit erdemei ellenere en sem komalok (pl. Java). Viccnyelvnek ennek ellenere nem neveznem. Latom, hogy lehetseges azokkal is ertekes munkat vegezni. A C# a masik pelda, irtam jopar GUI-s programot benne, engem nem fogott meg annyira. Nem neveznem viccnyelvnek, sot szerintem komoly szellemi munka van mogotte. Sot meg azt sem erzem furcsanak, hogy sok mas embernek az *a* nyelv.

Itt most arrol volt szo, hogy valakinek van ideje (lehet, hogy viszonylag sok ideje) es kerdezte, hogy mivel usse el. Szerintem a C++-ba eleg sok idot kell fektetni (itt vagy eleven peldanak te, hogy meddig er el az, aki nem teszi meg), de ha olyan szerencses vagy, hogy ezt a befektetest meg tudod tenni, akkor -szerintem- sokat lehet belole profitalni.

Persze most ide lehet cibalni szamtalan "nagy nev" C++-t alazo linkjeit. Linus lenne ugye az egyik, aki kapasbol az eszembe jut. Szerintem ez jelen esetben irrelevans. Linus egy nagyon specialis szemszogbol (jelen esetben a kernelfejleszto szemszogebol) van a C++ ellen. Az o programozasi nyelvekkel szembeni prioritasai markansan elternek a vilag programozoinak prioritasaitol. Ha a kerdezo azt vetette volna fel, hogy kernelt akar csinalni tanulasi cellal, hidd el meg sem mukkantam volna, szerintem sem feltetlen jo valasztas a C++ erre a celra.

Szoval nem fosom tovabb a szot, kerdes, hogy neked vannak-e erveid vagy ertekelheto meglatasaid a dologgal kapcsolatban?

Hidd el, te még polinál is mélyebben vagy... és nem csak az én szememben. Szóval a véleményed semmit sem számít.
A fenti nem is neked szólt. :DDD

Egyébként meg egész konkrétan emlékeztetsz arra a faszra, aki az utolsó csepp volt az egykori munkahelyemen: "projektmenedzserként" annyit tudott, hogy folyton baszogatta a projektben résztvevőket, hogy miért nincsenek még készen, de érdemi munkát senki sem látott tőle a környékemen. Pár év múlva kirúgták az akkori főnökömet és ezt az izét ültették a nyakunkra. Én voltam asszem az első, aki eljött részben miatta, viszont amint hallom, elég szép pusztítást végzett utána: részben szakmai téren, részben meg azzal, hogy a legjobb embereket rugdosta ki. Végül, ha jól tudom, ő is repült. :D

Azért elvárnám egy projektmenedzsreből szakterület vezetővé avanzsált egyéntől, hogy értsen az általa vezetett területhez valamennyire. Na ezt hiányoltam. (meg az embereiért való kiállást, de az más téma)

ui: szervezőktől sem láttam soha, egyetlen sor kódot sem, kábeleket sem cincáltak, valahogy mégis tudtam, hogy képben vannak, részben a fejlesztési dolgokkal, részben az adott terület szakmai részleteivel kapcsolatban. (pl. számviteli dolgok, könyvelés etc.)

annyit tudott, hogy folyton baszogatta a projektben résztvevőket, hogy miért nincsenek még készen, de érdemi munkát senki sem látott tőle a környékemen

B+, a projektmenedzsernek pontosan ez a dolga! Ne nyúljon hozzá semmihez, ellenben baszogassa a projekt résztvevőit. Ezért szokás őket tartani. A sikeres projektmenedzser titka abban rejlik, hogy pont akkor, pont azokat, és pont annyira baszogassa, ahogy az még éppen szükséges a sikerhez, se több, se kevesebb baszogatás ne legyen.

Az a baj, hogy erre egy sokadik senki segédmunkás is jó lett volna, minek ehhez egy ekkora szakember?
Addig nem is zavart különösebben (max. a munkámban), míg a projekteken pattogott. De amikor főnököt csináltak belőle egy olyan területen, ahol azért nem ártana, ha a vezető ért is az adott szakterülethez... :((

Példát tudok hozni, való életből merítve: üzemeltetés, egy emberre jut 6-7 rendszer. Ebből egy intenzív fejlesztés alatt.
Összedől valami, amitől megáll a céges ügymenet. Emberünk feje egyre lilább, mert nem találja, hogy mi van és percenként három telefon, hogy miért nem megy a rendszer.
Egyszer csak megjelenik projektmanáger úr és finoman érdeklődni kezd, hogy a másfél órával korábban kért teszt adatbázis miért nincs még kész?

És van valami hihetetlenül jó érzéke hozzá, hogy kizárólag olyankor állítson be az ilyen jellegű kérdéseivel, amikor épp diliház van valamiért...
Biztos, hogy ez kell az embereknek? ;)

Ki beszélt itt határidőről?
Dolgozunk, "csinájjá egy adatbázist, neked úgy is csak öt perc!" és jön reklamálni, mert tényleg csak annyi jut a tudatáig, hogy nekem csak öt perc. Azt már nem fogja fel, hogy azt az öt percet adott esetben el kell venni valahonnan. :)

Ismertem normális projektest is... egyikük nagyon magasra jutott (tartok tőle, hogy fog még szegény torkosborzot játszani :(( ), másikat kirúgták, a harmadik emberileg normális volt, de szakmailag nem tudtam vele kibékülni, végül ő is elment stb.
Így visszagondolva, ismertem jó néhány projektmenedzsert, volt köztük két hülye, de bennem ezek maradtak meg, mint _A_ projektmenedzser. A többi csak kolléga volt... :(

> mert tényleg csak annyi jut a tudatáig, hogy nekem csak öt perc. Azt már nem fogja fel, hogy azt az öt percet adott esetben el kell venni valahonnan. :)

Persze, ezrével szennyezik a levegőt az ilyenek, de pont azt mondom, hogy ez a rossz PM. Van jó PM is, ahol te örülsz fejlesztőként/rendszergazdaként/stb., hogy ő ott van, eltakarítani a kakit körülötted. Nyilván, ez utóbbi a ritkább. ;)

(Úgy szoktuk fogalmazni, mint a klasszikusban: nem az a fontos, hogy miből írod a diplomamunkát, nyuszika, hanem, hogy kia konzulensed.
Ez pedig úgy jön ide, hogy ahol megvan az a konzulensed a mátrixos szervezetben, aki a pjt vezetőnek jó szóval/még konzulensebbre hivatkozva/klaszterbombával elmagyarázza, hogy számodra addig a mindennapi biznisz a prio 1, amíg ő nem lesz az erősebb kutya, ott a mátrix nem a hetedik bőr lenyúzását szolgálja a felelősségi körök és prioriátsok elmosásával. Ahol ilyen konzulens nincs, ott nem csak a pjt vezető szar, viszont a belgyógyásznak és a fejvadásznak arany élete lesz.)

Sehol nem allitottam, hogy milyen kiraly vagyok benne. Sokat dolgoztam c++-al az elmult evekben, ezert batorkodtam ajanlani, mert szerintem en sokat profitaltam az alapos megtanulasabol.

Probalom leegyszerusiteni az allitasomat, mert elsore nem sikerult ertelmezned:

- Van az az embertipus, aki fikazza a c++-t, de ert hozza es *ertelmesen* meg tudja fogalmazni a velemenyet. Ertsd vannak ervei es vitakululturaja, tehat kepes ezeket az erveket utkoztetni. A vita eredmenye meg jo esetben az, hogy tanul mindenki aki reszt vesz benne (vagy valaki ugy all fel, hogy "bazze, igazad van, ezt kiprobalom). Ha igy sorba szeded a mondanivalodat, elbeszelgetunk es okosodunk. Talan az ilyen forumok optimalis esetben errol szolnanak.
- Van az az embertipus, aki fikazza a c++-t, mert hallotta az altala okosnak velt embertol, hogy az szar. Mivel nem erti a dolgot melysegeben, ervei kimerulnek arcoskodasban es mindenfele epkezlab ervet mellozo poenoskodni probalasban.

Lassuk ezt a diskurzust:

1. Tettem egy javaslatot, irtam erveket, szemelyes tapasztalatokat, javaslatokat.
2. Most gyorsan visszanezem a valaszaidat:

"mert egy viccnyelvet reklamoz?" -> lozung, zero erveles
"megjott HZ, aki meg annyira se ert hozza, mint atomjani." -> vicceskedni probalas, szemelyeskedes, zero info
"szerintem en mar tobbet felejtettem cppbol, mint te valaha tudni fogsz rola..." -> vicceskedni probalas, szemelyeskedes, zero info
"tehat ha valaki szerint rossz a nyelv = nem ismered, inkompetens vagy, biztos csak hallottad, nem is tudsz programozni, etc.
"kerlek irj meg egy ket oldalas esszet arrol, hogy te milyen kiraly vagy, mehet a /dev/nullba rogton, koszi!" -> olvasottak felreertelmezese, zero info, szemelyeskedes
"jajj HZ, nem jottel meg ra, hogy a te velemenyed a lista legaljan van nalam? atomjanival vetekszetek csak ott alul." -> szemelyeskedes, zero info
"a projektmenedzsernek ritkan dolga konkretan kodolni, kabelt huzni, whatever. lehet hogy ordas mennyisegu burokraciatol mentett meg titeket, csak eszre sem vettetek." -> jelen esetben ez lehet egy ertelmes allitas, de masszivan offtopic, bar nem te kezdted
"+sok, fun factor meg C++ AHAHAHAHA mi ez a kesz atveres show?" => vicceskedni probalas, zero info

Tehat legalabb 8 hozzaszolas erdemi info, erv nelkul. Ha atsiklottam valami lenyeges felett, nyugodtan szolj.

Ebbol en kezdek arra kovetkeztetesre jutni, hogy a fent leirt fikazok masodik csoportjaba tartozol. Ha lennenek jo erveid ennel lenyegesen kevesebb erofeszitsbol kb. 1 hozzaszolassal ossze tudnad irni oket es infot adnal a kerdezonek is. Nem tartom kizarnak, hogy kurva jo erveid lehetnek (lehet, hogy meg engem is meggyoznel es rohannek atkepezni magam). De temerdek hozzaszolas alapjan ez meg nem jott at.

C++-szal nekem az a legnagyobb bajom, hogy rengeteg nyelvi feature-rel rendelkezik, de hirtelen egy se jut eszembe, amire azt mondanám, hogy a C++-ban van a legjobban megvalósítva. Sokszor ugyan arra a problémára több megoldás is van, és nagyon nem mindegy, hogy melyik alternatívával választod, mert könnyen lábon lőheted vele magad. Pl. egy objektumot a stacken vagy a heapen tárolj le, ha a heapen akkor pointer vagy referencia mutasson rá, stb. Ezért van kevés jó C++ kóder és ezért baromi nehéz megtanulni, nem a szintaktikát nehéz elsajátítani, hanem az ilyen helyzetekben a jó döntés meghozásának képességét.

Egyébként a C-hez és C++-hoz mindig belinkelendő előadás: http://olvemaudal.com/2011/10/10/deep-c/

A világ egyértelműen a magasabb szintű nyelvek felé halad, a C++-t is sokan inkább próbálják lecserélni még natív fronton is (pl. D, .net native, stb.). Bár biztos, hogy még sokáig velünk lesz, én nem biztos, hogy abba fektetnék időt. Ugyanannyi idő alatt, amíg megfelelő szinten megtanulod a C++-t, megtanulhatod ugyanilyen szinten a java-t vagy a c#-ot is, jvm-mel/clr-rel, gc tuninggal, mindennel együtt.

Vannak igazsagok abban, amit irsz. Egeszen biztos, hogy a c++-al szemben felhozott egyik leggyakoribb (jogos) erv, hogy nagyon nehez "uzembiztos" jartassagot szerezni.

Nagyon ritka az a tanulasi utvonal, amikor valaki idiomatikus c++-t tanul. Sajnos a tutorialok nagy resze a C-bol indul, hozzaadja az osztalyokat, az oroklodest, a kiveteleket, stb. stb.... . Viszont ritkan van szo a RAII-rol (pedig talan az egyik legfontosabb c++-os idioma). Pedig hat Stroustrup szerint ez volt az egyik legfontosabb idea a nyelvben. Es mondjuk egy fust alatt a kivetelek mukodese is erthetoeve valik, ha az ember rajon, hogy mirol van szo lenyegeben.

Gyakori tapasztalatom, hogy fejlesztocsapatok sajat hatokorben karosnak vagy kerulendonek tartanak bizonyos feature-oket. Ezzel nem is lenne gond alapbol, mindenkinek joga van eldonteni, hogy mit hasznal es mit nem. Viszont gyakran erzodik ilyen dontesek mogott, hogy valami vezeto programozonak volt valami negativ tapasztalata pl. a kivetelekkel, aztan egybol kibombazzak kodbol es ternek vissza a kodokra. Viszont jo c++ kodot irni sok esetben nehez kivetelek nelkul (klasszikus pelda ugye a hibazo konstruktorok esete, amit kivetelek nelkul jol es elegansan megcsinalni joforman lehetetlen). Ha tudnad hany custom string implementaciot lattam ami 1-2 dologban jobb volt, mint a std::string, viszont masik harmincban meg rosszabb volt.

Szinten szemelyes tapasztalat, hogy hosszu tavon az a tarsasag jar altalaban jol, aki egesz kozel tud maradni a "kanonizalt" vonalhoz, es nem probal meg feltalalni es patkolni egy kulonutas valtozatot. Egyreszt tobbet lehet profitalni a tagabb ertelemben vett kozosseg tudasabol, masreszt a nyelv evolucioja sem fog folyamatosan reviziora kenyszeriteni. Ez meg neha a nagyoknak sem mukodik, peldaul szerintem a Microsoft, ha akarta sem tudta volna az MFC-t teljes ujrairas nelkul aktualissa tenni, ahogy fejlodott a nyelv.

A c++ lecserelese szerintem nagyjabol azota tema, amiota van c++ :). Nincs ezzel semmi gond, de ez egy lassu folyamat. Eloszor is a C++-nak kellene valamilyen porcikajaban masszivan idejetmultnak mutatkozni. Az a helyzet, hogy a sajat mufajaban a c++ viszonylag korszeru (teljesitmenyorientalt, hordozhato, nativ, tamogatja a generikus programozast es valamennyire a funkcionalis programozast is, majdnem teljesen kompatibilis a c-vel), es a hasznaloi jol elvannak vele. Nyilvan ha ok lennenek elegedetlenek, akkor tomegevel rohanna mindenki d-t tanulni, mert a beleolt ido gyorsan megterulne. De sajnos egyenlore az a helyzet, hogy nagy kodbazisokat (es csapatokat) c++-rol mas nyelvre migralni legalabbis vakmero vallalas, aminek a haszna kerdeses. Sot azert a kozben a c++ is fejlodik a jogos kritikak hatasara (van mar szabvanyos szalkezeles, funkcionals programozas fejlettebbe valt, template-eket okosabba tettek, jelentosen bovitettek es bovitik a szabvany konyvtarat).

Nade hogy megintcsak tegyek javaslatot is: szerintem nagy a c++ irodalom, egy kezdonek szerintem okosan kell valogatni, hogy mit hasznal a tanulashoz. Mindenkeppen az Effective C++-t tartom a jo tanulasi iranynak, mert a hasznos info/oldalszam mutatoja zsenialisan jo. Nyilvan nem egy referencia, de arra meg kiegesziteskeppen ott a cppreference.com, vagy a cplusplus.com. Most mar betaban elerheto az Effective Modern C++ is, ami a szabvany szerinti aktualizalt folytatas, remelhetoleg az is alapmu lesz. Amikor mar az alapkoncepciok jol mennek akkor egybol johet a Design Patterns es a Modern C++ Design. Ezek viszonylag regi konyvek, igen jo gyakorlat a leirt technikak aktualizalasa... Es itt most beszelek kb. 700 oldalnyi anyagrol, ami azert annyira nem kiugroan sok. De garantalom, hogyha valaki atragja magat rajtuk, megadja az elmeleti alapot, hogy kello gyakorlattal tuti c++ programozo lehessen.

RAII - kíváncsiságból kérdezem, pár szóban össze tudnád foglalni, hogy mi ez? Mert a wiki szövegét átfutva, nekem az jött le, hogy valami olyasmi, mint máshol a GC (már ha jól értem és arról van szó, hogy a konstruktorban lefoglalni a szükséges erőforrásokat és ezeket a destruktor futásakor automatikusan felszabadítja a rendszer)

Ha eleg messzirol inditom a dolgot, nezzunk egy fuggvenyt:

void foo() {
some_class obj;
}

some_class konstruktora meghivodik, amikor obj definiciojahoz erunk es a destruktor meghivodik, amikor scope-ot elhagyod. Fontos, hogy ez nem fugg attol, hogy hogyan hagyod el az adott scope-ot, tehat az lehet ido elotti return, kivetel dobasa es normal visszateres a fuggveny vegen. Ez azt jelenti, hogyha obj valamilyen eroforrast birtokol es a destruktorban gondoskodsz a felszabaditasrol, akkor egeszen biztosan nem lesz eroforras szivargasod.

Ez eddig egyszeru es jogosan adodik a kerdes, hogy miert mas ez, mint a GC (ott is felszabadulnak automatikusan a nem hivatkozott objektumok). A mogottes mukodes elegge eltero:

- obj felszabaditasa c++-ban azonnal megtortenik, amint elhagyod a fuggvenyt, GC eseteben a felszabaditas megtortenik valamikor kesobb (az hogy mikor, az nem igazan determinisztikus)
- ha tobb lokalis objektumod is van, akkor a felszabaditas sorrendje deteminisztikus c++-ban (jelesul a letrehozas sorrendjenek ellentettje). GC eseten a felszabaditas sorrendje nem determinisztikus
- a GC algoritmusa lenyegesen bonyolultabb, mint amit a c++-runtime-nak kell vegrehajtania. A c++-runtime-nak pontos kepe van arrol, hogy melyik objektumokat kell felszabaditani egy scope elhagyasakor (azokat, amik az adott scope-ban jottek letre), a garbage collectornak fel kell epitenie az elerheto objektumok grafjat, es a kimarado objektumok mennek a levesbe, ez aszimptotikusan egy nehezebb muvelet.

Ennek a GC viselkedesnek eleg sok (szerintem) negativ kovetkezmenye van:
- Ha olyan eroforrast birtokol az objektum, amivel takarekoskodni kell, vagy az eroforras akadalyozza a tovabbi programfutast (pl. egy lock-ot tart), akkor nem eleg azt tudni, hogy "majd valamikor azert felszabadul".
- Ha tobb objektumot gyujt be egyszerre a gc, amelyek hivatkoznak egymasra, akkor nem elhetsz azzal a feltetelezessel, hogy az objektum referenciai korrektek. Eleg problemassa valik a destruktorok jo implementacioja.

Termeszetesen ez nem azt jelenti, hogy a c++ okos a tobbiek meg tok hulyek.

Pl. legjobb tudomasom szerint c#-ban az elso problemat ugy oldjak meg, hogy van az ugynevezett IDisposable interfesz. Ha egy osztalyod ezt megvalositja es hasznalod a using konstrukciot, akkor a Dispose() meghivasaval determinisztikussa valik a felszabaditas. Viszont a programkodod is bonyolultabb lesz, ugyanis a fenti cucc igy nez ki c#-ban:

void foo() {
using (obj = new some_class()) {
...
}
}

remelem nem rontottam el, regen nem programoztam c#-ban, de gondolom a lenyeg atment. Szoval uj scope-ot kell nyitni, ami szerintem rontja az olvashatosagot es bonyolitja a programod szerkezetet. Masfelol ha elfelejted ezt megtenni, akkor maris ott van a baki, hogy az objektum mar nincs scope-ban, de meg rajta csucsul az eroforrason (tehat az automatikusnak szant eroforraskezeles megiscsak explicit marad, es el lehet rontani). Hiaba irod meg jol az osztalyodat, nem tul nehez (figyelmetlensegbol) pazarlo modon hasznalni. Ehhez kepest a c++ megkozelitest ugymond akarni kell rosszul hasznalni, a veletlen hiba eselye gyakorlatilag nulla (ezt hivjuk ugy, hogy "protection against Murphy, but not against Machiavelli").

Nyilvan nagy kenyelem a GC, de alapjaban veve nemdeterminisztikus folyamat, amit nem igazan lehet determinisztikussa tenni. Ezert is van, hogy a C++ jobb teljesitmenykritikus programok irasara, mint a GC kornyezetek. A GC altal okozott teljesitmenyminuszt szoktak altalaban szidni, de szerintem amirol most irtam sokkal kritikusabb tud lenni, mert a programod helyesseget is befolyasolja.

Errol szol az alaptechnika. Mondjuk a smart pointerek koncepciojaval parositva natur c-s handle-ek eroforrasat is lehet vedeni, tovabba teljesen ki lehet valtani az explicit new/delete hasznalatat dinamikus memoria hasznalatakor. De ez mar a kovetkezo lepcso...

"- Ha tobb objektumot gyujt be egyszerre a gc, amelyek hivatkoznak egymasra, akkor nem elhetsz azzal a feltetelezessel, hogy az objektum referenciai korrektek. Eleg problemassa valik a destruktorok jo implementacioja."

Ez nem tudom, hogy melyik platformra vonatkozik, mindenesetre érdemes lenne ennek jobban is utána menni, legalábbis én se arra nem fogadnék, hogy pl. javaban ez így van, se arra, hogy nem. Ott speciel a finalizerrel rendelkező objektumok (nem destruktor!) a gc futásakor bekerülnek egy sorba, ahonnan egy alacsony prioritású thread fogyasztja az objektumokat és futtatja a finalizereket. Tehát csak annyit kell csinálni, hogy amíg egy objektum ebben a sorban van, addig az általa hivatkozott objektumgráfot sem szabad takarítani, ami nem egy nehéz feladat.

"Ezert is van, hogy a C++ jobb teljesitmenykritikus programok irasara, mint a GC kornyezetek. A GC altal okozott teljesitmenyminuszt szoktak altalaban szidni, de szerintem amirol most irtam sokkal kritikusabb tud lenni, mert a programod helyesseget is befolyasolja."

Hát, én inkább azt mondanám, hogy egyrészt gc tuning és use case kérdése. Pl. ha stop the world gc-t használsz és rengeteg pici rövid életű objektumot hozol létre, a gc ritkán fog futni, de akkor, amíg le nem fut, megáll az alkalmazásod, c++ esetén meg folyamatosan érezni fogod a destruktorokból származó teljesítmény csökkenést. Viszont ha átváltasz egy másik ütemezőre ami nem STW, azzal jobb eredményt is elérhetsz, cserébe több memóriára, több cpu magra lehet szükséged.

Igen, a try-with-resources-t kihagytam, de mivel ugyanaz mint a using c#-ban, a lényege le lett írva. Legjobb tudomásom szerint egyébként a finalizereket azért csinálták, mert maga a java library használja, ha nem libraryt írsz akkor úgysem lesz rájuk szükséged, legfeljebb safety netként ha megvalósítod a Closeable interfészt.

Alapvetően nem is értem, mi a probléma. Átlag java fejlesztésnél nem használunk ilyen erőforrásokat (összesen egy dolog jut eszembe, ami hasonló, az a jdbc connection, de azt
meg egy try-catch-finally és egy connection pool tökéletesen lekezeli).

Szóval java-ban (és c#-ban is) a fejlesztés 0.001%-ban találkozik ezzel a problémával az ember, az összes többi esetben viszont ott van az a kényelem, hogy nem kell azzal szórakozni,hogy most heap-en vagy stack-en hozok létre valamit, hogy most pointer-t vagy referenciát ad át, hogy copy constructor-t irogasson, és az hogy legyen jó, hogy hogyan hegessze bele a kódba a mások által csinált, esetleg homlokegyenesen más logikával készült library-t, és a többi. Java esetén ráadásul az objektumok létrehozása baromi gyors, a gond ott szokott lenni, amikor sok objektumot egyszerre próbál felszabadítani a GC, de a 6-os 7-es 8-as java-ban a párhuzamos GC-vel már igazából ez sem jelent problémát.

Tehát az állításod az, hogy az esetek 99.999%-ban nem használsz file-okat, hálózati kapcsolatot, mutex-et, stb. Szóval úgy általában semmilyen erőforrást ami nem memória.

Erős a gyanúm, hogy a becslésed nem korrekt... :)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

A kilencesek száma talán kicsit sok, de nem arról van szó, hogy programok ekkora részében nincs file, hálózati kapcsolat vagy mutex, hanem hogy egy programban az objektumok ekkora része nem használ fájlokat, hálózati kapcsolatot vagy mutexet. Mert C++-ban minden egyes objektumnál foglalkoznod kell resource managementtel, mert minden objektum használ memóriát, míg egy GC-s nyelvben csak az objektumok 0.001%-a resource handler, amit try-finally-vel vagy try-with-resources-zal (determinisztikusan) kezelünk, a maradék 99.999%-on pedig gondolkodnunk sem kell, mert GC tudja a dolgát.

Pontosan... elhanyagolható azon osztályok száma, amelyekben socketet hozunk létre (kb. programonként 1 osztály), file-t kezelünk (megintcsak néhány osztály) vagy mutexet használunk. Ezeket a corner eseteket a try-catch-finally, vagy a try-with-resources tökéletesen megoldja, az összes többi csilliárd osztályban pedig ott a GC.

"Mert C++-ban minden egyes objektumnál foglalkoznod kell resource managementtel"

Igazából nem, mert az objektumok 90% a stack-en van vagy adattag. Lehet, hogy 99%.

Tudnék mutatni sokezer soros kódot egyetlen new-malloc nélkül (tudományos számítások).
Vagy hasonló mérető Qt-s GUI kódot egyetlen manuális delete nélkül. Egyikben sincs memory leak.

A RAII egy igen elegáns megoldás mindenféle erőforrás kezelésre (ideértve a memóriát is).

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Egy újabb C++-os félreértés, hogy csak a delete meghívása manuális memóriakezelés, és ha RAII-t használsz, az már "automatikus".

Jó, lehet így definiálni a fogalmakat, de az én szememben az is manuális memóriakezelés, amikor minden egyes objektumnál felteszed magadnak a következő kérdéseket:

* Túl kell élni-e az objektumnak a scope-ot, amelyben létrejött?
** Polimorf az objektum?
*** → stack allocation
** → scoped_ptr / unique_ptr
* Szükséges az osztott hozzáférés?
** → unique_ptr
* Lehetnek körkörös hivatkozások?
** → shared_ptr
* Megtörhetőek a hivatkozási körök gyenge referenciákkal?
** → shared_ptr + weak_ptr
* → tracing GC

Olvasási szabályok: minden kérdésre igen vagy nem választ kell adni, igen válasz esetén a következő azonos behúzású pontra kell ugrani, nem válasz esetén az alatta lévő, eggyel nagyobb behúzású pontra. Ahol nyíl van, az a pont megadja a végső megoldást az adott helyzetre.

Persze, az esetek legnagyobb részében a stack a jó megoldás, így csak két kérdést kell feltenni, továbbá egyre ritkábban jut csak el egyre mélyebbre az ember ebben a kérdéssorban. Ugyanakkor minél mélyebbre jut az ember, annál bonyolultabb ezeket a kérdéseket megválaszolni, és a legritkább esetben az is előfordul, hogy csak egy tracing GC tudja megoldani a problémát.

Összehasonlításképpen egy valóban automatikus memóriakezelésű nyelvnél a következő kérdéssort kell használni:

Hja, kérem, ezzel az erővel egy GC nyelvben minden egyes objektum létrehozásánál végig kell gondolni, hogy vajon lefoglal-e bármilyen erőforrást, ami nem memória, ha igen, akkor kell-e az az erőforrás a scope-on túl, stb. stb.

Ilyen ez a szakma, gondolkozni kell...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Elképzelhető ilyen, már ha a kolegák a legalapvetőbb oop-s elveket sem tartják be a változók szerepkörével, scope-jával kapcsolatban (bár még akkor is elég bénának kell lenni). Csak akkor meg bukik pár teszt elvileg. A refactor egy alap dolog javaban, ezen kár vitatkozni.

Egyik oka, hogy soha többé nem fogok programozni, éppen az, hogy képes vagyok órákat, akár napokat tökölni azon, hogy egy függvénynek, változónak milyen nevet adjak. :D
Nem igazán hatékony módszer.
Ha gyorsan és biztonságosan lehet átnevezni, akkor elsőre akár a1, a2, a3 stb. nevekkel is lehet próbálkozni és utólag kitalálni a neveket. ;)

Pedig ez az egyik legfontosabb lépés. Már persze, ha nem fire-and-forget rendszerben programozol, hanem szempont az, hogy később valaki (akár te magad) képes legyen használni a kódodat.

Ezen persze rugózhatunk még egy darabig, de attól még a rename léte vagy nem léte a nem definiált IDE-ben továbbra sem lesz érv a GC mellett vagy ellen. :)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

javaban ez így van, se arra, hogy nem. Ott speciel a finalizerrel rendelkező objektumok (nem destruktor!) a gc futásakor bekerülnek egy sorba, ahonnan egy alacsony prioritású thread fogyasztja az objektumokat és futtatja a finalizereket.

Hm?

Nekünk kifejezetten úgy tanították, hogy egyáltalán nem tuti, lefut-e a finalizer egy objektum halálkor...
--
blogom

Amikor a gc begyűjti az objektumot, akkor garantáltan lefut a finalizer, az nem biztos, hogy a program futása alatt a gc el fog ide jutni.

pl.: 


import java.util.Objects;

class Test {

        private String instanceId;

        protected Test(String instanceId) {
                this.instanceId = Objects.requireNonNull(instanceId);
        }

        protected void finalize() {
                System.out.println(instanceId);
        }

        public static void main(String args[]) {
                Test instance = new Test("Instance #1");
                instance = null;
                System.gc();
                instance = new Test("Instance #2");
        }

}

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ha a managed heapen lévő objektumod az unmanaged heapen memóriát birtokol, ilyenkor a finalizerrel biztosíthatod, hogy nem lesz memory leak. Viszont a legtöbb GC-s nyelvben nincs unmanaged heap, ezért csak foreign function interface avagy native interface használata esetén van értelme a finalizernek.

a) Igazán vészmegoldásnak jó, amennyiben az osztály valamilyen külső erőforrást birtokolt, amit a hanyag programozó elfelejtett lezárni (vagy kezeletlen hiba folytán pl), és még uccsó mentsvárként a finalizer megpróbálhatja felszabadítani.

b) Mikor példakódot írsz, hogy megmutasd másoknak, hogy nincs rá garancia, hogy lefut ;)

-
import groovy.transform.Immutable

Kétlem, hogy GSB ezt így tanította volna. :)

Az a nem tuti, hogy bármikor lefut a GC, illetve ha le is fut, bármikor felszabadítja. Ebből következik, hogy az sem garantált, hogy egy objektumnak bármikor lefut a finalizerje. De ha van neki, és a GC fel akarja szabadítani, és eljut addig a FinalizerThread, akkor le fog futni (legalábbis amíg nem dob exceptiont, mert azt meg simán ignorálja).

"The Java programming language does not specify how soon a finalizer will be invoked, except to say that it will happen before the storage for the object is reused." Egészen pontosan

És akkor még két fontos dolog:
"The Java programming language imposes no ordering on finalize method calls. Finalizers may be called in any order, or even concurrently."
"It is guaranteed that the thread that invokes the finalizer will not be holding any user-visible synchronization locks when the finalizer is invoked."

És a sensei (Joshua Block) szavai: http://www.informit.com/articles/article.aspx?p=1216151&seqNum=7

-
import groovy.transform.Immutable

Hát a GC egyedül a memória kezelésére alkalmas igazán, más erőforrásokat (file handlek, adatbázis vagy network kapcsolatok, stb...) tipikusan más nyelvekben manuálisan szoktak felszabadítani.
A RAII mindenféle erőforrás felszabadításáa nagyon alkalmas eszköz, mert akkor szabadul fel az erőforrás, amikor az objektum (determinisztikusan) destruálódik. Ez sok esetben egyszerűen annyi, hogy kimegy a scope -ból ({...}), de minden esetben jól kontrollálható.

Úgy általában nem tudom, mi a helyzet, python esetében az objektum felszámolása (x=Class() után x más értéket kap vagy törlöm) mindent felszabadít.
Úgy rémlik, a ruby is ilyen.
Erről én anno azt olvastam, hogy a GC csinálja.

Aztán ha valamit rosszul tudok... c'est la vie ;)

Szerintem nem igy mukodik, sem a Python sem a Ruby.

Gondolj bele, minden egyes referencia valtoztatas utan nekifutni es kitalalni, hogy mit lehet torolni... Az nagyon koltseges lenne.

Igazabol Ruby is Python is ugyanolyan elven mukodo GC-t hasznal, mint a JVM vagy a .NET, csak feltehetoen kevesbe ugyeset.

Idorol-idore a runtime ugy dont, hogy ideje takaritani. De ez nem feltetlenul tortenik azutan, hogy az objektumot hivatkozast null-ra vettem.

Persze adodik a kerdes, hogy melyik programozasi nyelv is kepes adni neked akarmilyen garbage collectiont es jobb futasideju teljesitmenyt a c++-nal alkalmazasok szeles koren (szoval az, hogy valakinek az Oracle-nel mar sikerult nagynehezen osszeizzadni egy olyan szintetikus benchmarkot, amivel mar jobb a managelt kod, mint a nativ, az irrelevans szvsz).

Ha mar itt tartunk: inkabb az lehet a gond, hogy a refcounting eseteben a korkoros referenciak kiszurese az ami koltsegesebbe teszi a dolgokat. Ezt a Python-nak meg kell fizetnie (mert ott, mint GC szerepel a modszer), ellenben a C++ ezt a koltseget nem fizeti meg, mert ok inkabb a determinisztikus felszabaditast valasztottak es trade-off-kent bent maradt a korkoros referenciak lehetosege( marmint a programozonak gondoskodnia kell olyan logikarol, ami ezt feloldja). Szoval ez egy majdnem jo kotozkodes, de kicsit durvan vesz egy kalap ala ket kulonbozo dolgot.

Sebaj, majd legkozelebb...

Azt akarom mondani, hogy az en velemenyem szerint:

- van a Python fele megoldas:
1. lassu mert futasidoben fel kell deritenie a koroket
2. teljesen automatikus
3. nemdeterminisztikusan szabaditja fel az objektumokat
- van a C++:
1. gyors, mert nem detektalja a korkoros referenciakat
2. nem automatikus
3. determinisztikusan szabaditja fel az objektumokat

Es most persze vitatkozhatunk rajta, hogy mennyire automatikus a Python megoldas. Mert nem az, ugyanis igaz, hogy a koroket felderiti es megszakitja "valahol", neked viszont a destruktoraidban (vagy finalizereidben legyen akarmi is a neve) fel kell keszulnod arra, hogy a kulso hivatkozasok mar nem elnek. Ez nyilvan extra kodot es vegiggondolast igenyel a tervezes soran.

Es ha mar valasztanom kell, en szemely szerint inkabb valasztom a C++ megoldast, ahol altalaban 1 helyen kell belenyulni, ahol megszakitod a kort es a tobbi automatikusan megy, mint a Python fele megoldast, ahol az osszes referencia potencialisan invalid lehet a megsemmisites soran. Plusz megkapom a determinisztikus sorrendet, ami miatt aszimptotikusan kevesebb code path letezik (tehat tesztelhetobb a tortenet), lehet, hogy O(1) vs O(n), de az is lehet, hogy O(1) vs. O(n!).

Ebben az esetben nincs silver bullet. Valasztani kell valamelyik ujjadat, amibe beleharapsz.

Es felreertes ne essek: nem azt mondom, hogy a C++ az egyetlen udvozito megoldas, viszont bazi dedos dolog kiragadni a dolog egy aspektusat es az alapjan velemenyezni a teljes megoldast. Mintha azt allitanad, hogy a C++ tervezoi olyan hulyek, hogy nem veszik eszre, hogy nem automatikus a korok kezelese. De eszrevettek, csak eppen volt egy masik szempont amit ervenyesiteni akartak (determinisztikussag + sebesseg), ami felulirta ezt a szempontot.

Szoval nezz a dolgok moge, mielott itelkezel.

A refcounting legnagyobb problemaja, hogy GC szempontbol nem teljesen korrekt algoritmus.

Ugyanis nem csak akkor szabad felszabaditani egy objektumot, amikor mar 0-ra csokkent a referenciaszamlaloja, hanem akkor is, ha mar nem erheto el az un. root objectekbol (regiszterek, statikusok, aktiv lokalis valtozok). A legegyszerubb pelda erre, ha van egy A es egy B objektumod, amelyek kolcsonosen hivatkoznak egymasra, de senki mas nem hivatkozik rajuk es mar kikerultek a scope-bol. Ilyenkor mindkettojuk referenciaszamlaloja 1-et mutat, tehat a naiv megkozelites szerint nem lehetne oket eldobni. Viszont mar nem elemei az un. "reachable set"-nek, magyaran szolva semmilyen aktiv valtozon keresztul sem tudod oket elerni, tehat mehetnek a levesbe. Ezt kell valamilyen modon detektalni.

Mondjuk kepzelj el egy fa adatszerkezetet, amelyiknel minden node hivatkozik a gyerekeire es a szulore is (nem mondom, hogy ez feltetlenul egy jo fa megvalositas, de a gyakorlatban ilyen szituaciok azert elo szoktak fordulni). Egy ilyen adatszerkezet orokre a memoriaban maradna, ha nem torod meg a koroket. Es a korok megtalalasa valoban lassabb, mint az az algoritmus, amit a JVM es a CLR hasznal GC-re (ok nyilvantartjak a root object-eket es egyszeruen felepitik az elerheto objektumok halmazat, az az aktiv objektum, ami nem erheto el, az mehet a kukaba).

Visszaterve az eredeti ketobjektumos peldara. A Python interpreter szemetgyujtoje valamikor ra fog ebredni, hogy A es B mar nem elerheto ezert megsemmisithetoek, es itt jon a problema: nemdeterminisztikus, hogy milyen sorrendben teszi ezt. Es ha mondjuk B objektum a destruktoraban vissza szeretne szolni A-nak, hogy o most eppen pusztulni keszul, nem lehet benne biztos, hogy A ott van vagy nincs. Ezert szokott egy good practice lenni a GC nyelvekben, hogy a finalizer-ek implementaciojaban nem nyulnak a referenciakhoz, vagy ha hozza kell nyulni, akkor mindig meg kell rola gyozodni, hogy milyen allapotban van a hivatkozott objektum. Itt a ketobjektumos peldanal ez nem feltetlenul nagy pluszmunka, de szerintem nem egy jol skalazodo megoldas. Ahogy egyre bonyolultabba valnak az objektumgrafok, annal komplikaltabba valik a problema es annal tobb explicit beavatkozast igenyel.

"Es ha mondjuk B objektum a destruktoraban vissza szeretne szolni A-nak, hogy o most eppen pusztulni keszul, nem lehet benne biztos, hogy A ott van vagy nincs."

Már fent egyszer kifejtettem, hogy szerintem ennek mért nem szabad problémának lennie, könnyű megoldást adni rá. Ami esetleg előfordulhat, hogy B objektum nem fogja tudni, hogy A-nak lefutott-e már a finalizerje (attól A még ott lesz a memóriában, mivel a finalizer nem destruktor és mivel B tartja a referenciáját A-ra), ezt viszont kézzel megint csak könnyen le lehet kezelni.

De most már bogarat ültettél a fülembe, mindjárt írok egy kis példaprogramot.

Kezdjük a legegyszerűbb esettel. Körkörös hivatkozás, finalizer hivatkozik a másik objektumra, ha a másik már nem elérhető vagy netán garbage lenne a helyén, akkor azt jutalmazzuk assertion errorral: http://pastebin.com/3EQ9KNmh

Ahogy azt várjuk, a program soha nem száll el, fut egy darabig, majd jön a GC és szépen felszabadítja az objektumokat, majd megint fut egy darabig és így tovább.

Egy picit bonyolultabb eset, tegyük fel hogy mindig a kisebb indexű finalizerjét akarjuk előbb futtatni. Csak hogy lássunk ilyet is, most direkt el fogom rontani: http://pastebin.com/DMWkJzx1

A kimenet valami ilyesmi: 


................ ... ...........B(629)#finalize calling other#finalize
	B(628)#finalize finalizer finished
 finalizer finished
B(376)#finalize finalizer finished
B(375)#finalize calling other#finalize
	B(374)#finalize finalizer finished
 finalizer finished
B(374)#finalize
java.lang.AssertionError
	at finalizerdemo.B.finalizerAssert(B.java:39)
	at finalizerdemo.B.finalize(B.java:22)
	at java.lang.System$2.invokeFinalize(System.java:1267)
	at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:98)
	at java.lang.ref.Finalizer.access$100(Finalizer.java:34)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:210)

A lényeg, hogy attól, hogy kézzel ráhívsz a finalize-re, még a FinalizerThread is rá fog hívni. Ezért nem ajánlott kézzel hívni a finalize-t, nem véletlenül protected. A megoldás egyszerű, kell egy flag ami megmondja, hogy lefutott-e már a kérdéses kód. Most megvalósítottam ehhez a Closeable interfészt is, de az remélem látszik, hogy ez semmit nem befolyásol: http://pastebin.com/BQXWGsTg

Innentől kezdve nem tudok olyan esetet kitalálni, amit ne lehetne megoldani, olyan nem lesz hogy egy referencia már nem él, azt pedig lehet workaroundolni, hogy az esetleges erőforrás felszabadítások mikor, milyen sorrendben fussanak le.

Kösz, közben sikerült pythonban is összehozni, miután rájöttem, hogy nem a konstruktorban kell csinálni a hülyeséget.
Annyira sikerült, hogy még a pythonból való kilépéskor sem fut le a destruktor. Hát izé... (vagy ha lefut, már nincs stdout ahová írjon)

http://pastebin.com/PD7YDjVw

a=A()
b=B()
a.setobj(b)
b.setobj(a)

És ettől kezdve hiába szabadítom fel a-t és b-t, nincs jele, hogy lefutna a destruktor. És ezt az az érzésem, hogy debuggolni sem lehet.

OK, nekem csak az volt a gondom, hogy előzőleg csak egy végtelen ciklusú rekurziót sikerült összehoznom ehelyett. :)
(szeretem a saját szememmel látni az ilyen hibákat, ha kivitelezhető)

Mondjuk onnan nem tiszta a dolog, hogy a pythonból való kilépés során mi történik ezekkel?
Egyéb úton sikerült olyat előállítanom, hogy csak a kilépéskor törlődtek bizonyos objektumok (interaktívan és nem emlékszem a részletekre :( ), de ez a kettő még akkor sem - legalábbis a __del__-gen lévő print kimenete nem jelenik meg sehol.

ui: szóval jó tudni, hogy a python bármennyire automatizált, hülyeség ellen ő sem véd.

Én azt nem értem, hogy mi az a probléma, amivel küzdötök.. van egy objektum, amiben van egy referencia a másikra, és valami okból szólni akar az objektum,
amikor már nem használjuk?

Most hirtelen pár ötlet a probléma megoldására:

close() metódus implementálása az objektumba, majd annak kézzel történő meghívása. (ez egy olyan ritka feladat, hogy erre lehet figyelni). Esetleg egy finalizer, assert kombinációval lehet védeni. ezt pedig egy klasszikus try, finally-ba lehet pakolászni.

ha még menőbb megoldást akarunk, akkor ott a try-with-resource (java7-es) feature, és akkor logikailag pont olyan lesz, mint python-ban..

http://www.oracle.com/technetwork/articles/java/trywithresources-401775…

Ha a Pythonban is elvégzed ugyanazt a munkát, amit C++-ban, (nevezetesen: garantálni, hogy ne legyenek körkörös hivatkozások), akkor a Python* is megadja azt, amit a C++ (azaz: automatikusan, determinisztikus sorrendben meghívott destruktorok).

A különbség ott vagy, hogy ha nem végzed el ezt a munkát, akkor C++-ban memory leaket csinálnál egyik destruktor sem fog soha lefutni, Python pedig így is fel tudja takarítani a memóriát, és még a destruktorokat is meghívja valamilyen sorrendben.

Szóval azt mondod, hogy jobb a memory leak és a soha le nem futó destruktor, mint a nem-determinisztikus futási sorrend?

------

* Mindez a CPythonra vonatkozik. A nyelv specifikációja** nem írja elő ezt a determinisztikus viselkedést, viszont a referencia-implementáció úgy van megírva, hogy annál ez adott.
** Nincs is specifikáció.

Tekintve, hogy Pythonban akkor is fizetsz a körkörös referencia keresgélésért amikor úgy írtad meg a programodat, hogy ilyen ne fordulhasson elő: igen a c++ megoldás ebben az esetben jobb.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

"Egy atomi integer inkrementálás illetve dekrementálás, utóbbi esetben 0-val ellenőrzés a költség."
Na de hányszor?

Józsi bemegy a benzinkútra. Megkérdi:
- Mennyibe kerül egy csöpp benzin?
- Á, semmibe.
- Csepegtesse már tele a tankot, kérem!

"Vesd össze mindenféle bonyolult reference counting algoritmusokkal."
He?

Hm, hát meglepő amit mondasz, főleg ha hozzáveszünk még pár dolgot, ami a gc folyománya. Pl (elvileg, aztán persze ezen még lehet optimalizálni, de úgyis elég gyakran) minden egyes accessnél ellenőrizni kell (a színfalak mögött) null pointerre, hogy dobódjon-e nullpointerexception (szemben a cpp undefined behaviourjával, javaban dobódnia _kell_ nullpointerexceptionnak, aminek van költsége). Aztán ott van még hogy a cpp -ben sok objektumot egyáltalán nem kell gc -zni, a stacken élnek (tudom gc esetén is van ennek megfelelője, külön algoritmus felel a rövid életű objektumokért, nade...). Aztán reference countingot a bottleneckek esetén teljesen mellőzni lehet cpp -ben (de hackelés nélkül, objektumorientált személet megtartásával!), javaban ilyesmire nem nagyon van mód.

Bár nem elképzelhetetlen.
Forrás?

Itt azért felmerül az a kérdés, hogy van-e lényegi teljesítménykülönbség a két rendszer esetében... simán lehet, hogy amíg neked a felszabadítás állandó fix költségedbe kerül, addig a vm csak akkor töröl, amikor ő úgy gondolja, hogy törölni kell, és mondjuk sok objektum esetén ez komoly előny lehet a VM javára, cserébe ott van az a történet, hogy nem determinisztikus, mikor történik a takarítás.

Kevesen tudják, hogy java-ban bizony lehetőség van arra, hogy hanyagoljuk a GC-t, és egy memóriatartományt saját magunk kezeljünk. Erről, illetve ennek a teljesítményéről itt:

http://mentablog.soliveirajr.com/2012/11/which-one-is-faster-java-heap-…

http://www.javacodegeeks.com/2013/08/which-memory-is-faster-heap-or-byt…

Még esetleg ez is érdekes lehet, hogy a java8-ban szépen átdolgozzák a permgen-t, bár a témához csak érintőlegesen kapcsolódik...

http://java.dzone.com/articles/java-8-permgen-metaspace

>Kevesen tudják, hogy java-ban bizony lehetőség van arra, hogy hanyagoljuk a GC-t, és egy memóriatartományt saját magunk kezeljünk.

Erre próbáltam utalni, hogy az objektumorientált szemlélet itt sérül, ugyanis az így foglalt memórián (FIXME) nem "élnek" objektumok, csak adatot lehet ide-oda mozgatni.

No igen, lehetett volna nyelvi elemként behozni, de gondolom úgy döntöttek, hogy inkább így valósítják meg, mintsem hogy egy olyan feature-t rakjanak a nyelvi elemek közé, amit az esetek elhanyagolható számában kell használni. Nekem alapvetően nagyon szimpatikus, ahogy a java nyelvet bővítik, nem szórják tele mindenféle nyelvidegen feature-rel, csak azért, mert a javaPistikéknek az tetszik...

Mondjuk úgy, a 10 éves java fejlesztői pályafutásom alatt még soha nem volt azzal gondunk, hogy a memóriafoglalás túl lassú lett volna, bottleneck mindenhol volt, csak itt nem. Ezeket profiling után algoritmus cserével, kód átszervezéssel, többszálúsítással, illetve cache beiktatásával tökéletesen tudtuk kezelni.

Olyan viszont volt, hogy a GC túl sokáig megakasztotta a program futását (még 1.5-ös java korában) ezt viszont GC tuninggal lehetett megoldani.

Igen, ahogy nézegettem, ott egy c struct szerű memóriatartományod van, azoknak az objektumoknak nincs klasszikus értelemben vett metódusa. Ez mondjuk erőteljesen egy elméleti kérdés, ha olyan nagy mennyiségben kell objektumot csinálni, akkor azok jó eséllyel csak tároló objektumok, lényegében rekordok, és nincs hozzájuk kapcsolt bonyolult üzleti logika. Tehát a rekordokon dolgozó osztályokat (általában típusonként 1-1-et) szépen a heap-en lehet tartani, míg a csilliárd rekord mehet a rendszermemóriába. Ennek a fajta szétválasztásnak (ilyen anti-oo jelleggel) van valami szép pattern neve is, de mindig elfelejtem...

Két dolgot összemosol: a garbage collection mint memory management, és hogy egy nyelv memory safe. Bár a zavar nem indokolatlan, mivel a legtöbb esetben a kettő együtt jár, sőt, a memory safety-nek szükséges feltétele a garbage collector, de a garbage collectornak nem feltétele a memory safety, sem pedig a null pointer hivatkozások ellenőrzése. GC-t C-vel meg C++-szal is lehet használni, de attól még ugyanúgy unsafe marad minden, és a null pointer hivatkozások sem lesznek ellenőrizve.

Egyébként pedig a null pointer ellenőrzésnek nincs többletköltsége, mivel a CPU hardveresen ellenőriz minden memóriahozzáférést. Annyi dolga van csak a JVM implementációnak, hogy ne mapoljon semmit a 0-s című page-re (ami nem nehéz, pl. Linux alatt ezt különben is csak a root teheti meg), valamint hogy regisztáljon egy handlert segmentation violation signalra. Költség csak akkor lép fel, amikor tényleg exceptiont kell dobni.

A stackkel viszont - végre - jó helyen tapogatózol, mert az tényleg gyors, és átlagosan azért nem lesz túl lassú a C++ memory managementje pl. Javához képest, mert sokmindent stackre lehet pakolni, meg reference count ugye nem kell, ha nincs osztott hozzáférés. Egyébként gondolj bele, ha annyira jó lenne az a reference counting, akkor pl. Javában, C#-ban stb.-ben is az lenne az elsődleges GC + egy tartalék a körök kezelésére. (Tudomásom szerint egyedül a Python csinálja így, aminek ugye nem tartozik a deklarált céljai közé a gyors futás.)

Egyébként a memory management sebessége valahogy így néz ki (a leggyorsabbtól kezdve):
1. stack
2. malloc/free (C++: new/delete); nem generational avagy egygenerációs GC
3. malloc/free + reference counting

Igen, sima GC sebessége átlagosan ugyanaz, mint a malloc/free teljesítménye, azon belül kisebb méretű objektumoknál gyorsabb a GC, nagyméretű objektumoknál pedig a malloc/free a gyorsabb. Érett, modern GC-s nyelvek (pl. Java, C#) viszont generational GC-t használnak, ami törekszik stackhez közeli teljesítményt elérni a legfrissebb és legrövidéletűbb generációra.

Ezen az oldalon számos jó anyagot lehet találni a GC-k működésének és teljesítményének tanulmányozásához. Itt pedig van egy kevésbé tudományos összehasonlítás, ami megmutatja, hogy a C++ shared_ptr milyen nevetségesen lassú más eljárásokhoz képest.

"azoknak a bonyolult GC algoritmusoknak sokkal ritkábban kell lefutniuk"

Azaz ha a gc nem fut le, és a memória nem szabadul fel, akkor az gyorsabb, mint a ref counting.
Ez alapvetően igaz, csak nem tudom mennyire erős érv. :)

Mindenesetre itt van egy érdekes összefüggés, miszerint ha sok szabad memóriád van (értsd több mint amennyi a programod futásához feltétlenül szükséges), akkor a gc ritkán futhat, így olcsó. Ha viszont a memória szűkös, akkor a gc gyakran kell fusson, ergo lassú.

Ez lehetne egy tervezési-nyelv választási szempont, a nehézség a dologban az, hogy ez attól is függ, hogy mégis mi mellett fog futni az adott program, ami nem feltétlenül tervezhető...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o

Eppen ezt a gondot latom utpkabel erveleseben, hogy rafokuszal valami apro feature-re, es az alapjan kijelenti, hogy a C++ szar vagy a Python szar (mert bizonyara a C++ tervezoi nagyon hulyek, bezzeg a Java tervezoi milyen okosak). Pedig itt trade-offokrol van szo.

- A Java tervezoi azt mondtak, hogy ne legyen leak, ne legyen undefined behaviour, legyen binarisan hordozhato, legyen az oroklodes egyszeres, egyszerubb generikus programozasi modellt, de cserebe a teljesitmeny lehet ramatyabb, mert azt ugymond hardverberuhazasbol kompenzalni lehet. Aki a Java teljesitmenyproblemait tagadja, az nezzen ra az Eclipse-re es a Tomcat-re. Ezzel nincs semmi baj es megtalalt egy eleg szeles reteget. Ott van a mobiltelefonoktol a nagy banki rendszereken mindenhol.

- A C++ tervezoi azt mondtak, hogy akarnak glueless c integraciot, determinisztikus es szigoru eroforrasmanagementet, tobbszoros orokolodest es fejlettebb template rendszert, de bevallaljak, hogy nincs automatikus GC, es lehetseges az undefined behaviour. Es a C++ szinten megtalalt egy szeles reteget, beagyazott eszkozoktol a szuperszamitogepekig mindenhol ott van.

Szoval csak azt nem ertem, hogy miert viccnyelv, mert olyan kornyezetben kell dolgozom, ahol a beagyazott klienseknek nincs annyi memoriaja, hogy egy JVM-et futtasson, a szervernek pedig 3 evig processz ujrainditas nelkul kell kiszolgalnia folyamatosan parszaz beagyazott klienst. Es a C++-al remekul mukodik a dolog, kepesek vagyunk ra, hogy segfaultok nelkul kitoljuk a fejleszteseket. Nem konnyu, de szerintem nagyon tanulsagos.

Ha általánosságban fogalmazok meg kritikát a C++-szal kapcsolatban, akkor a konkrétumok hiánya a baj, ha konkrétumot említek, azon elkezdünk vitatkozni, és akkor meg azt érzitek, hogy ráfókuszáltam egy apróságra.

Tisztázzunk pár dolgot:

1.
Hogy a C++ viccnyelv, azt nem én mondtam.

2.
Te viszont azt mondtad, hogy a C++ mennyire jól végiggondolt nyelv, amivel mélységesen nem értek egyet. Az egyes C++ feature-öket csak lokálisan gondolták át, abban a kontextusban, ahol először felmerültek. A nyelv globálisan viszont egy átgondolatlan katyvasz, 90%-os feature-ök sorozata, ahol az egyik 90%-os feature az előző 90%-os feature-ből fennmaradó 10%-ot igyekszik javítani.

Ezzel persze nem azt akartam mondani, hogy a Java tökéletes, annak a nyelvnek is megvannak a maga hülyeségei; talán nem annyi, mint a C++-nak. Példaként a C vagy a Go olyan nyelv szerintem, amiben a C++-nál sokkal kevesebb átgondolatlanság van.

3.
A tervezési trade-off-ok létét nem tagadom, mint ahogy azt sem, hogy létezhet olyan szűk alkalmazási területet, ahol a C++ a legjobb választás. Ami viszont roppant zavar, és ami elsődlegesen motivál ezen vitába való bekapcsolódásra, az az olyan üres, bullshit buzzwordök puffogtatása, mint a "determinisztikus erőforrás-kezelés". Feltételezem akik ezt így használják, azok azt akarják kifejezni, hogy milyen jó a C++, a többi nyelv meg milyen már. Ehelyett azt fejezik ki, hogy mennyire nem értik a C++-nál magasabb szintű programozási nyelveket (ez alatt azt értem, ami memory safe, azzal pedig együtt jár a GC is), sőt, félreértik, azaz azt hiszik, hogy értik, miközben egyáltalán nem.

Mert állandóan hangsúlyozni a determinisztikusságot csak akkor van értelme, hogy van olyan, hogy nem-determinisztikus, márpedig a GC-s nyelvekben alkalmazott try-finally vagy try-with-resources (C#: using, Python: with) teljesen determinisztikus. Ezekben a nyelvekben a memória nem tekinthető erőforrásnak, mivel a nyelv absztrakciós szintje magasabb, és a memória nem kezelhető közvetlenül, pontosan úgy, mint ahogyan C-ben el vannak rejtve a regiszterek. Pontosan ezért abszurd a gondolat, hogy program működését kössük a nyelv absztrakciós szintje alatti, run-time által végrehajtott eseményekhez (értsd: finalizerek használata takarításra). Így amikor valaki azt mondja, hogy milyen rossz destruktor a finalizer, mert a GC nem determinisztikus, akkor ebből nekem az jön le, hogy az imént taglaltakkal az illető egyáltalán nincs tisztában, ezért törekszem - kevés sikerrel - az ilyen embereket felvilágosítani a helyzetről.

Az elso kettovel nem vitatkozom (az 1.-ben igazad van, a 2. velemenyes, es tiszteletben tartom a te velemenyedet).

A determinisztikussag/nemdeterminisztikussag: ha en egy eroforrast reprezentalok egy osztallyal, akkor tudom *garantalni* azt, hogy felszabadul, amint az objektum elerhetetlenne valik?

1. Erzesem szerint c++-ban igen:

class Resource : public non_copyable {
public:
Resource() : some_fd(open(...)) {}
private:
int some_fd;
};

void foo() {
Resource r;

...
}

A C++ runtime garantalja, hogy az objektum destruktora meghivodik. Azaz akarmit csinalsz foo fuggveny implementalasakor az r fuggveny felszabadul.

2. A Java valami ilyesmi lehet:

void foo() {
try (Resource r = new Resource()) {
...
}
}

Ezt en nem nevezem automatikusnak es jol vegiggondoltnak. Mert mi van:
1. Ha a kedves user elfelejti, hogy ez egy Closeable objektum? Tehat nem teszi oda a try blokkot... Valamikor felszabadul az eroforras, de hogy mikor azt nem tudjuk. Es itt ne csak memoriat nezzunk sokkal veszelyesebb tud ez lenni lock-okkal. Lehet, hogy az osszes teszt soran nem lesz gond, a production rendszer meg alkalmankent deadlock-ol.
2. (Ez egy kevesbe elmeleti, de szerintem cikisebb problema): A Resource osztaly csak refactoring soran valt Closeable osztallya. Akkor vegig kell menni az osszes felhasznalason es manualisan kell try blokkokkal korbevenni.

Tehat ujrafogalmazom a dolgot: az eroforras felhasznalojanak figyelmessegen mulik, hogy az eroforras determinisztikusan (scope-ot elhagyva rogton) vagy nemdeterminisztikusan (gc altal valamikor kesobb) szabadul fel.

Az a gond, hogy nagyon corner esetről beszélünk. Nézzük meg, hogy milyen fő dolgok lehetnek, és ezeknek mi a következményük:

1, Socket connection: ha server socket-et csinálsz, és elfelejted lezárni. Vicces módon egyébként ha bekerül a GC hatáskörébe, akkor vagy le lesz zárva előbb vagy utóbb, vagy nem, és akkor látod a problémát, ha egy idő után nem tudsz klienssel csatlakozni. Mennyire veszélyes-általános a probléma? Az esetek legkisebb %-ban kezeljük saját kézzel a socket-eket, hanem valami framework-öt használunk. Ha mégis előjönne, akkor jó eséllyel lesz a logban egy exception, amiből aztán kapásból kiderül a probléma.

2, File socket: pontosan ugyanaz a helyzet, mint az első esetnél, valószínűleg kicsit előbb fog előjönni a probléma, ugyancsak nincs elég fileleíró szerű dolog lesz a logban, könnyen javítható.

3, Deadlock: deadlock akkor lesz, ha két külön szál próbál keresztbe foglalni erőforrást. Ha synchronized kulcsszót használunk, akkor a felszabadítás automatikusan megtörténik (persze deadlock-ot ettől még lehet csinálni), ellenkező esetben (kézzel kezelt lock és társai) valóban figyelni kell rá. De itt sokkal veszélyesebbnek érzem azt, hogy deadlockot csinál a kedves user.

Ez a három eset van, ami így eszembe jut, az első kettő szinte sosem fordul elő, a harmadiknál pedig ha synchronize-t használ, akkor sem lehet gond, egyedül ha kézzel használ lock-okat. Akkor meg sajnos oda kell figyelni. (talán a profiler egyébként mutatja a foglalt lockok számát, ha ez folyamatosan nő, akkor az jel lehet arra, hogy valahol bug vagyon...)

Cserébe a fejlesztés további részében nem kell arra figyelnem, hogy ki kit mikor szabadít fel, hogy stack-en vagy heap-en vannak-e a dolgaim, hogy referenciát vagy pointert adok át, hogy ezeket hogyan védem. Ezt a rengeteg energiát felhasználhatom arra, hogy abban a 10 osztályban, ahol a fentieket használom, helyesen kódoljak.

>Cserébe a fejlesztés további részében nem kell arra figyelnem, hogy ki kit mikor szabadít fel, hogy stack-en vagy heap-en vannak-e a dolgaim, hogy referenciát vagy pointert adok át, hogy ezeket hogyan védem. Ezt a rengeteg energiát felhasználhatom arra, hogy abban a 10 osztályban, ahol a fentieket használom, helyesen kódoljak.

Érdekes, én pont azt érzem, hogy ezekre nem kell c++-ban különösen odafigyelnem, szinte magától íródik a program, sokkal nagyobb a biztonságérzet mint cpp -ben. A hátránya persze ennek, hogy sokat kell gépelni, lassítja a fejlesztést.
A másik irány az a magasabb szintű nyelvek, js, ruby, ott kevesebbet kell gépelni, de csökkent a biztonságérzet, oda kell figyelni. Úgy is jó.
Java/c# -al kapcsolatban ilyen worst of both worlds érzésem van: Sok gépelés, csökkent biztonságérzet.

"Valamikor felszabadul az eroforras, de hogy mikor azt nem tudjuk."

Nem tudom ki írta a Resource osztályt, de ha én csináltam volna, én biztos nem rakok resource elengedést a finalizerbe amolyan back-up megoldásként, ha esetleg a user elfelejtené. Csak fölöslegesen szopatnám a tesztelőket az így becserkészett nem-determinisztikussággal.

A helyes működés az, hogy ha a user nem szabadítja fel az erőforrást explicit (vagy try-with-resources blokk által), akkor az erőforrás soha nem szabadul fel. Konzisztensen, tesztelhető módon, és függetlenül attól, hogy az erőforrást reprezentáló objektum elérhető-e még.

"ha en egy eroforrast reprezentalok egy osztallyal, akkor tudom *garantalni* azt, hogy felszabadul, amint az objektum elerhetetlenne valik?"

Nem, de ettől még determinisztikus, hiszen a close() determinisztikusan hívódik meg (explicit, finally-blokkban, try-with-resources által), vagy determinisztikusan nem hívódik meg (programozó "elfelejtette").

Nincs olyan, hogy normal kodbazis. Illetve mindenkinek mas a normal kodbazis. Eppen ezert nem ertem, hogy miert szamitok en kinevetni valonak mert azt mondtam, hogy a nekem "normal kodbazisnak" szamito problemakra a C++ egy eleg adekvat valasz a Java-val szemben...

Timerek: http://man7.org/linux/man-pages/man2/timerfd_create.2.html (gondolom javaban is vannak timerek: http://docs.oracle.com/javase/7/docs/api/java/util/Timer.html, ez pl. JVM szalat is foglal maganak, meg valami globalis binary heapen tarolodnak, szoval gondolom tekinthetjuk eroforrasnak, amit nem art takarekosan kezelni :) ).
Bufferek: hat *neha* (mondjuk masodpercenkent nehany tizszer-szazszor-ezerszer-...) kell memoria a kimeno/bejovo adatoknak, azt meg tobbnyire csak az oprendszer ad ....

A fenti értelembe véve nem, hiszen nem kell kezelni:

Timer:

"After the last live reference to a Timer object goes away and all outstanding tasks have completed execution, the timer's task execution thread terminates gracefully"

Thread:

Ha a szál run metódusa lefut, akkor meg is szűnik, nem kell kívülről kezelgetni...

Buffer:

ha nincs mögötte operációs rendszer erőforrás (pl. bytebuffer) akkor megint csak nem kell lezárni.

Tehát miért is de?

Attól még hogy adott esetben impliciten kezelődik, attól még erőforrás, valamit csinálni kell vele, ha mást nem, tudni azt, hogy mi történik a háttérben.
Mondjuk az elég nagy baj ha folyton ha szálak indulnak és szűnnek meg, ezt célszerű valami queueval elsimítani. Az is erőforrás, amit nem az os ad közvetlen.
És mi van ha van ha van a bytebuffer mögött egy natív buffer? Akkor mégis meg kell szabadulni tőle.
Rengeteg eset előfordulhat, ezeket cpp -ben lehet egységesen kezelni, javaban meg külön-külön kell, persze nem megoldhatatlan problémák ezek. Amit én mondok, hogy ez nekem egyszerűbb, biztonságosabb érzés. Ha neked nem az, akkor neked nem az. De olyat ne mondjunk már hogy a cpp hű de bonyolult hogy mindent kézzel kell csinálni, mert nagyon távol áll az igazságtól.

"valamit csinálni kell vele, ha mást nem, tudni azt, hogy mi történik a háttérben."

Na persze. Ez a fránya C++ összezavarja a fejeket.

A thread nem "erőforrás". Csodálkoztam is, amikor először megláttam, hogy C++11-ben akként kezelik. Hiszen egy thread esetén nincs olyan, hogy "felszabadítás". Ha véget ér a thread futása, akkor automatikusan felszabadul, nincs mit csinálni vele. Le lehet persze ölni egy threadet, de jellemzően olyat soha nem csinál az ember.

Aztán rájöttem, hogy a std::thread destruktora joinolja a threadet (blokkolja a futó szálat amíg másik szál véget nem ér). WTF is wrong with these guys...

De aztán rájöttem, hogyan zavarodtak így össze a C++-osok. Itt van ez a destruktor, ami alapvetően egy olyan control flow feature, ami igen jó takarításra meg erőforrás-felszabadításra. Aztán találtak egy use case-t, ahogyan igen hasznosan fel lehet használni a destruktort mint control flow feature-t threadekhez. Mivel a C++ fejekben - tévesen - az van, hogy a destruktor erőforrás-felszabadításra van, a reverse logika alapján kiderült, hogy a thread egy erőforrás.

"A thread erőforrás." - ez is egy olyan igazság, ami csak a C++ univerzumban létezik, ahol minden fogalom kicsit (nagyon?) mást jelent, mint pl. a resource vagy a safety.

Wikipedia szerint:
A resource, or system resource, is any physical or virtual component of limited availability within a computer system.

Threadből véges áll rendelkezésre? Igen, nagyon is. Resource, oda kell rá figyelni.
Ha nem akarod hogy a thread destruktora joinoljon, akkor detacholod.

"a nehézség a dologban az, hogy ez attól is függ, hogy mégis mi mellett fog futni az adott program, ami nem feltétlenül tervezhető..."

Meg hogy kinek. Mert ha az effektív futási idő egy álom, de a GC olykor másodpercekre megállítja a showt, valószínűtlen, hogy a szép futásidőkről beszéljen az ezerfejű, és ha az ezerfejű megtalálja azt a nagyfejűt, aki a specifikáció időlimitjeit nem a mi kedvünkre értelmezi, lehet javítani azt, ami egyébként jó.

>Viszont jo c++ kodot irni sok esetben nehez kivetelek nelkul (klasszikus pelda ugye a hibazo konstruktorok esete, amit kivetelek nelkul jol es elegansan megcsinalni joforman lehetetlen).

Biztos ez?
Én is kivétel-ellenes vagyok amúgy. Vagyis csak akkor használok kivételt, amikor már minden úgyis minden rossz, és meg se próbálom elkapni őket, amolyan fatal error hogy mégiscsak legyen egy kis információ mi történt.
És hogy miért? Olyan rejtett utakat behoz, amin egyszerűen túl sokat kellene gondolkodni, teszteléskor is nehezen jönnek ki, egyszerűen nem éri meg.
Hibázó konstruktorok: Kétfázisú construction? Maga a konstruktor private, egy static factory method meg visszaadhat valamit ami egyértelműen jelzi a hibát (pl. egy üres shared_ptr -t). Tudom, ebbe is bele lehet kötni (mert manuálisan kell ellenőrizni hogy nullptr -e), de én ezzel együtt tudok élni.

Csak hogy a legnyilvanvalobbat emlitsem a problemak kozul:

- nem feltetlenul rossz, ha egy osztaly default constructible, ezt igy alapbol bukod
- vannak olyan konstruktorok (illetve tagabb ertelemben muveletek), amiknek nem fogsz tudni hibakodot atadni, a teljesseg igenye nelkul: copy constructor, move constructor, assignment operator, operatorok. Letilthatod a masolast es a move-olast, de ezzel kapasbol az osztalyod hasznalhatosagat korlatozod igen durvan. Pedig egy copy construktor is dobhat. Es igen tudni kell azt is kezelni. Attol meg hogy nem birsz atmasolni egy szazmegas buffer-t (bar ez nagyon hulye pelda).
- mivel privat a destruktorod, ezert a make_shared<> szoba sem johet az objektumra mutato shared_ptr letrehozasara. Ez rogton azt jelenti, hogy ketszer kell memoriat foglalni az objektumodhoz. Holott, ha engeded, hogy legyen egy kivetel dobasra kepes publikus konstruktorod, akkor meg akar stack-en is lakhatna, joforman zero overhead-del. Bar itt meg probalkozhatsz az objektumot szarmaztatni az std::enable_shared_from_this osztalybol, az egyik dinamikus memoriafoglalas megmarad es az nem tul olcso. Tovabba shared_ptr referencia szamlalasa szalbiztos, szoval a lock-olas vagy atomi muvelet koltsege is ott van.
- Megis melyik univerzumban szamit nullptr visszaadasa "egyertelmu hibajelzesnek"?
- Tegyuk fel, hogy van 10 overload-od a konstruktorra (lasd pl. std::vector<>) azert eleg meredek lenne 10 factory method-ot is csinalni hozzajuk. A template konstruktorok is adnanak okot nemi fejvakarasra. Es ha azt mondod, hogy probalsz ultra-okos lenni, akkor csinalsz egy variadic template factory method-ot, ami lefedi az osszes konstruktort, akkor is felulhetsz a szoporollerre, mert ez azokat a konstruktorokat is publikussa teszi, amiket egyen okokbol nem akartal publikussa tenni.
- Es osszessegeben megiscsak ugyanakkora mennyisegu munkarol beszelunk. A hibakezelest rohadt nehez jol csinalni, ezen nem a sufnimegoldasok fognak atlenditeni. Le kell ulni, meg kell csinalni a hazit.
- Tovabba a +1-es implementacios problema: ha az altalad javasolt modon jarunk el, akkor van az objektumodnak egy olyan allapota amikor a konstruktor mar bekrepalt, de az objektum a memoriaban van. Tehat potencialisan hasznalhatja valaki. Egy felkesz objektumot. Ebbol azert lehet baj, bar ha kovetkezetes vagy a shared_ptr-el, akkor ez feltehetoen nem issue.
- Es +2: Ha az osztalyod ososztalya vagy valamelyik adattag inicializaloja dob, akkor *nincs* ra mod, hogy megakadalyozd a kivetel tovabbadasat felfele. Egy function try-catch-el elkaphatod, de automatikusan ujradobodik a catch blokk vegen (ezt irja elo a szabvany es jo okkal!!!). Tehat a hivo scope vegehez fogunk erni rogton, az adott objektumot fel sem kell szabaditani, mivel "sohasem jott letre", destruktor sem hivodik meg, a nagytakaritast a function catch-ben kell elvegezni.

A kulcskulonbseg annyi, hogy a kivetelek lehetove teszik hogy a hiba keletkezese es a hiba kezelese kicsit tavolabb legyen es hogy kozben az eroforrasok ne vesszenek el. Es ez jo. Nem kell mindig hasznalni, de szerintem van sok eset, foleg ha library-t irsz, amikor a kivetelek a jo megoldasik a hibak jelzesere.

Alapvetően ebben az exceptionös kérdésben nem értünk egyet, szerintem nem is fogunk, sebaj :)

>Tovabba a +1-es implementacios problema: ha az altalad javasolt modon jarunk el, akkor van az objektumodnak egy olyan allapota amikor a konstruktor mar bekrepalt, de az objektum a memoriaban van. Tehat potencialisan hasznalhatja valaki.

Nem, nincs, csak a statikus factory method láthatja ezt, de az az osztályhoz tartozik, nem baj.

>Megis melyik univerzumban szamit nullptr visszaadasa "egyertelmu hibajelzesnek"?

Bármelyikben, ha így van specifikálva az interface.

>mivel privat a destruktorod, ezert a make_shared<> szoba sem johet az objektumra mutato shared_ptr letrehozasara. Ez rogton azt jelenti, hogy ketszer kell memoriat foglalni az objektumodhoz.

Konstruktorra gondoltál, de miért ne lehetne? Ha a factory method shared_ptr (vagy unique-ptr) -t ad vissza, az meghívhatja a make_shared -et (make_unique) -ot.

>vannak olyan konstruktorok (illetve tagabb ertelemben muveletek), amiknek nem fogsz tudni hibakodot atadni, a teljesseg igenye nelkul: copy constructor, move constructor, assignment operator, operatorok. Letilthatod a masolast es a move-olast, de ezzel kapasbol az osztalyod hasznalhatosagat korlatozod igen durvan.

Nem tipikus, hogy olyan osztályok, amiknél a copy/move -nak van értelme, hibáthatnak constructornál, persze előfordulhat.

>Tegyuk fel, hogy van 10 overload-od a konstruktorra (lasd pl. std::vector<>) azert eleg meredek lenne 10 factory method-ot is csinalni hozzajuk

Szintén nem tipikus, hogy az ilyen utility jellegű osztályok hibázzanak. bad_alloc -ra gondolhatsz, de az a kategória, amit említettem, hogy akkor már hagyjuk is, inkább szálljon el a program. (Persze nyilván van olyan eset amikor ez nem igaz, általában beszélek)

> Ha az osztalyod ososztalya vagy valamelyik adattag inicializaloja dob, akkor *nincs* ra mod, hogy megakadalyozd a kivetel tovabbadasat felfele.

Hát nyilván, ha az ősosztály olyan, hogy kivételt dob, akkor azt kezelni kell, bár ezt is be lehet csomagolni egy factory methodba... :)

> Nem, nincs, csak a statikus factory method láthatja ezt, de az az osztályhoz tartozik, nem baj.

Ez csak akkor lenne 100%-ig igaz, ha az objektum vakumban letezik. Mivel azonban ez nem igaz, igy eleg valtozatos interakciok elkepzelheto a "megkonstrualt, de nem valid" objektum es egyeb programreszek kozott. Ha pedig tobbszalu programrol beszelunk, akkor a lehetosegek tarhaza vegtelen.

> Bármelyikben, ha így van specifikálva az interface.

Jogosnak latszhat az erv, de ez a design hamarabb bizonyul rossznak, minthogy az elso demo elkeszulne. A nyelvet keszitoknek meg a valos vilag igen valtozatos kihivasainak kell megfelelni. Es a gyakorlatban a hibahoz hozzatartozik a hibakod, valami szoveg, neha meg szamos mas info is.

> Konstruktorra gondoltál, de miért ne lehetne? Ha a factory method shared_ptr (vagy unique-ptr) -t ad vissza, az meghívhatja a make_shared -et (make_unique) -ot.

Igen, konstruktorra gondoltam, bocsanat. A problema az, hogy a factory method meghivhatna a privat konstruktort, de a make_shared nem (hiszen privat). Illetve hat kacifantos friend deklaraciok utan talan, de a gyakorlatban nem. Ugyanis nem fogod tudni, hogy melyik fuggveny lesz, ami konkretan meghivja a konstruktort :). Az interfesz meg van adva a szabvanyban, de a megvalositas mindig mas nevu fuggvenyt hiv meg, ami elvegzi az allokaciot. Szoval a make_shared friend-e tetele egy szinten eleg bena megoldas (ami valoszinuleg sosem fog jol mukodni). Marad a ket memoriafoglalas koltsege.

> Nem tipikus, hogy olyan osztályok, amiknél a copy/move -nak van értelme, hibáthatnak constructornál, persze előfordulhat.

Ez rossz spekulacio szerintem. Elofordul es meg csak nem is hollo. Nyilvan nem moricka programok esetet kell extrapolalni. Epp az a lenyeg, hogy problemak szeles koret megnyugtatoan, sot minel biztosabban tudjuk kezelni, ha ugy hozza a szukseg. Nem veletlenul szerepelnek a szabvany konyvtarban az is_nothrow_default_constructible<>(), is_nothrow_copy_constructible<>(), is_nothrow_assignable<>() fuggvenyek.

Nezd nyilvan nem az lenyeg, hogy meggyozzelek teljesen az igazamrol (nyilvan eltero tapasztalatok eltero szokasokat szulnek). Azt azert szigoruan fenntartom, hogy kategorikusan elutasitani a kiveteleket nagy butasag. Nyilvan esetrol-esetre ki kell talalni, hogy milyen modon jelzi es kezeli a rendszer a hibakat. Ha nekem kellene fejlesztesi guideline-t adni, en azt mondanam, hogy alapbol kivetelek es ha vannak ertelmes ervek arra, hogy egy adott eset miert nem jo kivetelekkel, akkor keresni valami mast.

Nem elutasítom a kivételeket, hanem kerülöm, azaz csak _kivételes_ esetben használom.
Nekem bevált ez a hozzáállás, és nem bizonyult rossznak, egyáltalán nem. Az általad megfogalmazott problémák jogosak, foglalkozni kell velük, de összességében jobban működik _nekem_, mint az exceptionös hibakezelés (amivel szintén kell foglalkozni, ebben nincs különbség). Nyilván stílus és ember kérdése is.

"klasszikus pelda ugye a hibazo konstruktorok esete, amit kivetelek nelkul jol es elegansan megcsinalni joforman lehetetlen"

Klasszikus példa arra, hogy egy rosszul megtervezett elem hogyan húz maga után újabb feature-öket.

A konstruktor helyett nyugodtan lehetne használni factory függvényt, és akkor nem muszáj kivételezni. Most erre azt mondod, hogy de a konstruktor az garantálja, hogy az inicializáció megtörténik a használat előtt, míg egyéb módon ezt el lehetne felejteni? Hát dehogy garantálja! Egyszerűbb esetekben igen, de kapásból tudok két olyan példát mondani, amikor a konstrukor nem végzi el a dolgát a megfelelő időben.
Igen, ilyen az a nyelv, amit "alaposan végiggondoltnak" nevezel. 90%-os megoldások végtelen sorozata.

1. Ez elég nyakatekert, nem reális példa, ilyet kezdő csinál, de aki tisztában van a nyelv működésével, az aligha.
Az tény, hogy erről compiler nem ártana ha warningot adna, de attól még elég edge case.

2. Hát kerüld a globális változókat, és a singletonok halmozását, ennyi. C++al az a helyzet, hogy veszélyes használni, ha az ember nincs képben.

1) Nevetseges, hogy ezt cibalod ide. Egyfelol 10 eves a cikk, ma mar boven az osszes fordito figyelmeztet erre. Masreszt minden kezdo konyvben tisztazasra kerul, hogy mi a jo sorrend (segitek: Hatekony C++ 13. szakasz). Nem veletlenul adtak a GoTW cikkben 2/10-es difficulty-t a cikknek. Az ott szereplo pelda a C++ szabvany szerint undefined behaviour (mar akkor is az volt!!!). Vagy most akkor mit is kerunk szamon?
2) Ennek amugy mi koze is van a konstruktorban dobott kivetelekhez? Ja semmi.

Es egyebkent minden nyelv amelyik tamogatja a statikus adatok letrehozasat meg kell kuzdenie a statikus inicializacio sorrendjenek gondjaval. Konkretan legjobb tudomasom szerint a nyelvek nem csinalnak forditasi idoben analizist a jo inicializacio sorrendjerol. Alexandrescu (Modern C++ Design) 2001 kornyeken mar a velejeig kitrancsirozta ezt a kerdest, es o is csak hivatkozik egy meg korabbi cikkre ahol Scott Meyers adott olyan pofonegyszeru megoldast (Meyers-singleton, 1996), ami megtalalja a korrekt inicializacios sorrendet, *ha letezik olyan*. Ha pedig nem letezik olyan, akkor mit is kellene tenni (a c++ szabvany ezt megintcsak undefined behaviour-kent tartja szamon)?

Just for the log:

some_type &give_me_the_instance() {
static some_type the_instance = ....;
return the_instance;
}

Ezzel a konstrukcioval a statikusok inicializalasara automatikusan jo sorrend generalodik (ismetlem: ha van ilyen sorrend, mert nem mindig van).

Szoval eddig elohozakodtal egy 10 eves cikkel, ami mar igazabol akkor sem volt problema (a jogos kerdes a gotw cikkben az, hogy miert engedte at az egyik fordito a problemas kodot warning nelkul), ma meg plane nem az. Tovabba egy problemaval, amire eleg korrekt es jol mukodo megoldas van 18 eve...

Ne haragudj, nem a c++ a viccnyelv, hanem a te tudasod felszines.

Úgy csinálsz, mintha a workaround léte megszüntetné a probléma létezését. Pedig nem. Az, hogy léteznek olyan praktikák, amik megvédenek a nyelv egyes csapdáitól, az nem jelenti azt, hogy nem hemzseg a nyelv csapdáktól.

Csinálj nekem Javában (tiszta Java, JNI nem játszik) segfaultot, és majd én is adok neked tanácsot, hogy hogyan kerüld el, meg hogy csak hozzá nem értők írnak olyan kódot.

( uid_7086 | 2014. 07. 16., sze – 18:54 )

Jól látom, hogy ha valaki a C szintaxisát ismeri és valamelyest képben van az OOP alapjai terén is, akkor elég hamar bele tud tanulni a C++ használatába és ettől kezdve leginkább a különböző library-ket, keretrendszereket kell "csak" megismernie?

Szerintem nem. A c++ -ra jobb úgy tekinteni szerintem, mint egy a c-hez képest teljesen más nyelvre, amiből történetesen meg lehet hívni c kódot is, persze ez a hasonlat is sántít, de amire gondolok, hogy c++ tanulása közben sok dolgot kell úgymond "unlearn"-ölni, szokásokat amik c -ben hasznosak de c++ -ben inkább hátráltatnak.

Persze ha azt kérdezed, aki már programozott valaha 1 programozási nyelven, az könnyebben megtanul bármi mást, mint aki még egyen sem, ez kétségtelen... :)

Ez a kérdésem egyébként onnan ered, hogy a tutorialspoint-ról letöltöttem a C++ tutorialt és a kb. 250 oldalas anyagból az első 100 a usingnamespace-t és a cout-t leszámítva nem nagyon találtam újdonságot, pedig C++-t életemben nem láttam. :)
Változó típusok többsége, alapműveletek, pointerek... szóval rengeteg olyan dolog, ami számomra nem volt újdonság.
(jó, egy kétszáz oldalas tutorial ahhoz képest, hogy egy komolyabb C++ könyv ezer oldal... :) )

A C++ tervezesenel szempont volt, hogy a C programozasban szerzett tapasztalatbol minel tobb hasznosithato legyen. Sot tovabb menve: maga a c-ben megirt kod is *majdnem* teljesen hasznalhato. nyilvan gond van, ha olyan valtozonevet hasznalsz, ami c++-ban nem megengedett pl. int throw = 5; esetben pampog a c++ fordito. Van meg par aprosag, de en azt mondom, hogy a jol megirt c kod c++ kornyezetben valo felhasznalasa nem kulonosebben nehez (ez szerintem pokolian nagy elony, egy csomo jo c-s library-t lehet integralni a c++-kodhoz mindenfele kiterjesztesek irasa nelkul).

A jelentos elteres ott adodik majd, hogy a C-ben megszokott idiomak/best practice-ek esetleg elavultnak szamitanak c++-ban, vagy vannak egyeb lehetosegek is. Nyilvan meg kell oket ismerni es el kell tudni donteni, hogy az adott helyzetben erdemes-e oket hasznalni.

Pl.:

- hibakezeles: a hibakodon felul (c-ben nagyjabol ez az egyetlen lehetoseg) lehetoseged van kivetelek dobasara
- generikus kod: c-ben ezt altalaban a legnagyobb kozos oszto (azaz legyen minden void *) esetleg makrok segitsegevel lehetett megtrukkozni, C++-ban template-ek is vannak
- eroforras-kezeles: c-ben ez expliciten ment minden esetben, c++-ban ugye letezik a destruktor, ami sok esetben sok boilerplate kodtol kimel meg, illetve konnyebbe teheti a hibak kezeleset.
- funktorok: c-ben a fuggvenypointerek vannak erre a celra, c++-ban a fuggvenyobjektumok, amik eleg sok hasznos extraval birnak.

Szoval nem veletlen, ha jo c tudassal ismeros terepen erzed magad a c++-ban is, ugyanis ez tervezesi szempont (es a sikeresseg egyik oka) volt. Azonban a felszini hasonlosagok ellenere rengeteg technika van, ami pluszkent jelenik meg.

A tutorialok helyett/mellett ajanlom Scott Meyers: Effective C++ konyvenek elso fejezetet is (magyarul is megjelent!). Jol ir ezekrol a dolgokrol.

Köszi szépen, bár én nem akarom megtanulni, csak mint érdekességet néztem meg azt a tutorialt (tutorialspoint.com)

upd: azért ha valaha a kis logboncoló python programocskámat sikerült működőképessé tenni, a hecc kedvéért lehet, hogy valami tutorial használatával átírom C++-ra is :)

( sz332 v | 2014. 07. 16., sze – 22:34 )

Akármelyik nyelvet lehet és érdemes is hobbiból tanulni, ahogy most írták. Ha már java, akkor érdemes valami keretrendszert tanulni, mert standard java viszonylag kevés helyen van. Vagy, ahogy többen mondták, érdemes lehet a javascript-re ráfeküdni, most az a menő. De itt is keretrendszerek vannak. Vagy a kettőt kombinálni, és GWT-zni, ott java-ban programozol, de javascript kódot fordít.

A funkcionális programozási nyelvek mind érdekesség jópofák, nem igazán láttam sehol őket önmagukban használni, viszont ad egyfajta gondolkodási sémát, ami érdekes lehet.

C++-t nem igazán ajánlom, ha csak nem akarsz embedded világban dolgozni. PHP az ilyen igásló, nem egy jó nyelv, viszont van benne minden. Esetleg még html5+css-be érdemes lenne egy kicsit beleásni..

( kleinie | 2014. 07. 17., cs – 09:29 )

Binary
Which programming language are you?
01101100 11001100 11110000 10001000 11100000 10010010 10111011 01110111 11101110 11101111 11100000 11110000
YOU ARE BINARY.
YOU ARE NOT HUMAN AND GO TO GREAT LENGTHS TO PROVE IT. YOU ALWAYS KNOW WHERE YOU ARE AND HOW YOU GOT THERE, BUT NO ONE ELSE DOES EVER.

*szerk: nem ide akartam... hanem válaszként ide.

( winben | 2014. 07. 17., cs – 12:14 )

Szép kis flame lesz ebből a témából...
Nincs jobb vagy rosszabb nyelv, vagy hasznos, kevésbé hasznos a fejlesztők részéről. Mindenki a maga véleményét fogja mondani, ami nem feltétlenül egyezik meg a valósággal.

A C alapú nyelvek divatosak a c++ és java linux miatt, c# windows miatt. A php-t szidni egyszerűen csak divat.

Tehát szerintem ne vagy kapcsolat legyen a nyelvek között, hanem és. Egymás után/mellett tanuld mindet.

Én webes vagyok, de folyamatosan érdeklődök más nyelvek után. Tehát sok évi php/js mellett ott van java, c, c# is és tervben van éppen c++.

Személy szerint nekem az összes között a java volt eddig messze a legunszimpatikusabb és c# .net alapokon a legtetszetősebb.

Találd ki mit szeretnél csinálni és ahhoz válassz megfelelő nyelvet. Egyre inkább a webé a jövő, így én a js(jquery)+php-t ajánlom első körben. (lehet azt jól is csinálni)

-------------
Command line Russian roulette:
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*

Winben blogja

Reklámmentes képfelt

Amíg jsr meg pep van, vagy több évet csúszik a specifikációs folyamat miatt egy C++0x, addig igen, azt mondom, hogy átgondoltak az alapok. Nem azt, hogy minden húzás tökéletes, hanem azt, hogy rengeteg időt és kutatást ölnek abba, hogy az aktuális tudás szerinti legjobbat próbálják kihozni.

haystack-needle sorrendcserélgetést meg csinálják a pistikék.

ez is egy olyan probléma, amit kb. minden php framework kezel, de ettől függetlenül tényleg árulkodik arról, hogy anno nem annyira lett figyelve a részletekre. mondom úgy, hogy php-vel dolgozom, de keresgélek, mert belefutottam már (szerintem) nem jó megoldásokba

Hát ha keresgélsz, szerintem az iparban nem sok választásod van így script nyelvről script irányba: Python vagy Ruby. Előbbire jobban ráfeküdt az ipar, utóbbi meg kényelmesebb. Iletve Ruby-nál ne felejtsük el, hogy JRuby-val megkapod a Java ökoszisztémát, IronRuby-val a .Net-et, és a többi. Python-nál is lehet, azt nem tudom.

"Személy szerint nekem az összes között a java volt eddig messze a legunszimpatikusabb és c# .net alapokon a legtetszetősebb."

Erre reflektálnék egy picit. A javat mint nyelvet és mint standard libraryt egyaránt addig nem szerettem, amíg meg nem értettem mögötte a jvm működését és az egész történelmét. A nyelv nagyon keveset változott az évek során, verziónként olyan 1-1 nagyobb újdonságot hozott, a többi csak syntax sugar. A jvm alapvetően ma is ugyanúgy futtatja a kódot, ahogy az 1.0 idején, a jelentősebb változások a gc, a jit és más, a java nyelvhez nem kapcsolódó dolgokban merülnek ki. Ami sokat változott, az a library. Ezzel az a gond, hogy van egy nagy rakás api, ami úgy maradt meg, hogy még csak nem is deprecated, de normális esetben eszedbe nem jut használni. Pl. már van 3 beépített dátum api, abból a Date lett nagyrészt deprecated, de maga az osztály megmaradt dto-nak. A .net világban meg merik azt tenni, hogy a deprecated dolgokat a későbbi verziókból egyszerűen kidobják, de teljesen szokványos, hogy több verzió legyen egyszerre a gépeden.

"A php-t szidni egyszerűen csak divat."

Hülyeség, a php egy rossz nyelv. Ezt mindenki látja, akinek nem a php volt az első nyelve, vagy megtanult még egy nyelvet azon a szinten amin a php-t ismeri. Az ehhez kapcsolódó kötelező olvasmányok: http://www.phpwtf.org/ és http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

( Soultrane | 2014. 07. 17., cs – 21:59 )

Ha pénzt akarsz keresni programozással, nézz szét milyen terület érdekel és ahhoz milyen tudást kérnek. Ha csak hobbi akkor teljesen mindegy, csináld amihez épp kedved van.

( Morin | 2014. 07. 17., cs – 22:56 )

Kicsit mas megkozelitesbol szolnek hozza a temahoz. Nem vagyok programozo, epp csak annyira, hogy tetszoleges nyelven lekodoljam, amire szuksegem van a munkamhoz.
Szerintem majdhogynem tok mindegy, hogy melyik manapsag trendi, vagy epp kevesbe trendi nyelvet tanulod (egyebkent tenyleg erdemes tobbet ismerni), csak a lenyeg, hogy olyan kodot irj, ami hasznalhato es mukodik.

Az, hogy melyik nyelv mire jo inkabb azt a (HUPos) programozok biztosan jobban tudjak. En csak azt latom, hogy C es C++ -ra is van boven igeny. Ahol manapsag latom ezeket a nyelveket, azok mind nagyon erdekes es izgalmas teruletek, tele kihivassal es jo fizetessel. (Ertsd meg, lehet C-vel, C++ -al es pl. Assembly-vel dolgozni ugy is, hogy nem feltetlenul szoftvert fejlesztesz a klasszikus ertelemben)

A helyi trollok pedig tevednek a PHP-val kapcsolatban. Lehet, hogy a Pistikek PHP-t kodolnak, mert konnyu es 20K-ert lekodolnak barmit es ezert tenyleg nem nagyon lehet veluk konkuralni, de azt is latni kell, hogy ezek a Pistikek valoszinuleg rajottek arra, hogy a PHP-t mar nem fizetik olyan jol es egy ideje atvandoroltak Java programozonak. :P

Morin
OSCE / CEH / ECSA / ABC / NBC / FBI / KGB / NSA / STB

( uid_720 | 2014. 07. 17., cs – 23:20 )

Szerintem tanulj SQL-t. Az adatok helye az adatbázisban van, adatokat feldolgozni mindig kell.

Fuszenecker_Róbert

+1

tipikusan az a terület, amihez sokan nem értenek (én is csak kevésbé mint kéne), és sokat lehet vele fejlődni (mert megintcsak más mint egy programozási nyelv, márcsak azért is mert nem az :) )

viszont most belefutottam egy olyan programba, ahol konkrétan az a felépítésbeli hiba, hogy mindent mysql tárolt eljárásokkal írt meg a fejlesztő, amit nekem debuggolni rémálom, ellenben minden az adatbázis szerverre terhelődik, ergo én azt is figyelembe venném, hogy egy jó sql optimizálással sokat lehet nyerni (főleg ha már az alapok rosszak), de átlagos webes project-nél nem mernék terhelni adatbázisra bármi többet...

( leho | 2014. 07. 18., p – 13:06 )

@dNi, most, hogy már 3 napja folyik a flamewar, amit kirobbantottál ártatlan kérdéseddel, és már igazából senki sem foglalkozik az eredeti témával, azért én megkérdezném tőled: közelebb kerültél a megoldáshoz, vagy azóta már más portálokon próbálsz segítséget kérni, esetleg elmentél inkább bankárnak/közgazdásznak/kecskepásztornak inkább? :D

Én most Haskel tanulásra adtam a fejem, jó kikapcsolódás a "hagyományos" programozási nyelvek mellett :) Egyébként a Java abszolult jó döntés, és önmagában akkora univerzuma van, hogy kifogyhatatlan tanulási lehetőségek vannak benne, és ez a fontos. Javaslom a javacodegeeks rendszeres olvasását, nagyon jó cikkek szoktak lenni kezdő és haladó témákban is. Sok sikert
-
import groovy.transform.Immutable

Na, végre valaki, aki funkcionális nyelvet is felemlegetett :)

Amúgy tényleg attól függ, mi érdekel igazán.

Webre:

Java: ha átgondolt, erős alapokkal rendelkező és extrém elterjedt nyelvet akarsz tanulni. Nem lőhetsz mellé, Java programozót mindig keresni fognak, és az átgondolt, standardizált megoldásokra törekvésre szoktat.

PHP: valóban vannak inkonzisztens megoldásai, illetve a PHP-Pistike jelenség tényleg egy elég káros dolog (rossz a szakmának, mert lenyomja az árakat, rossz az ügyfeleknek, mert igénytelen és instabil megoldásokat eredményez) viszont kellő öngyegyelemmel és egy jó frameworkkel szintén jó választás lehet.

Javascript (+HTML, CSS): az új üdvöske, sokan a Következő Nagy Nyelvnek kiáltották ki már 1-2 évvel ezelőtt is. Van benne valami, mert - bár valóban vannak furcsaságai - a webalkalmazások elsőszámú nyelvévé vált az elmúlt pár évben. Nyilván főleg azért, mert ezt támogatja natívban az összes böngésző, de ez most mellékes ebből a szempontból :) Szóval egy alkalmazásfejlesztésre erősen ajánlott, széles körben elterjedt nyelv, aminek már a node.js személyében van desktop/server futtatókörnyezete is. Amúgy egy jó Javascript programozó egy jó Java programozóhoz hasonlóan a világon bárhol fog találni jól fizető állást egy hét alatt.

desktop/web/egyéb:

C#: Java, Microsoft által (tovább)fejlesztve. Sok esetben átgondoltabb, mint a Java, viszont erősen Windows-only. Természetesen a .NET keretrenszernek, amire épül, van Linuxos portja is (Mono), ami szép eredményeket ért el az elmúlt években, de még messze van az igazi áttörés.

Python: Én személy szerint ezt ajánlanám, illetve a Java-t, aztán a Javascriptet. Az egyik legfelhasználóbarátabb szkriptnyelv, és tudsz benne webes alkalmazásokat is kódolni. A szintakszisa egy álom, bár kissé fura a többi nyelv után a sok sallang hiánya, de gyorsan rááll az ember szeme.

C: Gyakorlatilag minden alapja. C nyelven írták az operációs rendszered magját, az összes szoftvered alapjait kiszolgáló könyvtárakat, a böngésződet (jó eséllyel), az autód ABS-ét működtető szoftvert, a telefonod alapszoftverét, stb. Egyetemen ezt tanítják első nyelvként sok helyen, sokan szidják is, mint a bokrot. Érteni kell, hogy mit csinálsz, sok esetben nagy gyakorlat kell hozzá, hogy olyan transzparensen tudd már használni a C nyelvi eszközeit, hogy a problémára tudj koncentrálni pl. a memóriakezelés és a struktúrák menedzselése helyett. Bár én nagyon szeretem, és szívem szerint mindenkinek kötelezővé tenném, csak hogy értse, mi történik a háttérben, mikor a magasszintű nyelvének az eszközei épp kinyalják a kis fenekét, de mégis azt mondom, ha hobbiból akarsz nyelvet tanulni, a C egy nem egyszerű eset. Belevágni mindenesetre érdemes, csak ne számíts pár nap alatt olyan látványos eredményre, mint mondjuk egy Java/JS esetében :)

C++: ugyanez, csak pepitában. Ha komolyan veszed és rászánsz pár évet, brutális pénzeket akaszthatsz le pl. azzal, hogy teljesítménykritikus rendszereket írsz benne pénzintézeteknek. Ugyanúgy sok helyen használják a kutatásban és iparban is, ahol teljesítménykritikus alkalmazásokat kell írni. Volt már itt említve, de én is csak megerősíteni tudom: maga a nyelv egyszerű, de a jó C++ programozó stílust elsajátítani nehéz.

Összefoglalva, ahhoz válassz nyelvet, ami érdekel, így a rangsor (szerintem)

web/szerver oldal:
java
python
php + valamilyen framework (cakephp (általános MVC), symfony (általános MVC), drupal (CMS), joomla (CMS))

web/kliens oldal:
javascript (+ HTML és CSS, ezek nélkül esélytelen)

desktop:
C#
C++ + valamilyen framework (pl Qt, WxWidgets)

remélem, sikerült növelni a káoszt :D

( kl3on v | 2014. 07. 22., k – 22:05 )

Egy programozó tudjon programozni :)

Próbáld ki mindet, ha jól értem időd van rá és nem vagy kötve semmihez még.

- Nézd át a php alapjait rendesen és próbálj ki legalább egy valamirevaló keretrendszert hozzá (pl Drupal). php programozó annyi van, mint nyúlsz*r a réten, de jó php progarmozó ennek a tizede kb.
- Tanulj C++-t, én Stroustrup könyvét ajánlom, remek szórakozás és nagyon hasznos. Nézz hozzá majd pl GNU könyvtárakat, abból is rengeteget lehet tanulni, vagy Windows-os apikat a Visual C++-szal.
- A Java szerintem nagyon átgondolt nyelv és remek standard lib-bel rendelkezik, plusz nagyon elterjedt, nem lehet kihagyni. Az Agyhullám (Head First) könyvet javaslom, vagy a Hatékony Java-t (Effective Java).

Ezek után még javasolnám, hogy vizsgáld meg a Pythont pl, a .NET-et, a Perl-t. Aztán majd tudni fogsz dönteni és lesz rálátásod.

( uid_17784 | 2014. 07. 23., sze – 00:20 )

Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python Python

---
mert csak