Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop <jon@ffconsultancy.com>]

On Wednesday 05 November 2008 15:05:13 Kuba Ober wrote:
> > However, Trolltechs own demos segfault on my machine regularly
> > and KDE is unreliable despite being written almost entirely in Qt's
> > native language. So I would not be so hasty to blame PyQt for Qt's
> > reliability problems.
>
> As a longtime KDE user, I'm very much disappointed by the most recent
> major KDE release, in terms of how much slower it got on my
> not-all-that-old-hardware (an AMD64 Compaq machine running in 32 bits).
> A lot of it comes from the fact that my home directory is mounted via NFS,
> but this used to work a lot better.

I now have a terabyte of ext3, 4Gb of RAM and eight 2.1GHz Opteron cores and 
KDE still runs like a dog, burning only 1 core at a time. This is a fresh 
install on a new machine as well, so distro baggage isn't the problem.

> A typical KDE application literally hammers the filesystem upon every
> single application startup, and it got progressively worse every major
> KDE release. Qt is not an angel in that respect either -- that's about
> the major gripe I have with Qt.

I believe that fixing this is tantamount to Greenspunning managed C++ so I 
don't believe that will ever happen. Qt will be relegated to the embedded 
niche before dying completely.

> As a longtime developer who uses Qt (recently only for open source stuff),
> I do know that Qt's performance in general has continuously improved, and
> they have made real low-level architectural improvements. New KDE releases
> always hammered Qt pretty hard, it was a similar story when KDE 3 came
> out, although the perceived slowdown wasn't as bad (and it was on worse
> hardware).

I think these are all knock-on effects. C++ is an awful programming language 
for high-level work because it is so inefficient (e.g. no GC). Qt is 
effectively C++-only so almost all non-trivial Qt applications are sluggish.

If you build a GUI toolkit on a solid foundation like OCaml (when it gets its 
parallel GC) then GUI programming becomes much easier and much more 
efficient. That is unquestionably the way forward, as .NET has proven. Using 
Qt or C++ is just building on sand.

> As for Qt demos segfaulting: I wonder if that may be due to OpenGL bugs.
> Seriously.

This is a high-performance OpenGL workstation that is used almost entirely for 
scientific visualization using OpenGL. None of our other software has any 
problems, just Qt.

My guess is the Qt code isn't detecting error conditions at startup when it is 
obliged to, whereas glut and SDL are. Moreover, these are old bugs in Qt: I 
saw them years ago as well.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e