On Thu, May 28, 2015 at 11:58:55PM -0400, Jude Nelson wrote:
> Hi Jonathan,
>
> 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.)
> >
>
> What language would you propose?

(I) Scheme

The official scripting language for the GNU project seems to be
Scheme, as implemented by 'guile'. I suspect other implementations
could do as well. SOme of the modern Scheme inplementations actually
compile to byte code or machine code during interpretation, makint it
relatively efficient.


I'm told it's the scripting language for the Gimp.


It is the report generator in gnucash. In fact, gnucash was originally
written in Scheme (I think in fact it was guile) with specific parts in
C or C++. The current gnucash developers don't like Scheme much, and
have pretty well eliminated it from most of the code. It still remains
in the report generator. To the extend they are still using a
scripting language, they're using python now.

I think their reasons for avoiding Scheme are:
(1) the interface between Scheme and the C/C++ code is undocumented,
making it pretty well unusable, and
(2) they don't like parentheses.

Of course emacs is mostly implemented in its own dialect of Lisp,
which serves as a scripting language as well, but (*big* defiency)
does *not* do static binding of identifiers properly.


(II) Lua

Lua is also popular as a scripting language. I believe it was
*designed* as a scripting language.

The revision control system monotone uses lua for its user-coded
plug-ins. Independent of this, it also has an 'automate' interface
allowing monotone to be controled from another process, with a text
interface piped biderectionally through Unix pipes. I don't know how
this interface works on Windows.

> If I create shui, I'd make it
> language-agnostic so users can select whatever language(s) they want. My
> example with shell scripts was just to illustrate the possibility :)

Make it a library, so that the various language users can easily do
their own bindings. Avoid needing pointers to data that's managed by
the user's programming language so that garbage collection wont make
everything go blooey when the data are moved. Especially avoid storing
pointers to user data long-term. Of course, this may be unavoidable
for some purposes (such as callbacks).

-- hendrik

>
>
> > * 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.
> >
>
> Yeah, a RAD tool would be a natural extension of the idea!
>
>
> > Just imagine the possibilities if Powerpoint gave you access to an
> > environment like that!
> >
>
> It didn't occur to me when I wrote my original email, but it turns out
> Powerpoint can be scripted with VBA. So can Libreoffice (it supports
> Javascript and Python as well as Libreoffice Basic). There are others,
> like Blender, GIMP, KDE (i.e. SuperKaramba, Plasma, Kross), GNOME 3, the
> NetBSD kernel (Lua), the Linux kernel (ePBF), and so on, that I had
> forgotten to list.
>
> If anything, I think it validates the case for a system like shui. The
> fact that different applications in different problem domains independently
> gain built-in support for scripting suggests that there's a
> naturally-occurring need to be able to interact with applications
> programmatically as well as interactively. So, why not design applications
> with this need in mind from the get-go?
>
> -Jude
>
> PS Not sure why, but your email hit my (Gmail's) spam filter. Just
> thought you should know :)

> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng