On 1/17/2016 12:09 PM, rbowman wrote:
On 01/16/2016 11:40 PM, Don Y wrote:
I've also been rummaging through older languages with an eye towards
language features that would be suitable for a *user's* scripting
language (i.e., something a non-technical person could use to
say: "When I come home, at night, turn on the kitchen lights
as soon as I open the door.")

Imagine doing that in many of the modern languages -- littered
with lots of bizarre punctuation and idioms that make a *programmer's*
life easier -- but do nothing for a NON-programmer!

FORTH. The core language is a bit arcane but you can create words that are
suitable for the end user. I did one project to develop a simple interface for
QA engineers who were using a robotic arm to pick and place the components
under test.

It isn't appropriate. Recall, you're dealing with "QA Engineers",
not housewives, plumbers, accountants, etc.

The two biggest issues with FORTH a
- too hard to enforce/check syntax. I.e., "Is this combination/sequence
of words legitimate/valid?" You can make a word do damn near anything
so no easy way for the user to *see* what it expects "upstream".
And, no way to verify ("at compile time") that the sequence is
even legitimate
- the RPN nature (stack machine) is incredibly CONSISTENT -- but,
counterintuitive. People are more likely to think along the lines
of "do SOMETHING to THIS and THAT"; not "THIS and THAT have SOMETHING
done to them"

Beyond that, it also doesn't conveniently lend itself to the sorts of
services that an "applet" needs to avail itself of (in my world).
I.e., I deliberately want the heavy lifting to be done in services
that are provided to the user: recognize(&face); speak(prompt);
listento(response); etc.

So, there is inherently a high degree of parallelism. IME, people
have a hard time dealing with parallelism/concurrency. But, can
more readily think about it in a procedural framework: "I expect
something to have been done at this point..." (so the code can
implicitly wait for it, *then*). The applet writeer can think in
more linear terms and the "environment" can exploit parallelism
for efficiency and abstraction (hiding lots of mechanism from
the user/writer)

It's REALLY a hard problem! Complicate it by the fact that you (I)
want to address a wide population of potential users -- each with
potentially different abilities and HANDICAPS! I.e., something
that requires lots of keystrokes to compose would be difficult for a
movement impaired individual to write; something with lots of
cryptic "vowel-less" abbreviations would be hard to "speak" to
a visually impaired writer; etc.

OTOH, only the "hard" problems are worth the time to undertake! :