Re: dual-language systems increase modularity

[address@hidden]

> This reminds me of a comment Martin Fowler made in his talk at the
> Softpro bookstore in Burlington, MA about a year ago.  To judge how
> well-designed a system is, he applies this rule of thumb.  If the
> system provides a GUI, how difficult would it be to slap on a CLI on
> top of it?  If the answer is, not very hard, congratulations, you have
> a fairly well-designed system.
Interesting comment. It conflates several ideas though.. after all
most GUI programs end up having "actions" that are hooked up to
mouse-clicks and menu-options and buttons that provide obvious CLI
entry points. But good GUI applications also involve "direct manipulation"
interfaces -- where perhaps you are visualizing and clicking on a
vertex of a 3d solid that represents a molecule, or a lozenge that
represents a resource allocation -- how would a CLI go about
providing hooks for those? The fact that application designers
do not provide for a way to map those visual entities in ways
that are user referenceable .. is not a design deficiency -- to me
it often reflects cost/time tradeoffs. There are also mildly
interesting questions to ask about things like "undo" that users
of GUI programs care mightily about and CLI programs only make
passing references to.

> Shriram said at the workshop that his big question was, how do you go
> "from scripts to programs"?

> My question is, how do you go from programs to scripts?  Is it useful
> to explicitly adopt a dual-language architecture as a way to achieve
> greater modularity?

I don't think of this as a dual-language issue. If you are interested
in GUI's I'd have thought that MVC and MVC2 were well known. Having clear
layers
of separation between models and views, and controllers that co-ordinate
their interaction can be done in one, two or several languages.
Architecturally speaking, if you build your systems right, they
can all evolve independently.

W/ any language that provides decent introspection capabilities..
some of this really comes for free. I'll give you an example -- JavaBeans
uses get/set method name prefixes to provide IDE's help in laying
out GUI components. It's not that much of a stretch to imagine say
"action*" methods would be things invokeable by GUI options like I
mention above, and hence there could be a generic layer that could
intercept/log/script calls to such methods.