With a mighty <5k2v86$e2@lyra.csx.cam.ac.uk>,
ljw1004@cus.cam.ac.uk uttered these wise words...
> I think this is a silly debate. You could write it in C++Builder, and
> select the button in the integrated development environment, and click on
> the 'font' button, and select a font for it graphically, without any lines
> of code. So what?
I said something like this a while ago, but I guess nobody noticed.
Code generators for MFC/C++ aren't the only way of doing this. VB did
it a little earlier, Pascal programmers can do it with Delphi - and
this is just for Windows!
Some Lisp programmers have done it, too, but these tools have tended
to be for X Windows. I think that Garnet has an interface builder, but
not all of them are for Common Lisp.
Yes, this is very silly. Pick an app with 400 forms, and you might
find some significant differences, but a simple "Hello, World" app
will tells us _nothing_. That same argument can be used to justify
tools like WinBatch (yep, build your app in a language that makes
Basic look sophisticated! Never mind Tcl...) in just a couple of lines
of source code. It could even justify using assembly language, so that
the object code will be small enough.
When you have 400 forms, perhaps tools like ObjectVision make more
sense, but I don't know if it's still available. Ok, just build the
same kind of abstractions in another language, perhaps by using sexprs
in Lisp (or Prolog, or any language that you can build an sexpr parser
with), writing your forms in your domain-specific meta-language, and
then compile it into, say, Lisp expressions that build the user
interface using your chosen tool (Garnet, Tk, CLIM, whatever).
You could even compile them into C++ code using MFC, OWL, V, or some
other C++ framework. V would give you Windows _and_ X Windows. It
might even give you Mac support, but I don't know if that's been added
yet. Alternately, how about compiling to HTML forms and CGI code (C,
Perl, Java, etc), or just go for Java and the AWT.
The important thing is that you'd have complete control over the meta
language and the abstractions that it uses, the code for the forms
could do whatever you wanted (like specifying validation formats,
compiling reg-exprs to state automata), and because the expressions
are s-exprs, they're easily manipulated, unlike strings. This means
that when you make some fundamental change to your meta language, you
can let the machine to the rewriting.
If you have 400+ forms, this could be a _big_ win. This is isn't an
articifical example, BTW. Some people actually write such apps. If
they use tools like ObjectVision, it's likely that they won't get the
same leverage that a programmer who builds a domain specific meta
language will get. Even for smaller apps, you can still win big, esp
if the effort to build the meta language is small enough, which it
often will be.
Followups adjusted, for the benefit of the perl, python and eiffel
people who don't appreciate this thread. If you know this stuff
already, then I apologise for wasting your time.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
|