On 05/27/2015 02:27 PM, Jude Nelson wrote:
> Hi Hendrik,
>
> On Wed, May 27, 2015 at 6:12 AM, Hendrik Boom <hendrik@???
> <mailto:hendrik@topoi.pooq.com>> wrote:
>

>     On Wed, May 27, 2015 at 03:32:00PM +0200, Laurent Bercot wrote:

>

>     >  As a rule of thumb, developers should always use the smallest
>     possible
>     > amount of dependencies for a project, and clearly separate
>     layers - e.g.
>     > if a project comes with an engine and a GUI, then the engine
>     should come
>     > as a command-line tool in its own package with no dependencies
>     on graphical
>     > stuff, which would be the role of the GUI package. But I'm a
>     dinosaur AND
>     > a fan of minimalism, so I don't expect many people to think like me.

>

>     I mean this as a serious question, not as a piece of sarcasm,
>     though it could easily be misconstrued as such.

>

>     I am testing the limits of the advice to separate interaction from
>     command line, though.  Sometimes limit testing leads to discoveries.

>

>     I'm in the process of writing (yet) a(nother) editor and output
>     formatter,
>     and on reading this, I started to wonder -- just how could one
>     separate
>     a command-line version from the UI?  I can see that the output
>     formatter can be so separated (and very usefully), but the actual
>     editing?

>

>     Brainstorming welcome.

>
>
> 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. However, we would like to be able
> to do this in order to allow the user to apply existing tools and
> skills in one domain without affecting the other domain, and allow
> developers to innovate in one domain without affecting the other.
> This should be possible, since rendering a UI is usually (but not
> always) a separate, orthogonal concern from performing the desired
> functionality.
>
> [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.
>

Shell-based command access to software like Powerpoint would indeed be
great. But I wonder if we can raise the bar a bit
and consider an approach that could serve the largest audience.
Especially users who themselves aren't developers or
programmers.

It seems to me such a system must be characterized by the following two
properties:
* basic - the language itself should be simple enough that the user
doesn't have to spend too much time on boilerplate and
learning eccentricities of the language. (And the environment should be
able to generate as much of the boilerplate on its own,
especially for common patterns.)
* visual - we know the user is already interacting with a graphical
system. So it makes sense that the command-based
system should include graphical modes of interaction and visualize as
much as it can. (For example, letting the user choose
from a set of familiar widgets rather than making them memorize a
baroque naming system.) It should look as familiar as it
can without sacrificing power, letting the user see as much of the data
flow without having to create the entire mental model
on their own.

Just imagine the possibilities if Powerpoint gave you access to an
environment like that!

-Jonathan

a20379251c47f4b0322b70d1069ab8ba66499228a7c92dccb1fdf7b99a3e77f2