Java vs. Qt

Programozás - kezdő

Mindig is azt hittem Java lesz a következő nyelv amelyiket meg fogom tanulni és ezt igazolják az álláshirdetések is. Viszont most, hogy kicsit megismerkedtem a Qt-val nagy a kisértés.
A Netbeans után a Qt Creator használata az én gépemen óriási élmény volt a gyorsasága és a sok paletta miatt, és még a végeredmény is szebb (én nem tudtam elérni, hogy a Java alkalmazások felvegyék a GTK stílusát). Úgy vettem ki, hogy most már a license is engedélyezi kereskedelmi használatát.

Célom egy szolgáltatók számára használható komplett platform független ügyviteli rendszer megvalósítása. Nem igazán láttam ügyviteli rendszert Java-ban, bár ez sztem nem feltétlenül jelenti azt, hogy nem ajánlott a használata.

Szóval ti mit javasoltok mikor járok jobban, ha Javat tanulok vagy ha Qt és C++.

  • 5993 megtekintés

( yetii | 2009. 08. 14., p – 21:16 )

Ne haragudj, hogy nem közvetlenül a kérdésre válaszolok, de ha én akarnék bármi platformfüggetlent csinálni, akkor web alapú cuccot fejlesztenék. Szal vagy ruby-t, vagy php-t javaslom :D Ja, és hozzátenném még, hogy a ruby sokkal szebb nyelv :)

Mar amennyire platformfuggetlenek ezek.
Eloszor is bejon a szerveroldali platform. A PHP es a Ruby is hadilabon all bizonyos tekintetben a platformfuggetlenseggel, foleg a 64 bites rendszerek eseten vannak erdekessegek.
A masik kerdes pedig a kliensoldali dolog: bongeszoverziok kovetese, JS motorok nyalanksagainak kovetese.
Valamint weben keresztul nem lehet mindent megcsinalni. Peldaul szamitasigenyes alkalmazasok, valodi MVC architekturat igenylo alkalmazasok, stb.
Vagyis lehet emulalni bizonyos dolgokat, de az mar ganyolas.

Velemenyem szerint mindket emlitett platform megfelel a celra, bar pl 64 bites Windows 7-re nem fordult le az utobbi idobe na Qt, mig 64 bites Java van, es mukodik is.
Java olyan szempontbol jobb, hogy tovabb tudsz lepni enterprise java ismeretek fele (a Qt esetben igye ez nem mukodik, egy platform van es kesz), vagy mobilprogramozas fele.
A Qt mellett szol, hogy nem virtualis gepen fut, igy valamivel nagyobb a teljesitmenye es kisebb a memoriaigenye, mint a megfelelo Javas alkalmazasnak, valamint tobb platformon is nativ megjelenest biztosit.
Amennyiben neked nativ megjelenes kell Javas alkalmazasbol, akkor az Eclipse SWT (Standards Widget Toolkit) projektjet ajanlom: platformfuggetlen widget-rendszer, amely minden platformon a megfelelo nativ widget-rendszert hasznalja, nem ugy mint a swing, ami csak emulalja a megjelenest.
Viszont az SWT Qt alapu widget-rendszert nem tamogat, csak Win32, WPF(folyamatban), Cocoa, es GTK van.

A szerveroldali cuccnak nem is kell platformfüggeltennek lennie, pont elég ha azon a szerveren jól fut, amin megy. A kliens oldalon meg, mint ahogy írta valaki feljebb, platformfüggetlen könyvtárat kell használni, és akkor nem te szívsz a különböző böngészőkkel. Egyébként nem véletlen, hogy mostanában mindenki a webfejlesztést nyomja.
A számításigényes alkalmazásokban igazad van (bár persze van rá megoldás, de nem olyan egyszerűek), viszont a topicindítóban írt ügyviteli rendszerhez szerintem nincs ilyenre szükség.

Még annyit, hogy nemsokára a Qt érkezik a Nokia telókra, szal lehet, hogy fel fogják kicsit kapni azt a platformot most.

( voloferenc | 2009. 08. 14., p – 21:19 )

Van QT-s és GTK-s cucc java-hoz!

( Rackshee | 2009. 08. 14., p – 21:47 )

Bocs az OFF-ért (azaz nem válaszolok a kérdésedre), de azt képzelném, hogy mivel a java nagyon hasonlít szintaxisában a C-hez, ill. a C++ is nagyon hasonlít a C-hez, ezért a kettő között viszonylag könnyű és fájdalmommentes az átjárás. Azaz, ha egyiket jól megtanulod, akkor kis energiabefektetés árán megtanulhatod a másikat is. Vagy csak naív vagyok? (Tapasztalatlan mindenképp!!!!)

( zp | 2009. 08. 14., p – 22:22 )

hékás, a qt mióta programozási nyelv?

>a qt mióta programozási nyelv?

A kérdésed első közelítésben jónak tűnik, de mégsem teljesen az.

Gondold csak el, hogy egy container (collection) hogyan néz ki mezei C++-ban, Qt-tal és Javában. Mezei C++-ban template-eket használsz, míg Qt-tal vagy Javában mindennek QObject/Object az őse, így az egész template koncepció kuka.

Memória felszabadítás szemszögéből a C++ mindent a programozóra hagy (pl. autoptr-t lehet használni). A Qt kijelöl egy utat. A Java kötelező objektumreferencia, felszabadítási és GC megoldást ad.

Ezeken túl Qt-nál létezik a slot és signal koncepció, ami C++-ban nem. Az eredeti kód nem C++, azt a moc köpi ki magából.

A C++, Qt, Java és ezer másik mind jó eszköz, csak másképp. GUI alkalmazásokhoz talán Qt lehet a legjobb, de esete válogatja. Ha az ember nem kezdő, amúgy is kb. 10 nyelvet használ párhuzamosan. Pl. webes dolgokhoz HTML, JavaScript, PHP/Ruby, SQL, általános dolgokra sh, Perl, mezei alkalmazásokhoz Java, C++(+Qt), C, és én még használom a cégünk saját nyelveit is, mert hát elosztott, hibatűrő rendszerekhez ezek nevetségesek.

Hint: nem kotelezo pure c++-ban se template-zni, illetve lehet Qt-ban is template-zni. Akkor megeccer vegyuk at.

Kulonben Qt-nal nem minden osztalynal QObject az os, csak a view/controller osztalyoknal, ahol kell a signal/slot. Egy sima modellnel peldaul nem feltetlen kell QObject.

A moc nem compiler. Ugyanazt a kodot kopi vissza, inkabb csak hozzair a kodhoz. Ezert tud peldaul az automoc eseteben az #include izehoze.moc" mukodni.
-- 


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

Ugy ertettem, hogy nem ket nyelv kozott fordit, hanem csak egy kodgenerator, akarminek is hivjak. Csinal egy csomo segedkodot, ami nyilvan nagyon jo meg hasznos, de ezzel ki is merul a funkcionalitasa. Az eredeti forrassal nem csinal semmit.
-- 


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

A signal/slot miben ter el attol, hogy lenne egy addListener(event, listener) tagfuggvenye az osztalyaidnak a connect helyett, stb. Az, hogy ad egy olyan makrot, amivel lehet MVC strukturat kiepiteni, az nem jelenti azt, hogy ez a nyelv hibaja. Java-ban sincs ilyen beepitve a nyelvbe, csak vannak osztalyok, amelyek igy epulnek fel. API kerdese az egesz.

A signal/slot miben ter el attol, hogy lenne egy addListener(event, listener) tagfuggvenye az osztalyaidnak a connect helyett
Ezek a widgetek közötti kommunikáció két különböző alapkoncepciója.

Jöjjön egy idézet, hogy minek is a moc!

C++ GUI Programming with Qt 4, Second Edition -- chapter 2, section 2

Standard C++ doesn't provide support for the dynamic meta-information needed by Qt's meta-object system. Qt solves this problem by providing a separate tool, moc, that parses Q_OBJECT class definitions and makes the information available through C++ functions.

Valamint egy példa, hogy mit lehet segítségével csinálni, amit a C++ nyelv alapból nem tesz lehetővé.

C++ GUI Programming with Qt 4, Second Edition -- chapter 2, section 5

We can access the form's child widgets using QObject::findChild(): 

QComboBox *primaryColumnCombo =
        sortDialog->findChild<QComboBox *>("primaryColumnCombo");
if (primaryColumnCombo) {
    ...
}

The findChild() function is a template member function that returns the child object that matches the given name and type.

A fenti példával ellentétben sima C++-ban nem lehet egy osztály egy tagját úgy elérni, hogy a tag neve egy sztringben van meg. Ehhez a bravúrhoz szükséges meta-információt a moc gyűjti össze, és generál belőle valid C++ kódot.

A signal/slot es listener kozott semmilyen kulonbseg nincs, csak szintaktika. Ugyanugy MVC-t valosit meg, te mondod meg, melyik objektumok legyenek osszekotve melyik masik objemtumokkal, a szintaktikus kulonbseg az az, hogy a signal es a slot neve tetszoleges lehet, mig mashol a megfelelo listenereket implementalni kell adott interface szerint (es emiatt van tipusellenorzes is nyelvszinten, stb).

Sima C++-ban is implementalhatsz olyan osztalyokat, amik ezt megcsinaljak, csak itt ez elore meg van irva a moc altal keszitett kodban, hiszen ok is C++-t hasznalnak.

Maga a kod, ami fordul, gcc altal fordulo szabvany C++ kod. Csak szamodra lesz kenyelmesebb bizonyos szolgaltatasok hasznalata a moc altal (metainformaciok), amit nem kell kezzel megirnod, mert mar masok megcsinaltak helyetted, ugyanis a C++ RTTI-je minden, csak nem rendes futasidobeli metainformacio es reflection. Javaban van peldaul normalis reflection.

De attol a nyelv nem lesz tobb, hogy van hozza egy olyan eszkozkeszlet, amit mar elore megirtak, es ugyanugy C++, csak kapsz egy preprocesszort meg par elore elkeszitett osztalyt, hogy hatekonyabban hasznald.
Az STL sem resze a C++ nyelvnek (de a C++ szabvanynak igen), es megis milyen jo, hogy van.

"A fenti példával ellentétben sima C++-ban nem lehet egy osztály egy tagját úgy elérni, hogy a tag neve egy sztringben van meg."

A baj az a példával, hogy ezt Qt-ban sem teheted meg... Kivéve, ha QObject::setObjectName-mel beállítottad az objektum nevét. Ezt a moc nem teszi meg helyetted, egyedül az uic teszi meg, a Designerben megadott névre.

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

C++ az egy nyelv. Az egyetlen "container" a tömb.
Az STL (azaz Standard Template Library) egy lib.
A Qt meg egy másik lib.

Egyébkén a container osztályok Qt-ban is template osztályok. És egyáltalán nem mindennek a QObject az őse. (Pl a konténer osztályoknak sem...)

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

Ez így van. De nem kell túlmisztifikálni, a sok slot, signal, emit, Q_OBJECT mind csak makró, a moc meg csak pluszban generál némi kódot. Kb egy az egyben ki lehetne azt is váltani makrókkal, csak kevésbé lennének az osztálydeklarációk szépek.

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

Igen, valóban a Qt containerek template osztályok és nem mindennek QObject az őse. Nálam, mivel csak GUI-s szösszenetekhez használok Qt-ot, mégiscsak így alakul.

Igazából a mondandóm lényege nem is egészen ez lett volna, hanem inkább az, hogy pl. Qt segítségével "Javásítani" lehet a C++-t. Másképp mondva leszűkíthetjük a C++ használatát egy olyan szintre, hogy egy átlag programozónak is oda lehessen adni. Vö: "...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." (Vajon honnan másolhattam?)

Nyilván ettől még a lehetőség ott marad...

(Szerk: Azért az látszik, hogy nem a Qt a fő területem...)

"Másképp mondva leszűkíthetjük a C++ használatát egy olyan szintre, hogy egy átlag programozónak is oda lehessen adni."

Semmilyen leszűkítésről nincsen szó, mindössze egy jól átgondolt, és jól tervezett frameworkről. Ami egyébként egy hosszas evolúció eredménye (hasonlítsd össze a qt3-at a 4-gyel).

A Qt azért tűnik különlegesnek, mert előtte a legtöbb GUI (vagy hasonló bonyolultságú) könyvtár használhatatlanul szar volt.

Illetve összehasonlítva az stl-lel a megfelelő részeket, az is igaz, hogy Qt-ban sokkal kevesebb szabadsága van a programozónak. Egyszerűbb. De attól még C++.

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

> Semmilyen leszűkítésről nincsen szó

Ezért írtam, hogy "Nyilván ettől még a lehetőség ott marad...".

> a legtöbb GUI (vagy hasonló bonyolultságú) könyvtár használhatatlanul szar volt.

Egyetértek. De kíváncsi vagyok, te miben látod mondjuk a wxWidgets és a Qt között a lényegi különbséget.

"De kíváncsi vagyok, te miben látod mondjuk a wxWidgets és a Qt között a lényegi különbséget."

Nyilván nem a funkcionalitást szeretnéd hallani. :)

wxWidgets, gomb összekötése egy fügvénnyel: 


// .h

class MyWindow : public wxWindow
{
public:
     MyWindow(wxWindow* parent, wxWindowID id);

     void onClick();
private:
  	DECLARE_EVENT_TABLE()
};

// .cpp

enum
{
	ID_BUTTON=100,
};

BEGIN_EVENT_TABLE(MyWindow, wxWindow)
	EVT_BUTTON(ID_BUTTON,MyWindow::OnClick)
END_EVENT_TABLE()

MyWindow::MyWindow(wxWindow* parent, wxWindowID id)
{
   new wxButton(this,ID_BUTTON...);
}

Ugyanez Qt-ben: 


// .h

class MyWindow : public QWidget
{
     Q_OBJECT
public:
     MyWindow(wxWindow* parent, wxWindowID id);

public slots:
     void onClick();
};

// .cpp

MyWindow::MyWindow(QWidget* parent)
{
   QPushButton* b=new QPushButton(this,...);

   connect(b,SIGNAL(clicked()),this,SLOT(onClick()));
}

Olyan hatalmas a különbség? Nem. A moc minden ténykedését meg lehetne oldani néhány trükkös makróval? Igen.

moc kicsit talán szebbé teszi a dolgokat. Mondjuk ez se igaz, mert akárhány C++-os embert ismerek (magamat is beleértve), mindnek az első ellenérve a Qt-val szemben a moc, illetve a nem típusos (lényegében stringekkel mahináló) signal-slot rendszer.

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

Úgy értem, ahogy általában szokták. :)
Fordítási időben nem derül ki, hogy a signal-slot jól van-e megadva, és a típusaik kompatibilisek-e. Mondhatod, hogy futási időben kiderül, és ez nem nagy dolog, és bizonyos szempontból igazad van. De attól még nem "szép".

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

Stdlib in Qt... yuyy. Tobb helyen is emlitik, hogy ellenjavallt. http://codepad.org/mfuUlxyv (mielott megkerded: typo).
A masik kis kedvenc a QApplication konzolos app eseten. Csak ezert az egy osztalyert kell a komplett QtGui libet hozzalinkelni... hat. Meg ize. QCoreApplication.
-- 


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

Fogalmazzunk ugy, hogy programozasi nyelvnek ott van a Java es a C++ a ket esetben.

A programozasi nyelvre epulve ott van a Java SE/EE/ME es Qt, mint platform.

A magy kerdes itt az, hogy melyik platformmal erdemesebb nekiallni egy ilyen fejlesztesnek, nem csak a programozasi nyelv.

De van olyan platform, pl. a .NET, amely ala tobb programozasi nyelven is lehet fejleszteni. Ott meg felmerulni a kerdes: .NET, de milyen nyelven? C#, Visual Basic, Object Pascal, managed C++, stb.

( praetor | 2009. 08. 14., p – 22:46 )

tessek szepen megtanulni Javaul is programozni, es C++ban is, es QTt is, es GTKt is. ha lehet, akkor kis .NETet is.

( biboka v | 2009. 08. 14., p – 23:01 )

Qt-Jambi, és akkor mindenki örül :-)

Az egyetlen hiba vele, hogy a Nokiának nem tetszett és átadta a közösségnek, abból meg ki tudja mi lesz...

( yals | 2009. 08. 14., p – 23:50 )

A Java praktikus, mert ha nem működik rendesen a progid, majd ráfoghatod, hogy sz*r a platform.

( Medvesajt | 2009. 08. 15., szo – 14:25 )

Mivel a js keretrendszereket nem a böngésző gyártók konzorciuma készíti, így szerintem felesleges is azon gondolkozni, hogy a Java program, vagy a php+js alkalmazás nyújtja a stabilabb világképet.

Hát nem mókás azon gondolkodni, hogy mondjuk egy IE6-hoz készített honlap (js keretrendszerre gondolok), hogyan is fog működni 5 év múlva, mikor kijön az IE 13?

Én már több évvel ezelőtt belefutottam ebbe a kérdésbe, de addig, amíg egynél több böngésző van a világon, addig csak a többlet munkát generálják most, és az összes kész projektre visszamenőleg is.
Akkor nem értem, hogy mit kell ezen favorizálni? Nem látom át, hogy ki az a mazochista, aki szeret visszafelé dolgozgatni, csak azért, mert megjelent egy újabb böngésző verzió?

Példa:
Miért kell azon rágnod a körmödet, hogy az ügyfeled lefrissít-e az IE 8-ra, mikor az extjs még nem támogatja azt stabilan?
Másik:
Java-ban felületet csinálni nem egyszerű. Sokkal nehezebb, mint html-ben. A JS keretrendszerek is már oda fejlődtek, hogy annyi idő megtanulni, belejönni, mint a Javában felületet csinálni. Akkor megint csak felvetődik a kérdés, melyiket célszerű tanulni?
Talán az xy keretrendszert, amivel tudok felületet csinálni bizonyos böngészőkbe?
Vagy inkább Java, amely egységesebb bármely js keretrendszernél a böngészőbe, desktop-ra, mobil-ra, szerver és kliens oldalra egyaránt?
Harmadik:
ha esetleg pénzre váltanád a tudásod, szerinted melyik fog többet érni: java, vagy xy js keretrendszer+php? Asszem nagyságrendi különbségek vannak ...

A webes világ mindig kész szenvedés, ha egy kicsit is összetettebb, felhasználóbarátabb felületű alkalmazást szeretnél csinálni. Én azt mondom, hogy aki js keretrendszerre támaszkodik (akár mondjuk az extjs-re), akkor az olyan alkalmazást hoz létre, amely éveken belül működésképtelen is lehet.

Java és C++ közötti választásnál szerintem csak a feladat dönthetne. Bennem az alakult ki, hogy altalában C-ben a erőforrásigényes programokat kellene firkálni, míg az üzleti alkalmazásokat Java-ban. Egy ügyviteli rendszer-hez pont a Java illene :)

Azt is figyelembe kell venned, hogy a C-vel olyan rejtett mélységek tárulnak fel, amelyek java-ban nem biztos, így aztán ez is döntő tényező lehet.

Egy picit beszallok ebbe a JS-QT-Java vitaba, de tenyleg nagyon lagyan.

Most inkabb nem elemeznem ki az IBM java meg a Sun Java meg a GCJ kozti hasonlosagokat, mondjuk ugy, tobb kozuk van egymashoz mint az IE-nek meg a Firefoxnak, de nem sokkal.

Tovabba firefox van minden platformra, igy ha a delikvens firefox-only (urambocsa' XUL!) alkalmazast fejleszt, ugyanott van, mint a javanal. Ha esetleg megmarad egy HTML5 standard subsetnel (amire, ha nem ismeri fel a bongeszot, egy jobb lib visszakanyarodik), akkor nagy baja nem lesz az IE13-mal se.

A J2ME-t meg nem is hozom be a buliba, az aztan tenyleg agyonkompatibilis. Mmint ha egyetlen fizikai telefonon futtatod, talan elindul masodszorra is a program, csak nem garantalt. Akkor mar inkabb HTML5.

QT-val az a nagy baj, hogy forditani kell mindenre, kulon. Rogton ra fogsz jonni, hogy azert sokmindent megsporolt neked a java.

Na meg aztan szeretnem latni azt a J2EE alkalmazast, aminek a vegen nem webfelulet van. Marpedig ha a Faces es egy rails (ahogy itt hivjatok: ruby) / django (ahogy itt hivjatok: python) / symfony (hasonlo php -ban) rendszer kozt kell valasztani, mindenki erdekeben gondolkodas nelkul dobom a facest.

Kiveve persze, ha teli vagyok java fejlesztokkel, akik nem mernek a JS-hez nyulni, merthogy az bonyolult.

A bongeszok tobbsegeben a DOM API-ban kulonboznek csak, ill. ott is az IE kulonbozik a tobbitol. Maga a JS nyelv ugyanaz, strict parsing eseten az IE es mozilla azonos.

Tovabba: Qt van pythonhoz is, meg GTK is. Sot, van PHP-hoz is, de az szerintem is gyilkossag...

Egyetlen gaz van: IDE tamogatas. Bar az Ext.JS IDE tamogatasa kezd jo lenni az uj Ext builderrel, de ha neked nagyon IDE kell, bar nem ertem, mi nem tetszik a netbeans-en (azert nezd meg a faces-alapu builderet), akkor hasznalj nyugodtan Qt-t. Igaz, multiknak eladhato alkalmazast inkabb javaban vagy .net-ben leszel kenytelen irni, mert ok erre vannak raallva.

"Nem az a kerdes, hogy altalaban a gyengen tipusos nyelvek miert sz*ok, hanem hogy a JS gyenge tipusosaga miert negativum."

Csak akkor negativum, ha nagyobb rendszereket akarsz benne fejleszteni. Amire eredetileg kitalaltak, igy is tokeletes...

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

Tudom, hogy az ilyen kommentek mellett el kene mennem szo nelkul, mert teljesen felesleges, de nem.

A Javaban van kemenyen 5 darab tipus (forras: java language reference, 3rd edition). Ebbol az intet meg a floatot siman ki kene valoszinuleg dobni, de nem baj. Javascriptben is van 1-2 tipus, de nem errol szeretnek beszelni.

A JS nyelv nem ratyi, vagy ha az, akkor az a lisp is: ebbe a nyelvbe ugyanis makroval lehet atirni oda-vissza, azaz, a ket nyelv kozti kulonbseg pusztan szintaktikai, nem pedig technologiai.

Vannak erosen tipusorientalt JS frameworkok, de errol se kene beszelni.

Hanem hogy mire jo a tipus.

Egyreszt baleseteket uszol meg vele - compiler-szinten ellenorzott interfesz es szignatura
Masreszt a futo program memoriamenedzsmentjet, ezzel sebesseget segiti.

Az utobbira mar ott vannak a JIT-alapu rendszerek, pl. a tracemonkey (Firefox 3.5), amirol ezt szepen elmagyarazzak: http://ajaxian.com/archives/a-detailed-look-at-how-tracing-and-tracemon…

De ott a SquirellFish Extreme (Safari 4) is, vagy a Google V8 (Chrome), vagy a tobbi. Ezek ELEG gyorsak. Upgrade-elj.

A balesetmeguszasra pedig egy hatekony projektmenedzsment, meg iszonyatosan jo kozmegegyezes azert segit.

A sebessegre egyebkent ott a valasz a JIT-es cuccokban. Nem nagysagrendekkel lassabb egy jit-es js engine felett futo program, mint egy java vagy epp .net alkalmazas.

Magunk közt szólva nem vagyok Java specialista, viszont ezek a kérdések soha nem merültek fel egyetlen ügyfélnél se (mármint IBM vagy Sun), viszont a böngészők kérdése annál inkább (azaz szembesültek már ezzel a problémával ők is, nemcsak a fejlesztők)
Elméletileg igazad lehetne a firefox-al (és milyen jó lenne, ha így lenne), csupán az a baj, hogy ma még nem életszerű. Egyetlen ügyfél elé sem lehet leülni úgy, hogy bocs, de csak IE vagy csak Firefox.

Az életszerűség tetten érhető a nagy cégeknél úgy, hogy a mai napig felhúzzák a Microsoft védővonalat (XP), senki nem telepíthet semmit, aztán se firefox, se opera, de még IE klón sem.
A kisebb cégek már nem csinálnak ilyen policyt, de hát Magdika és Petike, akik az Outlook beállításához is rendszergazdát hívnak, szóval ők se fognak harcolni a firefox-ért.

Aki fejlesztett mondjuk extjs-ben, az szintén tisztában van két érzéssel:
- azt a mindenit, egy álom
- a fr***-ba, ezt hogy lehetne vajon megoldani? (és persze hosszú órák telnek el kereséssel)
Magam részéről nagyon szeretem az extjs-t, ha választanom kellene js fw-ök közül, akkor tuti ez lenne a befutó. Viszont ehhez is idő és tapasztalat kell, hiába vagy Master of JS. (különösen a 3-asban jelentek meg izgalmas feature-ök).

Magunk közt szólva egy dolgot nem látok itt felmerülni, az pedig a flash - illetve a flex.
Aki fejlesztett már Flex-ben, AS-ben, az tudja, hogy mindezek itt felesleges szavak, hiszen a Java-nál és a JS-keretrendszereknél kevesebb energiával is tud böngészőbe ügyviteli alkalmazást csinálni (ha van már elég tapasztalatod a gyors munkához :) )
Na jó, aki használta már JavaFX-et, az szintén találkozhat azzal a furcsa érzéssel, hog milyen gyors és egyszerű
UI-t készíteni, és tök mindegy, hogy mi a környezet. Ezzel még nem próbálkoztam mobilra, ha valakinek van ilyen tapasztalata, azt szívesen fogadnám.

Szerintem jól rátapintottál az IDE kérdésre is. Engem legalábbis erősen befolyásol, ha döntést kell hoznom, bár Eclipse-ben még nem találtam olyan feladatot, amit ne lehetett volna megcsinálni - talán a JavaFX, Netbeans-ben sokkal jobb a környezete.

Mindent egybevetve, szerintem egy desktop alkalmazás tovább fog működni hiba nélkül, mint egy js fw-ös site. Hosszú távon gondolkodva, csak ez lehet a fontos - aki ebből él az tudja.

Vízió:
Látni vélem magam előtt a jövőt, mikor egy operációs rendszer nem a sok programból, felületből, ilyen-olyan keretrendszerekből fog állni, hanem egyedül a böngészőből, ami aztán tudni fog mindent. A böngésző nyújtja a felületet, a keretet, a library-ket, és miegymást, így aztán a böngésző lesz maga az oprendszer :)
(és így persze szebb lesz a világ nekünk is)

Amig nem kell WebSphere- be integralnod valamit, tenyleg nem merul fel, hogy a Sun-os JVM picit mas :) De tenyleg kevesebb vele a kompatibilitasi zurzavar.

Egyebkent a "firefox only" programok sokszor nem a bongeszo chrome-jaban (bocs az idegen kifejezesert: cimsor, back-gomb stb) futnak, hanem kozvetlenul a XULRunner felett, amit le is lehet tolteni. Ilyenek a Tomtom desktop alkalmazasai peldaul, vagy a miro player. Nyilvan a problema itt az, hogy kulon ossze kell csomagolnod minden platform xulrunner binarisaval.

Hasonlo celokra talaltak ki az Ext.JS altal is tamogatott Adobe AIR-t, ami picit szerintem el lett rontva, de ott az appcelerator titanium meg meg jopar hasonlo framework.

Flex: A Flex, legalabbis ahogy a mi cegunknel fejlesztik, picit kaotikus, az XML-ek koze agyazott AS fajlokkal. Konnyen lehet, hogy ez egy kivulrol jott bevett szokas, vagy epp a tapasztalatlan fejlesztok igy fogtak neki, es nem tudjak, hogy kene szebben. Persze ebbol aztan csomo bug van. Nekem anno a flexbuilder el se akart indulni, raadasul sajna az egy fizetos szoftver meg mindig tudtommal.

De egyebkent igazad van, a Flex egy lehetseges, jo alternativa.

(Majd - nem feltetlen ebben a threadben - jo lenne kifejteni, mi az, ami az ext.js-be hogyafrancba kategorias :) nem emlekszem vele ilyenre)

Az IE6 nagyon sok cegnel azert van megtartva, mert ebben futnak az alkalmazasaik. Nalunk van olyan alkalmazas, ami konkretan nem is HTML-ben irodott, hanem vmi IE-only XML-ben, kapom is a fraszt tole rendesen :) Persze a progi van vagy 10 eves, kezdunk is rola leszokni lassan, csak nem termel penzt a kifaktoralasa, az emberek ugyis firefoxot hasznalnak minden masra.

En azt gondolom, lassan kezdenek megjelenni azok a feature-ok, ilyen a civilizalt sebessegu javascript, a CSS2.1 lassu de biztos bestabilizalodasa, a szabvanyositott XHR ("Ajax"), talan a canvas, a client-side storage es a webworkerek is ide tartoznak, amik nem fognak eltunni 5-10 even, tehat egy vallalati szoftver atlagos eletciklusan belul.

De lehet en vagyok csak az optimista, es eloreszaladok az idoben :)

( dii | 2009. 08. 15., szo – 17:38 )

Én iszonyúan szeretem a Qt-ét, sokat is dolgozok benne, a következőt tenném a margóra:

C++ nyelvet jól használni egy rövidebb élet kell szerintem. Nagyon nehéz nyelv (vagy csak nekem), a teljes elsajátítása szerintem 4-5 év közepes intenzitással. Mármint, hogy tudd használni és ki tudd használni. Nekem ez a gyakorlat még nincs meg, így állandóan szomorkodva nézek az 1-2 éves kódjaimra, hogy "haj ha tudtam volna akkor amit most tudok". Lehet, hogy lehurrognak ezért a nálam jobb programozók itt, de ez a véleményem. A JAVA szerintem könnyebb és jobban vigyáz rád. Persze oda is tudni kell.

A másik amin érdemes gondolkodnod, hogy mi van a munkaerő piacon. Minden második bokorba keresnek JAVA fejlesztőt, szerintem akár nagyságrenddel többet mint Qt-hoz értőt. Mondjuk a Qt piac is növekszik, nem statisztikailag reprezentatív nézelődéseim alapján úgy becslem, hogy 1 év alatt kb dupla annyi állás hirdetés van most, hogy a Nokia bevásárolta.

Viszont azt is megnézheted, hogy milyen állások vannak. JAVA világban nagy sok a "könnyedebb" meló, vállalati ügyvitel, kliens szoftver, stb. Qt-ben gyakrabban látok C++ veterán szakértelem köré épülő hardcore projekteket, orvosi műszerek, szimulátorok, robotika, tudományos projektek. Szóval sok szempontból keményebb dió, de ha van hozzá kedved... senki ne tartson vissza ;)

Pont ezt vettem észre én is a munkaerőpiacon ezért is szerettem volna Javat tanulni. Erre voltam kíváncsi mikor a topicot indítottam, hogy csak én látom úgy, hogy a Java tanulását a későbbiekben jobban tudom kamatoztatni.

Egyébként a Linuxon Qt- ben elkészített és tesztelt alkalmazás Windows-ra fordításával vannak gondok, vagy rendesen lefordul ? Mert ugye ez sem egy elhanyagolható kérdés.

Amíg nem lépsz ki a Qt keretei közül, addig egy új platform nulla ráfordítást igényel (qmake, make, oszt jónapot). Na jó, mivel Qt-val nem jön installer, ha igazán profinak tűnő dolgot akarsz, akkor installert (vagy csomagot) gyártanod kell.

Értelemszerűen, ha Qt-n kívül más könyvtárat is használsz, akkor lehetnek gondok.
(Viszont ha megnézed mi minden van a Qt-ban, akkor rájössz, hogy elég speciális programot kell írnod ahhoz, hogy ne legyen meg minden ami csak kell.)

A nyelvekről:
C++ nehéz. Talán a legnehezebb. A fentebb írt 4-5 év teljesen reális. Ez persze nem azt jelenti, hogy 4-5 évig tart mire az első használható programod elkészül.
Lehet valamivel úgy dolgozni, hogy nem érted teljesen. Csak C++-szal nagyon nehéz.

A Java könnyű. Olyanra tervezték. Emiatt sokan ismerik alap szinten, anélkül, hogy mély ismeretekkel rendelkeznének. Ellentétben a C++-szal a Java mindent elrejt a programozó elől, így miközben nem érted a teljes rendszert, képes vagy programokat írni. A hazugság ott van, hogy így mély ismeretek nélkül csak szar programokat lehet írni. Ezért van annyi vacak java program, ami dög lassú, és zabálja a memóriát.

Ebből egyébként következik az is amit a munkaerőpiacon látsz:
Profi C++ programozóból kevés van, nagy rájuk a kreslet. Ha jó vagy simán el tudsz helyezkedni.
Kezdő C++ programozóból nincs túl sok, de kereslet se nagyon, mert életveszélyesek...

Profi Java programozóból szintén kevés van, de mivel a Java könnyű, ezért a kezdők is el tudnak helyezkedni...

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

Majdnem teljesen egyetértek a fentiekkel.

Ez a mondatod viszont sajnos téves általánosítás szerintem:
"Kezdő C++ programozóból nincs túl sok, de kereslet se nagyon, mert életveszélyesek..."

Szoktunk kezdőket is felvenni és bennem ennél árnyaltabb vélemény alakult ki.

Vannak, akik nagyon jók és vannak, akik teljesen ótvar kódokat írnak és nem is nagyon lehet őket "átnevelni". A saját tapasztalatom az, hogy a Java egyfajta C++ killer (gyilkos) és sajnos rossz értelemben. Ez azt jelenti, hogy szerintem jó C++ programozó csak olyanból lesz, aki nem találkozott Javával, mielőtt profivá vált volna C++-ban.

Szóval találkoztam már olyan C++ kezdőkkel, akik igencsak profikká váltak, de ezek inkább mérnökök, akik sehol nem tanultak Javát, pláne nem pl. első OO nyelvként.

Tudom, a Javások fújnak az ilyen kijelentések miatt, de az a helyzet, hogy a Java világából egyszerűen nem látszanak azok a szempontok és finomságok, amik kellenek ahhoz, hogy ne barmoljunk széjjel egy C++ projectet.

Én a qmake helyett a CMake-et preferálom (http://www.cmake.org), mert a külső könyvtárakat elegánsabban kezeli, a CMakeLists.txt-je sokkal átláthatóbb. Valamint: ez ügyben a qmake-et nem ismerem eléggé, de a CMake normálisan kezeli az "out of source" build-et minden platformon, ami nagyon jó tud lenni verziókövetés mellett.
--
http://www.naszta.hu

( asch v | 2009. 08. 15., szo – 17:44 )

ha platformhoz hasonlító kinézetet akarsz, akkor lehet még Java+SWT-t is tolni.

( gUHU | 2009. 08. 15., szo – 19:52 )

Egyrészt létezik Qt javahoz is. qt-jambi néven fut.
Másodsorban van javaban írt ügyviteli rendszer. Keresgélj még egy kicsit. Csak az elmúlt 1 évben teszteltem 5 nagyobb rendszert, ami javaban volt csinálva és mondható rá, hogy ügyviteli rendszer. De majd a java expertek megmondják, hogy mi a dörgés.

Vagy ha nagyon akarod magadnak a jót, akkor nézz szét gwt terén. Ott is lehet szép dolgokat csinálni. Pont a napokban hallottam a samrtgwt projektről.

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

( Nickname | 2009. 08. 15., szo – 20:13 )

Kicsit lehet off leszek, de ez is java meg webprogramozás bár lehet ebben ügyvitelezni is, tehát:
Ha már a petárdákat durrogtatjuk, akkor érdemes a ZK Direct RIA - Open Source Ajax -t is megkukkantani, hasonó a gwt-hez, csak jobb :), szerver oldali inkább, bár most a 3.5-ben előretolható - igen, JS-ként - a kliensre sokminden, szóval ez is finom, és hátul java meg xml gui leírónyelv - a la' XUL - , és alá lehet heggeszteni sokminent, mert moduláris, JPA, MVC, skálázható, pushable, meg plugines meg event-s meg asszinkron meg listeneres mindez egy J2EE-s puritán standard AS-ben és persze van hozzá pénzért support is...
Vagyis nem vagy egyedül, ha fekete lyuk szimulációt akarsz írni, és ki kell jusson a fény a unit tesztjeidbe legalább... :)

( uid_13349 | 2009. 08. 16., v – 10:20 )

Bár elég hosszan lett rágva eddig ez a csont, én is csócsálok rajta egy kicsit. Megpróbálok célra tartani.

Én a Java oldalt ismerem, onnan látom a dolgokat. Sztem jó ideig megéri még Java-ba fektetni. Nagyon sok feladat van, ami jól ki tudja használni ezt a nyelvet. Nem könnyű magas szinten művelni, sok plusz energiát bele kell annak fektetni, aki jól akarja tudni használni. (Ez azonban nyilván nem csak erre a nyelvre jellemző.)
Qt Creator - gyorsaság: a Java-s IDE-k nem sebességbajnokok (köszönhetően annak az igen gazdag funkcionalitásnak amit kínálnak és annak a sokféle technológiának, amit támogatnak), de a mai, fejlesztők számára általánosan rendelkezésre álló gépeken ez nem igazán probléma. Fejlesztési feladattól és stílustól is függhet, h milyen funcionalitásában érzheted lassúnak.
Qt Creator - paletta: ez GUI fejlesztési funkcionalitást jelent? Mert akkor a java-s IDE-k hasonló részével kell összevetni. És a NB nem az egyetlen versenyző.
GTK stílus: próbáltad a GTKLookAndFeel-t és nem az nem adott megfelelő eredményt? Örök vita tárgya, hogy miközben a Java adja az eddigi legjobb platform függetlenséget, úgy általában, mennyire várható el a maximális platformspecifikus működés a benne írt UI-tól.

Bár az írásodból az derül ki, h standalone alkalmazást tervezel, sokan minden átmenet nélkül webes fejlesztés keretében folytatják a "melyik a jobb és miért" vitát. A mai világ olyan, h ha igényli az alkalmazás a webes felületet, ha nem, mindent úgy akarnak megoldani. Amire neked figyelemmel kell lenned:
- milyen igény támasztja alá a webes felületet
- milyen feladatot jelent ez neked, programozónak (új techológiák kiértékelése, választása, megtanulása, alkalmazása stb.)

Hogy Java-ban írt ügyviteli rendszerről nem hallottál ne tartson vissza. Rengeteg komoly, komplex rendszer fut Java-n.

IDE vs rendszerkövetelmény témához annyit, hogy ilyenkor a gép munkaeszköznek számít, amire nem szabadna sajnálni a pénzt. Ha veszel egy erősebb laptopot + extra RAM-ot, az lehet akár 300k körül is, de ennek az árát Java programozóként max 2 hónap alatt visszakeresed.

Az engem is zavar, hogy minden programot web-re irnak ha kell hanem, ha nem, pedig mar a vekonykliensek is nagyon erosek. Es szerintem a Swing az egyik legjobban megtervezett GUI keretrendszer, vannak gyerekbetegsegei, de jo tervezessel kikuszobolheto. Egybkent most ismerkedem a GWT-vel, es tok az az erzesem, mintha swing-ben programoznek, egy kis listener itt, egy kis handler ott, tokre tetszik. Ha en most kezdenek valamibe, akkor vagy swinget, vagy gwt-t hasznalnek.
Ja es amit nagyon elfelejtenek a webes alkalmazasoknal, meretezni a szervereket, es amikor 500-an elkezdik hasznalni a rendszert az egesz leterdel, mert nem erre terveztek, es akkor lehet talicskaval hordani a RAM-ot, meg CPU-t a szerverekbe. A vegen 10x annyit koltenek vasra, mintha rendes vekonyklienses GUI alkalmazast irtak volna Swingben.

Swing: +1
Méretezés: +1
Viszont, ha pl. szerver/kliens architektúra lesz, a webes vagy Swinges felhasználói felülettől függetlenül a szerver oldali rész skálázhatósága is megtervezendő. A webes felület technológiájától függően annak működése többlet-terhet (többlet skálázási igényt) jelent. Na persze el tudom képzelni, h ez gyakran nagyobb teher, mint a "tiszta szerver" rész. (Amikor stateful webes kliens van, különösen érdekessé válik az architektúra).

Úgy általában: az elosztott alkalmazások fejlesztésének alfáját vajh hányan ismerik/értik?

Az tetszik meg, hogy magukat komoly 'architect'-eknek tekinto emberek azt hiszik, azzal hogy J2EE, meg EJB akkor mar skalazodik is vegtelenul. Majd kiderul, hogy az osszes EJB ugyanazt a static singleton szar hivja, amiben tolti a program az ido 90%-at, es akkor csodalkoznak, hogy nem skalazodik. Ja es profiling-rol, meg container tunning-rol meg eletukben nem is hallottak.

E jó. A cikk alapvetően igazolva érzi azt, h mindent web-re írnak, de faramuci mondatok kerekednek benne:

Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.
Writing Photoshop, Word, or Excel in JavaScript makes zero engineering sense, but it's inevitable.

Szóval tök mindegy, h van-e értelme, végül úgyis megírják web-re. Tehát tartsunk a tömeggel...
Nem ezt hívják csordaszellemnek?

( emberk | 2009. 08. 16., v – 13:33 )

Szerintem ha érdekel tanuld meg mind a kettőt. Úgyis a feladat határozza meg az eszközt, és nem fordítva. Mindkettő másra alkalmas inkább.

Igaz. Kicsit kései válasz, de még mindig igaz. Nekem mestintet kell delphiben írni. Nem mintha nem lenne rá alkalmas, de egy agyrém a számomra. Iszonyatosan rossz matematikai szempontból. double=real*real, és az egyik real 0.0, de kereken az eredmény szerinte nem nulla. Ezzel egy napot szívtam.

Amikor megírtam C-ben simán nem fordult elő, soha. Amikor át kellet kódolni delphibe, mert naná hogy nem volt kompatibilis a C-ben írt dll-el(függvényhívás jó volt, fastcall-al sem stdcall-al sem, akármit akárhol alakítottam, C-ből vidáman ment). Ezzel az a baj, hogy olyan kódnak kellett lennie, ami 0-kat keresett, amely 3 változó szorzatának eredménye. Most úgy van hogy három vizsgálat van, és külön külön a két változó értéket elemzi, és akkor szorozza össze ha egyik sem 0, de ez kb 0.1-ezrelék. A kód máris bukott a sebességben 20%-ot. Szóval a delphi, elég igénytelen ebből a szempontból, bár tény, hogy nem erre találták ki hanem gui-írásra, de hatalmasat csalódtam benne. Ez csak egy dolog volt ami felnyomta az agyvizemet. A threadkezelése az szerintem közröhej, pláne ha abba képelemzést akarsz betenni, egy kis fft-vel. Szóval ha lehet kerülöm.

"nem volt kompatibilis a C-ben írt dll-el"

Nem tudom a mostani verzióknál ez hogy dívik, de Delphi 7-hez volt kifejezetten DLL fordító. (Szokásos DLL -> Borland DLL).

Hogy ezt mennyire tartom szánalmasnak, az nem fér el ide... :)

Részemről egyébként a Qt-t és C++-t preferálom, Visual Studio-ban, CMake-kel. :)
--
http://www.naszta.hu

( zoner | 2009. 12. 10., cs – 21:05 )

Szia!

Én is most kezdtem el tanulni a Qt-t (C++ már megvan, fejlesztettem Borland C++ Builderben ügyviteli rendszert, tehát van tapasztalat is). Ha igénybe vennél segítséget, szívesen beszállok a dologba.

A Java-t én egyébként nem ajánlom. Maga a nyelv elég egyszerű, de az a sok összefüggéstelen jar nem valami szép.

--
http://sandor.czettner.hu

Múltkor én is nézegettem, a java nagyon jól megkonstruált cucc, bár az én munkámra tökéletesen alkalmatlan (masszív számításigényű matek, az inkább C, és asm, bár ez utóbbiban fejlődnöm kell még), de a Cpp, és a C is akár, ugyancsak koppinthatna ötletet. Csak a Garbage korrektort semmiképp ne. :) Az valami rettenet, hogy mennyire erőforrásigényes, és alig spórol az ember vele egy kevés munkaidőt. Mindegy a lényeg, hogy semmiképp nem mondanám szedett vedett-nek.

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

Függ a problémától is a dolog. Amiről én beszélek az a nem egyszerűen párhuzamosítható feladatok (nem seti@home). Itt a node-ok közötti kommunikáció kritikus (infiniband kell meg MPI), és a program abból áll, hogy komplex mátrixokkal számol elég sokat. Ez meg a Fortran.

Neked talán egy SSD alapú klaszter lehet a megoldás, vagy valamilyen "óriás-memóriás" rendszer. Előbbiek drágák, ezért nincs ilyen gép nagyon, utóbbiak még kísérleti stádiumban vannak.

A fortran a világon a legtutibb nyelv szerintem. (Persze számomra, és azok közül amit ismerek. :) ) Hogy őszinte legyek, én is inkább a fortrant preferálnám, de a cégben nem sokat érek vele, mert a kollegák jelentős része csak a klikkelős nyelveket ismeri. (ezt a borland C++-t ,s a Delphit) Ezért lett C a dologból, ill Cpp, is mert gui is kell.

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

Csakhogy az nem eleg.
Fortan kelloen primitiv ahhoz, hogy egyszerubbek legyenek a nem requrziv hivasok. Ill. Konyebb eldoneteni, hogy mely memoria terulethez biztos nem fog piszkalni mas miatt a kod. Igy konyebb optimalizalnia a forditonak.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ebbe én is belegondoltam, és sejtettem, hogy nem teljesen igaz, mert programozói oldalról ok, de a fordítónak dunsztja sincs a felfogásváltásról. De köszi, hogy ezt te informatika nyelvén meg is fogalmaztad. :)

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

Amig csak C ben is letezo egyszeru dolgokat (kifejezes,ciklus) hasznalod, neha meg ugyesebb is, de egyebkent nagyon nem.
Mintha jvm kepes lenne kulonbozo forditasi egysegek kozott is optimazlizalni, amire pl. gcc. nem kepes.
SIMD utasitasokra jol optimalizalni egyik sem kepes, itt jon kepbe az assembly, amit C be konyebb belegorni.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Kepes optimalizalni, sot, deoptimalizalni is tud ha tovabbra is hotspot marad az a kodreszlet, hogy megprobalja ujabb utvonalakon az optimalizaciot. Tovabba SIMD kodot is kepes (lenne) generalni.
De a gond inkabb az, hogy nincsenek hatekonyan reprezentalva a tipusok a vm-ben. Pl.: a java generic implementacio type erasure-val tortenik, igy futasi idoben nem lehet tipusnak megfelelo hatekony jit kodot generalni, az allando box/unbox muveletek meg jollaknak a processzorral.

( Csab | 2009. 12. 11., p – 16:36 )

A java vs Qt elég érdekes párosítás.

Olyan, mint a Word vs Excel.
Nem igazán konkurens termékek.