JAVA vs. C++ avagy melyik kell nekem?

 ( n0gabor | 2008. július 3., csütörtök - 20:10 )

Tanacsotokat szeretnem kerni. Eddig pythonban programozgattam, szeretnek megtanulni valami komolyabb (es keresettebb nyelvet).
A JAVA es a C++ jott szoba, win-only dolgokkal nem szeretnek foglalkozni.
Hobby szinten inkabb a GUI-s desktop alkalmazasok foglalkoztatnak, tehat az iranyvonal ez lenne. JAVA-ban irt multimedias/desktop programokat viszont eleg keveset latni, foleg linuxon.
Ilyen iranyban a C++ lenne e az alkalmasabb?

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

lehet hogy linuxban azért nem látsz annyi java cuccot, mert hatékonyság is fontos tényező
windowsra írt erősen profitorientált cuccoknál az a lényeg hogy könnyen és gyorsan kész legyen hogy jöhessen a következő melő, és ha egy kcit lassabb elesz vagy egy új gép kell hozzá, hát istenem
ha hobbybol programozol, akkor lehet hogy a c++ mert hatékony, és ott van hozzá pl a qt nagon jó kis doksival, ha nem, akkor a fent irt okokbol a java előnyös
én a c++-t jobban szeretem őszintén szolva, én azt szoktam mondani hogy a java scriptnyelv, mert nem fordít binárisra, persze ez nagyrészt poén, ne harapjatok érte
amúgy http://hup.hu/node/57455 java vs c#

"mert nem fordít binárisra"

Ma' hogy ne forditana binarisra? :^)

_________________________________________________________________________
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

A java compiler a java forráskódból java bytecode-ot fordít, ami natívan fut JVM-en.

De tudtommal tud binárisra fordítani, úgy hogy nem kell hozzá JVM. De lehet hogy tévedek.

Csak egy java bytecode-ot nativan futtatni kepes hardver... :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Aha na erre gondoltam.

mégis általában JVM-en használjuk, erre mondtam hogy nem bináris

Java 1.3 ota un. Hotspot VM van, ami futas kozben nativ kodra forditja a byte kodot.

Ezt JIT fordítónak hívják (Just-in-Time compiler).

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

http://en.wikipedia.org/wiki/Binary_data

De tudom, mire gondolt, csak akartam kotekedni egy kicsit! :^D

_________________________________________________________________________
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

Ez történik, de - én legalábbis - azt hívom natívnak, ami a CPU számára natív (anyanyelvi). Különben mondhatnám, hogy a bash szkriptek is natívan futnak a bash-en. :)

Szerintem C++ .. Java inkabb win-re terjedt el (jojo jon a lehurrogas.. :P), na meg hat nem is a sebessegrol hires, igy sokszor esett mar meg hogy emiatt nem valasztottuk az abban irodott termekeket.
--------
"キャアア!" > The girls scream when you do something ecchi to them. :)

[ironia] jaja, a komoly j2ee appszerverek winen futnak44!!!4441144one [/ironia]

miért válaszolsz egy kérdésre, ha nem értesz a témához?

Nem vagyok nagy varázsló, de eddig php-ban dolgoztam (otthon Zend Frameworköt használok) és sokat tipródtam azon, hogy mire kellene váltani mert a php arra nem alkalmas amit akarok. Pontosabban meg lehet csinálni, de sok favágással jár.

Szóval én is tipródtam, hogy C++ vagy java. Aztán a java mellett döntöttem, mert úgy látom, hogy ebből megélni is lehet.
Sokat nem pötyögtem még benne, de nagyon tetszik. Php után valahogy azt érzem, hogy vettem egy nagy lélegzetet a friss levegőn.

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

miért, php szarszagú?

Nem, csak sokkal körülményesebb benne dolgozni.
Szerintem.

Semmi bajom nincsen vele.

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

az. egy rakat fos a php.

Én úgy fogalmaznék, hogy másra való, mint a Java. Pl. össze kell ütni egy egyszerűbb portált hamar; milyen gyorsan tanulnád meg 0-ról a J2EE-t?

Szerk: vagy adott egy P3 + 256 MByte RAM, kell egy kisebb csoport számára valami szerveroldali cucc. Mit raknál rá?
- SJAS
- Tomcat
- LAMP

beágyazott java appszervert...

Apache + Rails. Mindket esetre.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

pontosan. kivéve, ha Quercus-szal java alatt futtatod :D

ha elég tökös gyereknek érzed magad, hogy több év tanulás után egy szűkebb álláspiacon helyezkedj el akkor c++

ha inkább a hamarabb megtanulható, néha nem jó teljesítménye miatt kizárt, de szélesebb piacot jelentő dolgok a szimpatikusabbak neked, akkor java

Java. És csinálj valami korrekt frontendet benne a cdrecord/growisofs/cdrdao/stb készlethez, a'la k3b!

párhuzamosan mindkettő :)


Andi, really. Take it from me. If I tell you something, I'm usually right.

+1

+1

Fél éves késéssel olvassátok a kommenteket? :D

+1, de azert azt ne felejtsuk el h van kornyezet, library-k is es azokat parhuzamosan ismerni mar azert eleg nyugos lehet, ha az egyiket ismered, mire a masikat is megismered, addig megcsinalsz az egyikben egy mnelot jopenzer
nem?

Én is a C/C++-t javaslom, mert az egy olyan nyelv ami "szinte" bárhova jó (pl PIC-et javaban nem igazán lehet kódolni, robotikában sem igazán hatékony, de ezek annyira speciálisak. Nem hizem hogy fogsz vele találkozni, nekem viszont fontos), és minden irányba jobb fejlődni belőle, viszont nehezebb valamivel, főként a pointerek, és a memóriakezelés, de nem megérthetelen egyáltalán. A Java sokkal kötöttebb. Én is elkezdtem Javat tanulni de nem igazán tetszett sőt egyáltalán nem, de szubjektív okokból. A C.ben és C++ ban sem vészes a gui készítés. Kicsit körülményesebb. Egyébként én azt veszem észre hogy ez a java lendület kezd kicsit lecsengeni, de lehet nincs igazam. Multimédiás alkalmazások terén a C elvileg lényegesen hatékonyabb lehet ugyanis sokkal könnyebben használhatóak benne alacsony színtű kódok (szóval assembly),mint javaban sőt tudtommal java esetén nem is igazán lehet, de lehet ebben is tévedek. Elég hamar abbahyagytam a java használatot. Viszont szerintem C- után sokkal könnyebb lenne javat tanulni, és használni, mint fordítva. Van egy véleményem ami nem feltétlenül igaz, de inkább saját tapasztalat. A C/C++ inkább local gépes fejleszésekre hardveres dolgokra való inkább, a java pedig inkább hálózat, és webes dolgokhoz jobb.

Azert egy Java for AVR fel tudna villanyozni. :) Bar, akar egy BasCOM linuxra is..

Aha ezt én is nézegettem, de azt láttam hogy elég mamut kódot állít elő, elég körülményes a hex-kód készítése. Ami azt illeti a C is elég nagy kódot fordít PICre, de a java-s még nagyobbat arra az Assembly az igazi.

Engem a pic nem erint igazan, AVR parti vagyok

Na én meg AVR-t nem használtam soha. De nem zárkózom el tőle.

Nekem tetszik. A PIC-nel valahogy nagyon takolt erzesem volt a furcsa szelessegu utasitasoktol, meg hogy minden processzorvaltashoz mas programozo kellett. Mondjuk nem is olcso platform. Az AVR meg gyorsabb, olcsobb, es printerport+8 szal drot kompinacioval programozhato mind a legkisebbtol a legnagyobbig.
Nezz szet ezen az oldalon, vannak jo cuccok: http://eposz.eu/page2/page2.html
Ezzel meg nagyon konnyen lehet programozni, de van hozza C is: http://www.mcselec.com/index.php?option=com_content&task=view&id=14&Itemid=41

Tetszik. Utánanézek. Jó kis stuff.

Én egy kicsit érdeklődtem a téma iránt, mint programozó (elektronikához nem értek), sokat olvasgattam mindkettőről, AVR messze jobb. Sokkal inkább processzor szaga van, a PIC valami tákolt érzés (bankváltások, fura utasítások, akkumlátor regiszter, brrrr....). Ingyenes C fordító (gcc-AVR) (de persze van BASIC is). Elvileg gyorsabb is. Programozó szemmel nézve fényévekkel jobb az AVR...

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

+1 egyertelmu!
fenyevekkel!
en is igy vagyok vele!
attol raz ki a hideg amikor vki azzal ervel h a PIC azert jobb mert kevesebb utasitasa van (ha jol remlik 35) es konnyebb megjegyezni... KONYORGOM JAHAAAJJ
aztan utana azzal hogy fejezi ki magat??
latszik h soxor nem igaazan prgozok azok akik ezekkel a kis "mikrogepekkel" foglalkoznak. nagyon, de tenyleg nagyon nem vagjak mirol van szo!
a lebutitott PIC-es basicstamp-et mar inkabb ne is emlitsuk
en is PIC-el kezdtem, de ahogy megismertem az AVR-t el is felejtettem.
tenyleg olcsobb, jobb, stb...
kar h nem mejedtem el jobban ebben a mikroC-es dologban...

JNI?

Sosem próbáltam. De én már maradok a C nél azért megnézem.

Csak hogy a jövőben esetleg elkerüljük az olyanokat, mint "sőt tudtommal java esetén nem is igazán lehet, de lehet ebben is tévedek" (;

Jó értem.Próbáltad esetleg mennyire hatékony? Hardverközeli lesz?

Ha assembly-t hívsz meg vele, akkor minden bizonnyal hardverközeli lesz...

Most lehet hülyeséget mondok, hacsak nem a virtuális gép virtuáis processzorának az assembly-e. Soha nem foglalkoztam javaval komolyabban.

Akkor talán legfőbb ideje, hogy megnézd sosperec linkjét itt alant, mielőtt ez a szálat tovább folytatod (;

ok :) Meglesem.

JNI - Java Native Interface. A celplatform binárisára fordul le, es a celgep futtatja, nem a jvm. Olyan, mint a scripnyelvekhez irt C extensionok.

http://en.wikipedia.org/wiki/Java_Native_Interface
Ez?

Nem igazan az, amire vagyom, de egy megnezest meger. Ujabb lokes, hogy megtanuljak javaul...

"Egyébként én azt veszem észre hogy ez a java lendület kezd kicsit lecsengeni"

Igen, a C#/.net javara.

_________________________________________________________________________
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

javára :D

Nekem a véleményem az hogy anyira gyors a Java mint a C++ nem lessz soha sem, de emiatt önmagában nem elvetendő, egyre gyorsabb hardwareket egyre olcsóbban lehet venni.
A másik hogy van hozzá Java Native Interface aminek segítségével egybe lehet fordítani c-vel, magyarul a hardware függő szolgáltatásokat, vagy teljesítményérzékeny részeket megírod c-ban, az egész rendszert meg Java-ban.

Nekem a véleményem az hogy anyira gyors a Java mint a C++ nem lessz soha sem [...]

Vannak területek, ahol az általánosan megírt Java kód gyorsabb (lesz), mint a C++ kód... persze lehet speciálisan optimalizált kódot is írni (mindkét nyelven), de ehhez több idő, drága programozó és drága rendszertevező kell.

Tehát véleményed lehet ez, de ha nem fedi a tényeket... :)
--
http://www.javaforum.hu

Én a C++-t szeretem, de:

A C++ az egyik legösszetettebb, legnehezebb nyelv, a legelterjedtebbek közül biztosan messze a legnehezebb. Ha belekezdesz, az elején ne remélj túl sok pozitív élményt, főleg, ha előtte nem erős-típusos nyelvvel foglalkoztál.

C++-ban GUI-t csinálni nagyon könnyű, mind Qt-ban, mind gtkmm-ben. Ehhez képest az AWT (Java-s alap GUI toolkit) egy rémálom.

A Java nyelv kifejezőereje sokkal gyengébb, persze emiatt kezdetben sokkal könnyebb használni (ezért is használják annyian (és a sok kezdő szinten megragadt coder miatt van annyi kritikán aluli Java program)).

C++-hoz talán egy árnyalattal kevesebb lib van, mint Javahoz, viszont használhatsz C-s libeket.

Ha tehát viszonylag könnyen akarsz megtanulni egy sokmindenre használható nyelvet, akkor Java, ha szereted a kihívásokat, van benned perverzitás, és szereted irányítani a dolgokat, akkor C++.

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

Egyreszt: nalunk (>50000 fos ceg) Java szoftverek alapvetoen Linux/Unix platformon futnak. Windowson a C# sokkal praktikusabb.

Masreszt en a C++-t mindenkepp megtanulnam, jo alapot ad a Javahoz -- akkor leszel igazan jo Javas, ha pontosan tudod, mi tortenik a hatterben, mit, mikor es hogyan csinal a GC, stb.

En a Javat (es a C#-ot) ket dolog miatt nem szeretem:
- tobbszoros orokles hianya
- reszleges template specializacio hianya

while (!sleep) sheep++;

C++ túl nehéz ahhoz, hogy alap legyen. :)

De azzal egyetértek, hogy ha jó programozó akar lenni az ember, akkor tudnia kell mi történik a háttérben. De ez nyelvfüggetlen (csak pl C-ben szem előtt van, Java-ban kicsit rejtettebb).

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

mit ertesz az alatt, hogy a java kifejezoereje kisebb?

metaprogramming nincs igazabol, de genericek igen [== template], es annotaciok is, amik viszont cppben nincsenek.

Kb amit leírtál. (generic != template, de közel van :) )
Plusz többszörös öröklődés, operator overloading, meg pár apróság.

Nem azt mondom, hogy a Java-ban bizonyos programokat nem lehet megcsinálni, csak azt mondom, hogy kisebb a mozgástér. Ez kezdetben jó (nem kell annyit tanulni), később viszont nehezítheti az ember életét...

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

amikor a jelenlegi szoftverfejlesztesi modellek ket celja a maintainability es a scalability egy nagy rendszernel, akkor nem hiszem, hogy az operator overloading fog hianyozni :)

felertes ne essek, szeretem a cppt, programoztam benne sokaig. es persze tudom, hogy a generic != template, de nuansznyi kulonbsegek vannak, az atlag halando (ertsd pistike szintu koder) nem fogja fel/nem erdekli.

a tobbszoros oroklodes meg igazabol nem hianyzik. c#ban sincs, ellenben vannak interfeszek :) tudom, ki lehet valtani c++ban is ha csinalj egy pure virtual classt es abbol orokolsz, dehat keremszepen. ennyi erovel az operator overloadingot is ki tudom valtani a+b helyett osszead(a,b) -vel ;)

Ennyi erővel a GC-t is delete-tel (;

"ellenben vannak interfeszek"

Szerintem van abban némi ellentmondás, hogy "felesleges a többszörös öröklődés", és közben "az interface jó dolog".

Én legalábbis nem látom a Java interface megoldását annyira másnak mint a többszörös öröklődést, kivéve pár kényelmetlenséget ami a többszörös öröklődés hiányából fakad...

Operátor overloadingnek az az értelme, hogy a programozó típusai szintaktikusan is illeszkedjenek a beépített típusokhoz. Ezzel is csökkentve a karbantartásra szánt időt. Gyakran sokkal átláthatóbb kódot eredményez. (Persze az idióta overloading ellen nem véd semmi, nade az idióta fv elnevezés ellen se véd...)

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

Te azért árnyaltabban szoktad látni a képet. Itt is plz! ;-) Az IF nem csak arra jó, uannyira fontos az implementáció elrejtése miatt is.

"C++-ban GUI-t csinálni nagyon könnyű, mind Qt-ban, mind gtkmm-ben. Ehhez képest az AWT (Java-s alap GUI toolkit) egy rémálom."

qtjambi?

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

Hol élsz? AWT?

És Swing?
És SWT?
És QtJambi?
és folytathatnám..

Ok, igaz, csak AWT-t használtam utoljára...

(QtJambi-t viszont diszkvalifikálom. Az nem lehet érv a Java mellett a C++ ellen. :) )

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

No akkor meg egy erv: Netbeans + Matisse. A Matisse egy igen-igen jo Designer, amivel jol lehet form-okat kesziteni. Vegre kapott az AWT/Swing paros egy jo layout-ot is, amivel mar ertelmesebben lehet dolgozni. Es a Netbeans jol meg van csinalva, ha az ember GUI-s dolgot akar fejleszteni vele. Ugyhogy nem kell azt a Swing-et annyira szidni.

Ettol fuggetlenul en szeretem es sokat dolgozom Qt-vel is.

Csak hogy kiegyensúlyozzak kissé egy véleményt ;-)
Az is fontos, h egy nyelv mellé milyen eszköz támogatás van (minél több technológia, framework, lib stb. gyűlt a nyelv köré, annál inkább). (Személy szerint nem szeretem a NB-t, sem az Eclipse-t, IDEA-t használok, de nem érdemes vitatkozni rajta, mert csak háború lesz belőle ;-) Ne feledjük, h a GUI szerkesztők leginkább röghözkötést eredményeznek. A JBuilder-t (JDeveloper?) kivéve nem nagyon tudok olyat, ami a forráskódból dolgozik és nem pedig xml leírókból. Persze lehet, h le vagyok maradva...
A Swing-gel meg akkor is lehet jól dolgozni, ha nem NB-t (nota bene akármelyik IDE-t) használjuk.

C++-ban sokkal nehezebb gui-t csinalni, mint javaba. Raadasul, a java gui jo esellyel futni fog minden buveszkedes nelkul barmilyen platformon, cserebe a Qt-hez hany plusz Dll is kell? Es akkor meg nem beszeltunk a portolas nehezsegeirol.

Ekkora csúsztatást...
Tehát az a C++ hibája/hátránya, hogy a Qt-hez kell pár dll.
A JAVA-hoz meg egy teljes JRE. Többször akkora tárterület, memória, stb. Azon vitatkozhatunk, hogy ez szempont-e, na de legjobb esetben is 1-1...

Milyen portolási nehézségek? Pl Qt-ban megírsz valamit, csak újra kell fordítani és már megy is más platformon. És nem a Qt az egyetlen cross-platform toolkit...

C++-ban nem nehezebb GUI-t csinálni, (ez mondjuk nem nyelv, hanem lib függő leginkább) viszont C++-ban nehezebb bármit csinálni kezdőként.

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

Qt GPL-es, ami azért elég sokszor komoly visszatartó erő.

Qt nem csak GPL alatt erheto el, mondjuk a masik verzio fizetos. A Trolltech oldalan van errol bovebb info.
--
ahan nem

Koszi a hozzaszolasokat.
Igazabol nem jutottam beljebb, mert amiket olvastam elotte a ket nyelvrol, ugyanazokat olvastam itt is. Igazabol mind2-t kene tudni :)

GUI-t egyebkent mindenkeppen qtjambi-ban vagy esetleg java-gnome-ban csinalnam (esetleg swt), Swing nagyon nem jon be, nagyon lassunak talalom, es igazabol semmilyen oprendszer toolkitjebe sem illeszkedik.
Multimedias/GUI-s programoknak linuxon talan a C/C++ jobban megfelelne, mivel sok lib van hozza, illetve a tobbi program is ebben van irva.

Talaltam is egy nagyon jo konyvet cpp-hez, ami tenyleg cpp, tehat a regi c-s megoldasokat hatterbe szoritja (viszont olvasgattam c-s konyveket is anno, Pere Laszlo - Linux programozas):
Addison Wesley - Accelerated C++ Practical Programming

Erre gondolsz: Accelerated C++: Practical Programming by Example ???

Letöltöttem. Adnak hozzá rengeteg jó példát is.

Én is inkább a két nyelv egyszerre történő elsajátítása mellett tenném le a voksom. Nem hiszem, hogy nagy gondot jelentene neked.

Swing: Mert rosszul kezeled.
Nezd meg, mi van, ha a main() metodusba a form letrehozasa elott csinalsz ilyent:

UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

Mindjart jobb. Azert van, hogy nem nez ki olyan jol a swing-es felulet, mert Metal temaval indul default a Swing. Ettol meg letezik native L&F csak ra kell jonni.

Ez a LookAndFeel... nagyon jó!

Annyi kiegészítés, hogy be kellett tennem egy try blokkba.

Hülye kérdésre, csak ilyen idióta válaszokat fogsz kapni.

A legelső kérdést ugyanis Magadnak kellene feltenned:

Mit akarok..

a. pénzt keresni?
b. webet programozni?
c. multimédiás alkalmazást írni?
d. desktop alkalmazást fejleszteni?
stb., stb.

.. és csak utána rátérni a megvalósítás eszközére.

Mivel gepesz mernoknek tanulok ezert c) es d)
Viszon manapsag nem art a tobblabon allas, ezert nem artana az a) is. :)
b) nem annyira erdekel egyelore.

both

>Igazabol nem jutottam beljebb, mert amiket olvastam elotte a ket nyelvrol, ugyanazokat olvastam itt is.

mit vártál? ezt lehet mondani:D

Kedves Linuxosok!

Mindig is érdekelt, miért utasítjátok el a Java-t, a fenti hozzászólások alapján kezdem kicsit megérteni, és szeretnék tisztázni néhány dolgot.

Először is, az üzleti alkalmazások _nagy része_ jelenleg Java-ban készül, szerver oldalon szintúgy, mint kliens oldalon. Valóban igényel a dolog némi memóriát, de nem árt a 'big picture'-t nézni: ha pl. csinálsz egy hello world servletet, lehet, hogy kell az appszervernek mondjuk 100 mega memória, na de akkor is ennyi fog kelleni (durván), ha ráengedsz 10, 100, 10000 klienst. Mennyi memóriát is eszik egy prefork Apache mod_php -ből mondjuk 300 processz? Kurva sokat, mi? De azért nem csináljátok a weboldalakat ti sem C-ben. Mert akkor sose készülne el. :) Ugyanúgy, ahogy a desktop alkalmazásaitok sem készülnek el soha, mondom ezt, mint hobbi Linux felhasználó.

Komoly probléma, hogy egyesek Java-nak nevezik a gcj-t és a GNU classpath-t, és abból kiindulva, hogy ezzel a tróger környzettel futtatva egy bóvli fájlcserélő klienst (Azureus) vannak problémák, már tudjátok is, mi fán terem a Java, és már nyitjátok is gyorsan Kdevelopban a 26. "myTorrent" never ending C++ projektet.

Minden tiszteletem azé a néhány emberé, aki tud programozni és úgy mondott ezt vagy azt, de Ti is értsétek meg, hogy az emberek 99.999% -a NEM tud C/C++ -ban programozni, nem is fog tudni soha.

Meglepő, hogy a Monot viszont szeretitek annak fényében, hogy az érdekesebb feature-ök 95% -a nincs implementálva Linuxon, nincs normális IDE, ráadásul egy MS-szarság az egész.

Nekem végül is teljesen mindegy, csak csináljatok jó minőségű programokat végre.

Aki AWT-t meg hasonlókat említett, az inkább maradjon ki a thread-ből.

+1

+1 :)


Andi, really. Take it from me. If I tell you something, I'm usually right.

"99.999% -a NEM tud C/C++ -ban programozni, nem is fog tudni soha."

Ezek viszont jobb ha hagyják a Java-t is, mindenki csak jobban jár ezzel...

"Valóban igényel a dolog némi memóriát, de nem árt a 'big picture'-t nézni:..."
Szerveren. De a kérdés desktopról, GUI-ról, és multimédiáról szólt...

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

szerintem a kerdes nyelvekrol szolt... legalabbis a legeleje ;-)

amugy jol jarnank azzal, ha a mostani koderek 80% -a hagyna abba, es menne kapalni.

olyan iszonyatsilany kodokat neztem mostanaban, hogy neha fajt a szemem:)

Ha egész pontosak akarunk lenni, a kérdés arról szólt, hogy desktopra, GUI-hoz, multimédiához melyik nyelvet érdemes megtanulni.

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

+1! :)

Igen valoban az uzleti (web) alaklamazasok nagy resze java -ban keszul es a kodolo droidikat szinte mindig keresnek.

Tudomasom szerint egy nagy java-s projektben legtobb resztvevo "droid", vagyis sok a kodolas abbol al, hogy kurva sok "modult" ossze ragasztanak en hamar meg unam. Tervezgetni lehet jobb moka.

300 process != 300 * akkora memoria, mivel librarikon es magan php interpreteren is osztoznak,ezek egyszer kerulnek be a memoriaba, valoban dragabb egy process, mint egy szal, mert java servlet ugye abbol csinalnak sokat.

Egyebkent tenyleg java eroforras hatkonyabb lehet, nagyobb terheles mellett, mint a php.

Az elterjedt opensource dolgok nagyon nagy resze C/C++ -ban van es lesz is, ezert erdemes ismerni.

"Minden tiszteletem azé a néhány emberé, aki tud programozni és úgy mondott ezt vagy azt, de Ti is értsétek meg, hogy az emberek 99.999% -a NEM tud C/C++ -ban programozni, nem is fog tudni soha."
php -ben lehet talan a leghamarabb sikereket elerni.

Sikerult nekem is eszre venni, hogy buta emberekre kell optimalizalni problemak megoldasat (ok vannak tobben) erre a Java kivallo, es egyut tudnak mukodni a droidok.
Kis szamu fejlesztonel php jobb lehet.

Java -val nehezebb labon lonod magad, de biztos olyanokra akarsz fontos alkalmazas irast bizni akik nem tudnak mondjuk C -ben megbizhato kodot irni?

php azert is jo, mert konyu kijavitani / workaroundolni akkar egy idegen kod problemajat is, Javanal, ha nem ismered sok csilliard reteg library/framework mukodeset amit eppen betettek (van egy jopar) akkor hamar bajban erezheted magad. Rendszerint a Javasok sokkal tobb retget tolnak bele a kodba, mint C/C++ arcok, ami nem kedvez a gyors hiba vadaszasnak.

Forgasd magad jegyeben, tobb baj van a javas cuccokal.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Java -val nehezebb labon lonod magad, de biztos olyanokra akarsz fontos alkalmazas irast bizni akik nem tudnak mondjuk C -ben megbizhato kodot irni?"

A php egy f*s mind a C++-hoz, mind a Java-hoz képest. Mondjuk cache eléggé hasznavehetetlen, mindig újraolvassa az include-olt fájlokat. Aztán relative több java programozó tud valóban kódolni, mint php programozó. "php-ban a hülye is tud"

"php azert is jo, mert konyu kijavitani / workaroundolni akkar egy idegen kod problemajat is"

egészen addig, amíg nem változónév elírás a probléma. A php-nál még warning sincs erre, ha balértékként szerepel.

"Rendszerint a Javasok sokkal tobb retget tolnak bele a kodba, mint C/C++ arcok, ami nem kedvez a gyors hiba vadaszasnak."

A komponenseket önállóan kell tudni tesztelni... Amúgy forrás? Merthogy egy MVC framework esetén van ugye 3, meg még egy, amely leképezi az adatokat az adatbázisra. Ez még mindig csak 4 javában, ebből is a lehető legtöbb nem kézzel kódolt, hanem egy meglévő keretrenrszerre épül (mondjuk JPA, Spring, Struts, és még ezernyi másik). Hol van ebben a "sokkal több"?

C++-nál is van kb. ugyanennyi.

> A php-nál még warning sincs erre, ha balértékként szerepel.

De:
error_reporting (E_ALL);

ok, de akkor ebben a kódban:

function almafa()
{
 $al = 4;
 $a1 = 5;
}

hogy vezetem be a két változót? (egy kis L és az egyes az eltérés) Amennyi kódot írtam már php-ban, sosem kellett olyat írnom, mint a perl-ben a "my" kulcsszó a use strict; utasítás után.

Szerintem te jobbértékkel kevered :P

> hogy vezetem be a két változót?

Az értékadással. Amíg nem adsz neki értéket, addig kifejezésben használva warning-ot kapsz. Próbáld ki.

> Szerintem te jobbértékkel kevered

Nem.

Szerk: rájöttem, mi a gondod: ha nem használod a változódat utána, akkor valóban nem derül ki a fenti balérték-elgépelés. Ebben igazad van. Viszont ritkán adsz értéket változónak úgy, hogy később azt sehol nem használod jobbértékként - ekkor viszont kiderül a turpisság.

Amúgy lényegében arról megy a vita, hogy a PHP fos vagy nem fos. Nos, én ezt a kifejezést nem mondanám valamire, amiben ennyi munka van, ami ennyi eredményt hozott már embereknek. Rengeteg CMS, fórum, mást ne mondjak: HUP, webboltok, sőt stb. Egyszerűen másra való, mint a Java. Mindkettőnek megvan a maga helye.

vegre egy ember aki python felol erkezik
nem hiaba ragtuk akkor a szankat

szerintem mindkettot utalni fogod python utan

ha gui-t akarsz akkor a java felejtos szerintem

Bírom ezeket a kijelentéseket ,-)
Szólni kéne azoknak is akik ezeket írták: NetBeans, IDEA, MagicDraw, Structure101, ThinkFree Office stb.

Eclipseknek mar szoltak, hogy legelabb gui legyen C librarybol :)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Vagy inkább nekik nem szóltak még, h ez a Swing már nem az a Swing ;-)

SWT?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Márminthogy elég jó a Swing ahhoz manapság, h ne kelljen SWT-vel foglalkozni.

Most hogy lgpl lesy a Qt/QtJambi, SWT-vel tenyleg semmi ertelme foglalkozni.

Vna ertelme, csak eggyel magasabb szinten: RCP alkalmazasok.

QtJambi-ban miert nem lehet RCP alkalmazasokat irni?

Tudomasom szerint az RCP alkalmazasok, amik Eclipse Platform ala irodnak, csak olyan UI-t tudnak a platformmal megjelentetni, amelyek legalabb az org.eclipse.swt.widgets.Composite osztalyt implementaljak. A Qtjambi-s Qt widgetkeszlet ezt megteszi?

Akkor már inkább NetBeans platform... Próbáltam az IDEA-soknak is megmagyarázni, h ilyen jó lenn, ha ők is csinálnának iyet, de nem láttak benne fantáziát :-(

a NetBeansben nekem az nem tetszik, hogy swinget hasznal, azaz nem nativ widgeteket, mig a Qt es az SWT szepen meghivja a megfelelo platform widgetkeszletet rajzolasra. Emiatt tenyleg ugy neznek ki az alkalmazasok, mintha nativak lennenek. Sajnos ez a Netbeansrol nem mondhato el, egybol meg lehet allapitani, hogy Javas, Swinges approl van szo. Az AWT mas teszta, az megintcsak nativ widgeteket hasznal, de sajnos annak korlatozott a tudasa.

Na ja. Akinek vagy amikor számít az, h natívnak tűnjön, akkor nyilván más kell. Biztos van ilyen igény, én még nem nagyon talákoztam ilyennel.

Nem csak, hogy tunjon nativnak (emulalja a kinezetet), hanem legyen tenyleg nativ. Szerintem ez fontos, hiszen illik betartani a platform UI Guidejat, nem veletlenul talaltak azt ki. A userek szamara a megszokottsag elegge fontos.

A java generics es a c++ templatek teljesen masok.

Java-ban a generics egy vicc, type erasure-el szimulaljak a tipusossagot, a List List

lesz, annak minden hatranyaval egyutt. A C++ templatek _nem_ generics-ek, sokkal tobbek annal. Az erejere meg csak most kezdunk raerezni. (Illetve 2000 kornyeketol kezdunk.)

while (!sleep) sheep++;

Ehm, "A C++ templatek _nem_ generics-ek". Van olyan nyelv, ami erősebb, mint a C++ például a típusosság és a biztonságosság terén, és ott épp generic-nek nevezik a sablonokat. Szóval kicsit így vicces a megfogalmazás, hiszen ha jól sejtem, igazából az első mondatot ismétled.

C++ es Qt/

Hát ha rám hallgatsz akkor én azt mondanám, hogy itthon és a világban a java fejlesztőket keresik.

GUI -hoz a swing pont elég, persze egy jobb skin nem árt hozzá ->

http://www.javootoo.com/

De ha a jövőre is gondolsz akkor ez RULEZ ->

http://hup.hu/node/55213

--

"No trees were destroyed in the sending of this message. However, a large number of electrons were terribly inconvenienced."

GWT a legkirályabb :) nagyon ász benne weboldalt készíteni. csináltam már benne egy-két dolgot, de sajna még komolyabbat nem. melóhelyen remélem nagyon gyorsan átgondolják a jboss féle richfaces-t és dobják a picsába

LOL

Igen nálunk is pont ez törénik mostanában -> JBoss kikukázva GWT beélesítve :)

--

"No trees were destroyed in the sending of this message. However, a large number of electrons were terribly inconvenienced."

lehet hogy linuxban azért nem látsz annyi java cuccot, mert hatékonyság is fontos tényező

Java is lehet hatékony, sőt: vannak olyan feladatok, ahol hatékonyabb (mind fejlesztési időre, mind teljesítményre). A multimédia nem ez a terület, mivel a JMF eléggé mostohagyerek volt eddig, de a JavaFX majd legyúr mindenki mást jól... :)

Java inkabb win-re terjedt el (jojo jon a lehurrogas.. :P)

A Java elterjedtsége desktopon a legykisebb. Számszerűen a legtöbb a J2ME miatt a mobil eszközök, pénzben pedig a szerveroldali Java, amely legritkább esetben Windows. Ha az első három piacvezető bankot nézzük, akkor minden esetben Java programokon múlik az átutalásod és mindenféle ügyintézésed...

Aztán a java mellett döntöttem, mert úgy látom, hogy ebből megélni is lehet.

Igencsak meg lehet élni... de jobbára csak a Java EE tudással.

A C/C++ vs Java kérdés egyébként önmagában értelmetlen, de a Java által lefedett terület sokkal nagyobb, mint a C++ által lefedett terület, s egyre ritkábban kell kompromisszumokat kötni, ha valamit Java-ban akarsz implementálni.

A .NET/C# csak jót tett a Java vonalnak, ha megnézed, az 1.3 és az 1.4 között szinte semmi újítás vagy fejlődés nem történt, aztán megjelent a .NET/C# és a Java is gőzerővel fejlődik. Nem lenne jó, ha mindenhol Java lenne, de kell még idő ahhoz, hogy a rendszerek között az átjárás és az áthívás olcsó és könnyű legyen - de most sem lehetetlen.
--
http://www.javaforum.hu

_Franko_ -> ez frankó volt :-)

Még egy szó, én már vagy 10 éve azt várom hogy mikor csinál végre valaki olyan processzort ami nativan végre tudja hajtani a bytecode -ot. hmmm talán még megélem azt is :D

--

"No trees were destroyed in the sending of this message. However, a large number of electrons were terribly inconvenienced."

Már megélted (;

Kifejtenéd ?

--

"No trees were destroyed in the sending of this message. However, a large number of electrons were terribly inconvenienced."

http://www.jopdesign.com/

Még többmagos változat is lesz belőle hamarosan (;

Köszi a linket, akkor nem hiába álmodoztam róla -> egyből le is bookmark -oltam :D

--

"No trees were destroyed in the sending of this message. However, a large number of electrons were terribly inconvenienced."

Ha ez megnyugtat, már megélted...
Hallottam embedded környezetben ilyenről, és van(lesz) szerverekbe szánt co-proci.

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

Vazze bírom az ilyen kommentek ahol valamit csak hallomásból állítanak -> értsd: ember tegyél már oda egy linket is, ne nekem kelljen guglizni.

köszi

--

"No trees were destroyed in the sending of this message. However, a large number of electrons were terribly inconvenienced."

Drága: vagy te guglizól, vagy én. Fejből nekem se megy.
Most már tudoed, hogy van ilyen, ha jobban érdekel nézz utána...
Én mégse nézhetek utána helyetted... Tudod miért? Mert ennél jobban nem érdekel. Csak szóltam, hogy van már ilyen...

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

"a Java által lefedett terület sokkal nagyobb, mint a C++ által lefedett terület"

Ezt azért gondold át...
A szerver oldali Java az egyetlen terület ahol nincs C++, de van Java (ez is leginkább a libek hiányának tudható be). Viszont egy rakás helyet tudok sorolni, ahol C++ van, Java nincs.

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

Ne fogd vissza magad sorold csak fel !!!

--

"No trees were destroyed in the sending of this message. However, a large number of electrons were terribly inconvenienced."

Pl a marsjárókat nem Java hajtja. Oprendszert se írtak még Java-ban.
Általában embedded környezetben sincs Java. Hirtelen ennyi...

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

Vazze te tényleg nem szeretsz guglizni, ha ennyit beirsz, hogy java os akkor ezt dobja ->

http://en.wikipedia.org/wiki/JavaOS

Ha meg ezt irod be java embended akkor ezt dobja ->

List of Java embedded products

http://schmidt.devlib.org/java/embedded.html

Ja és amivel kezdted ->

Sun News - Features - Java Technology and the Mission to Mars

http://www.sun.com/aboutsun/media/features/mars.html

Szóval újra a kérdés, fel sorolnád hogy mihez nincs java ?????

--

"No trees were destroyed in the sending of this message. However, a large number of electrons were terribly inconvenienced."

Ok, rossz példák. (Mondjuk hogy ezeken a területeken C++ elterjedtebb mint a Java, azt tartom.)

De ettől még nem lesz igaz az, hogy "a Java által lefedett terület sokkal nagyobb, mint a C++ által lefedett terület".

Bár már ez a kérdés is régen off.

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

A marsjáróval pont mellélőttél. :) Még ott is volt rajta a Java matrica.

Amúgy így van, de én úgy érzem ezen a területen a Java hatalmas fejlődésen esik épp át. Ez egyébként nagyon jó: http://www.sunspotworld.com/

Rengeteg helyen használják a C++-t, bármily meglepő szerver oldalon is. Az tény, hogy enterspájz vonalon a java előretört, de ez korántsem a teljes szoftverspektrum, amiben gondolkozni kellene.

A szerver oldali Java az egyetlen terület ahol nincs C++, de van Java (ez is leginkább a libek hiányának tudható be).

Mondjuk ugye nem a for ciklustól vagy a println implementációtól lesz egy nyelv alkalmas valamilyen feladatra... hanem attól, hogy milyen eszközkészletet ad, amivel piacképes egyensúlyban lehet a fejlesztési ciklus és az erőforrás használat. Java nyelvhez nagyon-nagyon sok ilyen lib van, amelyek ugye alapból platform függetlenek, a C++ esetén pedig minden platformhoz meg kell írni a lib-ek jó részét.
Hozzá kell tenni, hogy a Java VM jó része C++ kód - hiszen valamilyen módon meg kell írni azt a kódmennyiséget, amely platformfüggő, a platformfüggetlen, de teljesítményorientált részek is C++ nyelven vannak megvalósítva, tehát mindig is szükség lesz C++ programozóra... :)

Viszont egy rakás helyet tudok sorolni, ahol C++ van, Java nincs.

Fogalmazzunk úgy, hogy nem tudsz róla... :)
Viccet félretéve: természetesen van olyan hely, ahol nincs Java - hiszen nem univerzális nyelv, megvannak a korlátai és a lehetőségei. Ahogy a C/C++ nyelvnek is. Ez így van jól. A kérdés viszont - szerintem legalábbis - megélhetési szempontokról szólt, és e tekintetben a Java - jelenleg - a lehető legjobb választás. Nincs annyi hozzáértő Java EE programozó, akiket a piac ne tudna azonnal felszívni: egy tucat céget tudok, akik azonnal felvennének embert, ha lenne, csak nincs.
--
http://www.javaforum.hu

"Hozzá kell tenni, hogy a Java VM jó része C++ kód .... tehát mindig is szükség lesz C++ programozóra"

Azért erre ne vegyél mérget :D

The main goal of the Squawk project is to write as much of the virtual machine as possible in Java, for portability, ease of debugging, and maintainability. Squawk aims at a small footprint, it is Java compliant, and is CLDC 1.1-compatible.

http://research.sun.com/projects/squawk/

--

"No trees were destroyed in the sending of this message. However, a large number of electrons were terribly inconvenienced."

Research project, azaz nem cáfolja _Franko_ állításait...

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

Azért erre ne vegyél mérget :D

The main goal of the Squawk project is to write as much of the virtual machine as possible in Java, for portability, ease of debugging, and maintainability. Squawk aims at a small footprint, it is Java compliant, and is CLDC 1.1-compatible.

Ismerem, de ez egy J2ME projekt, és a CLDC lényege teljesen más, mint egy Swing GUI vagy egy EJB konténernek. Fog még maradni C/C++ kód bőven a JVM alatt... :)
--
http://www.javaforum.hu

Persze, hogy fog maradni, de ez alapján azt gondolom hogy ha akár sok év alatt is, de az lesz a tendencia hogy a JVM megvalósításba azért egyre több java kód fog "beszivárogni".

--

"No trees were destroyed in the sending of this message. However, a large number of electrons were terribly inconvenienced."

főleg ha az irány az hogy a cpu/memórialimitált kis eszközökben c++ -> java irányban kísérleteznek.

főleg ha az irány az hogy a cpu/memórialimitált kis eszközökben c++ -> java irányban kísérleteznek.

Inkább kevesebb, mint több sikerrel... :)

Alapvetően az a probléma, hogy a JVM fizikai CPU-n fut, és minden különböző platformra JVM-et kell írni, amit jelenleg C/C++ nyelven tesznek meg (jelentős méretű közös kóddal). Meg lehet(ne) oldalni Java nyelven is, de ekkor a fizikai CPU-ra kellene fordítani a Java forrást, ami nem lehetetlen, de sokat kell még dolgozni rajta... ugyanis ehhez meg kellene oldani azt is, hogy az operációs rendszerrel (memóriafoglalás, fájlkezelés, stb.) és az ablakkezelővel (tálcán megjelenő ikon, stb.) nem a C/C++ nyelv jelenti a kapcsolatot, hanem a Java - és jelenleg ilyen nincs Java alá (jó, ott a JNI, de akkor ott tartunk, hogy behoztunk egy felesleges réteget a JVM-be :). Szóval nem olyan egyszerű dolog ez, nem olyan egyszerű kidobni a C/C++ kódot és felesleges is.

Ha lesz olyan processzor, amelyik a Java bájtkódot értelmezi (mikrovezérlő már van, ha jól rémlik akkor Atmel gyárt ilyen kiegészítőt), akkor nem kell JVM és minden probléma megoldódik - feltéve, ha addigra lesz használható operációs rendszer Java nyelven. :)
--
http://www.javaforum.hu

Igazából teljesen egyetértek.

Bár az is tény, hogy hozzáértő C++ programozóra is van kereslet. Viszont azt gondolom, C++-ban hozzáértővé válni nehezebb, mint Java-ban.

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

Bár az is tény, hogy hozzáértő C++ programozóra is van kereslet.

Hááát... szoktam figyelni a két nagy IT állásportál kínálatát, a Java a favorit, és jön fel a .NET is elég rendesen... van C/C++ is, de a tizede talán az előző kettőnek.

Viszont azt gondolom, C++-ban hozzáértővé válni nehezebb, mint Java-ban.

Ez attól függ, hogy mit nevezünk hozzáértőnek és mekkora területről van szó... :)

Java esetén ott a Java ME, a Java SE és a Java EE. Ebből csak az utóbbi akkora terület, hogy szinte lehetetlen átlátni... :)

Ha a nyelvről magáról beszélünk, akkor igazad van, a C++ önmagában nehezebb nyelv. :)
--
http://www.javaforum.hu

"Java nyelvhez nagyon-nagyon sok ilyen lib van, amelyek ugye alapból platform függetlenek, a C++ esetén pedig minden platformhoz meg kell írni a lib-ek jó részét."

Ki brobaltad mar, hogy mennyire platform fuggetlenek ?
C++ -t csak ujra kell forgatni, ket kulonbo architektura eseten. (persze, ha asm mentes)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"C++ -t csak ujra kell forgatni, ket kulonbo architektura eseten. (persze, ha asm mentes)"

Valami U-val kezdődő országban biztos így van, a valóság egész más. Linuxon írtam egy programot C++-ban, és mégsem fordul a mac-emen.

Macked es Linuxod kozott csak az architekura a kulonbseg ? Mert en azt mondtam, ha az ter el, nem azt, hogy mas platform :)
Tudni kell ugy kodolni, hogy az OS valtas se legyen problemas, csak olyan libre epitesz ami van mindenen.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"csak olyan libre epitesz ami van mindenen."
Nem vagyok hozzáértő, de az idézett kijelentés mennyire állja meg a helyét a napi gyakorlatban? Nekem az a sejtésem, hogy a feladatot azzal oldod meg, ami van, amit ismersz, amit tudsz használni. Feltehetően sok lib van, ami hasonló, vagy ugyanolyan dolgot valósít meg. Gondolok itt például grafikus elemekre, widget könyvtárakra. Biztos, hogy fejlesztéskor azt a grafikus gyűjteményt választod, ami sok másik architektúrán is rendelkezésre áll és nem azt fogod választani, ami adott esetben létezik egy maréknyira, de kiválóan használható a céljaid megvalósításához?
--
unix -- több, mint kód. filozófia.
Life is feudal

Linuxon olyat nehezebb talalni, ami nem cross-platform.
Konyebb olyan OS/ARCH part talalni amire nincs sun jvm.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Es azokon van grafikus felulet?
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

van.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ukrajna? :P
--
unix -- több, mint kód. filozófia.
Life is feudal

java-t szerintem könnyebb tanulni, pláne ha valakinek új az oo.
Gyorsabban is megszokja az ember benne az absztrakciót :) ...vagy hogy úgy mondjam előbb lesz kerek általa a világ.
Emellett több mindenre is használható, applet, jsp, mobil, stb... , főleg ha valaki webre is dolgozik..., php munkák mellett 100% hogy java-nak állnék neki előbb.
c++ -t majd ha már nagyon unatkozik, vagy ha kifejezetten az az elvárás valahol.

ok, a több minden úgy értendő, hogy amivel egy átlag embernek dolga akadhat. ...ilyen területeken sokkal inkább fejlődik, és támogatják manapság.

Most látom, a java sebességéről már volt szó a hup -on ->

http://hup.hu/node/19308#comment-162569

http://hup.hu/node/19308#comment-162845

--

"No trees were destroyed in the sending of this message. However, a large number of electrons were terribly inconvenienced."

(gyöngyöt disznók elé...)

Azon gondolkozom, hogy a fent tárgyalt nyelvek -összehasonlítva az Erlanggal- vajon mennyire bírják majd a jövő kihívásait (már az Intel is ezer processzormagról beszél)...

Nem hinném, hogy az olyan részben mesterségesen növesztett lufik, mint a Java/J2EE vagy C#/.Net egyhamar kikopnának az iparból (mert marha sok pénz és ezzel együtt érdek van mögöttük). :)
Majd megoldják a maguk módján nyelvi bővítésekkel, keretrendszerekkel, meg marketinggel, meg community-vel (mint ahogy most is).

Nem hinném, hogy az olyan részben mesterségesen növesztett lufik, mint a Java/J2EE [...]

Igaz, hogy belülről nézem és elfogult lehetek, de a Java EE nem mesterségesen növesztett lufi, hanem szükségszerűen megjelent eszköz, amely igen kényelmes, ha a fejlesztő jól ismeri és jól használja.
--
http://www.javaforum.hu

Én meg hadd ne szeressem a csillió szabványával, rétegével, patternjével. Rendes feljesztői eszköz támogatás nélkül meg se lehet "mozdulni" vele (néhány dolgot sikerült végigszenvedni a "hőskorszakban").

Azt nem vitatom, hogy sikerül vele komoly igényt kielégíteni, csak látni a világban más - számomra - elegánsabb megoldásokat is. Még Java berkeken belül is.

(Másik hozzászólásra: blogom nincs, php-ban nem programozok, ellenben jávában webes és háromrétegű alkalmazásfejelsztésben dolgozok néhány éve.)

Én meg hadd ne szeressem a csillió szabványával, rétegével, patternjével. Rendes feljesztői eszköz támogatás nélkül meg se lehet "mozdulni" vele (néhány dolgot sikerült végigszenvedni a "hőskorszakban").

Érdemes lenne mostanában egy pillantást vetni rá... az annotációk megjelenésével annyira egyszerű lett, hogy nagyon... :)
--
http://www.javaforum.hu

(És azzal építsek komplett alkalmazást... ;) )

És azzal építsek komplett alkalmazást... ;)

Nem... de sok időt és energiát lehet megspórolni, ha XML helyett annotálsz... :)

A javaforum.hu portált Java EE 5 technológiával fejlesztem (már egy éve :), és nem bántam meg.
--
http://www.javaforum.hu

+1 és a fentebbiekre is.

hát, programozz egy évet PHP-ben, és minden este imába foglalod az összes j2ee developer nevét :)


Andi, really. Take it from me. If I tell you something, I'm usually right.

++

miért lenne a j2ee mesterséges lufi? miben akarsz te egy, a saját blogodnál komplikáltabb rendszert megírni? php-ben?


Andi, really. Take it from me. If I tell you something, I'm usually right.

http://furryland.org/~mikec/bench/

előszöris a programozói tudás a lényeges, és itt egy fajta gondolkodásmódot értek, nem annak a képességét, hogy be tudom írni sprinf("hello world"); általában általános célú nyelveket használunk, szintaxisuk is, logikájuk is hasonló egymáshoz, ezen szerintem nem érdemes vitatkozni. aki meg tud programozni egy feladatot, nem fog fennakadni rendszerek "csekély" külömbözőségén.

végül is, minden fajta program egy számára adott környezetben fut, és a végén rendszerhívások vannak, a rendszerhívások végrehajtásának minősége egy adott környezeten belül állandó, vita csak a hívás módján lehet. nyilvánvaló, hogy egy interpretált nyelv esetében ez nem optimális. Az sem optimális, hogy nagyobb teljesítményt igényel egyes esetekben az alkalmazás GUI futtatása, mint maga a végrehajtandó hasznos feladat. Ez szükséges rossz, mert a felhasználónak rossz szokásai vannak.

Az, hogy egy feladat megoldása nem optimális, nem baj, ha ez nem válik zavaróvá, pl. ha egy program emberi reakció időn belül, kb 0.2 sec képes választ produkálni a felhasználó ténykedésére. ma már sokszor ez sem teljesül, és az sem zavaró ha az akarmi.com 12 helyett 15 másodperc alatt jön be.

A döntő inkább a rendelkezésre álló környezet és az alkalmazás célja. Pénzt meg mindennel lehet keresni, hovatovább vannak más szakmák is, ezen sem érdemes vitatkozni. Ha valamin nem lehet valamit megcsinálni, azt enm érdemes erőltetni. Telefonra sincs perl, de van java, pc-re meg minden van. Kérdés, minek, de legalább van...

Szerintem alkalmazások el nem készültének egészen más okai vannak (szerintem anyagi) mint a nem megfelelő eszközválasztás. Azon sem érdemes vitatkozni, hogy hobby programozók hobby projectjei nem készülnek el. Ezért ezt mégse kérjük számon rajtuk, szerencsére a világot nem ez mozgatja.

Azon viszont már érdemes vitatkozni, hogy a programozók miért nem tanulnak meg rendesen programozni, mert akkor tudnák, mi mire való, és mit hogy kell megoldani, a felhasználók meg megtanulhatnának végre rendesen felhasználni, (ha máshogy nem, legalább a saját kárukon) kezdhetnék ők is ugyanezzel. Ennek lehetne egy olyan hozománya, hogy a megrendelő nem fizet sz*rért, és senki nem tudna senki átvágni. Ennek lenne egy olyan hozománya hogy minden működne és nem lennének ilyen viták.

Iszonyatos butasagokat csinalnak a linkelt tesztben. Ures ciklus sebesseget tesztelni? Semmi koze nem lesz a valos elethez.

while (!sleep) sheep++;

a nyelv belső mechanizmusainak a sebességét méri, mert külső nincs, alkalmazástesztnek ott a valós élet, és ez is ráfejel az előbbi gondolatra: meg kell tanulni programozni, felhasználni, pékeknek sütni, satöbbi :)

http://hu.wikipedia.org/wiki/Programoz%C3%A1si_nyelv

innen kiderül, mi mire jó. kb, hozzávetőlegesen.

Amúgy meg egy adott személy minél több képességet állít magáról, annál eladhatóbb a munkaerőpiacon. Ha ez volt a kezdő kérdés eszenciája, hogy mit állítsak magamról, hogy pénzt keressek? Sok pályakezdő (programozó) számára jó kérdés ez :)

Vagy oldd meg a problémát (legyen a te titkod miként). Sokszor ez is elég a sikerhez.

kitünő példa az iFart - nem hiszem hogy sokat filózott a mókus, hogy "jajj ezt most JAVA-ban vagy C++ ban írjam meg, esetleg turbo pascal, jajj" ahoz képest hogy mások nagyságrendekkel többet filóznak nagyságrendekkel kevesebb sikerért.

Egyiket sem tudod kihagyni.
--
CCC3

Sőt, szerintem nem is meghatározó, vagyis nem ez a meghatározó.

IMHO a legfontosabb, hogy tudj objektum-orientaltan tervezni es megvalositani software-t. Tokeletesen mindegy milyen nyelven. a Java es a C++ egyarant jo alap ennek elsajatitasahoz. A Java talan jobb, mert ott nem kell (feltetlenul) foglalkoznod pl. a memoria-felszabaditassal meg egyeb, a szoftver lenyeget nem befolyasolo problemakkal. De mint mondottad volt, a Python-t mar elsajatitottad valamilyen szinten.
Meg egyszer szeretnem kihangsulyozni, hogy az _elmelet_ a lenyeg es nem a nyelv.. Ez foleg akkor igaz, amikor van a birtokodban egy relative nagy project, amihez hozza kell adni valamit, vagy esetleg megvaltoztatni azt, na ekkor jon kepbe az eszszeru tervezes (hogy ne eld at ismet, milyen a farok masik oldalan lenni :)). Ha ezt tudod es elsajatitottad, a topicban szereplo kerdes fel sem merul benned, mert teljesen mindegy.
---
"A legjobb dolgok az életben nem dolgok."

JAVA-t tanulom a topicnyitas ota. Koszonom a segiteseget a valasztasban.

Ha GNOME-on akarsz programozni, akkor C, esetleg C++ (kevesebb),
ha KDE-n akkor a C++ Qt-s kiterjesztése.

De lehet java-ban is programot írni. Az azureus / vuze és a jdictionary is java programok.

A c++ ugyan gyorsabb, de a java sem használhatatlan.
Nem mindig kell a sebesség.

Fentebb írtam komolyabbakat is. Az azureus felülete, legalábbis régen, SWT-s volt, tehát inkább egy öszvérnek, mint Java programnak nevezném (csakúgy mint az Eclipse-t).