Tonight Henning and managed to make a release of mGTK. We call it a prerelease becase we have not written any documentation, the release has only been tested on my laptop (running Debian Sarge/Sid), and we have not made a Windows port yet. Still, now you can download it from Sourceforge and play with it.
7 thoughts on “mGTK pre-release 0.93”
While GTK bindings in itself is very useful for ML, I am wondering whether there is an opportunity to reach a higher level of GUI coding with ML. As far as I can understand your bindings, they present a more or less one-to-one mapping of the existing C api to ML.
How about trying to reach a higher level?
See for instance the Lit Window Library which is an attempt to provide a higher-level C++ GUI library (for WxWindows in this case), providing two new things: automated bindings of GUI elements to (complex) data structures, and use of a constraint system to define GUI rules.
Those two things definately seems like good extensions of the traditional GUI coding. And thinking further along those lines, the next idea could be automatic construction of GUI dialogs to edit (complex) data structures: You basically define a complex data type, pass that to the engine, and it will magically provide a dialog which allows you to edit that data structure.
In other words, use the data structure as a declarative Domain Specific Language for GUI design.
For such an idea to work out, you need a rich type system, and this is where ML kicks in. It has exactly that.
I agree that a higher-level GUI library would be nice to have, and there has been several interesting libraries for both Haskell and SML a newer example is Functional Forms (and slightly dated overview for more Haskell examples). But for mGTK it has been a explicit non-goal to provide a high-level library. Instead we want to focus on giving the SML programmer as much GUI power as the C programmer. That is, we want to give access to all parts of the C API, even the calendar widget.
Only when that goal has been reached will we start to look at making higher-level GUI library. However, if others want to start on such a higher-level GUI library and want to use mGTK as a substrate, then we’ll do what we can to support that efford.
Why not start on the higher level library before? Well, I don’t know about Henning, but for me the reason is that I’d rather try to produce something which is not just another proof-of-concept library.
I think Ken’s approach is the right one, though I will probably want to wait for the high-level, cool interface before I get my head seriously into GUI programming. I’ve always thought that those systems were far too complicated. (E.g., the claim that being a Windows C++ programmer is much more a test of your knowledge of the MFC hierarchy than it is a test of your C++ skills.
Ken wanted me to comment on this, and he was relentless, so here is my comment:
I basically agree with Ken that we don’t want yet another proof-of-concept library. It takes a good amount of work to design a library that has the right “functional feel” (look at the Standard ML Basis Library for an example). As Ken puts it: Making a library that feels “completely right” is something entirely different than making a library that is “good enough”.
In a sense, mGTK is about producing something that is “good enough” with all the
functionality you may possibly need (even a calendar widget), but not about producing something that is completely right for a functional programmer. Our hopes are that mGTK
might be a starting point from which further explorations may lead to a library with
a functional feel (but without the hassle of worrying about functionality at the same time).
I can certainly sympathise with that approach. Full credit for that.
The reason I feel a high level GUI library is interesting is that I think you need a competitive advantage to steal a market. And this advantage has to be substantial.
Ask yourself: Even when you have complete coverage of the C API, you still come up short against the C library, simply because you become out of date too fast. Also, the ML camp will always be behind in regards to XML libraries, network libraries, cryptographic libraries, and so on and so on.
The fundamental problem is that there are so many C people out there, and only so many ML people. If you are trying to compete on breadth and quality, you will always loose.
However, if you compete on efficiency, you have a chance.
So, my take would be to cover as much of the API that is usable in real life. Then go for higher level constructs where there is a chance for a big advantage.
Looking at functional forms, that does have some nice ideas. However, it stills looks too verbose in my opinion. Too much layout fiddling. I believe the computer can do most of the layout itself, and do that fairly decently.
His example with the alarms should be as simple as stating the data-structure:
alarm = None | Time (int, string)
and then one or two lines to bring up the dialog with a nice default layout.
Anyway, talk is cheap. Keep up the good work.
Asger, I understand your point an to some degree I agree with it. But you are far more optimistic about what mGTK could possibly do in the near future than what I am!
I don’t think that mGTK will help SML steal any markets in the near future. What mGTK will do is that it will enable SML to stay on the battlefield. SML has traditional had a strong as an language in education, but this “marked” in under serve attack from Java and C#. MGTK will take away one of the substantial advantages Java and C# have over SML: a GUI library.
The above is sounding a bit more negative about SML than what I really feel. And I’m sure that mGTK will enable interesting research, it already has.
I think there is value to following a dual-track approach: leverage existing — and future — technologies by establishing bindings to active development communities, in this case of GTK+ to ML as Henning and Ken have done with mGTK; and build a novel technology on top of existing substrates that provides well-defined ‘competitive’ advantages.
(Bill Cates has called this the ’embrace and enhance’ strategy, cynics say that should be understood as a ’embrace and choke’ metaphor.)
It appears to me that these advantages in the GUI construction domain could be productivity (more correct GUI functionality per programmer hour) and efficiency (faster and more responsive execution at moderate or no space increases) _simultaneously_. This is not only by attaining a ‘functional feel’ to integrate GUI programming with, say ML programming, but by leveraging and exploiting properties of functional programming: the applicability of caching, memoization, sharing, coalescing and data identification (by hashing) for purely functional (and thus always light-weight memoizable) computations on immutable (and thus always replicable, sharable, and efficiently identifiable) data. E.g., screen displays could be rendered in a compositional fashion from abstract gui states that in turn are ‘views’ of (functionally determined by) some ‘model’ (logical system state), where values are cached, intermediate results memoized, results from different users and different GUI parts shared, and doing so across multiple machines in a network (cache the menu bit map wherever convenient, e.g., both in an applet server and applet clients).
Compare this to Swing-programming (and, I suspect, GTK+ programming etc.), which is brittle, complex and inefficient. How many applications compute and render the same menu again and again, even though it wasn’t changed for years? Probably all of them…
Functional computations can be expressed in any language, say Java or C# for that matter. What is likely to be critical is that certain computations are guaranteed to be easily (read: automatically) recognizable as being purely functional and that certain data are guaranteed to be easily — automatically — recognizable as immutable data, and I suspect this must be the defining principle of a corresponding high-level GUI architecture. But even more important from a ‘competitive advantage’ perspective is that programmers must be able to express (much of) their system — in this case GUI — functionality in a functional style. My experience is that very few people can do that and a very large proportion of them are academically trained in functional programming. Those people can typically program declaratively when and where beneficial in any programming language, but it is interesting that they tend to prefer a functional language, whenever possible. That isn’t so curious. After all, an object-oriented language also makes it easier to express object-oriented designs. But who says GUIs are best described and implemented by numerous stateful objects whose states are interdependent and that get updated by frequently by mulitple concurrent threads, unless one is interested in creating difficult problems that then require clever solutions…