Peter Dimov wrote:
Please allow me to present the opposite point of view.
A GUI DSEL that masks the underlying architecture can do more harm than good
How can a cross-platform GUI library not mask the underlying architecture? ...
A stream-based DSEL can be even more deceiving, it not only masks this important principle, but also establishes a false analogy with respect to stream I/O, and can lead a novice programmer to believe that "C++-like" equals "stream-based".
I agree with this. GUIs are not streams. ...
The other important principle that GUI programmers will inevitably need to learn, earlier or later, is that appearance and logic must be kept as separate as possible. (Just ask anyone that has been programming active Web sites.)
The reason that this is true in traditional GUI environments is that there is a tremendous amount of housekeeping and overhead in even very simple interfaces. It makes sense to isolate this code because there is so much of it that has very little to do with the logic of your program. The truth is, however, that the appearance of an application has a great deal to do with its logic. Changes in a program's logic will almost always change its appearance. If you can automate the largely redundant bookkeeping behind a GUI all you really have left is expressing the relationship between your program's logic and its appearance. This is done with a DSEL.
In our domain this means that we must drop the E from the DSEL and concentrate our efforts on supporting the use case where the GUI appearance is described by a _separate data file_ that is not embedded in the C++ code. We can afford to do that, because GUI building is not a performance- critical task.
But then you still have to define the relationship between your program and this external data file. If your logic changes you have to change your C++ code and the external file. Many mistakes that could have been caught by the compiler will be delayed until runtime. For comparison what if in Spirit you had to put your EBNF in an external file instead of embedded in C++?
I have done GUI design in C++ code and believe me, it's a fundamentally flawed approach. ;-) The compile-link cycle can drive you mad.
There are actually two Hello World programs, one that builds the GUI by hand and hence needs to map closely to the underlying architecture in order to 'teach' it by example, and another, that simply reads a GUI description from an external resource (XML is popular these days). We are trying to cram these two introductory programs into one. This is not needed, and can be harmful to both.
My goal with the GUI library I've made is that you only need to know C++ to use it - I don't want our programmers to have to waste their time mastering the ins and outs of MFC - I've already suffered for them :). Again, I don't see how any platform independent library can "map closely" to the underlying architecture. Brock