Slashdot Mirror
A Taste of Qt 4
Karma Sucks writes "In 'A Taste of Qt 4', Trolltech reveals that it is positioning Qt 4 directly against Java. Qt 4 promises to be smaller and faster than its predecessors and there will be a boatload of new features including support for non-GUI applications and accessibility under Linux using Sun's ATK. More controversial is the introduction of a new and elegant foreach construct. Incidentally, for those still opposed to Qt's moc preprocessor, Havoc has some interesting comments. It is possible the idea will be adapted to provide GObject introspection in the future."
"Trolltech reveals that it is positioning Qt 4 directly against Java."
And what about Mono?
When KDE released version 3.2, there was a noticable speed improvment for most users. Will we get to see another good speed boost when/if KDE moves to QT4? Here's hoping.
*twitch*
excuse me for the following expression :
.. what's the case ?
qt vs java ? WTF ?
this is like comparing a ford vs. titanic.
java is much more than some simple thread/socket apis
and visual components.
java has technologies from j2me to j2ee including
huge transactioning clusters which work with thousands
of clients. show me an qt based application server like jboss.
there are none.
so how could you POSSIBLY compare these things ?
java runs anywhere from sun to x86, you don't have to
compile anything if you switch the platform.
with qt you have to. that's the trouble most users don't want to take.
java can work in a cluster where machines are ranged
x86's to ultrasparcs and Apple's G4's. Qt isn't able
to do it. so
it's hard to write a memory leaking application in java
(i know it can be done, i have seen some "java programmers"
who are experts on it, but usually it doesn't happen),
every forgotten free() or a typo in a c/c++ program can
cause you memory leaks.
it's very hard to get a segmentation fault in java, in the
opposite of that you get a catchable exception which
you can handle as you like, as in c i belive everyone
reading this forum has opened the bloody gdb and looked
"where the f do i go wrong here... ?".
gush. who ever wrote the article should be ashamed a bit.
there is absolutely no point in the whole thing whatsoever.
you may define one define that qt the standard of c++ as
j2sdk is for java, but you couldn't obviously compare a c++
library to the whole java business.
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
A Qt widget set target against the Parrot virtual machine would be lovely.
.Net has well, all that Windows stuff (I'm not a big windows graphics programmer)
Just think.
Java has Swing / Eclipse and the old one whose name I can't remember but I did use it a lot but its 7:30am and the coffee hasn't hit me yet.
A Parrot/Qt set would give Perl, Python, Ruby etc a nice graphics toolkit targettable against multiple platforms. Yes I know about Tk/Tcl and WxWindows.
Uurgh. Must get coffee. And train
regards, treefrog
First, we need to clear up the confustion from the following statement:
"Qt is positioned as superior alternative to Java".
Trolltech cannot possibly mean that. What they meant to say is: "Qt is an alternative to Java when it comes to cross platform client applications using a GUI". While Qt may do some non-GUI things, too, it's totally different from Java (clue: Qt is not a programming language) and from the Java platform (it doesn't come with a VM, it doesn't have its own bytecode, etc...). What remains is that it's an alternative to Java if you want to deploy applications across Windows, Mac, and Linux. Giving Trolltech the benefit of doubt, this is what they meant.
Having done client-side programming for many years, i can see that there is something to that. I once hoped that Qt would develop into a viable alternative because AWT/Swing was so slow.
However, since then Sun has done their homework and made Swing fast (indistinguishable from native, for the most part), and they are continuing to work on performance in release 1.5. There is still a lot of room for improvement. Things like Apple's library caching - where they pre-compile the native libraries and cache the machine code on the hard disk which makes a Java apps start as fast as a native apps, more hardware acceleration for Swing etc.
Once we get performance out of the way (i have not seen Qt, but i assume it's fast), there is nothing Qt could offer that Java didn't do better.
For example, you don't have to deal with c++. Java is not perfect, but it's - yes we can say that in public - definitely more productive than c++, in the same way that c++ is more productive than asm machine code.
Add to that extensive networking libraries, array bounds checking (buffer overflow exploits not possible in java, imagine that), garbage collection, serious instead of optional OO, and the list could go on and on, no recompiling, runs on more platforms than Qt, free deploy license...