On Wed, 27 May 2015 14:27:17 -0400
Jude Nelson <judecn@???> wrote:


> I've been thinking about the general form of this problem (and a
> general solution) for months, and I think I'm almost ready to provide
> a formal design document.
>
> [The Problem]
> Many programs couple the business logic to the presentation logic.
> The code that drives the UI is too intermingled with the code that
> provides the application's core functionality to use them separately,
> or develop on them independently.

Hi Jude,

Be careful what you wish for. MVC was created to solve this problem,
and it looks to me like, in the hands of most developers, like MVC
makes an unfathomable Easter Egg Hunt where a reasonably simple
algorithm can't go six lines without the need to go look something up
somewhere else. And yet, in the hands of most practitioners, my
observation is they *still* manage to intersperse program logic, data
and UI.

Separation is good, but not all ideas for separation are good.

[clip]

> [Motivation]
> I was watching my SO create a (long) Powerpoint presentation the
> other day, and she wanted to add a "fade in" animation to each bullet
> point on each slide. Powerpoint (and every office suite I'm familiar
> with) makes you do this by hand, bullet-point by bullet-point, with a
> mouse. The UNIX hacker in me saw this, and wondered why it's not
> possible to simply open a shell and run something like "for
> ppt_bullet in $(ppt-ls "bullets"); do ppt-animate "fade-in"
> "$ppt_bullet"; done". This would have saved an hour of tedious,
> repetitive effort.
>
> The reason this isn't possible is because Powerpoint (and every other
> office suite) does not offer a command-oriented UI. What could
> Powerpoint have done? One option is to add a program-specific
> command-language (like how vim and emacs do). However, I don't think
> this the answer either, for two reasons:
> (1) The UI (the command-language in this case) is still tightly
> coupled to the program, and has rules and semantics that are only
> applicable to the program.

I think #1 above is a *good* thing. There's a reason it's called a
*domain* specific language. It's the functions of this program's
"business logic", and nothing more.


> (2) Without careful design, the user can't bring to bear existing
> knowledge or existing tools to address problems. This is a general
> gripe I have against vim and emacs too--if you're going to offer a
> Turing-complete command language, why not offer one that is
> widely-used already and lets people use external tools?

That's just it. I think packaging a Turning-complete language is
overkill, much the same as having the init system take charge of login
logic. I'm an elder in the Church of the Parsimoneous Scope. I'd prefer
to expose every business logic function, such that it's callable from
the command prompt and other places. Those functions are the thin
interface connecting business logic and appearance. There's nothing
Turing complete about them. If you want Turing completedness, that's
for the program

Years ago GoLUG's Gary Miller told me something I never forgot. When
writing a program, he makes his entire user interface as input and
output to a socket. That way, on his side of the socket, there's no
need for Python-Tk, nor Curses, nor GTk nor tk nor HTML generation nor
mod-apache-whatever: None of that complication. Nothing but business
logic algorithms and the functions that implement them. Write it in
simple, no-dependency C, Python, Perl, Ruby, Lua, whatever.

Then Gary publicizes the commands that socket takes, so the other guy
can write a program with Curses or Python-Tk or whatever, to present the
info to the user, as needed. This presentation program has all the GUI
molassas, but no business logic, so it's pretty straightforward. And
you have complete separation of business logic from presentation,
enforced by a socket.

But of course, the thing on the far side of the socket can be more than
a UI. It can be a script. It can be a program that turns a config file
into a script. It can be a command prompt (using telnet) to tweak. You
can accomplish almost anything, except adding a function or changing a
function's actions on Gary's side of the program. If you want to do
that, do it on Gary's side.


>
> What I would like the most is if Powerpoint were somehow designed so
> that its runtime state was exposed to the system shell, so I could
> operate on it directly. Powerpoint wouldn't need to ship with its
> own custom language, and I could use whatever tools I wanted.

I'm pretty sure Gary's method would do just that.

[snip]

> [Design Notes]
> The idea I I'm working on can be thought of as a re-telling of the
> SQUEAK story for the UNIX environment:
> * The shell is the binding language between different aspects of the
> application, as well as between the application and external tools
> (this replaces Smalltalk).
> * Persistent state is encoded as files

As a djb enthusiast, I'm always happy when state is encoded as files
and directories.



> * Applications are encoded as directory hierarchies, where:
> -- a directory represents either one aspect of the program (i.e. a
> dialog box, a text area, a file explorer, etc.), or an aggregate of
> multiple aspects.
> -- leaf files are either persistent state for the aspect that their
> parent directory represents, or executables that should be run in
> response to an external event (i.e. from the user, from the passage
> of time, or from another program).

Be careful of those executables. Some fool will try to put business
logic in the program that runs part of the UI.

>
> For example, a simple network manager might look like:
>
> $ cd network-manager/ && find .
> .
> ./window-main
> ./window-main/panel-buttons
> ./window-main/panel-buttons/button-Cancel
> ./window-main/panel-buttons/button-Cancel/data
> ./window-main/panel-buttons/button-Cancel/on_click.sh
> ./window-main/panel-buttons/button-Connect
> ./window-main/panel-buttons/button-Connect/data
> ./window-main/panel-buttons/button-Connect/on_click.sh
> ./window-main/selectbrowser-networks
> ./window-main/selectbrowser-networks/on_timer.sh
> ./window-main/selectbrowser-networks/data
> ./window-main/selectbrowser-networks/on_select.sh
> ./window-main/menubar-main
> ./window-main/menubar-main/help
> ./window-main/menubar-main/help/002-Credits
> ./window-main/menubar-main/help/001-About
> ./window-main/menubar-main/file
> ./window-main/menubar-main/file/001-Quit

I'm hoping that the preceding does nothing, nothing, NOTHING except ask
questions of the business logic module, and display the answers.

Exactly what are the .sh files and what do they do? Do they simply call
functions from the business logic module (good), or are they intended
for main-window to add its own business logic (bad), or incorporate code
from the business logic module into the .sh file (probably bad)?

If you're going to do this, have you given any thought to making a
Rapid Application Development (RAD) program out of it? You appear to
already be doing window generation. Add in some templating, and who
knows how fast development might get.

Or how bad. I have no doubt that RAILS is fast to develop, but I
shudder every time I look at RAILS "code".

SteveT

Steve Litt
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz