I received the following comment:
My interest is in understanding the utility of such a proposal in
enterprise context viz: say in Banking
Can Domain driven DSL provide a plausible power user interface for
Banking apps driven primarily by UI screens and backend processes.
MathsDomain specially may have an appeal in that direction.
I responded:
My concept of Domaintalk is that it would not be limited to one
particular platform, but used on a wide range of platforms; in you
example both for the PC, tablet, workstation and mainframe or server,
maybe even phones. Its use would be open ended, limited only by the
users' imagination. A simple example should suffice to convey my
meaning, while not a domain per se, Digitalk's Smalltalk/V used a global
dictionary to open up the OS2 and Windows APIs to the programmer, even
allowing the user to extend the APIs made available; moreover, all of
the OS specific attributes, like handles, were made available. Something
that was not available in ObjectWorks and I am not sure is available int
Pharo. If domains were added to Pharo, then I am sure someone working on
the Pharo internals (VM) could make the OS APIs available and provide a
means to add new ones. Such a domain would not even require exposure of
the OS attributes of the window because the programmer could simply
create their own windows. A word of caution, this would mean that use of
that OS specific domain would limit the application to that specific
platform; however, that is something that I am willing to live with, in
fact, it is something I desire, then I could give the application user
the UI that they expect, the one that matches their platform.
I can see where a banking application could benefit from the SQL Domain
and the Math Domain decimal class and methods, I recall the heavy use of
the decimal data and instructions in the IBM mainframes.
I can even envision a domain that wrapped the windowing API that made it
more usable, so that someone could create another domain that used that
domain to add a language that would make window creation easier, either
a graphical window builder (similar to the WindowBuilder application of
Smalltalk/V) or a scripting type language.
The term banking congers up many things to me, of course there is the
standard banking account transaction processing, but there also the
investment side of the business and other backroom analytical functions.
I believe that application for all those diverse requirement could
benefit from Domaintalk.
For about thirteen year I was the head of computer departments with
multimillion dollar IBM MVS mainframes. One thing that I could count on
was that when I took over a new department I would find a staff that
though that programs always had bugs the they would need to fix. I
always seemed that 40% of my programming resources was spend fixing
bugs. (Just like the ObamaCare web site.) I established the policy that
programmers created bugs, not programs, and implemented step to
eliminate all bugs, including having the heads of projects that had bugs
meet with me each morning for a very uncomfortable meeting. I took about
six months to get the level of bugs down to an acceptable level, about
5%, and mostly in programs scheduled for replacement. So I am well aware
of what is required for an enterprise quality application. One reason I
want Domaintalk is that, I have observed that, code that is not readable
lends itself to errors. Another observation is that when the syntax of a
language is stretched beyond its intended use, it become unreadable.
I apologize for the lengthy response and I look forward to your
response, and answer to the DSL question.
BW
