From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,55958fd991db66fe X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-09-15 12:49:11 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!hse-mtl-ppp74279.qc.sympatico.CA!not-for-mail From: Christopher Browne Newsgroups: comp.lang.ada Subject: Re: Advantage of XML based GUI? (was Re: Ada-inspired OS/Language) Date: 15 Sep 2002 19:49:09 GMT Organization: cbbrowne Computing Inc Message-ID: References: <3D7DF095.C5C705BA@acm.org> NNTP-Posting-Host: hse-mtl-ppp74279.qc.sympatico.ca (64.229.208.56) X-Trace: fu-berlin.de 1032119349 2356435 64.229.208.56 (16 [125932]) X-Draft-From: ("nnvirtual:Languages" 259) X-Home-Page: http://www.cbbrowne.com/info/ X-Emacs-Acronym: Energetic Merchants Always Cultivate Sales Microsoft: We've got the solution for the problem we sold you. X-Uboat-Death-Message: ANNOYED BY NETSCAPE. CREW UNMOTIVATED. LEAVE BOAT. U-377. Xref: archiver1.google.com comp.lang.ada:28994 Date: 2002-09-15T19:49:09+00:00 List-Id: After takin a swig o' grog, Marin David Condic 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