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

[Jon Harrop <jon@ffconsultancy.com>]

On Tuesday 04 November 2008 23:06:00 Kuba Ober wrote:
> On Tuesday 04 November 2008, Jon Harrop wrote:
> > You'll just be invoking autogenerated Python code using OCaml so OCaml's
> > class system is only relevant if you want to do some fancy
> > statically-typed shim. I'd forget about that and just focus on making the
> > whole of Qt4 available safely from OCaml in any form first. Even this is
> > an unsolved problem in the OCaml world!
>
> Python bindings for Qt extensively use Python's API. You'd need OCaml to
> provide said API first.

No, you just invoke the existing Python bindings. OCaml doesn't have to 
implement anything except bindings to Python, which are already done.

> > Of those, only core and GUI might be relevant here but the core lacks
> > first-class functions for events and callbacks
>
> Maybe they are not first-class, but the way they've done it is via
> preprocessing using moc and things behave like they were first-class.
>
> In Qt, if you have a user interface dialog box (a form) called MyForm
> with an element named say ExitButton, you'd have this:
>
> class MyForm : public QDialog {
> Q_OBJECT
> 	Ui::MyForm ui;
>
> 	MyForm::MyForm(QWidget * parent) : QDialog(parent) {
> 	  ui.setupUi(this); // calls code autogenerated by UI compiler
>         }
>
> public slots:
>         void on_ExitButton_clicked() {
>            ui.ExitButton->hide()
>         }
> };

Compare with the equivalent F#+WPF code:

  button.Click.Add(fun _ -> window.Close())

> The code is hopefully easy to understand and as you can see you don't even
> have to connect signals and slots manually if you don't want to. All the
> magic happens behind the scenes. It's very easy to use.

I prefer my F# to your C++.

> > > WPF is just another thing, and it's not really portable in any decent
> > > sense of the word.
> >
> > Sure. My point is that you're building on antique technology when you
> > could be building modern technology instead.
>
> With Qt there's a real chance of machine-translating the code to say LISP
> or OCaml or what have you.

Even if anyone ever managed to do that, the result would be an unusable buggy 
mess.

> With WPF, you're stuck with .Net and that's the end of it.

That is not a reason to ignore WPF's design.

> > > Camelia could be run on a 486 system with perhaps 64MB of
> > > memory when compiled using Qt/Embedded. While one can question whether
> > > it's useful or not, Qt has the benefit of targeting all major computing
> > > platforms out there.
> >
> > That sales hype for Qt is just a reflection of the fact that Qt was built
> > on sand using a dying technology (C++). In practice, the world moved on
> > to garbage collected virtual machines for GUI programming years ago. Qt
> > was left behind and is desperately trying to catch up by migrating to the
> > JVM but the JVM is now dying...
>
> Qt has not migrated to JVM. Relevant Qt classes implement parent-child
> ownership, implicit copy-on-write and reference counting, and are used
> just like you would any random collection of things in a garbage-collected
> language. You're also free to use a garbage collector with any C++ project,
> this has nothing to do with Qt.

You'd have to Greenspun managed C++ if you want a real GC for your C++ code. 
You can pull in Boehm but it breaks existing code and is not reliable (hence 
the Mono project are desperately trying to remove it).

So you are not "free to use a garbage collector with any C++ project" at all. 
Quite the contrary in fact: you're completely screwed if you choose C++.

Even industry are running from C++ like rats from a sinking ship:

  http://www.itjobswatch.co.uk/jobs/uk/c++.do

Is that really the trend you want to join?

> > > Using Qt4 in a decent language will be easy once there is a C++ parser
> > > in said decent language.
> >
> > You'll be Greenspunning managed C++ from the .NET world. That's a fine
> > idea if you regard Qt as useful legacy code but I don't see the point
> > myself. Qt will always have a stone-age API and reimplementing managed
> > C++ is a huge undertaking.
>
> This is not about greenspunning anything. Most of Qt code is written in
> such way that the C++-isms are completely abstracted out at the level of
> core classes such as QObject and collections (QList, QVector, etc).

The C++isms are nowhere near being abstracted out. Just look at that code you 
posted above.

> By 
> translating the use of basic Qt primitives (really QObject and collections)
> to whatever OCaml/Lisp/Python/blabla provides, you can very cleanly port Qt
> codebase to another language, and it will look pretty much as if it were
> written in said language.

A triumph of hope over reality.

> > In contrast, you can implement a GUI toolkit in OCaml that far exceeds
> > the relevant limitations of Qt4 with quite easily.
>
> Qt has very few language-inherent limitations that are not abstracted out
> to the core. Whatever other limitations Qt has are design decisions that 
> have little to do with choice of the language.

I was referring to the limitations of Qt itself. Look at this example from one 
of our products:

  http://www.ffconsultancy.com/products/fsharp_for_visualization/demo2.html

That uses a 3D layer with a 2D layer overlaid. The labels are 2D widgets. 
That's trivial with WPF because it renders everything through a single 
pipeline: you just put a 2D widget over a 3D widget. That's impossible with 
Qt its OpenGL widget is completely uninteroperable.

Trolltech are hailing Mathematica 6 as a success story for Qt. Look at the 
Mathematica notebook interface:

http://reference.wolfram.com/mathematica/tutorial/Files/DoingComputationsInNotebooks.en/1.gif

That is one giant OpenGL widget covering the whole window and everything is 
rendered using custom code precisely because Qt does not provide the required 
functionality.

> > > I don't know if I mentioned it, but some time ago I
> > > did a proof-of-concept of machine-translating QObject.cpp and friends
> > > to LISP and it not only worked, but required no moc ;) So I'd say that
> > > as soon as there's a good-enough C++ parser written in OCaml, and given
> > > availability of a basic AI package (to implement a KB and searches), it
> > > should be perfectly doable to translate Qt4 into human-readable,
> > > not-too-bad OCaml.
> >
> > Then the question is simply whether it is easier to write a C++ parser in
> > OCaml along with the translation code and a sane shim over the whole of
> > Qt4 or just replace it wholesale.
>
> Qt has to cover a lot of platform-specific ground. Reimplementing it from
> scratch implies having to fix most of the bugs that Qt folks have already
> fixed. Qt's code base as a fine reference for a lot of platform-specific
> borkedness that Qt's users have run into, and the trolls have fixed.

FUD. Those are design flaws specific to Qt. OCaml+OpenGL source code is 
already portable.

> > I would not regard that as flame bait here. I'm sure if OCaml had decent
> > Qt bindings they would be very heavily used indeed (the OCaml language
> > would excel at GUI programming, which is precisely why so many people
> > here are yearning for such bindings) but Qt4 is nowhere near useful
> > enough to make me want to go back to C++ or any language that does have
> > Qt bindings.
> >
> > From what I've heard, a lot of OCaml programming use OpenGL for GUI
> > programming instead of GUI toolkits.
>
> Show me a generic, reuseable OCaml-written, OpenGL-based common widgets
> such as model-view tables, buttons, editors, tree views, ... Then we'll
> talk.

I've actually implemented most of that in Smoke and Presenta already. We never 
made any money out of it (selling OCaml libraries to OCaml programmers is 
almost impossible) so I am considering open sourcing it all.

> > The type error is reported at the "+." operator because the type was
> > incorrectly inferred to be "int" when the type checker came across the
> > "0" in the first clause. Highlighting the unification points of that type
> > immediately leads the programmer to the point of error. Without this, the
> > programmer has no idea where the error really is.
>
> So, OCaml compiler itself doesn't produce that? It'd be easier to add it to
> OCaml, than to redo it from scratch.

Yes.

> > > > It is a logical progression from building your own GUI toolkit. You
> > > > represent graphics using scene graphs. Everything in an interactive
> > > > session is converted into scene graphs for rendering.
> > > >
> > > > So:
> > > >
> > > >   val pretty_printer : Expr.t -> string
> > > >
> > > > becomes:
> > > >
> > > >   val pretty_printer : Expr.t -> Scene.t
> > > >
> > > > and the resulting Scene.t is fed through a renderer like Smoke.
> > >
> > > 1. How exactly do you see the pretty_printer rendering things?
> >
> > Easiest for me to answer by just posting our code. Here is the code from
> > the current version of Smoke that typesets paragraphs of text by
> > overflowing words onto new lines:
> >
> > let rec charsmap = function
> >
> >     | 'f' :: 'f' :: 'i' :: t -> (`CMR, 177) :: charsmap t
> >     | 'f' :: 'f' :: 'l' :: t -> (`CMR, 178) :: charsmap t
> >     | 'f' :: 'f' :: t -> (`CMR, 174) :: charsmap t
> >     | 'f' :: 'i' :: t -> (`CMR, 175) :: charsmap t
> >     | 'f' :: 'l' :: t -> (`CMR, 176) :: charsmap t
> >     | c :: t -> charmap c :: charsmap t
> >     | [] -> []
> >
> > let word string =
> >   let string = charsmap(list_of_string string) in
> >   let aux x (font1, c1) (font2, c2) =
> >     let contours = Cmfont.glyph font1 c1 in
> >     let contours = List.map Contour.make contours in
> >     let g = List.map (Contour.trans (translate x 0.)) contours in
> >     let advance =
> >       if font1=font2 then Cmfont.advance font1 c1 c2 else
> >         Cmfont.advance `CMR 32 32 in
> >     x +. advance, g in
> >   let rec aux2 x = function
> >
> >     | [] -> []
> >     | h1::t ->
> >
> >         let h2 = match t with h2::_ -> h2 | _ -> `CMR, 32 in
> >         let x, g = aux x h1 h2 in
> >         g :: aux2 x t in
> >   aux2 0. string |> List.concat |> ContourGeometry.of_contours
> >
> > let word = memoize (fun _ -> word)
> >
> > let paragraph ~skip ~justify ~width ~string =
> >   let words = List.map word (String.split ' ' string) in
>
> LOL. If you seriously think it's worth reimplementing the wheel for
> a millionth time, go for it.
>
> Qt already can do rendering in OpenGL, so if one wants to do something
> that actually really needs OpenGL, it can be done.
>
> But to just render a paragraph of text? There's code for it in Qt ;)

You have completely missed the point, of course.

You will need to use some modern GUI applications before you can begin to 
understand how they are designed. These screenshots might help:

http://download.infragistics.com/users/AndrewF/WPF-CAB.png
http://www.deepshift.com/images/WPFSampleSourcePosted_B5E0/SNAG000015.jpg
http://www.mismashd.com/BlogImages/EndtoendWPFdemoFamily.Show_E22C/familyshow3.jpg
http://wpf.netfx3.com/photos/articles/images/785/425x307.aspx
http://mdavey.files.wordpress.com/2007/03/lab49wpfequitiestradingdemo.jpg

Note how the GUI elements are arbitrary 2D and 3D graphics. They may be 
overlaid whereas Qt's native and OpenGL widgets cannot be. They have a 
uniform representation whereas Qt widgets and OpenGL content are completely 
separate and uninteroperable. And they can interact with each other whereas 
Qt is completely oblivious to whatever you do in an OpenGL widget.

> Have you ran recent Qt demos distributed with Qt? I'd say they look pretty
> cool in my book.

They would not have impressed me a decade ago, let alone today. Many of them 
don't even work on either of my Debian machines.

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