HOVD 2011 - Kedvenc programnyelv

 ( trey | 2011. december 10., szombat - 18:42 )
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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

Én is ezt mondtam. Szégyellem is magam...
:-)

Megleptél.

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

Minden nyelven lehet szar API-t írni, Javaban is van rengeteg legacy dolog, pl. a java.net.URL.equals() viselkedése. Érdemes tudni róla, de az STL tényleg hányás. API designban jó video: http://www.youtube.com/watch?v=aAb7hSCtvGw

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.

Mindig öröm olyan emberrel találkozni akitől dübörög a gazdaság. Valóban fölösleges a gyorsaság és optimalizált szoftver, hiszen fél év múlva bármilyen szar, tohonya program gyorsan fog futni az újonnan megvett gépen.

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)

Írtam, hogy tudom, de nekem akkor sem tetszik. És persze azt is tudom, hogy ez meg nem érdekel mást. :-) Valahogy favágás lett idővel a míves faragásból. De ez van, hajrá Java.

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

Hát erről szívesen hallanék még. Mitől inkonzisztensek az STL tárolói?
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.
----
Hülye pelikán

"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

a php-ra böktem, de elvagyok az pascallal és a vba-val is. kövezzetek meg! :D

--
[ Falu.me | Tárhely | A Linux és é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

+1 a Mono/C#-ra

Nalam is a kedvenc a Pascal, hiaba hasznalok azota mas/jobb nyelveket, megiscsak o volt az elso, meg most is neha eloszedem :)

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.

+1

A perl de le van maradva... :/
--
Discover It - Have a lot of fun!

Rá se ránts, ahogy fogynak a Perl guruk, úgy lesz egyre értékesebb a tudásuk ;-)
Csaba

ehehehehe

Python - egyre jobban a kedvenc. :)

én még várom, hogy meggyőzzön. addig marad a perl.

Ez durva volt. Mégis mivel kéne meggyőznie a szépséges királylánynak, hogy ne a vén, falábú bibírcsókos boszorkányt válaszd? Ez a királylány nem ám csak szövöget otthon és szépítkezik...
----
Hülye pelikán

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.

Megérzés, de szerintem tévút.

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

miert?

Mert nem ipari igény szülte a nyelvet, hanem akadémikus elgondolás.
----
Hülye pelikán

Nekem nagyon is gyakorlatiasnak tűnik - a jó elméleti alapok mellett persze, ami viszont kell egy jó nyelvhez.

Inkább az tartja nagyon hátul, hogy nincs elterjedve, vannak mások helyette a porondon, az általános célú nyelvek körében magas a küszöb.

Én is azt gondolom, hogy ez olyan, mint az eszperantó vagy az interlingua. Hiába van jól megcsinálva, ha senki sem használja, akkor senki sem fogja használni.

Fuszenecker_Róbert

Neked annak TŰNIK. De ismétlem: nem az ipar szülte. Nem volt ott az igény, hogy legyen egy D nyelv. Semmi sincs benne, amire égetően szükség lenne más nyelvekben, és még nem oldották volna meg valahogy.
----
Hülye pelikán

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_audiolejatszo_bsd_rendszer_bongeszo_programnyelv_jeloltek#comment-1383747

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

Nekem lenne, neked nincs. Semmi gond. Nekem ezert kedvencem a D. De a fentebb leirt feltelek mellett pl. a C# lenne a kedvencem.

"De Java gyorsasagarol megtartott akademiai vitak mellett a valosag azt mutatja, hogy tobbsegukben igen lassu es memoriaigenyes porgramokat sikerult benne kesziteni. "
A D hasznalhatosagarol megtartott akademiai vitak mellett a valosag azt mutatja, hogy senki nem hasznalja.

Nem azert nem hasznaljak, mert nem hasznalhato. A Javaban pedig azert irnak lassu es eroforrasigenyes kodot, mert ezt adja a nyelv. Az atlagos programozo ezt tudja belole kihozni.

Egy átlagos programozó a C-ből memleaket vagy buffer overflow/underflow-t hoz ki. C++ hasonlóan. Az, hogy nem értesz egy nyelvhez, nem a nyelvet minősíti, hanem téged.
A D nyelvhez nem értek, szar kódot írnék benne. Tehát a D nyelv szar!!!

Erdekes kovetkeztetes, hogy ha masok lassu es eroforrasigenyes programot irnak Javaban, akkor szerinted en nem ertek a nyelvhez. Sajatos vitastilus.

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

"A Javat viszont úgy írták meg, hogy a best practices egyben lassú megoldásokat is eredményez."
Mikor programoztal te Javat utoljara? 16 eve tenyleg lassu volt a runtime. Ma mar nem.

na ne már :P
létezik open source, beágyazott platformokon működőképes .net futtatókörnyezet, amit oda portolsz, ahova nem szégyelled. egyenesen a gonosz, megátalkodott microsofttól...
és szintén létezik keresztplatformos fordító c#-hoz.

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

Én csak egyet ismerek: http://netduino.com/ Nekem nem tűnik micro pc-nek.

--
Don't be an Ubuntard!

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.

Most gondolkodtam el, hogy kipróbálom. Mekkora lenne már ez egy FPGA-ba ágyazott SoC-n...

bizony, nem volna rossz dolog. a bme-n önlab feladatként láttam a .net micro framework microblaze-re portolását kiírva, de nem tudom lett-e már belőle valami...

Tudom, azon a tanszéken vagyok én is, meg ágazaton, csak más a témám :-).
Szerintem még semmi.

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.

+1

D tulajdonképpen egy újratervezett C++.

Vannak akik a Javara is ezt mondják. Ezek azok az emberek, akik nem értik a C++ lényegét.
----
Hülye pelikán

Mi a C++ lenyege?

Na igen, erre én is várom a korrekt választ :)

A C++ lényege az, hogy erős eszközt adjon a programozó kezébe, amivel hatékony és karbantartható szoftvereket állíthat elő.
----
Hülye pelikán

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

A D nyelv pont a Java ill. C# nyelvi kepessegeit otvozi a C/C++ sebessegevel.

Egy nyelvnek nincs sebessége. A megvalósításainak van, és ezek jelentősen eltérőek is lehetnek. pl.: http://speed.pypy.org/

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.

Erdekes, hogy a HipHop-ot hoztad peldanak. Pont ebben a honapban volt rola hir (lehet itt a hupon is), hogy a facebook most PHP VM-et ir es bytecode-ra fordit. Tervek kozott van, hogy ezzel valtjak ki a C++-ra forditast. Arstechnica cikk

Ez azért van, mert a HipHop nehezen karbantartható a cikk szerint. Pedig C++-ban írták jó mérnökök. Pedig ugye közismert, hogy C++-ban könnyen lehet karbantartható kódot írni. Ez a lényege, mint kiderült.

Félreértetted a cikket, a PHP kód karbantartása vált nehézkessé.

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.

Ez miert nem igaz a Java-ra, vagy a D-re?

Egyszeru a valasz: mert azoknak a nyelveknek nem ez a lenyege.

Azért, 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.
----
Hülye pelikán

Mik azok az ideologiak, amik menten megterveztek a Java-t es a D-t es ami miatt ezek a nyelvek nem teljesithetik a "hatékony és karbantartható szoftvereket állíthat elő" kitetelt?

Még mindig nem fogtad fel, úgy látom. Szó nem volt arról, hogy a Java és a D ne lenne alkalmas hatékony és karbantartható szoftverek előállítására.
----
Hülye pelikán

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?

Régen nekem is ez volt a kedvencem, de most már a Go.

http://golang.org/

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

+1

Milyen igaz! Az Asm lemaradt a listáról. :(

--
GPLv3-as hozzászólás.

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

ojjektív c hát hol vagy? :]

NSLog(@"%@", [ObjectiveC holATurobanVagyTeBorzalmasRettenet]);

hát nem véletlen, hogy pont ott. :)

nekem megfelel! én nem ragadok le a nyelvi sajátosságoknál ;)

Most őszintén, minden irónia és offense nélkül kérdezem, hogy mi az, ami neked tetszik a nyelvben? (Vehetjük ide még az NS* frameworkoket is)

Én idén dolgoztam vele egy ideig, és nem találtam meg benne a szépet, pedig nem voltak negatív prekoncepcióim, sőt.

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?" -=-

Akkor szavazz a Scala-ra :-)
Első 10 évben főként C++-ból éltem, a következő tízben Java-ból, remélem a következő tízben meg majd Scala-ból :-)

Annyira nem nagy élmény, a tapasztalataim szerint.

Egy-két könyvet el kell a témában olvasni, kicsit használni és akkor már nagy élmény.

Lisp

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