HOVD 2011 - Kedvenc programnyelv

Címkék

c
14% (121 szavazat)
c#
6% (56 szavazat)
c++
14% (124 szavazat)
haskell, erlang, caml, ... (funkcionális nyelvek)
2% (21 szavazat)
java
17% (150 szavazat)
perl
8% (69 szavazat)
php
21% (181 szavazat)
python
14% (122 szavazat)
ruby
3% (29 szavazat)
scala
1% (8 szavazat)
Összes szavazat: 881

Hozzászólások

Több év után először, ezt kell, hogy mondjam: Java. Egy SCJP könyv olvasása után kinek van kedve STL-lel balf*szkodni...?

Engem meg az lepett meg, hogy miután jó sokat megtudtam a Javaról, és C++- hoz kellett nyúlni, ott nem köszönt vissza a javás konzisztencia, interfészek, stb.

Amíg Qt-vel használja az ember, tökéletes (qtl, ftw). De pl. az az " életmentő " boost is hányingert keltő...

Furcsa, hogy ezt mondod, ugyanis a C++ standard könyvtára meglehetősen pici. Arra tervezték a nyelvet, hogy külső könyvtárakkal legyen használva. Ezért kicsit igazságtalannak érzem a Java böhöm könyvtárának legjobb részeihez hasonlítani a C++ picike könyvtárát.
----
Hülye pelikán

Amíg hitvita, meg gyorsaságbuzulás hajtja a C++ programozót, addig védi is a nyelvet, de valós életben, piacképes szoftver írásakor nemcsak a nyelv számít, hanem a hozzá jövő: libraryk, IDE, Debugger, Unit/GUI/Vertical/stb. testing frameworkök és így tovább.

Hiába ezek nyelvtől függetlenek, de úgy veszem észre, itt is érvényes a 80-20-as szabály (a döntésnél 20% a kényelmes, célorientált nyelv, 80% a hozzá tartozó productivity stuff)

Én egyrészt C++ rajongó vagyok, de ettől függetlenül azt is látom, hogy rengeteg jó cucc van hozzá. Libraryk, IDE-k, debuggerek, testing frameworkok (vicces, mert épp ebből írom a diplomamunkám).

A Javat nem érzem úgy, hogy kényelmesebb lenne a C++-nál, ugyanolyan nehézkes, csak más vonalon. Ami azért baj, mert a C++-t szinte lehetetlenség lett volna úgy megcsinálni, hogy ne legyen nehézkes, hiszen erős és alacsonyszinten is működő nyelvet akartak, de a Javara vannak példák, hogy hogy is lehetett volna, ha átgondolják, lásd C#.

Fanatikusnak nem lehet nevezni, nem a Java koncepciójával van bajom, hanem hogy az is egy baromi nehézkes és kényelmetlen nyelv, miért pont azt hozza föl valaki a C++ ellen. Nem ítélek el minden nem C++ nyelvet, második kedvencem a Python, ami azért messze áll tőle.
----
Hülye pelikán

A C++ IO-kezelése a leggyönyörűbb... (nem).

Meg az össze-vissza template-zett minden, ami már szinte áttekinthetetlenné válik...

Az a bajom, hogy a C++-hoz tartozó félig-meddig beépített osztályok (iostream, ifstream, stb.), meg az STL nevezéktana baromira nem egységes. (Legalábbis amikor használtam, akkor néha felsírtam, hogy ezt hogy lehetett ennyire nem logikusan elnevezni).

Szóval jó az a C++, de nehézkes.

És akkor a copy constructorról, az = operátorról ne is beszéljünk. A magam részéről szeretek magára a problémára koncentrálni, nem a kötelező körítésről gondoskodni. Szóval nekem ez a két dolog a nagy szálkám a C++-ban.

Az, hogy mennyire gyors valami, vagy mennyire optimalizált, programozási nyelv független (C++-ban és Java-ban is lehet buborékrendezést írni, de quicksortot is). Ha a sebesség ennyire számít, akkor úgyis GPGU lesz a megoldás. Viszont az nem mindegy, mennyi időbe kerül megvalósítani ezt a nagyon optimalizált, fürge kódot. Akkora a verseny, hogy számít a time-to-market. Jobb kijönni hamarabb egy használható, de nem optimalizált programmal, mint fél évet eltökölni azon, hogy megpsóroljunk 30 CPU ciklust. Azt a második verzióban meg lehet lépni, nyer a vállalat fél évet arra, hogy optimalizáljon, úgy, hogy a termék első verziója már a piacon van.
Ez a "release early, release often"-filozófia, ami open source körökben egyenesen követelmény. Nézd meg, mobilalkalmazásoknál milyen gyakran jön firssítés, sokszor akár hetente is: bugfixek, gyorsaságot érintő javítások. A disztribúciós platform megengedi, hogy mindig új verziókkal gyere ki, ezárt ezt ki is használják. Nem baj, ha elsőre nem lett optimális a kód, a lényeg, hogy használható legyen a szoftver.

Az a különbség, hogy az egyik nyelven alapból az a jó gyakorlat, ami egyben a hatékony kódot is eredményezi, és errefele irányít a nyelv maga, a másikban meg nem, és ugyan lehetséges, de extra erőfeszítés. Hiába mondod amit mondasz, nem véletlen hogy sok területen egyszerűen nem elég a Java.
----
Hülye pelikán

Ahol nem elég a Java, ott remélem van is pénz arra, hogy a C++ fejlesztéseket megfizessék. Sokszor rengeteget lehet szívni azzal, hogy melyik SDK melyik fordító alverzióval fordul le jól és csinál jó kódot (kmARC HUP-tag tudna erről sokat mesélni), egyszerűen ez túl sok munkakiesés olyan környezetben, ahol fontosabb a működő kód, mint a gyors kód.

Na pont ez a szemlélet, amiről beszélek. Nem elég gyors, gyorsabb processzor, még az sem elég, hát legyen GPGU. Kevés a memória? Az olcsó, tegyél bele kétszer annyit.

Viszont az tökéletesen igaz, amit írsz, a fejlesztési ciklus felgyorsult, ehhez meg az kell, hogy gyorsan csinálj kódot, mindegy a sebessége, mindegy optimális, csak legyen meg minél előbb. Lehet én vagyok öreg, de ez nekem már nem tetsző irány, hiába tudom, hogy ez van.

"Azt a második verzióban meg lehet lépni, nyer a vállalat fél évet arra, hogy optimalizáljon, úgy, hogy a termék első verziója már a piacon van."
De ilyen meg jó eséllyel nem lesz, mert addigra már valami újat kell kihozni, szintén optimalizálatlan kóddal.

Azért ez a szemlélet, mert a hardve sokkal olcsóbb ahhoz képest, amennyibe egy jó programozó kerül, vagy amennyi időt elvesz az optimalizálás.
Az élőmunka nagyon drága (főleg ha szellemi terméket készít), a gép olcsó. Ez eddig is így volt, ezután is így lesz.
Régen tényleg muszáj volt optimalizálni, mert a hardver volt drága az élőmunkához képest (10 000 $ /MB volt régen egy drive, manapság meg 8-10 cent egy GB és hasonlók)

Ha kazánt kell fűteni, akkor sajnos a faragás nem alternatíva.

Én úgy látom, hogy ami a java előnye, az egyben a hátránya is. Rengeteg kész komponens van, amikből csak össze kell legózni a kész programot. De ha a kényelem/szűkös határidők miatt csak nagy építőkockákat használunk, a végeredmény is csak nagy lehet. (Ígérem nem folytatom a legós hasonlatot. :)) C++-hoz is elérhetőek kész komponensek ugyan (az STL-en túl), de azok beemelésekor már jobban el kell gondolkozni, hogy valóban szükség van-e arra, megfelelően lehet-e integrálni a projektbe, stb. Azaz a fejlesztő rákényszerül a tervezésre. Természetesen nem azt állítom, hogy java esetén nincs tervezés. Viszont azt látom, hogy a mai fejlesztési modellekben a tervezést próbálják minél inkább lerövidíteni, amihez a java remekül illeszkedik, de a C++ nem.

--
Don't be an Ubuntard!

A kolléga az STL tárolókat hasonlította össze a Java megfelelő részével,ami pedig a Collections Framework, ami meglehetősen konzisztens API-t ad a C++ STL tárolóihoz képest, ezzel is csökkentve a tanulási időt. Az STL tárolók azonban csak egy részét adják a C++ Standard Librarynek, ugyanúgy, ahogy a Collections Framework is csak egy része a Java SE-nek.
A C++ Standard Library többi része (I/O streamek,karakterláncok, memóriakezelés, RTTI) a Java-ból a java.io, java.lang.String, java.lang.ref és java.lang.reflect elemeknek feleltethető meg. Ezen kívül a NIO, NIO.2 és további elemekről szó nem volt, csak az STL tárolókról.

"Arra tervezték a nyelvet, hogy külső könyvtárakkal legyen használva."
Ez sajnos nem igaz ebben a formában, ugyanis nincs ABI-ja, más C++ fordítóval fordított könyvtárat nem tudsz használni.
Abban az értelemben igaz, hogy szándékosan lett kicsi a C++ Standard Library. De a nyelvet nem így tervezték, csak a standard C++ platformot. De azt se sikerült konzisztensen megvalósítani. A Java API-kban is van sok inkonzisztens dolog, de messze nem olyan sok, mint mondjuk C++-ban vagy PHP-ban, ettől lesz könnyebben tanulható.

"Azt nem látom, hogy az ABI miért szükséges a könytárakkal való együttműködéshez. Látod te is, hogy működik a dolog."
ABI azért kell, hogy egy Visual C++-szal lefordított, nem nyílt forrású libet is lehessen linkelni MinGW-vel fordított kódhoz. Vagy éppen Intel C++ fordítós kódhoz. Ez jelen pillanatban nem működik, kivéve ha gányolsz. Java-nal ott a jar, használhatod, linkelődni fog.

"Mitől inkonzisztensek az STL tárolói?"
Attól, hogy rossz absztrakciókat használnak. Például nincs általános Collection, ami elemek együttesét (nem halmazát!) írná le. Másrészt a lista előírás szerint kétszeresen láncolt listaként valósítandó meg. Ahelyett, hogy lenne X listaimplementáció a lista API-jával, és azt használod, ami éppen neked a teljesítmény miatt kell. Javaban ez így megy: List->LinkedList vagy ArrayList vagy amit akarsz. Minden kód, ami List-et vár paraméterül és List-et ad vissza, megfelelően működik, attól függetlenül, hogy mi a mögöttes implementáció, nem is érdekes.
A map előírás szerint rendezett kell legyen, annak ellenére, hogy ez csak azért érdekes, hogy bizonyos műveletek gyorsak legyenek. Az implementációnak semmi köze az absztrakt adattípushoz (asszociatív tömb).
A lényeg: összekeveredik az absztrakciós szint és az implementációs szint.

Még mindig nem látom, hogy az ABI miért is olyan fontos ahhoz, hogy a nyelv a külső könyvtárakon alapuljon. A könyvtárakból is lehet több változatot fordítani, szokás is, működik a rendszer. Lásd bárhol. Írtam opengl-es programot három platformon (igaz csak kettőn láttam az eredményt), a Qt fordul rengeteg platformon, többféle fordítóval.

Az STL-es design aggályaid csontig rágott témák. Olvass utána, miért lett így, ahogy. Amíg nem voltak szabványos tárolók, voltak olyan implementációk is, amilyen szerinted a jó lenne. Nem jött be. A template is egy absztrakciós szint, és nagyon jól működik, köszöni szépen. Annyi a különbség, hogy néha újra kell fordítani a kódot, míg a te módszereddel on the fly lehet cserélgetni a modulokat. Nem egy nagy előny a legtöbb területen, és sokat veszítesz miatta. Van szabványos felület, csak meta területen: iterátorok. Persze Java világból nézve nehéz lehet megérteni, hogy van élet az OO-n túl is.
Ha akarsz egy nem kétirányú láncolt listát, használhatsz azt is. Az algoritmusokat meg lehet írni úgy, hogy bármelyiken működjenek. Nem igazán látom hol a probléma. Ami nem algoritmus az egy konkrét listát fog használni, ha betypedefeled akkor EGY helyen kell átírni, és jó eséllyel újrafordítás után már egy másik listaimplementációval fog futni. És megspóroltunk egy rakás virtuális függvényt és inlineolhatatlan függvényt.
A map olyan, amilyen. Van másfajta asszociatív tároló is. Nem tudsz asszociatív tárolót anélkül írni, hogy valamiféle összehasonlító műveleted lenne, és az egyenlőségvizsgálatot megkövetelni éppolyan random mint a kisebbet. Ők ezt választották.

"A lényeg: összekeveredik az absztrakciós szint és az implementációs szint."

Ezzel egyetértünk, ez hatékonysági okokból van így, és NEM lesz tőle nehezebben használható a könyvtár. De tényleg, meséld el, hogy az iterátorok (ami az APIját képviseli a tárolóknak) mitől inkonzisztensek.
----
Hülye pelikán

Miért kövezne meg bárki is. Egyrészt senkinek semmi köze ahhoz, hogy neked mi a kedvenc nyelved, másrészt ha elkészül a feladat határidőre, akkor mindegy, hogy mivel csináltad (főleg, ha a megrendelőt sem érdekli).

Én orthodox linuxos létemre C#/Mono-t használok, és kiválóan elvagyok vele. És jót nevetek magamban, mikor mesélik a kollégák, hogy hogy mennyit szopnak a %s nyelvvel/keretrendszerrel/technológiával...

Fuszenecker_Róbert

Eléggé kifordítva az Erkel által írt operában szereplő ária szövegét:


,,Pascal, Pascal, te mindenem,
Tudom, hogy mindenem (*) Neked köszönhetem!''

Gábor

(*) az első, számomra valóban jól használható és tanulható programozási nyelv volt, amely segített abban, hogy beleártsam magam a programozásba...
============================================
"Share what you know. Learn what you don't."

C-re böktem, de Cpp-t is kb ugyanannyit használom. De a C-t jobban szereem. MIndíg olyan érzésem van, hogy "jobban a kezemben van a gyeplő".

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Python - egyre jobban a kedvenc. :)

Tetszik a hasonlat, jót mosolyogtam rajta. De azért, ha gyorsan kell valami működő kód, akkor mégiscsak Perl-t választok, főleg azért, mert a modul ellátottsága az én területemen (bioinformatika) több nagyságrendekkel jobb, mint a Pythoné. (Bár elismerem, jön fel az is rendesen.).
Csaba

Pascal, de az nincs a listán :) így Python lett.

Nem akarom megeygszer leirni, ezert kerlek, hogy olvasd el az ebben a szalban adott valaszaimat:

http://hup.hu/cikkek/20111205/hovd_2011_kedvenc_kommunikacios_program_a…

A "nem az ipar szulte" pedig hat kicsit ugy hangzik, hogy nem nagy ceg szulte. A nagy ceg az ipar? Sajnos nem all mogotte tokeeros nagy ceg. Ezert nem terjed el. nem azert mert akademiai nyelv. Ilyen alapon a C# vagy a Java is akademiai nyelv. A D legalabb annyira jol hasznalhato nyelv, mint a masik ketto. A fenti linken pedig leirtam, hogy mi a helyzet beagyazott es PCs kornyezetben, es miert volna igeny ra. De az igeny csak szakmai korokben letezik, es nem management korokben. Ja a vevo meg le van szarva. Majd vesz nagyobb teljesitmenyu gepet meg windows servert meg akarmit az "ipari igeny" szulte megoldasokhoz. A beagyazott rendszereken meg ganyolunk tovabb C-ben, jo az oda, falura, parasztnak, gatya ala, hetkoznapra.

Szoal szerintem ne keverjuk ossze a szakmai igenyt a toke igenyeivel. A Java azert kerult managed kornyezetbe, hogy minden platformon fusson, a C# pedig azert, hogy pontosan csak egyen. Ezek az elkepzelesek mindket esetben gazdasagi megfontolasok menten szulettek! Sajnos a Java nem sikerult olyan nagyon jol, de nyilvan bizonyos kornyezetben (elsosorban PCs vilag) akar meg hasznalhato is lehetne. De Java gyorsasagarol megtartott akademiai vitak mellett a valosag azt mutatja, hogy tobbsegukben igen lassu es memoriaigenyes porgramokat sikerult benne kesziteni. Nyilvan ipari igenyekre szabva. ;-)

Szoval az ipari igeny az, amit a nagy cegek alkottak sajat gazdasagi erdekeltseguk menten ipari igenynek. Nem az, ami szakmailag is minden szempontbol jo volna.
Ha a C# egy szabad nyelv lenne kivalo keresztplatformos forditokkal es tolem akar minden platformon futo managed kornyezettel, es lenne hozza nativ fordito a beagyazott chipekre, akkor valoban nem lenne igeny masik nyelvre.

Az én fejemben a C++ nyelv járt, amikor ipari igényről beszéltem. A C-s gányolásban megfáradt programozó továbbgondolta, hogy mi lenne hasznos a munkájában, és így született a C++. A D pedig úgy, hogy valaki kijött az egyetemről, dolgozott fél évet, és elképzelte hogy lehetne az egyetemen tanult szép elméleteket belerakni egy nyelvbe. Nem kétlem, hogy néhány speciális területen nagyon jó lenne, de itt most általános célú nyelvvé válásról volt szó.

De mondhatnám az Erlangot is. Ami elvileg funkcionális nyelv, gyakorlatilag nagyon sok egyéb helyről összerakott eleme van. Miért? Mert az ipar szülte. A tisztán funkcionális nyelveknek nagyon szűk a használhatósága, ezért nem is használják őket igazán.

A D is valamiféle tisztább elméletiséget próbál megvalósítani, ami nem találkozik az ipar általános igényeivel. Ez van.

Ha megnézed, C++-ban is van egy feature, ami az elméleti szépség miatt került bele, de többek között a C kompatibilitás égető szüksége miatt nem használja senki, ez az exception specification.
----
Hülye pelikán

Bocs, hogy nem irtam ki a C++-t a ganyolasnal a C melle, de odatartozik. Ugyanolyan elvault haszanlahatatlan iszonyat remseg, mint a C. Igen van OO paradigma ezert elonyben reszesitem a C-vel szemben. De hogy jon egy C++ barmelyik modern nyelvhez? Egy tragedia. Egy torzszulott. Ahol kulon csak a problemakrol (csapdakrol) konyvek garmada szuletett. Ahol az ember allandoan a nyelv hulyesegeire koncentral, ahelyett, hogy a feladatot oldana meg. Hogy minden fordito kulon elkapraztat, hogy mit muvel pl. a templatekkel. Es igen, en is ebben keresem a kenyerem, de azert nem gondolom, hogy ez lenne a kanaan. Sot.

Várj, itt nem egyéni preferenciáról volt szó, hanem arról, hogy mi kell egy nyelv elterjedéséhez. Szerinted az, hogy a multik mögéálljanak, és szegény kicsi D olyan elhanyagolt, pedig ANNYIRA jó csak nem karolták fel. Hoztam egy ellenpéldát, hogy milyen az alulról jövő nyelv, és hogy a felkarolás nem szerencse kérdése, hanem azt kell tudnia a nyelvnek, amit elvárnak tőle, nem azt, amit a készítője kitalált, hogy milyen jó is lesz.
----
Hülye pelikán

Eredetileg az ipari igenyekbol indultunk ki. En azt probaltam leirni, hogy szerintem miert van szukseg egy olyan nyelvre, mint a D (most, hogy pont a D vagy masik az mellekes, nekem a D tetszik a legjobban). Az elterjedes csak azert jott a kepbe, mert szerinted azert nem terjedt el, mert nincs ra igeny. Szerintem azert nem terjedt el, mert nincs mogotte penz, es eros gazdasagi erdek.

A linux alulrol jovo? Elterjedt? Szukseg van ra? Desktopon? Szerveren? Okostelefonban?

Tehat a minosegnek az elterjedtsegnek es az igenyeknek jellemzoen egymashoz vajmi keves kozuk van. A penz es a gazdasgi erdek dominal.
A C++ azert terjedt el, mert akkroiban nem volt valodi alternativaja, nem azert, mert annyira jo. De akkor azert egy meroben mas helyzet volt, mint ma.

Én meg azt próbálom megértetni veled, hogy attól mert te és még néhányan úgy gondoljátok, hogy igény van a D képességeire még nem lesz igény rá. Ha lenne rá igény, elterjedne.

A Linux egy operációs rendszer, egészen más kategória, és nem is igen értem mit szeretné mondani vele.
----
Hülye pelikán

Nem, nem és nem. Az átlagos alatt olyat értünk, aki ért a nyelvhez, csak nem zseniális. Az ilyen nem csinál buffer over/underflowt gyakrabban, mint más nyelvben, mert tudja, mire kell odafigyelni. A Javat viszont úgy írták meg, hogy a best practices egyben lassú megoldásokat is eredményez. Lehet gyorsat írni, de az már a template metaprogramming szintje.
----
Hülye pelikán

Te most katalogusadatokat mondasz, vagy hasznaltal mar ilyet? Namost ugye az oda portolom, ahova akarom az kb. 3x annyi ido mint .net nelkul megirni a firmwaret akarmilyen gany nyelven. A masik, hogy egy managed kornyezet lenne az utolso dolog, amit jozan ember (real-time) firmware fejlesztesre hasznal. Igen, teny es valo, hogy specialis micro PC-ket is hivnak beagyazott kornyezetnek, de azert a kettot nem erdemes keverni.
A keresztplatformos C# fordito meg akkortol letezik, amikor ez a beagyazott chipeket gyartok kinalataban megjelenik. Na most ugye az ngen-t nem nevezhetjuk native forditonak, mert lenyegebn nem az. A mononak van meg vmi megoldasa, ami x86-ra talan mukodik. De nem biztos, hogy nem kell hozza a managed kornyezet (ezt nem tudom).

Igen, ez egy evalboard egy Atmel ARM processzorhoz. A demo erdekes, nem rossz. Persze az nem derul ki, hogy mi van a micro frameworkben, honnan varazsoljuk ugye a hardware classokat (ez azert ugye controller specifikus), van-e garbage collection (a videokban szereplo peldak szerint feltetelezheto, hogy van, de akkor mar komoly aggalyok vannak a real-time tekinteteben), stb. Az interruptok definialasa is nagyon erdekes (az egyik peldaban beallit egy port interruptot), de mondjuk az nem derul ki, hogy pl. hogyan allitod a linker sectionoket, vagy mondjuk van-e azert low-level hardware hozzaferesed. Memoria cimzesek, stb.

Azert orulok, hogy van, erdekes.

ez nem real-time, soha nem is volt annak szánva. van gc, "természetesen".
hw-classok generálása: hal portolása egyelőre a fejlesztőre vár, jól le van dokumentálva a mikéntje. ezt adott elvárások szerint te írod meg c++-ban. (pl. gpio-nak, timereknek, soros portnak, stb.)
gyakorlatilag erre a rétegre (és még pár absztrakciós szintre) épül a tényleges managed környezet, amiben az alkalmazás fog futni. aztán ha megvan az alacsony szintű "driver", akkor managed kódban is lehet hozzá magasabb szintű meghajtókat írni.

linker section-ökkel akkor lehet foglalkozni, amikor lefordítod a frameworköt, természetesen úgy csinálod meg ahogy úri kedved tartja.

használtam, egész jól el lehet vele szórakozni. természetesen realtime feladatokra nem, vagy csak erősen korlátozottan alkalmas bármilyen managed környezet, de ezt nem is várja el senki. (viszont pl. felhasználói felület építésére nagyon kellemes)
a portolás nem nagy etwas, gyakorlatilag csak a hw absztrakciós réteget és a bootstrap kódot kell masszírozni.

az alkalmazásból natív kódot tényleg nem fog generálni semmi, viszont a frameworköt portolhatod bármilyen platformra, azon pedig már futhat a kód... ennek az egésznek nyilván van egy elég durva overheadje, de ezzel jár az egész.

Semmiben sem egyedi. Amolyan mix. Nem tűnik használhatatlannak, sőt szerintem egész ötletes (Szerintem C++, Java hibrid). De pont azt a rétegeget fedi le amire már nagyon jól bevált megoldások vannak. Szerintem nincs rá igény.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Köszönjük, ezt eltesszük az utókornak emlékbe. A karbantarthatóság egyáltalán nem függ a nyelvtől, az egyedül a programozó dolga. PHP-ban is lehet karbantartható kódot írni, de szart is. C++-ban is így van, C-ben is, D-ben is, Java-ban is, és így tovább.
Mivel a template-k Turing-teljesek fordítási időben, ezért ez + a halting problem együtt azt adja, hogy simán lehet olyan kódot írni, ami végtelen idejig fordul le, vagy éppen két fordítás más eredményt ad.

A kérdés az volt, hogy mi a nyelv lényege. Ez a lényege. Nem az volt a kérdés, hogy melyik nyelven mit lehet megcsinálni. Ezen még gondolkodj, mert látom hogy izzad a homlokod és már köpnéd a következő hülyeséget.

"idejig"

Ehhez meg csak gratulálni tudok.
----
Hülye pelikán

Köszönöm a gratulációt.
Minden gyakorlati használatra tervezett programozási nyelvnek az a lényege, hogy hatékonyan oldjanak meg vele problémákat, nem a C++ van ezzel egyedül, hidd el.
Sem a Java, sem a C#, sem a C nyelvet nem ideológiák mentén tervezték, hiába is gondolod ezt. Vagy ha számodra ideológia a "write once, run anywhere" vagy az, hogy csináljunk egy hordozható assemblyt, akkor a C++ részben OOP/részben procedurális/részben metaprogramozás kialakítása is ideológia.

A C++ nyelven írt programok tényleg nagyon hatékonyak tudnak lenni, nem véletlen a HipHop For PHP projekt. Viszont figyelembe kell venni, hogy a HipHop compiler, ami tényleg gyors és hatékony C++ kódot gyárt, 300E soros, karban kell tartani, eléggé sok mérnökévnyi munka van benne, ezt is hozzá kell venni a hatékonysághoz. Nem csak azt, hogy mennyire hatékony kódot állítunk elő, hanem mennyire hatékonyan állítunk elő kódot. Az utóbbi manapság sokkal fontosabb a felhasználások túlnyomó többségében, mint az előbbi.
Ahhoz, hogy valaki jól ismerje a Java nyelvet, sokkal kevesebb képzés kell, mint ahhoz, hogy valaki jól ismerje a C++ nyelvet. Csak a nyelvről van szó, nem az API-ról. Az más kérdés. Egyszerűen nem éri meg sok időt tölteni egy nyelv megismerésével, ahelyett hogy a valós problémákat oldanánk meg. Ha valós probléma a teljesítmény, akkor lehet C++ vagy C felé fordulni. Amíg nem valós probléma ez (és olcsóbb hardvert venni, mint fejlesztőt fizetni), addig a Java jobb megoldás. A Google-nél is a teljesítménykritikus részek íródnak C++-ban, a többi Java/Python és Go. Nem véletlenül. Mert ami nem teljesítménykritikus, ott a C++ egyszerűen hátrány. És a világban rendkívül kevés számú probléma teljesítménykritikus. Nem mondom, hogy ami teljesítménykritikus, az nem fontos, dehogynem. Csak nincsenek sokan.

Nyílván egy iparban használt nyelv a produktivitás felé fog menni.
A Javanál kiemelik, hogy ilyen és olyan dolgokban milyen jó, és de szép ez meg az.
A C++-t folyamatosan szídják, és nagyon sokat beszélnek a hátrányairól.

Mégis mindkettőben új projektek indulnak folyamatosan.

Én nem azt mondom, hogy írjunk MINDENT C++-ban, én a szemléletről beszélek: a C++ egy adott célra jött létre, leváltani a C-t és kiterjeszteni a használhatóságát. A Java azért jött létre, hogy legyen egy egyszerű nyelv, amin gyorsa(bba)n lehet alkalmazást fejleszteni, és mellesleg beletettek ilyen marhaságokat, hogy tisztán OO (faszt), meg egyéb, papíron jól hangzó dolgokat.

Mellesleg a write once, run anywhere az pont annyira igaz a C++-ra mint a Javara, amire gondolsz az a compile once, ...
----
Hülye pelikán

off:
"Nyílván","szídják"
Ezért külön gratuláció. 1:1 Igaz, van nyílván is, de mást jelent.
on:
A C++ is egy iparban használt nyelv, sok helyen használják. Mégsem a legproduktívabb.

"és mellesleg beletettek ilyen marhaságokat, hogy tisztán OO (faszt)"
Senki nem mondta, hogy a Java tisztán OO. Aki ezt mondja, az nem ismeri a Java nyelvet.

"Mellesleg a write once, run anywhere az pont annyira igaz a C++-ra mint a Javara"
Hálózatkezelés platformfüggetlenül külső lib nélkül van-e?
Hány helyen kell a különféle compilerek és C++ runtime-ok miatt #ifdef-ekkel ellátni a headereket? A MinGW és a Visual C++ Runtime eléggé eltér még Windowson is.

"beletettek ilyen marhaságokat, hogy tisztán OO (faszt), meg egyéb, papíron jól hangzó dolgokat"
Leszámítva, hogy javara konkrétan ez nem teljesen igaz, de tfh. mondjuk ruby vagy smalltalk stb. programozókat értesz ez alatt...

Ugye milyen buták?

Sőt, a funkcionális programozás hívei meg még egy rendes for ciklust sem tudnak csinálni, hogy elkerüljék az állapotokat - mindig csak az a nyüves rekurzió meg a magasabb rendű függvények. Nevetséges, nemde? Hát milyen lassú programokat írhatnak így: nyilvánvalóan a fellegekben járnak...

Pedig az ő számukra is adott a C++ kényelme és sebessége! Ki érti ezt... ;)

Szorszalhasogatas, megha igaz is. Ha igy tetszik csak a generalt kodnak van sebessege. De a generalt kod eros korrelacioban van a forditoval (megha tobbfele is van, azert valahogy altalanosan elmondhato, hogy vannak nyelvek, amikhez konnyebb olyan forditot irni, ami gyors kodot csinal, es van amihez nem, a D egyebkent abban a filozofiaban keszult, hogy minel konyebb legyen hozza jo es es gyors kodot generalo forditot irni), a fordito meg vegsosoron a nyelvvel. Tehat a kapcsolat valoban kozvetett, de letezik, es a korrelacio szerintem eleg eros.

"valahogy altalanosan elmondhato, hogy vannak nyelvek, amikhez konnyebb olyan forditot irni, ami gyors kodot csinal, es van amihez nem"

Ezt meg is tudod indokolni, vagy csak úgy gondolod?
Javaslom keress rá a hup-on syntern kollégának a Java lassúságával kapcsolatos régi hozzászólásaira.

Matematikai egzaktsaggal nem tudom megindokolni, mert nem foglalkoztam a temaval beahtobban es nem irtam meg forditot sem. De nyilvan van olyan szintaxis, amit konnyeb ertelmezni, es van, amit nehezebb. Ebbol kovetkezik az eroforrasokra valo optimalizalhatosagnak is a jobb vagy rosszabb lehetosege.
En ebben a dolgoban most a tapsztalataimra tamaszkodom, eleg sok nyelvvel, forditoval, runtimemal dolgoztam. Nyilvan a nyelv megalkotasanal mar eleve figyelembe veszik, hogy mire keszul. Szkriptnyelv lesz, managed kornyezteben futo nyelv lesz, forditott nyelv lesz. Korabban a D nyelv kezdooldalan kint volt egy olyan megjegyzes, hogy a D-t (tobbek kozott) arra lakottak, hogy konnyu legyen hozza forditot irni. Mindez annak a szajabol, aki C es C++ forditok irasabaol el. Az sem lehet veleteln, hogy a fordito keszitok olyan lassan implementaltak a C++ featuroket, es hogy minden forditonal ujabb es ujabb meglepetesekkel kell megkuzdeni. Nyilvan ez specifikacios hianyossagokra is visszavezetheto, de a specifikacio az maga a nyelv.

Az a baj, hogy a HipHop nem tamogatja a PHP minden elemet, ezert nem irhatnak barmilyen PHP kodot, csak olyat, amit a HopHop megeszik. Es ok jobban szeretnek barmilyen PHP kodot irni, mintsem HPHP kodot. Ezert nem azt csinaljak, hogy a HipHop-ot modositjak, hanem csinalnak egy sajat PHP engine-t. Nekem ebbol az kovetkezik, hogy a HipHop-ot nagyobb munka felkesziteni a barmilyen PHP tamogatasara, mint a HHVM megirasa. Azaz szerintem a HipHop epphogy nem karbantarthato kod.

A Facebook máshogy gondolja: a HipHop azért nem támogatja a PHP minden elemét, mert a statikus analízis természeténél fogva nem tud megbirkózni egy dinamikus nyelv minden elemével. A HipHop kód karbantarthatóságának ehhez semmi köze, sőt, a HipHop fordító egyes részeit a HHVM-ben is használják.

En csak probalom megerteni az allaspontodat, amit csak szukszavakban fejtesz ki (ezert kerdeztelek). Eddig ezt mondtad (innentol kivonat, osszeolvasva a kerdeseimet a valaszaiddal ebbol a szalbol):

-kivonat start-
Akik a D-re es a Java-ra azt mondjak ujratervezett C++ azok nem értik a C++ lényegét. A C++ lényege az, hogy erős eszközt adjon a programozó kezébe, amivel hatékony és karbantartható szoftvereket állíthat elő.
Ez a D-re es a Java-ra nem igaz, mert azokat a nyelveket valamilyen ideológia mentén tervezték meg, hogy kéne egy olyan nyelv és hmm. A C++-t meg nem, az összevadászta a meglévő megoldásokat a különböző nyelvekből.
Szó sincs arrol, hogy a Java és a D ne lenne alkalmas hatékony és karbantartható szoftverek előállítására.
-kivonat end-

Ezek alapjan ugy tunik a D meg a Java ugyanarra valo, mint a C++, csak nem osszevadasztak, hanem egy szervezesi rend menten epitettek fel oket. Ez a velemenyed?

ha nincs assembly, hát legyen a "c" :D

A szavazás alapján a C/C++ dominanciája (összeadva a szavazatokat) még mindig él. Helyes.

Szavaznék Pascalra meg assemblyre, de nincs. Nem szavazok C-re meg Javara, pedig ezekből élek vagy 5-6 éve... :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Évről-évre meglep, hogy a kedvenc webes keretrendszer a RoR, de az ennek alapot adó programnyelv a Ruby viszont sereghajtók között van.