Re: Advantage of XML based GUI? (was Re: Ada-inspired OS/Language)

[Christopher Browne <cbbrowne@acm.org>]

After takin a swig o' grog, Marin David Condic <mcondic.auntie.spam@acm.org> belched out...:
> But do keep in mind that to a large extent, the price is already
> being paid. Any GUI already takes up a bunch of resources just by
> being a GUI rather than a command line. When someone builds
> something like Explorer or Netscape, they've got to ride on top the
> OS doing a lot of redundant work. Doing something where the GUI
> engine is also basically a browser means you're consolidating
> functions and probably the net result is you're using fewer
> resources. Isn't Windows already increasingly trying to use Explorer
> as the basis for many OS functions? I think the trend is already
> started and creating an Ada OS or Ada development/execution
> environment that uses XML in some manner as the basis for its GUI is
> just a natural extension of what is already happening in the world.

Let me suggest another possibility, namely that there may be no
significant "price" in this to worry about.

I'll point at GTk's Glade system as an example.

Many (most?) modern applications based on the GNOME application
framework use an XML-based GUI description scheme called Glade.

It can load in, on demand at run time, a fair-sized horde of UI
specifications, including:

 a) A Glade file that specifies the sets of menus that appear at the
    top of the main window;

 b) Many GTK specifications for dialog windows that only get loaded
    occasionally, including:

     advanced-filter.glade col-width.glade exp-smoothing.glade
     mean-tests.glade search-replace.glade analysis-tools.glade
     colrow.glade font-sel.glade moving-averages.glade search.glade
     anova-one.glade consolidate.glade formula-guru.glade names.glade
     sheet-order.glade anova-two.glade correlation.glade
     fourier-analysis.glade plugin-manager.glade sheet-rename.glade
     autocorrect.glade covariance.glade function-select.glade
     print.glade solver.glade autoformat.glade delete-cells.glade
     goalseek.glade random-generation.glade summary.glade
     autosave-prompt.glade descriptive-stats.glade graph-guru.glade
     rank.glade tabulate.glade autosave.glade dialog-stf-export.glade
     hf-config.glade regression.glade variance-tests.glade
     cell-format.glade dialog-stf.glade histogram.glade
     row-height.glade workbook-attr.glade cell-sort.glade
     dialog-zoom.glade insert-cells.glade sampling.glade

With all of these, there is _nothing_ that makes it important that
they be 'compiled' in order to be especially efficient.  They all
represent functions that will get run periodically, and where the user
will _have_ to do some thinking about what to do with the results.  If
it were to take 0.2s to load in the XML file to get the GUI running,
that is unlikely to appreciably injure the "user experience."

Furthermore, for particular UIs that are of particular "performance
importance," nothing prevents you from using some sort of "compiler"
process to transform the XML into native code.

There are compilers for Glade for various languages, including C, C++,
Eiffel, OCaml, Perl, and even (go, figure) Ada95.

You thus generally have a choice:
 a) Load in the XML at runtime, dynamically evaluating and binding it;
 b) Compile it into your code.

Both have advantages and disadvantages:
  -> Compiled code is faster;
  -> Compiled code tends to be bigger (oops);
  -> Compiled code can't be modified at runtime.

The Common Lisp folk have discovered an interesting thing in the realm
of compiling that parallels this; they often like to have both the
ability to compile to bytecode as well as to native machine code.

Native machine code is fastest, and is very valuable for the code that
runs a lot.

On the other hand, bytecode is a LOT more compact.  I found a typical
"factor of five" difference, myself.  Code that doesn't run very often
or in which performance is not critical ought to be bytecode-compiled,
as that provides substantial savings.

There's also another parallel that can be drawn that involves pretty
much the same conclusions:  CORBA.

Most CORBA implementations compile protocol specifications in the IDL
language into native code for the "stubs" and "skeletons" for
marshalling arguments to and from the language's native form into the
form described by the IDL.  In scripting languages, it is not uncommon
for the IDL to dynamically be read at runtime, thus being
'interpreted' in much the same way XML or bytecode would be.

The _exact same results_ fall out.  

If you have a desparate need for marshalling speed, compiled code is
far and away the best way to go.  On the other hand, the compiled
"stubs" and "skeletons" expand into a pretty big blob of compiled
code, so that the speed comes at some cost in memory consumption.
-- 
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://cbbrowne.com/info/languages.html
"I'd much rather punch my timecards with a punch awl and blood
spattered fist than use the Solomon IV "Timekeeper" module."
-- Peter da Silva