Embedded Scripting -- Tcl? Lua? Thoughts? Suggestions?

[Tim Wescott]

The title says most of it.

I'm working on a project for which the customer wants a lot of flexibility
to customize a product. The existing "macro language" is ancient (ca
1985), cryptic (it looks like machine language), limited, clunky, etc.
The customer is willing to change.

I'm planning on having a chunk of serial flash (or an SD card) with a file
system on it (maybe FAT, maybe something home-rolled and primitive).
Scripts will be stored as text files, and read in as appropriate.

Rather than just use some clunky cryptic and limited language that's
unique to the problem and to me (and charging my customer up the wazoo for
it), I'd like to use something that's open-source and available.
Something that uses modest resources is to be preferred -- my
understanding is that I can expect Lua to use about 100k of flash, which
is a bit much for me but bearable. I don't know how Tcl compares -- I
just know that it's an alternative.

So -- anyone have any direct experience with either of these, or with
something else? We briefly considered Java, but it just looks entirely
too big -- it would basically drive us to use Linux or some other "real"
OS (even the little linuxes are too big for my tastes) -- I'd really
rather just have a scripting engine that gets called whenever a script
needs to run, and otherwise doesn't need much hand-holding from the
application code.

I'm looking for opinions, so fire away!

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

[Don Y]

Hi Tim,

I think Blue is better than Red.

Bagels beat donuts hands down! (unless you're *not* in NYC; then
damn near ANYTHING beats a bagel!)

Chicago Pizza beats New York Pizza.

42

Connery over all others (Moore, Brosnan, Lazenby, Dalton, Craig)

Anything with butter.

As to *your* question...

What sorts of things does the customer expect to *do* with those scripts?
And, (besides space) what other constraints are you needing to place
on those actions? E.g., any timeliness constraints? Performance?
Numerical precision? etc.

Who is the intended user: *just* the client? Or, will these things be
exposed to users?

What sorts of things do the scripts interact with (displays, etc.)?
E.g., do you need to be able to manipulate a GUI without constraint?
Or, are you just serving up text and/or canned dialogs?

What sort of user input device (keyboard, keypad, etc.)? Other I/O's?

I opted for a (bastardized) Limbo as my scripting language. But, I
use it to generate "real" applications and not just automate some
preexisting actions. However, it won't fit your memory requirements.

Can you tolerate something as "crude" as a bastardized BASIC? I.e.,
add "product specific" hooks to it to address some of the special needs
(displays, etc.) at a "native" level. A BASIC interpreter/compiler
can be really small.

The same can be said of C interpreters, mini-compilers (JIT). But,
you'd be targeting a different class of "developer" (user).

--don

[Tom Gardner]

I wish everyone was as mature and rational! I'm personally sick
and tired of scrotty little scripting languages that grey like
Topsy until nobody, including their originators^H^H^H^H^H
perpetrators, understood them anymore.

I haven't used it myself, but Lua looks like it might be a good
starting point, particularly since it is embeddable in/with C.

ISTR there being an embeddable JavaScript (not Java!) interpreter,
which might have the benefit of more familiar syntax.

[David Brown]

I used Lua in a project a number of years ago, and would use it again if
I needed scripting. It has a few key advantages over TCL. It is a
nicer language, it is quite easy to integrate in a C project (it
consists of just a few C files), and it's easy to make your own
functions callable from Lua. A disadvantage is that there is only one
number type, which is floating point by default, but you can change that
to integer if it suits you better (and it's certainly better than
everything being a string, as it is in TCL).

[Tim Wescott]

<< smart-assery snipped >>

>
> As to *your* question...
>
> What sorts of things does the customer expect to *do* with those
> scripts?
> And, (besides space) what other constraints are you needing to place on
> those actions? E.g., any timeliness constraints? Performance?
> Numerical precision? etc.
>
> Who is the intended user: *just* the client? Or, will these things be
> exposed to users?
>
> What sorts of things do the scripts interact with (displays, etc.)?
> E.g., do you need to be able to manipulate a GUI without constraint?
> Or, are you just serving up text and/or canned dialogs?
>
> What sort of user input device (keyboard, keypad, etc.)? Other I/O's?
>
> I opted for a (bastardized) Limbo as my scripting language. But, I use
> it to generate "real" applications and not just automate some
> preexisting actions. However, it won't fit your memory requirements.
>
> Can you tolerate something as "crude" as a bastardized BASIC? I.e.,
> add "product specific" hooks to it to address some of the special needs
> (displays, etc.) at a "native" level. A BASIC interpreter/compiler can
> be really small.
>
> The same can be said of C interpreters, mini-compilers (JIT). But,
> you'd be targeting a different class of "developer" (user).

The product will have a character display, and it'll store text files for
later retrieval. It has a measurement thingie (I don't want to get too
specific -- but it makes measurements) that'll cough up a number when it's
actuated, and it has a sea of (well, around 100) buttons that the user can
press.

My intention at the moment is to make the box this big dumb thing with
some system code that knows to call a function for each measurement and
button press (i.e., when the user presses button 1, the function named
"button_1" will get called if it exists). Then I'll encode the actual
functionality as a bunch of functions in the language-o-choice.

The nice thing about this is that if a user comes up with some desired
customization (which we expect, as we're replacing an existing product for
which this was common), we can either tell them to start coding and have
fun, or we can charge them $$ to code the thing up to their specifications.

The real driver for wanting to do this as a scripting language is to make
it easy for the user to customize. I'm imagining that some users won't
want to touch the customization with a 10 foot pole, some will be happy to
customize a button or two, some will get their feet wet and then call us,
and some will go whole hog with the thing, and do entire systems without
us even knowing it's going on.

[Tim Wescott]

On Fri, 13 Mar 2015 15:03:09 -0700, Don Y wrote:

<< snip >>

> Can you tolerate something as "crude" as a bastardized BASIC? I.e.,
> add "product specific" hooks to it to address some of the special needs
> (displays, etc.) at a "native" level. A BASIC interpreter/compiler can
> be really small.

Oh, and -- we've booted the idea of BASIC around, too. As far as I'm
concerned, the first letter or two of BASIC stands for BArf, and I'll have
to write scripts for the thing. So it's not high on our list of preferred
options.

[mrob...@att.net]

Tim Wescott <seemyw...@myfooter.really> wrote:
> So -- anyone have any direct experience with either of these, or with
> something else?

I did a tiny amount of Tcl 10+ years ago, but that was on a Linux
desktop with GUI. For a while, sometimes Tcl was used as sort of the
Linux equivalent of Visual Basic - for when you wanted a simple GUI but
didn't want to spend weeks screwing around with X/(GTK|Qt)/C++. I've
never tried embedding Tcl in anything.

I *have* used embedded Lua more recently. Wireshark (a packet sniffer,
formerly called Ethereal) understands lots and lots of packet formats,
but if you've come up with your own weird thing, it just gives you a hex
dump of the payload. You can write your own packet parser in Lua and
Wireshark will run it on the payload for you. The basic application is
to make the packet more human-readable. You can also use it along with
Wireshark's native ability to trigger on or sort by certain data fields
to only log packets of interest.

The thing I found odd about the choice of Lua for this application was
that *it didn't have any bitwise operators*. You couldn't do stuff like
"if(packet[3] & 0x04) { /*...*/ }". I did a lot of multiply and divide
by 2, and tests like "if(packet[5] > 127)" to see if the high bit was
set. Also, IIRC, Lua's default numeric type was float.

This was a couple of years ago; maybe "full" Lua could do bitwise back
then and Wireshark was only implementing a subset, or maybe Lua couldn't
do it back then but can do it now.

Wireshark also had the option of writing a packet dissector in C, and
then compiling it into a library (.so or .dll depending on platform);
this was said to give you faster decoding. Most of the protocols I was
looking at sent packets at no more than a few dozen Hz; I think one of
them topped out around 1 KHz. The Lua scripts didn't seem to have any
problem doing "live" decodes on a new-in-2007 PC.

I know I've seen the option to embed a Lua interpreter in something more
"embedded", possibly U-Boot. Lua's Wikipedia page lists a lot of places
where it has been embedded.

I will give my standard advice: ship a few example scripts with the
product. You can assume that people know how to use arithmetic
operators and things like that, but the details of how to get data out
of and back into your hardware will be unique to your implementation.
I think Wireshark had a limited example in the manual, but since it's
popular, I was able to find additional examples online. Most
applications won't be able to count on that, though.

Matt Roberds

[Don Y]

On 3/13/2015 5:06 PM, Tim Wescott wrote:

>> Can you tolerate something as "crude" as a bastardized BASIC? I.e.,
>> add "product specific" hooks to it to address some of the special needs
>> (displays, etc.) at a "native" level. A BASIC interpreter/compiler can
>> be really small.
>
> Oh, and -- we've booted the idea of BASIC around, too. As far as I'm
> concerned, the first letter or two of BASIC stands for BArf, and I'll have
> to write scripts for the thing. So it's not high on our list of preferred
> options.

Presumably, your goal is to make life pleasant for the *customer*, not
*yourself*! :>

I offered BASIC as an option as you can write one in a few KB and is
easily understood by "non-programmers". I've worked on instruments
where (my) customer (e.g., chemist) was charged with scripting behaviors
that *his* customers would blindly invoke (e.g., to determine if the
hospital patient has Hep-C, HIV, etc.). So, lots riding on (my)
customer "getting it right" as I'm not looking over his shoulder to
verify he's considered every exception, boundary case, etc. (All I
have to do is ensure the language is well-behaved and has no "gotchas"
that are likely to trip someone up two-levels removed from me!

[Don Y]

Hi Matt,

On 3/13/2015 5:28 PM, mrob...@att.net wrote:
> Tim Wescott <seemyw...@myfooter.really> wrote:
>> So -- anyone have any direct experience with either of these, or with
>> something else?
>
> I did a tiny amount of Tcl 10+ years ago, but that was on a Linux
> desktop with GUI. For a while, sometimes Tcl was used as sort of the
> Linux equivalent of Visual Basic - for when you wanted a simple GUI but
> didn't want to spend weeks screwing around with X/(GTK|Qt)/C++. I've
> never tried embedding Tcl in anything.

Are you sure you're not thinking of tk?

I looked at a bunch of OTS languages when I had to settle on a
scripting (i.e., "application") language. Many are far too cryptic
for casual users (I wanted to target "real programmers", hobbyists
and "homeowners" -- lots of competing criteria!).

Tcl has some features that are troublesome (e.g., upvar, uplevel) even
for "conventional" programmers. Imagine trying to explain them to
*casual* programmers/users.

> I *have* used embedded Lua more recently. Wireshark (a packet sniffer,
> formerly called Ethereal) understands lots and lots of packet formats,
> but if you've come up with your own weird thing, it just gives you a hex
> dump of the payload. You can write your own packet parser in Lua and
> Wireshark will run it on the payload for you. The basic application is
> to make the packet more human-readable. You can also use it along with
> Wireshark's native ability to trigger on or sort by certain data fields
> to only log packets of interest.
>
> The thing I found odd about the choice of Lua for this application was
> that *it didn't have any bitwise operators*. You couldn't do stuff like
> "if(packet[3] & 0x04) { /*...*/ }". I did a lot of multiply and divide
> by 2, and tests like "if(packet[5] > 127)" to see if the high bit was
> set. Also, IIRC, Lua's default numeric type was float.

I didn't like the fact that you could mix and match types without
anything alerting you to the fact that you're trying to do something
"wrong". E.g., if (5 == "5")...

Likewise, I thought the ability to perform multiple assignments
(with a *single* assignment operator) would cause problems. E.g.,
x, y = 1, 3 -- how would you "read that over the phone"?
"x and y get 1 and 3, respectively"? "x gets 1, y gets 3" (then
how is that *read* different from x=1 y=3)

Likewise, the potential for confusion when arguments are omitted
from function invocations. I.e., it doesn't do much to help
protect the programmer from "little (painful) mistakes":
"Oh, crap! Foo() takes *3* parameters!)

I've been surgically removing/rewriting features of Limbo (my
scripting choice) to try to ensure users can "get it right"
without scratching their heads to figure out what's wrong
with their code. Too many multiple character operators, etc.

[Clifford Heath]

On 14/03/15 08:27, Tim Wescott wrote:
> I'd like to use something that's open-source and available.
> Something that uses modest resources is to be preferred

> I'm looking for opinions, so fire away!

I've been around scripting languages since I built my first one 35 years
ago, and I don't think there's a really good solution for your
application yet... based on my definition of "good". The problem is
two-fold:

* Languages whose parser is very small tend to be hard to read & write
(Lisp, Forth) and tend not to have any static type checking, and

* Scripting languages tend to be garbage-collected, which adds to the
memory requirement and introduces unpredictable delays.

What I think would work best for embedded application :

* has a static data model (just global and local variables, but no
dynamic allocation),

* has a highly humanised syntax that pre-compiles into a byte code
format on a host computer, where it can be statically type-checked, but
is still easy to execute on the target.

I've been thinking about (and even started) writing such a beast since,
oh, about 1995 I think. I actually set out to write an event-driven
(actor) language like this, for high-school robotics programs, back when
my kids were starting high school. I really don't think it's a very
difficult thing to do (just a weekend project for me), but I'm not aware
that it's been done. I'd like to hear if anyone knows of an existing
candidate that meets these design criteria.

Clifford Heath.

[Clifford Heath]

On 14/03/15 12:45, Don Y wrote:
> Are you sure you're not thinking of tk?

tcl is the language, tk the toolkit - they're very close friends.

> Likewise, I thought the ability to perform multiple assignments
> (with a *single* assignment operator) would cause problems.

> how is that *read* different from x=1 y=3)

The only real use for multiple assignment is swapping values without
using an explicit temporary:
x, y = y, x

> Likewise, the potential for confusion when arguments are omitted
> from function invocations. I.e., it doesn't do much to help
> protect the programmer from "little (painful) mistakes":
> "Oh, crap! Foo() takes *3* parameters!)

Calling a 3-argument function with 2 arguments should return a function
that takes the remaining argument :) (I.e. currying)

> I've been surgically removing/rewriting features of Limbo (my
> scripting choice)

Where can I read more about Limbo? Is this the language from Inferno?
Hmm, that looks a lot like what I described in my other message :)

[Paul Rubin]

David Brown <david...@hesbynett.no> writes:
> A disadvantage [of Lua] is that there is only one number type, which

> is floating point by default, but you can change that to integer

They finally added integers to Lua, as of version 5.3, released earlier
this year.

[Paul Rubin]

Tim Wescott <seemyw...@myfooter.really> writes:
> I'm planning on having a chunk of serial flash (or an SD card)... my

> understanding is that I can expect Lua to use about 100k of flash,

> which is a bit much for me but bearable. ... We briefly considered

> Java, but it just looks entirely too big -- it would basically drive

> us to use Linux or some other "real" OS ... I'm looking for opinions,
> so fire away!

OK, embedded enterpreters were one of my favorite subjects for a while,
so here goes.

1. The smallest SD cards available these days are in the gigabytes, so
100k is nothing. The interpreter's RAM footprint is probably of more
concern on a small embedded system. How much ram are you willing to
use? I also have to ask whether you're going to be the one writing the
customizations at the user's request, or if the customer him/herself
wants to write customizations. You should probably stay away from weird
or difficult languages if the customer is doing the customization.

2. TCL and Lua are both quite easy to embed but Lua is a more modern and
generally better language, so I'd pick it over Tcl. Lua has more of a
programmer community these days (lots of mobile games and apps embed it)
and there's a high performance compiler (LuaJIT) available if you want
that.

3. However, from my language snob perspective, Lua and Tcl are both
somewhat distasteful. Also, you'll probably get much better user uptake
from Javascript (another distasteful language) since so many people know
it. Javascript will need a lot more machine resources and I don't know
what the embedding side is like, but you might want to consider it if
you have the CPU and RAM for it.

4. Other alternatives include Lisp dialects--I used to be into these.
You might look at GNU Guile (Scheme), Hedgehog Lisp (sort of a
functional subset of Scheme), and Lysp
(http://piumarta.com/software/lysp/). I guess each of these have
drawbacks.

5. You can use Javacard or J2ME in an embedded (non-Linux) environment
but I'm not sure why you'd want to. It requires external compilation
tools and a somewhat bureaucratic approach to development. I mention it
because you brought it up. Main thing it tries to supply (with some
success but not total) is security against untrusted, potentially
hostile scripts trying to mess with the surrounding application or with
other scripts in the same container. I don't know if that's an issue
for what you're doing.

6. You can also consider Python though its embedding challenges are
harder. I think it can be used without Linux but I've never done it.
If you go this route it's probably better to write your outer
application in it, calling C modules from Python as necessary, rather
than the other way around (writing the outer app in C and loading Python
into it).

7. If you're -really- resource constrained or your scripts need realtime
guarantees, there is Forth, but I'd stay away from it if you have enough
cpu and memory to run something like Lua.

Of all the above, based on the limited info you've given, the quick
answer is probably "Lua unless you can afford Javascript or you're a
language geek and like Lisp". If you can say more about your
application and your hardware constraints, that might help narrow things
down.

[Don Y]

Hi Clifford,

On 3/13/2015 7:14 PM, Clifford Heath wrote:
> On 14/03/15 12:45, Don Y wrote:
>> Are you sure you're not thinking of tk?
>
> tcl is the language, tk the toolkit - they're very close friends.
>
>> Likewise, I thought the ability to perform multiple assignments
>> (with a *single* assignment operator) would cause problems.
>> how is that *read* different from x=1 y=3)
>
> The only real use for multiple assignment is swapping values without using an
> explicit temporary:
> x, y = y, x

Yes -- saving a temporary. But, it's a feature that can easily be
abused (no direct consequences of doing so -- for the *abuser*).

Limbo suffers from this same problem:
x, y := 3;
sets *both* x and y to '3'. x, y = 2, 3 is an error.

To it's *credit*, the lua style of multiple assignment can be
accomplished using tuples:
(x, y) := (2, 3);
though tuples are far more useful for other things!

>> Likewise, the potential for confusion when arguments are omitted
>> from function invocations. I.e., it doesn't do much to help
>> protect the programmer from "little (painful) mistakes":
>> "Oh, crap! Foo() takes *3* parameters!)
>
> Calling a 3-argument function with 2 arguments should return a function that
> takes the remaining argument :) (I.e. currying)
>
>> I've been surgically removing/rewriting features of Limbo (my
>> scripting choice)
>
> Where can I read more about Limbo? Is this the language from Inferno?
> Hmm, that looks a lot like what I described in my other message :)

The vita nuova web site has has the two seminal papers on Limbo
(A Descent into Limbo; The Limbo Programming Language). I htink
there are two (?) texts that also address the language/"system"
(as Limbo is intimately tied up in Inferno... where the language
ends and the system begins can be debated).

But, it's more fleshy than a scripting language. E.g., contains
communication primitives *in* the language, seamlessly supports
RPC, multitasking, demand loadable modules, exceptions, GC, etc.

So, it's a good language to develop *real* applications in addition
to just hacking together simple little "basic" scripts.

The biggest problem is all the syntax that can easily intimidate
a casual user.

E.g.,
i = 1;
i := 1;
behave similarly but subtly different. A casual user might be
stressed to discover his problem boiled down to a missing/extra
colon! Or, "<-" vs. "->" vs. "=>". Niggly details. I, for
example, found it frustrating that you can't declare const lists.
Or even *initialize* a list in it's entirety!

(the current compiler leaves a lot to be desired in terms of
localizing errors)

FWIW, I think the current license terms are much more generous than
the *paid* license I acquired (change in their business model?)
So, you can download the environment -- BSD, Windows, OSX, Linux,
Slowaris, Plan 9 (of course) -- and play with it. At one point,
you could run the VM in a browser (not sure if that is still supported).

[Tim Wescott]

I'm trying to stick with an ARM M4 cored processor that has 256kB to
512kB of flash, and maybe 64kB of RAM, and a 72MHz CPU speed. Everything
can run at "human time", so delays of no less than 50ms are OK. There is
an issue that a really hot operator shouldn't be able to overrun the
machine, but the buttons are actuated by a wand (it's complicated -- they
just are), which should slow things down.

Even if I loved Lisp (or Forth) more than anything else in the world, I'd
still use Lua if it meant better user acceptance. I'll consider
Javascript for that very reason, particularly if I can find an open-
source interpreter that seems serious and well-supported.

--
www.wescottdesign.com

[Paul Rubin]

Tim Wescott <t...@seemywebsite.com> writes:
> I'm trying to stick with an ARM M4 cored processor that has 256kB to
> 512kB of flash, and maybe 64kB of RAM, and a 72MHz CPU speed.

Hmm, ok, I think Javascript is not practical in something that small.
Lua can work but will be a little bit cramped. How much of that flash
and ram will actually be available to Lua (i.e. not needed by the
non-Lua code)? How complicated do you expect the scripts to be? Are
you ok with cross-compiling the scripts? That means loading a script by
compiling it to bytecode with a PC application, then loading the
bytecode to your embedded board, instead of including the compiler in
the board so you can talk to it with a terminal.

http://wiki.eluaproject.net/FAQ#minimumrequirements

has some info. TCL (especially old versions) is probably smaller. I
know there are some bigger Cortex M4 parts, like ST has one with 2MB of
flash and 256k of ram -- do they cost too much or something?

> I'll consider Javascript for that very reason, particularly if I can
> find an open- source interpreter that seems serious and
> well-supported.

You'd have to use a bigger processor, but it still may be worth it. I
worked on something a couple years ago that could have been done in C on
an 8 bitter, but we used an embedded ARM7/Linux system with 64 meg of
ram for development convenience, adding maybe $5 to the hardware BOM
which was acceptable for what we were doing. I think it was well
justified by the flexibility it gave us. We were able to ship a better
product faster.

I don't know anything about JS embeddability. I've only programmed it
at the application level. I know that various applications other than
web browsers do embed JS, but it may be a lot more complicated than
using Lua.

Will your scripts have to process much non-numeric data like strings and
complicated structures? If not, maybe there's some BASIC dialect that
your users would find comfortable, especially if they're hardware types
who have been around for a while.

[Paul Rubin]

Paul Rubin <no.e...@nospam.invalid> writes:
> I think Javascript is not practical in something that small.

Hmm, this may be of interest: http://www.espruino.com/

It claims to run JS in a 64k ram part like yours.

I just came across it and don't know any more. I don't know what
dialect of JS it uses. It could be limited in a way that frustrates
your users who are used to programming browser JS. I'm sure that
fancy modern JS implementations like V8 are way larger.

[mrob...@att.net]

Don Y <th...@is.not.me.com> wrote:
> On 3/13/2015 5:28 PM, mrob...@att.net wrote:
>
>> For a while, sometimes Tcl was used as sort of the Linux equivalent
>> of Visual Basic - for when you wanted a simple GUI but didn't want to
>> spend weeks screwing around with X/(GTK|Qt)/C++.
>

> Are you sure you're not thinking of tk?

Now that I think about it, all the GUI stuff seemed to be a
combination: Tcl/tk. I guess you can use Tcl on its own without tk.

>> The thing I found odd about the choice of Lua for this application
>> was that *it didn't have any bitwise operators*.
>

> I didn't like the fact that you could mix and match types without
> anything alerting you to the fact that you're trying to do something
> "wrong". E.g., if (5 == "5")...

I don't remember ever crashing Wireshark by screwing up my Lua scripts.
Things just wouldn't decode / display on the Wireshark GUI correctly.
If that happened, I could always save the captured packets to a file,
fix my Lua script, reload the file in Wireshark, and have the script
run again.

The Lua interpreter also supported a simple printf-like function that
would just display on the Wireshark console and not in the GUI.
Wireshark would open a separate 80x25 text window when you used the
console. I found this useful for answering "am I pulling the right
bytes out of the packet or not", and *then* I could work on pushing
those bytes to the GUI in a useful way.

Matt Roberds

[Robert Wessel]

My limited experience is that Lua is a more "normal" language, not
that Tcl is hard, it's just going to look weirder to most users, and
Lua (in its smaller forms) has a smaller footprint, and is a bit
faster than Tcl (whether either of those is an issue is obviously
application dependent, but Tcl's "everything is a string" metaphor
hurts performance some).

Both interface fairly easily to your application, and allow you to add
your own commands/functions easily. Both are actively supported,
developed, and have widespread use.

If you eventually move to Java, Tcl does have a JVM version, which
might be useful for migration purposes.

I really don't think you'd go far wrong with either though.

[Tauno Voipio]

My vote to Jim-TCL or LUA.

--

Tauno Voipio

[Paul E Bennett]

Weighing in with a base-line requirement of about 8k of code-space and
easily extensible I would suggest Forth could probably suit your needs very
well. You add a little bit to it and design the script language environment
you need. You didn't mention which processor you are using in the product
but there is a Forth for most targets out there.

See <http://www.mpeforth.com/> or <http://www.forth.com/> for further
information. There are also some free to download books to help.

--
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E....@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1392-426688
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[Stefan Reuther]

Tim Wescott wrote:
> On Fri, 13 Mar 2015 20:16:32 -0700, Paul Rubin wrote:
>>7. If you're -really- resource constrained or your scripts need realtime
>>guarantees, there is Forth, but I'd stay away from it if you have enough
>>cpu and memory to run something like Lua.
>>
>>Of all the above, based on the limited info you've given, the quick
>>answer is probably "Lua unless you can afford Javascript or you're a
>>language geek and like Lisp".

+1 for that.

Lisp can be implemented in 5k flash, but still has the problem of user
acceptance. So I would choose Lua; I have already used it for writing
test drivers.

Another group managed to sneak a Python interpreter into their product,
but that's a huge Java blob, so I cannot say how much memory the Python
takes.

> I'm trying to stick with an ARM M4 cored processor that has 256kB to
> 512kB of flash, and maybe 64kB of RAM, and a 72MHz CPU speed. Everything
> can run at "human time", so delays of no less than 50ms are OK. There is
> an issue that a really hot operator shouldn't be able to overrun the
> machine, but the buttons are actuated by a wand (it's complicated -- they
> just are), which should slow things down.

This should be enough for Lua. If it's not enough, I believe Lua can be
off-line compiled.


Stefan

[Allan Herriman]

We had a related discussion in this thread from the middle of last
year:
https://groups.google.com/d/msg/comp.arch.embedded/geUFbpOZ2J4/eY4zcBLWsJYJ

Reading through it, I think Squirrel is the only language that this
thread hasn't mentioned.

Regards,
Allan

[Tauno Voipio]

AFAIK, Forth is the language of OpenBoot and its ancestors. I have last
really used Forth with boot of Intergraph workstations (based on M68k)
in early 1980's.

Forth is a fascinating language for old HP calculator users, but in my
classification, it belongs to the group of write-only languages.

--

-TV

[Paul E Bennett]

Tauno Voipio wrote:

>> Weighing in with a base-line requirement of about 8k of code-space and
>> easily extensible I would suggest Forth could probably suit your needs
>> very well. You add a little bit to it and design the script language
>> environment you need. You didn't mention which processor you are using in
>> the product but there is a Forth for most targets out there.
>>
>> See <http://www.mpeforth.com/> or <http://www.forth.com/> for further
>> information. There are also some free to download books to help.
>
>
> AFAIK, Forth is the language of OpenBoot and its ancestors. I have last
> really used Forth with boot of Intergraph workstations (based on M68k)
> in early 1980's.

It still is and there is also a version called FICL which most BSD users
might recognise.

> Forth is a fascinating language for old HP calculator users, but in my
> classification, it belongs to the group of write-only languages.

Whilst the underlying VM model has remained the same, there have been a
number of changes in the language definition. However, it still performs
well as an Application Specific Language Builder allowing you to create the
script language you need.

With a reasonable coding style it is far from Write-Only. As Chuck would
say, Forth is an "Amplifier of Programmer ability". It has been used in some
collaborative projects where reading others code was an important aspect of
the project. Still, it is Tim's choice.

[Mel Wilson]

On Sat, 14 Mar 2015 07:50:15 +0000, mroberds wrote:

> Now that I think about it, all the GUI stuff seemed to be a combination:
> Tcl/tk. I guess you can use Tcl on its own without tk.

openocd has a version of Tcl built-in for scripting. It works. Can't
say whether Lua would be better.

[Stephen Pelc]

On Sat, 14 Mar 2015 13:55:08 +0200, Tauno Voipio
<tauno....@notused.fi.invalid> wrote:

>AFAIK, Forth is the language of OpenBoot and its ancestors. I have last
>really used Forth with boot of Intergraph workstations (based on M68k)
>in early 1980's.
>
>Forth is a fascinating language for old HP calculator users, but in my
>classification, it belongs to the group of write-only languages.

All languages of that period suffered from such remarks. Try a modern
Forth in order to make current observations.

I speak as someone who wrote their first software in 1967.

Stephen

--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[Don Y]

Hi Matt,

On 3/14/2015 12:50 AM, mrob...@att.net wrote:
> Don Y <th...@is.not.me.com> wrote:
>> On 3/13/2015 5:28 PM, mrob...@att.net wrote:
>>
>>> For a while, sometimes Tcl was used as sort of the Linux equivalent
>>> of Visual Basic - for when you wanted a simple GUI but didn't want to
>>> spend weeks screwing around with X/(GTK|Qt)/C++.
>>
>> Are you sure you're not thinking of tk?
>
> Now that I think about it, all the GUI stuff seemed to be a
> combination: Tcl/tk. I guess you can use Tcl on its own without tk.

Yes. And you can use tk without tcl! :> (limbo uses a tk implementation
for its UI builder)

>>> The thing I found odd about the choice of Lua for this application
>>> was that *it didn't have any bitwise operators*.
>>
>> I didn't like the fact that you could mix and match types without
>> anything alerting you to the fact that you're trying to do something
>> "wrong". E.g., if (5 == "5")...
>
> I don't remember ever crashing Wireshark by screwing up my Lua scripts.

The above isn't technically "wrong". If you think about it, the
expression evaluates to FALSE. I'd rather the language not allow
such "mistakes".

> Things just wouldn't decode / display on the Wireshark GUI correctly.
> If that happened, I could always save the captured packets to a file,
> fix my Lua script, reload the file in Wireshark, and have the script
> run again.
>
> The Lua interpreter also supported a simple printf-like function that
> would just display on the Wireshark console and not in the GUI.

tcl/tk's big development win was wish.

IME, one of the biggest advantages to many of these languages was their
interpretive/JIT-ed nature. A development cycle was just edit-test
instead of edit-compile-link-test. Likewise, being able to "stop"
the program and probe its contents.

[Tauno Voipio]

On 14.3.15 20:04, Stephen Pelc wrote:
> On Sat, 14 Mar 2015 13:55:08 +0200, Tauno Voipio
> <tauno....@notused.fi.invalid> wrote:
>
>> AFAIK, Forth is the language of OpenBoot and its ancestors. I have last
>> really used Forth with boot of Intergraph workstations (based on M68k)
>> in early 1980's.
>>
>> Forth is a fascinating language for old HP calculator users, but in my
>> classification, it belongs to the group of write-only languages.
>
> All languages of that period suffered from such remarks. Try a modern
> Forth in order to make current observations.
>
> I speak as someone who wrote their first software in 1967.

I win by a few years, June 1964, with an IBM 1620.

--

-TV

[George Neuner]

On Sat, 14 Mar 2015 11:46:56 -0700, Don Y <th...@is.not.me.com> wrote:

>On 3/14/2015 12:50 AM, mrob...@att.net wrote:
>> Don Y <th...@is.not.me.com> wrote:
>
>>> I didn't like the fact that you could mix and match types without
>>> anything alerting you to the fact that you're trying to do something
>>> "wrong". E.g., if (5 == "5")...
>>
>> I don't remember ever crashing Wireshark by screwing up my Lua scripts.
>
>The above isn't technically "wrong". If you think about it, the
>expression evaluates to FALSE. I'd rather the language not allow
>such "mistakes".

The problem is that in some languages 5 == "5" is true. I've never
actually used Lua, but IIRC, TCL makes that mistake, as does
Javascript (both mentioned elsewhere in this thread).

George

[George Neuner]

On Sat, 14 Mar 2015 13:14:12 +1100, Clifford Heath
<no....@please.net> wrote:

>The only real use for multiple assignment is swapping values without
>using an explicit temporary:
>x, y = y, x

No, there are other uses - the most common to return both a result and
error/status from a function.

However, multiple assignment - or equivalently, multiple value return
- too often is abused by allowing some of the values to be elided.
There are times when all values aren't interesting, but IMO there
should be a syntactic placeholder that is not assigned to.

>> Likewise, the potential for confusion when arguments are omitted
>> from function invocations. I.e., it doesn't do much to help
>> protect the programmer from "little (painful) mistakes":
>> "Oh, crap! Foo() takes *3* parameters!)
>
>Calling a 3-argument function with 2 arguments should return a function
>that takes the remaining argument :) (I.e. currying)

Remember which forum you're in 8-)

Currying creates closures and *may* additionally require GC. Many
high level language features don't mix well with small devices.

George

[George Neuner]

On Fri, 13 Mar 2015 20:35:54 -0700, Don Y <th...@is.not.me.com> wrote:

>Hi Clifford,
>
>On 3/13/2015 7:14 PM, Clifford Heath wrote:
>
>> The only real use for multiple assignment is swapping values without using an
>> explicit temporary:
>> x, y = y, x
>
>Yes -- saving a temporary. But, it's a feature that can easily be
>abused (no direct consequences of doing so -- for the *abuser*).
>
>Limbo suffers from this same problem:
> x, y := 3;
>sets *both* x and y to '3'.

Which is crazy. Looks like a bastard cross between Pascal's
assignment and Modula's constant declaration syntax.

> x, y = 2, 3 is an error.

That's more reasonable. If you using := for assignment, then = is
equal and multiple value equal doesn't make a whole lot of sense
unless you're talking about ordered sets (tuples). But I would assume
that Limbo has a syntax for constant tuples.

>To it's *credit*, the lua style of multiple assignment can be
>accomplished using tuples:
> (x, y) := (2, 3);
>though tuples are far more useful for other things!

But a tuple semantically is different from multiple values. A tuple
is a single container with multiple content - the container must be
"opened" to get at its content whereas the individual values
(typically) do not.

Then there is the question of whether tuples can be frame allocated or
whether they end up on the heap. And whether a tuple has O(1), O(N) or
O(something else) access.

Depending on the implementation, it might actually be faster to
allocate a heap tuple than to return/set multiple values. But because
it usually is slower to unpack the tuple, that may eat up any saving
from using it in the first place.

George

[George Neuner]

On Fri, 13 Mar 2015 16:27:12 -0500, Tim Wescott

<seemyw...@myfooter.really> wrote:

>Rather than just use some clunky cryptic and limited language that's
>unique to the problem and to me (and charging my customer up the wazoo for
>it), I'd like to use something that's open-source and available.
>Something that uses modest resources is to be preferred -- my
>understanding is that I can expect Lua to use about 100k of flash, which
>is a bit much for me but bearable. I don't know how Tcl compares -- I
>just know that it's an alternative.

Javacard would fit depending on the libraries you include. Javacard
is a Java VM, but pure interpreter and very small. It does not
support dynamic load or verification of class files. Be aware though
that Javacard also has no GC - applets have to request heap space at
startup and manage it (if they are so inclined) themselves.

I haven't used Lua myself (dose of salt) but my understanding is that
the VM is separable. If you can cross compile the bytecode, it should
be workable.

TCL will look weird to many people. IME (not recent) it also has
lousy feedback on script errors. I have never tried to use it in a
really small space so I can't comment on it's minimum RAM needs.


Code space wise, any of these should have plenty of headroom with
100KB. The real question is how much RAM can they use?

>So -- anyone have any direct experience with either of these, or with
>something else? We briefly considered Java, but it just looks entirely
>too big -- it would basically drive us to use Linux or some other "real"
>OS (even the little linuxes are too big for my tastes) -- I'd really
>rather just have a scripting engine that gets called whenever a script
>needs to run, and otherwise doesn't need much hand-holding from the
>application code.
>
>I'm looking for opinions, so fire away!

If you have a little more [well, 3x] space I'd mention TCC.


Have you looked at PicoC ? https://code.google.com/p/picoc/


George

[Paul Rubin]

George Neuner <gneu...@comcast.net> writes:
> Javacard also has no GC - applets have to request heap space at
> startup and manage it (if they are so inclined) themselves.

GC is present in some Javacard devices. Maybe more of a problem is that
I don't think Javacard is open source.

> TCL will look weird to many people.... I can't comment on it's minimum
> RAM needs.

I checked into this yesterday and tcl these days has gotten rather
bloated. The "small footprint" version is 100k-200k of code:

http://jim.tcl.tk/index.html/doc/www/www/index.html

I used an embedded tcl several versions back and it was smaller then,
but people probably expect the recent improvements.

> If you have a little more [well, 3x] space I'd mention TCC.
> Have you looked at PicoC ? https://code.google.com/p/picoc/

It doesn't sound like there's much need to host the compiler on the
embedded board, and using C defeats a main benefit of scripting
languages, which is to supply automatic memory management and protect
the user from the usual C hazards like pointer errors causing memory
corruption.

I do see there are some Scheme implementations around with mighty small
ram requirements, e.g. http://armpit.sourceforge.net/ (scroll down the
page) discusses some targets with as little as 32k of flash and 8k of
ram. It is written in ARM assembler though, making me wonder if it has
a reasonable C FFI.

https://github.com/ryansuchocki/microscheme might also be interesting:
someone just pointed it out to me and I haven't looked at it much yet.

For simple purposes like UI customization, Scheme is probably ok for
non-Schemers since they can probably get their stuff working by copying
and modifying existing examples. There are also lots of books on
Scheme. So it seems worth looking into these if Lua turns out to be too
large.

I looked at Tiny Scheme which is a well known small implementation
(about 40k), but its ram footprint looks rather large, maybe since it
uses a recursive S-expression evaluator instead of a VM.

I'm a fan of Hedgehog Lisp which has an offline compiler and a very
compact VM (about 20k), but it's a weird dialect with almost no users.
Sometimes I think of hacking it to be more compatible with Scheme, and
maybe adding alternative front end to it. For a while I thought using
its VM as a runtime for a Haskell dialect for microcontrollers that I
wanted to call "Control-H", so that the file extension would be a
backspace character. ;-)

[Don Y]

On 3/14/2015 8:59 PM, George Neuner wrote:
> On Fri, 13 Mar 2015 20:35:54 -0700, Don Y <th...@is.not.me.com> wrote:
>> On 3/13/2015 7:14 PM, Clifford Heath wrote:
>>
>>> The only real use for multiple assignment is swapping values without using an
>>> explicit temporary:
>>> x, y = y, x
>>
>> Yes -- saving a temporary. But, it's a feature that can easily be
>> abused (no direct consequences of doing so -- for the *abuser*).
>>
>> Limbo suffers from this same problem:
>> x, y := 3;
>> sets *both* x and y to '3'.
>
> Which is crazy. Looks like a bastard cross between Pascal's
> assignment and Modula's constant declaration syntax.

It's effectively,
x: int;
y: int;
x = 3;
y = 3;
Or,
x, y: int;
x = y = 3;

>> x, y = 2, 3 is an error.
>
> That's more reasonable. If you using := for assignment, then = is

':=' declares and defines; ':' declares while '=' defines
So,
x, y = 3;

> equal and multiple value equal doesn't make a whole lot of sense
> unless you're talking about ordered sets (tuples). But I would assume
> that Limbo has a syntax for constant tuples.
>
>> To it's *credit*, the lua style of multiple assignment can be
>> accomplished using tuples:
>> (x, y) := (2, 3);
>> though tuples are far more useful for other things!
>
> But a tuple semantically is different from multiple values. A tuple
> is a single container with multiple content - the container must be
> "opened" to get at its content whereas the individual values
> (typically) do not.

That's not required in limbo. E.g., it is common for a function to
return a tuple: one member being a flag (success/fail) with the other(s)
being the expected result(s).

E.g., you could create a function that parses a (unsorted) list of values
comparing each to a "given" and returns:
- the count of values below the given value
- the count of values above the given value
- the count of values *at* the given value
- a (sorted?) list of all (unique) values below the given value
- a sorted list of all the unique values above the given value
- a summary code (like an error code: LIST_EMPTY, SUCCESS, etc.)
[Note that the number of entries in each of these lists may be less
than the *counts* returned as duplicates will be elided]

In the following, assume the "values" are strings:

check_list(
given: string, // what we seek
candidates: list of string // where it is sought
) :
(int, // count below
int, // count at
int, // count above
list of string, // sorted strings below sought
list of string, // sorted strings above sought
int // result code
)

it could then be invoked as:

(below, at, above, before, after, result) := check_list("Penny", names);

Use of the ':=' operator saves me the effort of declaring each of the types
of the members of that tuple. This is sort of an "anonymous" tuple (the
function could have returned it's values to a variable of the appropriate
tuple type)

Then, I could say:
if (below < above) {
sys->print("Of the " + string (len names) + "names examined, far"
+ " more names preceded the name of interest than followed."
+ " There were %d different names preceding, lexically,"
+ " and %d names following.", len before, len after);
...

[Highly contrived example]

Assuming these are the only return values used from that function
invocation, a smarter way of invoking it would have been:

(below, nil, above, before, after, nil) := check_list("george", names);

which makes it obvious which values are not used.

[Wouter van Ooijen]

> The only real use for multiple assignment is swapping values without
> using an explicit temporary:
> x, y = y, x

IMO there are other use cases, like rteurning multiple values, and
dissecting a tuple (you can argue that these are the same case):

status, result = some_operation()
name, address = person

Wouter

[David Brown]

Very nice!

And I see that bitwise operators are now official, rather than just a
common patch.

That pretty much removes the two stumbling points Lua had as an embedded
language for something like a Cortex M4.

[George Neuner]

On Sat, 14 Mar 2015 22:20:25 -0700, Paul Rubin
<no.e...@nospam.invalid> wrote:

>George Neuner <gneu...@comcast.net> writes:
>> Javacard also has no GC - applets have to request heap space at
>> startup and manage it (if they are so inclined) themselves.
>
>GC is present in some Javacard devices.

Javacard does not require GC - that's an extension. The standard
manager allocates but does not recycle until the applet ends.

>Maybe more of a problem is that I don't think Javacard is open source.

Oracle's VM isn't *libre*, but it is an open reference platform. There
are FOSS versions available.

>For simple purposes like UI customization, Scheme is probably ok for
>non-Schemers since they can probably get their stuff working by copying
>and modifying existing examples. There are also lots of books on
>Scheme. So it seems worth looking into these if Lua turns out to be too
>large.

I also like Scheme, but it is a non-starter for a lot of people.
Notwithstanding that a lot of scripts could be accomplished by
modifying examples, the prefix notation just seems to turn off many
people.

>I'm a fan of Hedgehog Lisp which has an offline compiler and a very
>compact VM (about 20k), but it's a weird dialect with almost no users.
>Sometimes I think of hacking it to be more compatible with Scheme, and
>maybe adding alternative front end to it. For a while I thought using
>its VM as a runtime for a Haskell dialect for microcontrollers that I
>wanted to call "Control-H", so that the file extension would be a
>backspace character. ;-)

I have, on occasion, embedded Guile and mzScheme. Bare bones, they
are small enough, but useful configurations grow quickly.

George

[George Neuner]

On Sat, 14 Mar 2015 22:30:30 -0700, Don Y <th...@is.not.me.com> wrote:

>On 3/14/2015 8:59 PM, George Neuner wrote:
>
>> But a tuple semantically is different from multiple values. A tuple
>> is a single container with multiple content - the container must be
>> "opened" to get at its content whereas the individual values
>> (typically) do not.
>
>That's not required in limbo. E.g., it is common for a function to
>return a tuple: one member being a flag (success/fail) with the other(s)
>being the expected result(s).

And how do you access those values in the tuple - surely it can't be
the same as values not in the tuple.

Multiple-value return is more complex than single-value return. Many
languages allow functions to return a container type to preserve the
(relative) simplicity of the single-value return. Ansi C does this
with structs.

I don't know what Limbo does, but tuple using languages typically
allocate the tuple and its contents separately and then return a
reference to the tuple. Which goes back to what I said about the cost
of accessing the values.

George

[Paul Rubin]

George Neuner <gneu...@comcast.net> writes:
>>GC is present in some Javacard devices.
> Javacard does not require GC - that's an extension.

Right, fair enough, but some devices do include it.

> The standard manager allocates but does not recycle until the applet
> ends.

Sort of like Microscheme :)

> Oracle's [J2ME, Javacard?] VM isn't *libre*, but it is an open

> reference platform. There are FOSS versions available.

Oh cool, good to know.

> I also like Scheme, but...the prefix notation just seems to turn off
> many people. I have, on occasion, embedded Guile and mzScheme. Bare

> bones, they are small enough, but useful configurations grow quickly.

Hmm, I had been wondering about the memory footprint of Guile. I know
that it has some front ends for other language syntaxes, particularly
Ecmascript a/k/a Javascript, with Lua supposedly in development.

I spent yesterday evening looking into very small ram-stingy Scheme
implementations and I wonder whether the Guile Ecmascript front end
could be used with them. But, it probably increases the product's
support burden.

Picobit looks interesting: https://github.com/stamourv/picobit

Absolutely unsuitable for non-nerd user scripting, but maybe of interest
to language geeks: Purescript (purescript.org) is a Haskell dialect that
compiles to Javascript, and could be probably made to generate Scheme
instead. I think someone is already working on retargeting it to Lua.
But I think the pure functional approach (no mutable data, lots of GC)
isn't a good fit for small embedded systems.

[Don Y]

On 3/15/2015 6:44 PM, George Neuner wrote:
> On Sat, 14 Mar 2015 22:30:30 -0700, Don Y <th...@is.not.me.com> wrote:
>
>> On 3/14/2015 8:59 PM, George Neuner wrote:
>>
>>> But a tuple semantically is different from multiple values. A tuple
>>> is a single container with multiple content - the container must be
>>> "opened" to get at its content whereas the individual values
>>> (typically) do not.
>>
>> That's not required in limbo. E.g., it is common for a function to
>> return a tuple: one member being a flag (success/fail) with the other(s)
>> being the expected result(s).
>
> And how do you access those values in the tuple - surely it can't be
> the same as values not in the tuple.

As in the example I posted. You *think* of tuples as structs. But,
they don't really exist in an abstract sense. I.e., they only
exist when you are accessing them -- as (...).

E.g., you can have a function return a (string, int). Another similar
function can also return a (string, int). You don't consider the
results of these two functions to be "the same type" -- in the sense
that (in C) you would create a typedef struct that *both* would use.
You don't reference the "members" of a tuple by "names/identifiers".
Rather, *positionally*, via a "(...) = <tuple_type>" assignment.

One of the annoyances of Limbo is exactly that. You end up with code
stanzas like:
(name, count) := function_that_returns_a_string_and_an_int(...);
...
(name, count) := function_that_returns_a_string_and_an_int(...);
The second invocation screws you because you've already got a
"name" and "count" in the current scope. So, you end up
rewriting:
(name, count) := function_that_returns_a_string_and_an_int(...);
...
(name, count) = function_that_returns_a_string_and_an_int(...);
or, declaring name and count "up top" somewhere and then:
(name, count) = function_that_returns_a_string_and_an_int(...);
...
(name, count) = function_that_returns_a_string_and_an_int(...);

> Multiple-value return is more complex than single-value return. Many
> languages allow functions to return a container type to preserve the
> (relative) simplicity of the single-value return. Ansi C does this
> with structs.

Yes. The struct analogy in Limbo is the adt (Abstract Data Type)
which is often a (user-)named type.

Modules (which are a formal type) are essentially adt's -- the
data and function members thereof accessed through pointers to
the underlying module: "module->member" notation (where
"module" is a pointer to a loaded "Module")

> I don't know what Limbo does, but tuple using languages typically
> allocate the tuple and its contents separately and then return a
> reference to the tuple. Which goes back to what I said about the cost
> of accessing the values.

Limbo avoids this by letting (forcing!) you to declare the variables
into which the result(s) get stuffed. So, it's just syntactic sugar, of
a sort.

I.e., in the first (":=") example, name and count are declared (created)
in the current stack frame so there's a place for these "return values"
to get stuffed. In the second ("=") example, the variables were previously
declared (and accessible in this scope) so the same idea applies.
There's no "hidden" allocation/GC required (beyond that of cleaning
up the stack frame when the block exists).

[Anders....@kapsi.spam.stop.fi.invalid]

Paul Rubin <no.e...@nospam.invalid> wrote:

> 6. You can also consider Python though its embedding challenges are
> harder. I think it can be used without Linux but I've never done it.

I don't know anything about it, but Micro Python is a thing that exists.
It is a Python 3 implementation optimized for microcontrollers.
<http://micropython.org/>

-a

[Paul Rubin]

Anders....@kapsi.spam.stop.fi.invalid writes:
> I don't know anything about it, but Micro Python is a thing that exists.
> It is a Python 3 implementation optimized for microcontrollers.
> <http://micropython.org/>

It's too large for this purpose, apparently. I'm told it needs around
256k.

I've been looking at Microscheme and Picobit (both small Scheme
implementations). Microscheme (intended for AVR8) is too minimalistic
but Picobit is interesting. There is an ARM port of Picobit but I don't
know how well maintained it is.

[Don Y]

On 3/14/2015 8:59 PM, George Neuner wrote:

> On Sat, 14 Mar 2015 13:14:12 +1100, Clifford Heath
> <no....@please.net> wrote:
>
>> The only real use for multiple assignment is swapping values without
>> using an explicit temporary:
>> x, y = y, x
>
> No, there are other uses - the most common to return both a result and
> error/status from a function.
>
> However, multiple assignment - or equivalently, multiple value return
> - too often is abused by allowing some of the values to be elided.
> There are times when all values aren't interesting, but IMO there
> should be a syntactic placeholder that is not assigned to.

Limbo supports this with the "nil" object. It;s required for parameters
in tuples that are to be "ignored".

It's also "good practice" to use it in places where you *want* to ignore
something (e.g., a return value) and yet indicate that you are deliberately
ignoring it (vs. "you forgot about it").

E.g.,

nil = malloc(...)

[George Neuner]

On Mon, 16 Mar 2015 15:42:18 -0700, Don Y <th...@is.not.me.com> wrote:

>On 3/14/2015 8:59 PM, George Neuner wrote:
>

>> ... multiple assignment - or equivalently, multiple value return

>> - too often is abused by allowing some of the values to be elided.
>> There are times when all values aren't interesting, but IMO there
>> should be a syntactic placeholder that is not assigned to.
>
>Limbo supports this with the "nil" object. It;s required for parameters
>in tuples that are to be "ignored".
>
>It's also "good practice" to use it in places where you *want* to ignore
>something (e.g., a return value) and yet indicate that you are deliberately
>ignoring it (vs. "you forgot about it").
>

>E.g. nil = malloc(...)

Yes. Deliberately ignoring returns is fine.

My gripe is against allowing to ignore the returned value(s)
completely ... which too many languages allow ... or to catch the
first value (or first N values) of a multiple return and ignore the
rest *without* any syntactic cues.

Lisp has both flaws - Scheme has only the first. In either language
you can completely ignore all the returned values, but if you want the
3rd value of 5, in Lisp you need to catch at least the first 3 values;
in Scheme you must catch all 5 values. Unfortunately neither Lisp nor
Scheme allows reusing a name to bind multiple values from the same RHS
expression, nor do they have explicit syntax to suppress binding of
particular values.
[Lisp's multiple-value-bind does implicit suppression of trailing
values, however there is no warning if you don't catch everything.
Scheme's let-values complains if the LHS doesn't match the RHS.]


I like certain aspects of multiple return/assignment and I included it
in one of the languages I designed. Like Scheme, I required that
every LHS identifier be matched by a RHS value, but I also included a
LHS placeholder which throws away the corresponding RHS value: I used
"_" because that what Prolog used for anonymous matching and I like
the visual effect of a "hole" in the expression. YMMV.

I also let the RHS be a list of arbitrary expressions so long as it
produces the correct number of values. So you could say stuff like:

a,_,c,d,e = func_returning_3(), func_returning_2();
and
a,b,_,d,e = 1,2,func_returning_2(),(1+2);

It was not any more efficient than evaluating the expressions and
performing the assignments in sequence, but I considered that choosing
to use the multiple assignment form might be conveying something
semantically important to the programmer ... and it was fairly easy to
do once I had multiple return.

George

[Don Y]

On 3/17/2015 1:25 AM, George Neuner wrote:
> On Mon, 16 Mar 2015 15:42:18 -0700, Don Y <th...@is.not.me.com> wrote:
>
>> On 3/14/2015 8:59 PM, George Neuner wrote:
>>
>>> ... multiple assignment - or equivalently, multiple value return
>>> - too often is abused by allowing some of the values to be elided.
>>> There are times when all values aren't interesting, but IMO there
>>> should be a syntactic placeholder that is not assigned to.
>>
>> Limbo supports this with the "nil" object. It;s required for parameters
>> in tuples that are to be "ignored".
>>
>> It's also "good practice" to use it in places where you *want* to ignore
>> something (e.g., a return value) and yet indicate that you are deliberately
>> ignoring it (vs. "you forgot about it").
>>
>> E.g. nil = malloc(...)
>
> Yes. Deliberately ignoring returns is fine.
>
> My gripe is against allowing to ignore the returned value(s)
> completely ... which too many languages allow ... or to catch the
> first value (or first N values) of a multiple return and ignore the
> rest *without* any syntactic cues.

Exactly. This is the same sort of thing as adding an explicit cast:
"Yeah, I *know* this is an APPLE. But, it's safe for us to PRETEND
it's an ORANGE, right now..."

Show the *next* developer that you were aware of something -- and
took steps to deliberately ignore it -- instead of potentially leaving
him wondering, "Why didn't he check the error code, here?"

> Lisp has both flaws - Scheme has only the first. In either language

The nature of lists -- they have no prescribed lengths! :-/

> you can completely ignore all the returned values, but if you want the
> 3rd value of 5, in Lisp you need to catch at least the first 3 values;
> in Scheme you must catch all 5 values. Unfortunately neither Lisp nor
> Scheme allows reusing a name to bind multiple values from the same RHS
> expression, nor do they have explicit syntax to suppress binding of
> particular values.
> [Lisp's multiple-value-bind does implicit suppression of trailing
> values, however there is no warning if you don't catch everything.

------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

That's the nature of this subthread. Like being able to mark the
source to say "ignore this warning in this place. And, if the warning
DOESN'T appear, bring that to my attention!!"

> Scheme's let-values complains if the LHS doesn't match the RHS.]
>
> I like certain aspects of multiple return/assignment and I included it
> in one of the languages I designed. Like Scheme, I required that
> every LHS identifier be matched by a RHS value, but I also included a
> LHS placeholder which throws away the corresponding RHS value: I used
> "_" because that what Prolog used for anonymous matching and I like
> the visual effect of a "hole" in the expression. YMMV.

I'm not fond of '_' in any use. Even seeing it in identifiers makes
me cringe. It still remains part of my typedef names (e.g., foo_t)
but I've been disciplining myself to get rid of it there, as well.

Limbo's "nil" (for placeholder) seems to stand out well enough (i.e.,
it doesn't bring up suggestions of some other identifier you might
have encountered in your code).

It also has value (actually, there's a pun hidden in that!) in
assignments:

comm_links: list of channel;
...
comm_links = nil; // cut all lines!

> I also let the RHS be a list of arbitrary expressions so long as it
> produces the correct number of values. So you could say stuff like:
>
> a,_,c,d,e = func_returning_3(), func_returning_2();
> and
> a,b,_,d,e = 1,2,func_returning_2(),(1+2);

A list is a list, right? :>

> It was not any more efficient than evaluating the expressions and
> performing the assignments in sequence, but I considered that choosing
> to use the multiple assignment form might be conveying something
> semantically important to the programmer ... and it was fairly easy to
> do once I had multiple return.

I'd be leary of a missing terminator causing two func() invocations
(on successive lines) to be cat'd (cons'd) together to fill a single
list. But, having/requiring number of values to equal number of
variables backstops that. (Too early in the morning to wonder if
there are any pathological cases where you could still get screwed
by something like that...)

C off to new class so I may actually get time for *work*, today!
(what a novel concept!) OTOH, I'm still stumped on some syntax for
the IDL so maybe work isn't such a good idea, after all! :-/

[George Neuner]

On Tue, 17 Mar 2015 10:39:25 -0700, Don Y <th...@is.not.me.com> wrote:

>On 3/17/2015 1:25 AM, George Neuner wrote:
>
>> My gripe is against allowing to ignore the returned value(s)
>> completely ... which too many languages allow ... or to catch the
>> first value (or first N values) of a multiple return and ignore the
>> rest *without* any syntactic cues.
>

>> Lisp has both flaws - Scheme has only the first. ...

>
>The nature of lists -- they have no prescribed lengths! :-/

Not lists - in both cases it's multiple value binding.

If a function returns multiple values, Lisp by default catches only
the first value ... if you want to catch others you have to use
multiple-value-bind. multiple-value-bind is a kitchen sink that
treats the returned values as a sequence - it can catch just the N
head values of the sequence and it can supply defaults if the sequence
isn't long enough.

In Scheme you must either catch or ignore *all* of the return values -
if you don't Scheme complains. let-values also [theoretically] treats
the returned values as a sequence, but the sequence must exactly match
the binding list, so there are no defaults and no skipped returns.

multiple-value-bind [or even a more general solution] can be written
in Scheme using call-with-values and catching the returns into a list
or vector before further processing, but the flexibility of Lisp's
solution isn't there by default.

Which mostly is a Good Thing(tm)[*] in my opinion.

>I'm not fond of '_' in any use. Even seeing it in identifiers makes
>me cringe. It still remains part of my typedef names (e.g., foo_t)
>but I've been disciplining myself to get rid of it there, as well.
>
>Limbo's "nil" (for placeholder) seems to stand out well enough (i.e.,
>it doesn't bring up suggestions of some other identifier you might
>have encountered in your code).

I don't like punning LHS placeholders and RHS expressions. What does
it mean to write "nil = nil" ?

IMO, the placeholder should be a reserved identifier that doesn't have
any other meaning - including on the RHS where it also might be used,
e.g., in an argument list to indicate a default value should be
substituted. That doesn't leave a lot of choices on an ASCII keyboard
unless you're willing to give it some kind of proper name.

I'm not per se opposed to the placeholder being a multi-character
symbol. Something like [] or %% might work fine, but I think it
should not be easily confused with other things that might be in an
expression list.

YMMV.

>It also has value (actually, there's a pun hidden in that!) in
>assignments:

I'm not a big fan of punning. Why I prefer Scheme to Lisp.


>> a,_,c,d,e = func_returning_3(), func_returning_2();

>
>I'd be leary of a missing terminator causing two func() invocations
>(on successive lines) to be cat'd (cons'd) together to fill a single
>list. But, having/requiring number of values to equal number of
>variables backstops that. (Too early in the morning to wonder if
>there are any pathological cases where you could still get screwed
>by something like that...)

Leaving off the terminator would cause an error because the list
requires a separator. However, if the programmer miscounts bindings
vs values, mistakenly ends the RHS with a separator instead of a
terminator *and* forgets to catch a value produced by the following
extraneous expression: e.g.,

a,b,c,d,e = funcA_returns_2(),
funcB_returns_2(), <- mistaken comma
func_returns_1();

well, there's no way to tell that that isn't exactly what was meant.
I'm absolutely dead-set against significant whitespace ala Python's
indentation which creates more problems than it solves. Cripes! even
Fortran finally stopped requiring it.

The above example wouldn't work if the extraneous expression produces
no value or produces more than 1 value. The extraneous expression (or
expressions as it might be with more separator mistakes) have to
exactly fill the binding list. So, although possible, it takes a
confluence of 2 mistakes and unlucky happenstance to occur.


You can't guard against everything - there would be virtually no
software if you did because 99.9994% of all source input would be in
error and only a tiny group of pathological masochists would ever
stick with it long enough to produce anything.

It would be like programming in the 1950s all over again 8-)

George

[*] Jerry Pournelle, 1977

[Don Y]

On 3/17/2015 2:06 PM, George Neuner wrote:
> On Tue, 17 Mar 2015 10:39:25 -0700, Don Y <th...@is.not.me.com> wrote:
>> On 3/17/2015 1:25 AM, George Neuner wrote:
>>
>>> My gripe is against allowing to ignore the returned value(s)
>>> completely ... which too many languages allow ... or to catch the
>>> first value (or first N values) of a multiple return and ignore the
>>> rest *without* any syntactic cues.
>>
>>> Lisp has both flaws - Scheme has only the first. ...
>>
>> The nature of lists -- they have no prescribed lengths! :-/
>
> Not lists - in both cases it's multiple value binding.

Grrr... too early in the morning. :< Conflated this discussion with
the (similar multivariable) issue I'm facing with my marshalling/unmarshalling
code in the stubs ("Gee, it's sorely tempting to just treat this as a list
of bytes and scrape them off the caller and transport them to the callee...")

> If a function returns multiple values, Lisp by default catches only
> the first value ... if you want to catch others you have to use
> multiple-value-bind. multiple-value-bind is a kitchen sink that
> treats the returned values as a sequence - it can catch just the N
> head values of the sequence and it can supply defaults if the sequence
> isn't long enough.
>
> In Scheme you must either catch or ignore *all* of the return values -
> if you don't Scheme complains. let-values also [theoretically] treats
> the returned values as a sequence, but the sequence must exactly match
> the binding list, so there are no defaults and no skipped returns.
>
> multiple-value-bind [or even a more general solution] can be written
> in Scheme using call-with-values and catching the returns into a list
> or vector before further processing, but the flexibility of Lisp's
> solution isn't there by default.
>
> Which mostly is a Good Thing(tm)[*] in my opinion.
>
>> I'm not fond of '_' in any use. Even seeing it in identifiers makes
>> me cringe. It still remains part of my typedef names (e.g., foo_t)
>> but I've been disciplining myself to get rid of it there, as well.
>>
>> Limbo's "nil" (for placeholder) seems to stand out well enough (i.e.,
>> it doesn't bring up suggestions of some other identifier you might
>> have encountered in your code).
>
> I don't like punning LHS placeholders and RHS expressions. What does
> it mean to write "nil = nil" ?

I don't think it is allowed. The only syntax that might allow it
would be a tuple-to-tuple assignment. "nil" isn't a proper
"variable". Rather, it's an indication of "empty". E.g., for
a string variable,
foo: string;
foo = nil;
foo = "";
are indistinguishable.

But, you can't (?) use '""' to indicate an empty *list*.
foo: list of <whatever>;
foo = <whatever> :: <whatever>;
foo = nil;
if (foo == nil) ...

Nor, can you use '""' to indicate an unused argument in a function
invocation. Or, a discarded return value in a tuple. Or, an
unused "place holder" in a function declaration. E.g., the way most
(C) newbies write main() would effectively be:
main(nil: int, nil: list of string)
instead of:
main(argc: int, argv: list of string)

> IMO, the placeholder should be a reserved identifier that doesn't have
> any other meaning - including on the RHS where it also might be used,
> e.g., in an argument list to indicate a default value should be
> substituted. That doesn't leave a lot of choices on an ASCII keyboard
> unless you're willing to give it some kind of proper name.

I prefer real names for things instead of yet another cryptic "special
combination" of symbols. One of limbo's problems is it's not very
effective as a "read over the phone" language. (unless you preagree
as to how to name particular character combinations: -> <- => :: etc)

> I'm not per se opposed to the placeholder being a multi-character
> symbol. Something like [] or %% might work fine, but I think it
> should not be easily confused with other things that might be in an
> expression list.

> You can't guard against everything

Of course! How many times have you seen "NUL" in a piece of code
and had to look at the surrounding code to understand if its a
typo for "NULL"?

> - there would be virtually no
> software if you did because 99.9994% of all source input would be in
> error and only a tiny group of pathological masochists would ever
> stick with it long enough to produce anything.
>
> It would be like programming in the 1950s all over again 8-)

To be fair, the tools to *write* the code are a lot more user-friendly
than pulling a card from a deck and leaning on DUP until you get to
the column that needs to be tweaked.

[George Neuner]

On Tue, 17 Mar 2015 19:36:34 -0700, Don Y <th...@is.not.me.com> wrote:

>I prefer real names for things instead of yet another cryptic "special
>combination" of symbols. One of limbo's problems is it's not very
>effective as a "read over the phone" language. (unless you preagree
>as to how to name particular character combinations: -> <- => :: etc)

I've never had to read - or listen to - code over the phone. 8-)

I do agree that symbols can be too cryptic, but I also don't much like
the Lisp way of spelling-everything-out-as-verbosely-as-possible.
Lengthy names (particularly those trying to redundantly encode type)
become unwieldy very quickly. There has to be some acceptable middle
ground.


> ... How many times have you seen "NUL" in a piece of code

>and had to look at the surrounding code to understand if its a
>typo for "NULL"?

Oddly enough, I once used a Lisp variant which had both null and nil.
null was nil ... I forget what nil was for. Too long ago.

>To be fair, the tools to *write* the code are a lot more user-friendly
>than pulling a card from a deck and leaning on DUP until you get to
>the column that needs to be tweaked.

Cards? Our machine had rows of those little "rice grain" toggle
switches. We had to (re)enter the program in binary, one byte at a
time, whenever the machine was reset. 8-)

George

[Don Y]

On 3/17/2015 10:50 PM, George Neuner wrote:
> On Tue, 17 Mar 2015 19:36:34 -0700, Don Y <th...@is.not.me.com> wrote:
>
>> I prefer real names for things instead of yet another cryptic "special
>> combination" of symbols. One of limbo's problems is it's not very
>> effective as a "read over the phone" language. (unless you preagree
>> as to how to name particular character combinations: -> <- => :: etc)
>
> I've never had to read - or listen to - code over the phone. 8-)

You have vision. How would a blind user "see" the code? How
would I tell him what to write to solve one of his problems?

[I've fed various sources into several different speech synthesizers,
haptic interfaces, etc. It is only then that you truly realize how much
our programming languages have come to rely on "symbols"]

Or, do you just exclude them from that technology? :> One of the
driving motivations for my current project is accessibility -- in more
than just a "token" sense.

As I said, you can adopt *conventions* to make what you see more
readily conveyed in (e.g., spoken) conversation. E.g., I'd never
say "colon colon equals" when reading an Algol fragment to someone...

> I do agree that symbols can be too cryptic, but I also don't much like
> the Lisp way of spelling-everything-out-as-verbosely-as-possible.
> Lengthy names (particularly those trying to redundantly encode type)
> become unwieldy very quickly. There has to be some acceptable middle
> ground.

Hence the appeal of lots of specific namespaces, short programs/modules,
avoiding reuse of an identifier in a nested scope, etc.

>> ... How many times have you seen "NUL" in a piece of code
>> and had to look at the surrounding code to understand if its a
>> typo for "NULL"?
>
> Oddly enough, I once used a Lisp variant which had both null and nil.
> null was nil ... I forget what nil was for. Too long ago.
>
>> To be fair, the tools to *write* the code are a lot more user-friendly
>> than pulling a card from a deck and leaning on DUP until you get to
>> the column that needs to be tweaked.
>
> Cards? Our machine had rows of those little "rice grain" toggle
> switches. We had to (re)enter the program in binary, one byte at a
> time, whenever the machine was reset. 8-)

I only saw front panels on small minis. Any of the "bigger machines"
(that were shared, of necessity) were pretty much "maintained". On
the odd occasion, you might have to load something off tape (DECtape)
but, for the most part, the system was "up" and most jobs were just
submitted on decks of cards. You did your "editing" at a keypunch
terminal in another room (or, a *single* terminal set up for "one off"
quicky changes (like fixing a JCL card in case of an immediate abend).

It was a *delight* to advance to the point of being able to use
an ASR33 w/103 modem to *type* in code! And, having a "local
copy" on PPT... :-/

[I still have an ASR33]

The Reading Machine had a "control panel". Pull the front (cosmetic) panel
off to expose the front panel of the minicomputer. Though, the switches
were sizeable -- like 1/2" wide plastic paddles. But, 16 of them ("data")
grouped in octal triads. Set address. Load data. repeat. Bit-switch in
your diagnostic, a loader, etc.

And, count on the little ferrite cores to "remember" for you!

[Our first *DRAM* machine was disturbing! "You mean it *forgets* when
it powers off??"]

[rickman]

On 3/13/2015 8:04 PM, Tim Wescott wrote:
> On Fri, 13 Mar 2015 15:03:09 -0700, Don Y wrote:
>
>> Hi Tim,
>>
>> On 3/13/2015 2:27 PM, Tim Wescott wrote:
>>> The title says most of it.
>>>
>>> I'm working on a project for which the customer wants a lot of
>>> flexibility to customize a product. The existing "macro language" is
>>> ancient (ca 1985), cryptic (it looks like machine language), limited,
>>> clunky, etc. The customer is willing to change.
>>>
>>> I'm planning on having a chunk of serial flash (or an SD card) with a
>>> file system on it (maybe FAT, maybe something home-rolled and
>>> primitive). Scripts will be stored as text files, and read in as
>>> appropriate.

>>>
>>> Rather than just use some clunky cryptic and limited language that's
>>> unique to the problem and to me (and charging my customer up the wazoo
>>> for it), I'd like to use something that's open-source and available.
>>> Something that uses modest resources is to be preferred -- my
>>> understanding is that I can expect Lua to use about 100k of flash,
>>> which is a bit much for me but bearable. I don't know how Tcl compares
>>> -- I just know that it's an alternative.
>>>

>>> So -- anyone have any direct experience with either of these, or with
>>> something else? We briefly considered Java, but it just looks entirely
>>> too big -- it would basically drive us to use Linux or some other
>>> "real" OS (even the little linuxes are too big for my tastes) -- I'd
>>> really rather just have a scripting engine that gets called whenever a
>>> script needs to run, and otherwise doesn't need much hand-holding from
>>> the application code.
>>>
>>> I'm looking for opinions, so fire away!
>>

> << smart-assery snipped >>
>>
>> As to *your* question...
>>
>> What sorts of things does the customer expect to *do* with those
>> scripts?
>> And, (besides space) what other constraints are you needing to place on
>> those actions? E.g., any timeliness constraints? Performance?
>> Numerical precision? etc.
>>
>> Who is the intended user: *just* the client? Or, will these things be
>> exposed to users?
>>
>> What sorts of things do the scripts interact with (displays, etc.)?
>> E.g., do you need to be able to manipulate a GUI without constraint?
>> Or, are you just serving up text and/or canned dialogs?
>>
>> What sort of user input device (keyboard, keypad, etc.)? Other I/O's?
>>
>> I opted for a (bastardized) Limbo as my scripting language. But, I use
>> it to generate "real" applications and not just automate some
>> preexisting actions. However, it won't fit your memory requirements.
>>
>> Can you tolerate something as "crude" as a bastardized BASIC? I.e.,
>> add "product specific" hooks to it to address some of the special needs
>> (displays, etc.) at a "native" level. A BASIC interpreter/compiler can
>> be really small.
>>
>> The same can be said of C interpreters, mini-compilers (JIT). But,
>> you'd be targeting a different class of "developer" (user).
>
> The product will have a character display, and it'll store text files for
> later retrieval. It has a measurement thingie (I don't want to get too
> specific -- but it makes measurements) that'll cough up a number when it's
> actuated, and it has a sea of (well, around 100) buttons that the user can
> press.
>
> My intention at the moment is to make the box this big dumb thing with
> some system code that knows to call a function for each measurement and
> button press (i.e., when the user presses button 1, the function named
> "button_1" will get called if it exists). Then I'll encode the actual
> functionality as a bunch of functions in the language-o-choice.
>
> The nice thing about this is that if a user comes up with some desired
> customization (which we expect, as we're replacing an existing product for
> which this was common), we can either tell them to start coding and have
> fun, or we can charge them $$ to code the thing up to their specifications.
>
> The real driver for wanting to do this as a scripting language is to make
> it easy for the user to customize. I'm imagining that some users won't
> want to touch the customization with a 10 foot pole, some will be happy to
> customize a button or two, some will get their feet wet and then call us,
> and some will go whole hog with the thing, and do entire systems without
> us even knowing it's going on.

I think what you are describing is Forth. There are two commercial
vendors, MPE and Forth Inc. I know the MPE license allows you to embed
the "interpreter" into your product for the customer to use. There are
also open source Forths around, but with varying levels of embeddability
and support. One is Mecrisp which is available for a few of the many
ARM processors around and the TMS430 I believe. There are many others.

Forth can be idiot simple to use. The assumption is it has a serial
terminal for I/O or something much like it. I/O can be redirected
from/to files or anything else by using deferred words. It can run on
the bare metal or under an OS. You can give as much power to your
customer as you think they can handle or as little as you think is wise.

I've cross posted this to the forth group to get input from some of the
regulars there.

Oh, about the "file system". If you are happy with no file system at
all, Forth can treat your storage as "blocks" of 1 KB and no real files
at all. You can't get much simpler than that.

--

Rick

[Stephen Pelc]

On Fri, 13 Mar 2015 16:27:12 -0500, Tim Wescott
<seemyw...@myfooter.really> wrote:

>I'm planning on having a chunk of serial flash (or an SD card) with a file
>system on it (maybe FAT, maybe something home-rolled and primitive).
>Scripts will be stored as text files, and read in as appropriate.
>
>Rather than just use some clunky cryptic and limited language that's
>unique to the problem and to me (and charging my customer up the wazoo for
>it), I'd like to use something that's open-source and available.

There are a number of Forth systems out there that fit the bill,
including ours. A basic multi-tasking Forth system with SD card
driver, FAT file system and file API layer can be done in around
32 kb of Flash on a Cortex-Mx class CPU.

Note that our Forth systems are proprietary, not FOSS.

Our website and contact details are below.

[Robert Wessel]

On Tue, 17 Mar 2015 23:32:50 -0700, Don Y <th...@is.not.me.com> wrote:

>On 3/17/2015 10:50 PM, George Neuner wrote:
>> On Tue, 17 Mar 2015 19:36:34 -0700, Don Y <th...@is.not.me.com> wrote:
>>
>>> I prefer real names for things instead of yet another cryptic "special
>>> combination" of symbols. One of limbo's problems is it's not very
>>> effective as a "read over the phone" language. (unless you preagree
>>> as to how to name particular character combinations: -> <- => :: etc)
>>
>> I've never had to read - or listen to - code over the phone. 8-)
>
>You have vision. How would a blind user "see" the code? How
>would I tell him what to write to solve one of his problems?
>
>[I've fed various sources into several different speech synthesizers,
>haptic interfaces, etc. It is only then that you truly realize how much
>our programming languages have come to rely on "symbols"]
>
>Or, do you just exclude them from that technology? :> One of the
>driving motivations for my current project is accessibility -- in more
>than just a "token" sense.
>
>As I said, you can adopt *conventions* to make what you see more
>readily conveyed in (e.g., spoken) conversation. E.g., I'd never
>say "colon colon equals" when reading an Algol fragment to someone...

I've advocated using Victor Borge's approach. But alas, I seem not to
be taken seriously...

[Paul E Bennett]

rickman wrote:

[%X]

>> The real driver for wanting to do this as a scripting language is to make
>> it easy for the user to customize. I'm imagining that some users won't
>> want to touch the customization with a 10 foot pole, some will be happy
>> to customize a button or two, some will get their feet wet and then call
>> us, and some will go whole hog with the thing, and do entire systems
>> without us even knowing it's going on.
>
> I think what you are describing is Forth. There are two commercial
> vendors, MPE and Forth Inc. I know the MPE license allows you to embed
> the "interpreter" into your product for the customer to use. There are
> also open source Forths around, but with varying levels of embeddability
> and support. One is Mecrisp which is available for a few of the many
> ARM processors around and the TMS430 I believe. There are many others.
>
> Forth can be idiot simple to use. The assumption is it has a serial
> terminal for I/O or something much like it. I/O can be redirected
> from/to files or anything else by using deferred words. It can run on
> the bare metal or under an OS. You can give as much power to your
> customer as you think they can handle or as little as you think is wise.
>
> I've cross posted this to the forth group to get input from some of the
> regulars there.
>
> Oh, about the "file system". If you are happy with no file system at
> all, Forth can treat your storage as "blocks" of 1 KB and no real files
> at all. You can't get much simpler than that.

Sometimes don't you wish Usenet had a "Like" button?

MPE's VxfForth is probably best for most of the platforms you are likely to
be dealing with these days. I do recall suggesting Forth earlier in this
thread. You really can design the script language you want and make it seem
quite natural to the user.

--
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E....@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1392-426688
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[Don Y]

On 3/18/2015 3:30 AM, Robert Wessel wrote:

>>>> I prefer real names for things instead of yet another cryptic "special
>>>> combination" of symbols. One of limbo's problems is it's not very
>>>> effective as a "read over the phone" language. (unless you preagree
>>>> as to how to name particular character combinations: -> <- => :: etc)
>>>
>>> I've never had to read - or listen to - code over the phone. 8-)
>>
>> You have vision. How would a blind user "see" the code? How
>> would I tell him what to write to solve one of his problems?

>> Or, do you just exclude them from that technology? :> One of the
>> driving motivations for my current project is accessibility -- in more
>> than just a "token" sense.
>>
>> As I said, you can adopt *conventions* to make what you see more
>> readily conveyed in (e.g., spoken) conversation. E.g., I'd never
>> say "colon colon equals" when reading an Algol fragment to someone...
>
> I've advocated using Victor Borge's approach. But alas, I seem not to
> be taken seriously...

Not sure I follow. Wasn't he the wonky pianist/comic?

[Robert Wessel]

Yes, one of the things he was famous for was a routine in which he'd
read something, and pronounce all the punctuation.

https://www.youtube.com/watch?v=6bpIbdZhrzA

[Don Y]

Ah! I'd only heard him playing piano with sheet music upside down, wearing
a seat belt to the piano bench, etc.

A programmer can exercise some control/discipline over his/her choice of
identifiers *if* non-grapheme output is a goal. But, the *language*
tends to give very little flexibility in how and where symbols are used.
Do you really need (want) to hear "open paren" <expression> "closed paren"
for every conditional? loop? etc.?

You can create "modes" whereby special types of "displays" are interpreted
according to a different set of rules (e.g., read "==" as "is equal to"
and "=" as "gets", etc.). But, the more of these you encounter as a
matter of course in a given bit of "input", the more taxing it gets
to become.

Nonsense example (unchecked for correctness/syntax -- but, everything over
which the developer has control has been chosen to be "pronounceable";
all other "words" are defined by the language):

implement fudge;
include "sys.m";
sys: Sys;

SHORT, MEDIUM, LONG: con iota;
FOREVER: con 1;

text: list of string;
pipe: chan of (string, int);

init(args: list of string): int
{
argv = tl args;
argc = len argv;

sys = load Sys Sys->PATH;

spawn consumer(pipe);

while (argc > 0) {
line := hd argv;
argv = tl argv;
argc--;

size := LONG; // assumption else otherwise
if (line == nil) {
break;
} else if (len line < 10) {
size = SHORT;
} else if (len line < 40) {
size = MEDIUM;
}

pipe <-= (line, size);
text = line :: text;
}
...
return 0;
}

consumer(hose: chan of (string,int))
{
input: string;
size: int;
shorts, mediums, longs := 0;

while (FOREVER) {
(input, size) =<- hose;

case size {
SHORT =>
shorts++;
MEDIUM =>
mediums++;
LONG =>
LONGS++;
* =>
/* can't happen */
exit;
}

sys->print("Received '%s'\n", input);
}
}

[George Neuner]

On Tue, 17 Mar 2015 23:32:50 -0700, Don Y <th...@is.not.me.com> wrote:

>On 3/17/2015 10:50 PM, George Neuner wrote:
>
>> I've never had to read - or listen to - code over the phone. 8-)
>
>You have vision. How would a blind user "see" the code? How
>would I tell him what to write to solve one of his problems?

I wouldn't expect a blind user - or ANY user for that matter - to be
reading code. At most I would expect to be read some error messages.
*Those* should be able to be pronounced by a screen reader.

>Or, do you just exclude them from that technology?

No. I expect blind and deaf to be abe to use things, but I don't
expect any non-technical person (~95% of the population) to be
programming them.

George

[Matthias Koch]

Hi Tim,

I am the author of Mecrisp-Stellaris, a Forth implementation that compiles to native code on the target and needs 16 kb Flash and about 1.5 kb RAM on an ARM Cortex M0/M3/M4 for its core when used standalone. RAM is necessary mostly for input buffers and its two stacks. As you called for Open Source, I think you are fine with GPL3 licencing ? If you are, then I am there for your help. Until now, Mecrisp-Stellaris is designed to be monolithic, but you can change initialisation code, memory map and interrupt handling for your needs. Something you still need to think of is wiring the parts of your code which should be user available into the dictionary and do parameters-on-stack interfaces for them.

If you like to try, Mecrisp-Stellaris already runs on chips from TI, STM, Freescale and NXP. An emulator for a Freescale M0 target running on Linux is included.

Best wishes from Germany,
Matthias Koch
mecrisp.sourceforge.net

[Don Y]

On 3/18/2015 11:09 PM, George Neuner wrote:
> On Tue, 17 Mar 2015 23:32:50 -0700, Don Y <th...@is.not.me.com> wrote:
>
>> On 3/17/2015 10:50 PM, George Neuner wrote:
>>
>>> I've never had to read - or listen to - code over the phone. 8-)
>>
>> You have vision. How would a blind user "see" the code? How
>> would I tell him what to write to solve one of his problems?
>
> I wouldn't expect a blind user - or ANY user for that matter - to be
> reading code. At most I would expect to be read some error messages.
> *Those* should be able to be pronounced by a screen reader.

So, they should *hire* folks to customize things to their needs?

bedtime() {
if (stove on)
warn("You left the stove on!")
if (door unlocked)
warn("Don't forget to lock the door!")
if (garage open)
warn("Don't forget to close the garage!")
if (lights on) {
warn("There are still some lights unexpectedly left on. "\
"Should I shut them off?")
if (yes)
lights(off)
}
heat(bedtime)

}

>> Or, do you just exclude them from that technology?
>
> No. I expect blind and deaf to be abe to use things, but I don't
> expect any non-technical person (~95% of the population) to be
> programming them.

I think that is changing. Things are getting too complex for a
"one size fits all" approach to all users.

"Non-programmers" already write macros in Excel, Word, etc.
And, even write VB scripts "without formal training". I don't
think it a stretch to assume they'll be able to "code" these
sorts of things -- esp if there are very high level abstractions
at their disposal.

[George Neuner]

On Thu, 19 Mar 2015 12:04:01 -0700, Don Y <th...@is.not.me.com> wrote:

>On 3/18/2015 11:09 PM, George Neuner wrote:
>
>> I wouldn't expect a blind user - or ANY user for that matter - to be
>> reading code. At most I would expect to be read some error messages.
>> *Those* should be able to be pronounced by a screen reader.
>
>So, they should *hire* folks to customize things to their needs?

No. For the vast overwhelming majority of users, customization should
*not* require manually writing (or even editing) a script. See below.

>>> Or, do you just exclude them from that technology?
>>
>> No. I expect blind and deaf to be abe to use things, but I don't
>> expect any non-technical person (~95% of the population) to be
>> programming them.
>
>I think that is changing. Things are getting too complex for a
>"one size fits all" approach to all users.

I didn't say anything about "one size fits all". I said the vast
majority of people should not be programming - an understatement to be
sure.

The best way I have seen has been "menu" [includes icons] driven UIs
that let people select functions and point out data to operate on, and
then generate the script. They can't guarantee the script will do
what the user wants, but they can guarantee that it is free from
stupid errors. Combined with operations that are intrinsically safe,
this is a good way to allow user customization.

It is, however, more heavyweight than a telnet session with a line
editor.

>"Non-programmers" already write macros in Excel, Word, etc.
>And, even write VB scripts "without formal training". I don't
>think it a stretch to assume they'll be able to "code" these
>sorts of things -- esp if there are very high level abstractions
>at their disposal.

Actually, the ability to write a Word or Excel macro says absolutely
nothing about the ability to write, e.g., a correct shell or Python
(or whatever) script. When a macro barfs, you can reload the file and
try again. When a script barfs, it may destroy the data it was
manipulating. Every day businesses suffer lost data and lost
productive hours due to amateurs writing "programs".

*Your* scripting language may be intrinsically safe, but that doesn't
invalidate my point.

George

[Don Y]

On 3/19/2015 2:52 PM, George Neuner wrote:
> On Thu, 19 Mar 2015 12:04:01 -0700, Don Y <th...@is.not.me.com> wrote:
>> On 3/18/2015 11:09 PM, George Neuner wrote:
>>
>>> I wouldn't expect a blind user - or ANY user for that matter - to be
>>> reading code. At most I would expect to be read some error messages.
>>> *Those* should be able to be pronounced by a screen reader.
>>
>> So, they should *hire* folks to customize things to their needs?
>
> No. For the vast overwhelming majority of users, customization should
> *not* require manually writing (or even editing) a script. See below.

That only makes sense for "trivial" systems where the only things
a user would want to change are "drop in" items (e.g., a ring-tone
on a phone).

When you want to program *behaviors*, you can't expect the way one person
(or even one *class*/group of people) to behave to bear any relationship
to some other group.

Unless you try to build a "be all" system with umpteen "configuration
options" that you grill the user about.

wakeup()
{
#if USER_DRINKS_COFFEE
power_up(coffeepot);
#endif

#if USER_DISLIKES_BRIGHT_LIGHT_ON_AWAKENING
lights(kitchen, dim);
#else
lights(kitchen, bright);
#endif

#if USER_LISTENS_TO_NEWS_WHILE_SHAVING
audio(bathroom, radio(news_channel));
#endif

#if USER_SHOWERS_IN_MORNING
hot_water_heater(on);
#endif

...

>>>> Or, do you just exclude them from that technology?
>>>
>>> No. I expect blind and deaf to be abe to use things, but I don't
>>> expect any non-technical person (~95% of the population) to be
>>> programming them.
>>
>> I think that is changing. Things are getting too complex for a
>> "one size fits all" approach to all users.
>
> I didn't say anything about "one size fits all". I said the vast
> majority of people should not be programming - an understatement to be
> sure.

I don't think that's the case, anymore.

How many appliances require some sort of "customization"? How does
a blind user configure his wireless router? Firewall? "Program"
his TV/cable box/DVR/XM radio? (do they even *have* provisions to
present data in a non-visual form?)

We were looking at refrigerators the other night. How would I know
the current temperature setting -- *buy* a talking thermometer and
leave it in the frig for a while?? How would I know if the "extra
compartment" was currently configured as a freezer, refrigerator or
"soft freezer"?

Everything is getting more "customizable". And those customizations are
becoming more *dynamic* in nature. It's not just a "set and forget"
sort of thing.

> The best way I have seen has been "menu" [includes icons] driven UIs
> that let people select functions and point out data to operate on, and
> then generate the script.

Yes, that's how my *interactive* user interface works. Because menus
can be easily presented in various output modalities (speech, haptic,
visual, etc.).

> They can't guarantee the script will do
> what the user wants, but they can guarantee that it is free from
> stupid errors. Combined with operations that are intrinsically safe,
> this is a good way to allow user customization.
>
> It is, however, more heavyweight than a telnet session with a line
> editor.
>
>> "Non-programmers" already write macros in Excel, Word, etc.
>> And, even write VB scripts "without formal training". I don't
>> think it a stretch to assume they'll be able to "code" these
>> sorts of things -- esp if there are very high level abstractions
>> at their disposal.
>
> Actually, the ability to write a Word or Excel macro says absolutely
> nothing about the ability to write, e.g., a correct shell or Python
> (or whatever) script.

Of course! But, PREVENTING them from writing a script -- or, typing
in a script that is read to them over the phone by one of their
friends/colleagues/etc. -- isn't a solution. And, relying on a
"language" that is prone to casual errors (e.g., "==" vs. "="
bites "experienced programmers"!) just makes the problem worse.

When you discuss a piece of code with a colleague, do you pronounce
every punctuation mark? Chances are, you adapt your presentation
(discussion) style to your expectations of the other party's capabilities.

Limbo, for example, forces me to distinguish between ':', ':=' and '='
far too often. Even when the person I'm talking too can *see* what
I've just described ("Hmmm... where did you *declare* x? I guess this
'x =' should really have been an 'x :=')

In the past, I would often "proof" PCB layouts against schematics with
colleagues (in the days when we did this sort of stuff by hand -- with
tape and rubilyth). One of us would trace signals on the schematic
while the other traced foils on the layout. If I was confident in
the abilities of my "counterpart", I'd say something like:
"D1 to C5 to J1 pin 3"
for a particular signal/foil path. If I *wasn't* confident in their
abilities, I'd be far more explicit:
"cathode of D1 to anode of C5 and on to pin 3 of J1"

When you're dealing with a "casual user", you have to be more
explicit -- OR, use a language that doesn't introduce "unspoken"
items into the dialog (e.g., punctuation, whitespace, etc.).

> When a macro barfs, you can reload the file and
> try again. When a script barfs, it may destroy the data it was
> manipulating. Every day businesses suffer lost data and lost
> productive hours due to amateurs writing "programs".

Sure! But that's usually because they don't have the ability (and
inclination) to easily and thoroughly *test* what they've written!
Or, do so in a "safe" manner. And, is compounded by folks trying to
do too much *in* a "program" (contrast this with my "bedtime()"
script).

> *Your* scripting language may be intrinsically safe, but that doesn't
> invalidate my point.

The whole move towards the "safer" programming environments (and those
are really only intended for "REAL" programmers) indicates that programs
can't continue to be intricate, error prone creations. The system
designer/implementer(s) have to consider the abstractions that they
present to the "user" (programmer?) to maximize the chances of the
user "getting it right".

E.g., I don't expect folks to write SQL to extract the information
they require from my DBMS. Rather, I provide a more abstract interface
that focuses on what the user (of that particular dataset) is likely
to want to do to/with that data.

answer_phone()
{
result = lookup(phone_book, calling_number);
case result {
"friend" =>
reply("Don's not home, right now. Leave a message.")
"employer" =>
reply("Don's on the can! Could he call you back?")
"SO" =>
reply("I'm on my way! See you soon!")
"police" =>
reply("No habla ingles")
* =>
play(Disconnected_Pipe_tones)
voice(Generic_Telephone_Operator_Lady)
reply("We're sorry. The number you have dialed is no
longer in service. Please check the number and
dial again."
log(phone_log, calling_number, time)
}
}

By way of example, there should be no need to specify a "time" argument
in the log() invocation; it should automatically stamp each message
with the time the function was invoked (as that's *probably* of
interest to anyone using the facility).

Note that this code fragment has lots hiding *behind* it. But,
none of that stuff should be of concern to the person writing it!
Nor is it an unusual desire for a typical user (though his choices
of categories and associated actions may vary).

It's no different than someone posting a message here (or in a forum)
asking "how do I configure my FOOMATIC2000?" Or, "How do I fix this
problem with that piece of equipment?" etc. You don't have to
(necessarily) *know* how the code works -- and certainly don't
have to know how to write it "from scratch" (many "programmers" can't
work from a blank sheet of paper!). But, you should be able to
"type it in" without stumbling over "invisible" symbols/punctuation...

[George Neuner]

On Thu, 19 Mar 2015 15:44:44 -0700, Don Y <th...@is.not.me.com> wrote:

>On 3/19/2015 2:52 PM, George Neuner wrote:
>
>When you want to program *behaviors*, you can't expect the way one person
>(or even one *class*/group of people) to behave to bear any relationship
>to some other group.
>
>Unless you try to build a "be all" system with umpteen "configuration
>options" that you grill the user about.

That's why there are AI systems that learn by doing. You don't ask
anything, just monitor and see what repetitious behavior falls out.


>>> ... Things are getting too complex for a

>>> "one size fits all" approach to all users.
>>
>> I didn't say anything about "one size fits all". I said the vast
>> majority of people should not be programming - an understatement to be
>> sure.
>
>I don't think that's the case, anymore.
>
>How many appliances require some sort of "customization"? How does
>a blind user configure his wireless router? Firewall? "Program"
>his TV/cable box/DVR/XM radio? (do they even *have* provisions to
>present data in a non-visual form?)

This may sound insensitive, but I rather doubt many blind users
configure these things much at all.

I have a very good friend who is almost completely blind ... he
perceives only light and dark ... and I see where he adapts the
surroundings and where he adapts *to* the surroundings.

My brother-in-law teaches at a school for the disabled. Some of his
students are blind, some are deaf and most have other disabilities as
well. I have seen much the same behaviors there ... they learn to
deal with things as they are introduced to them and don't mess around
too much.

Despite that, they accomplish a great deal. Might they accomplish
more if their surroundings were more individually friendly? Probably.
OTOH, if they walk into something because it was "customized" for
someone else, they might get hurt. And if they sit down to a computer
that is customized for someone else, they might be unable to do
anything at all. So it's a trade-off: standardize the environment and
everyone can do something. Customize it and perhaps nobody can do
anything.

>We were looking at refrigerators the other night. How would I know
>the current temperature setting -- *buy* a talking thermometer and
>leave it in the frig for a while?? How would I know if the "extra
>compartment" was currently configured as a freezer, refrigerator or
>"soft freezer"?
>
>Everything is getting more "customizable". And those customizations are
>becoming more *dynamic* in nature. It's not just a "set and forget"
>sort of thing.

And my question to that is "who the hell needs that?" For 250 years
[the "refrigerator" was invented in 1755], the refrigerator was a dumb
box and it worked just fine.

Despite what some people think, every goddamn thing does not need a
computer brain, and for most people the majority of things need very
little in the way of customization.

>When you discuss a piece of code with a colleague, do you pronounce
>every punctuation mark? Chances are, you adapt your presentation
>(discussion) style to your expectations of the other party's capabilities.

I don't recite a piece of code to anyone - they look at it themselves.
Likewise no one recites code to me - I look at it myself.

I used to know a vision impaired programmer who used a braille reader
and keyboard. I never worked directly with him, but he worked very
much like I did (and do): when he collaborated with other people they
would pass code back and forth with markup and comment.

I doubt there are even a handful of people who could successfully
write a non-trivial program via voice reader: it is too much context
to hold onto.

It is said that Stephen Hawking could hold and manipulate all the
equations in his head. But he is a genius - most people are not.

>When you're dealing with a "casual user", you have to be more
>explicit -- OR, use a language that doesn't introduce "unspoken"
>items into the dialog (e.g., punctuation, whitespace, etc.).

Show me a language with no (equivalent of) whitespace.

It's a fallacy to think that you somehow are reducing complexity by
renaming what you consider to be "cryptic" symbols. It doesn't matter
whether the symbol is represented by the character '=>*' or the word
'arrow-star' ... the person using it still has to understand what it
means.

And to repeat myself - why are you reciting it over the phone? Send a
goddamn fax, or an email, or a tweet, or a text message and let them
"read" it (for some definition of "read") for themselves.

>The whole move towards the "safer" programming environments (and those
>are really only intended for "REAL" programmers) indicates that programs
>can't continue to be intricate, error prone creations. The system
>designer/implementer(s) have to consider the abstractions that they
>present to the "user" (programmer?) to maximize the chances of the
>user "getting it right".

That's one way to look at it. The other way is there are a whole lot
of people who are charitably called "programmers" and who would be
doing the world a favor if they did something else.


This isn't going anywhere. We should just agree to disagree.
George

[David Brown]

On 20/03/15 07:38, George Neuner wrote:
> On Thu, 19 Mar 2015 15:44:44 -0700, Don Y <th...@is.not.me.com> wrote:
>
>> On 3/19/2015 2:52 PM, George Neuner wrote:
>>
>> When you want to program *behaviors*, you can't expect the way one person
>> (or even one *class*/group of people) to behave to bear any relationship
>> to some other group.
>>
>> Unless you try to build a "be all" system with umpteen "configuration
>> options" that you grill the user about.
>
> That's why there are AI systems that learn by doing. You don't ask
> anything, just monitor and see what repetitious behavior falls out.
>
>
>>>> ... Things are getting too complex for a
>>>> "one size fits all" approach to all users.
>>>
>>> I didn't say anything about "one size fits all". I said the vast
>>> majority of people should not be programming - an understatement to be
>>> sure.
>>
>> I don't think that's the case, anymore.
>>
>> How many appliances require some sort of "customization"? How does
>> a blind user configure his wireless router? Firewall? "Program"
>> his TV/cable box/DVR/XM radio? (do they even *have* provisions to
>> present data in a non-visual form?)
>
> This may sound insensitive, but I rather doubt many blind users
> configure these things much at all.
>

The reality is that very few users of any sort configure these things.
I'd guess that something like 95% of households in developed countries
have a firewall/router device. And I would guess that 90% of these have
never configured or customised anything on them beyond the bare minimum
of picking a wireless SSID and password by following the "getting
started" instructions. And well more than half of /those/ will have
been set up by a friend, other family member, or the neighbour's teenager.

The great majority of people don't need "customisation" - they need
things to work out of the box. And for the little that needs done, such
as setting the time on the VCR, why would you need a special interface
for blind people or other disabled users? They can do what most other
people do - ask someone for help.

(This is not being callous - we all have things we can do ourselves, and
things we need help for. I can configure firewalls, but if something
goes wrong with the car I ask my car-enthusiast neighbour or take it to
the mechanic.)



(I've snipped the rest of your post, because I only wanted to add this
one comment. But it was a very interesting and informative post - I'm
glad Usenet has no "like" or "+1" button, but if it did, it would have
got one from me.)

[Don Y]

Hi George,

On 3/19/2015 11:38 PM, George Neuner wrote:
> On Thu, 19 Mar 2015 15:44:44 -0700, Don Y <th...@is.not.me.com> wrote:
>
>> On 3/19/2015 2:52 PM, George Neuner wrote:
>>
>> When you want to program *behaviors*, you can't expect the way one person
>> (or even one *class*/group of people) to behave to bear any relationship
>> to some other group.
>>
>> Unless you try to build a "be all" system with umpteen "configuration
>> options" that you grill the user about.
>
> That's why there are AI systems that learn by doing. You don't ask
> anything, just monitor and see what repetitious behavior falls out.

So, release a product that assumes *nothing* and let EVERYONE deal with
the learning issue? (i.e., why tailor a "default release" to one group
over another? Do you canvas the entire market and figure out what the
"best" group to target is *likely* to be? What if they don't end up
being the *actual* customers?)

>>>> ... Things are getting too complex for a
>>>> "one size fits all" approach to all users.
>>>
>>> I didn't say anything about "one size fits all". I said the vast
>>> majority of people should not be programming - an understatement to be
>>> sure.
>>
>> I don't think that's the case, anymore.
>>
>> How many appliances require some sort of "customization"? How does
>> a blind user configure his wireless router? Firewall? "Program"
>> his TV/cable box/DVR/XM radio? (do they even *have* provisions to
>> present data in a non-visual form?)
>
> This may sound insensitive, but I rather doubt many blind users
> configure these things much at all.

Because they *can't*. A "display reader" (i.e., decode N-digit 7-segment
displays) has been high on the wish-list of many blind/VI folks for many
years. What's that digital clock say? How much time is remaining on
the count-down timer on the microwave oven? (when will my biscotti
be ready to come out of the oven?)

> I have a very good friend who is almost completely blind ... he
> perceives only light and dark ... and I see where he adapts the
> surroundings and where he adapts *to* the surroundings.

I'm sure he doesn't let others arrange *his* surroundings and then
learns what they are! Anything he has control over he undoubtedly
opts to arrange himself.

> My brother-in-law teaches at a school for the disabled. Some of his
> students are blind, some are deaf and most have other disabilities as
> well. I have seen much the same behaviors there ... they learn to
> deal with things as they are introduced to them and don't mess around
> too much.

Again, because they are *forced* to do so! Look at how long it has taken
to get *money* that can be resolved without visual cues: all paper money
here is the same size, same basic color. And that's something that's
essential to "living"!

You will also see that people address disabilities differently depending on
when they encounter them in their life. E.g., blind from birth is different
that losing vision to diabetic retinopathy, macular degeneration, etc.
Folks who lose their vision later in life tend to have no real recourse:
too late to learn braille (and neuropathy from e.g., diabetes, can make
it too difficult to gain the tactile sensitivity to resolve braille) to
any effective degree.

If you lost your vision *today*, would you suddenly be incompetent as
a programmer? Could you not "visualize" code fragments in enough detail
to compose a working script *if* you could see what you were "writing"?

People losing their (central) vision later in life end up "dealing with"
the loss -- by simply realizing it *is* a loss; gone along with the
things that relied upon it (reading, driving, setting the household
thermostat, etc.)

> Despite that, they accomplish a great deal. Might they accomplish
> more if their surroundings were more individually friendly? Probably.
> OTOH, if they walk into something because it was "customized" for
> someone else, they might get hurt. And if they sit down to a computer
> that is customized for someone else, they might be unable to do
> anything at all. So it's a trade-off: standardize the environment and
> everyone can do something. Customize it and perhaps nobody can do
> anything.

So, all computers should be standardized? Anything that *could* be
customized *shouldn't* -- because it wouldn't be a uniform interface
for *all*? Perhaps the seats in cars should all have their adjustment
disabled? Or, at least forced to be located in a particular location
so folks can access them "universally"? Perhaps automatically returning
to some "default" position when they sense the occupant getting off?

That's just silly. What you want is to tailor customizations to individuals.
E.g., *my* house should be set up for *my* needs; not those of some "nominal
occupant". When we have house guests, we don't expect them to *know* where
the clean linens are located. Or, where the trash basket in the *kitchen*
is located (is it behind *this* cabinet? Or, *that* one? Or, perhaps
somewhere else entirely??) or the clean glassware/dinnerware, etc.

Yet, no one has ever died of thirst, here, for want of a drinking glass.
Or, come wandering out of the shower au naturel because they couldn't find
fresh towels.

My solution is to tie the customizations *to* the individual. So when *I*
interact with it, it behaves as *I* expect it to behave. Yet, when
another person standing beside me interacts, it reacts *differently* -- as
*they* expect.

>> We were looking at refrigerators the other night. How would I know
>> the current temperature setting -- *buy* a talking thermometer and
>> leave it in the frig for a while?? How would I know if the "extra
>> compartment" was currently configured as a freezer, refrigerator or
>> "soft freezer"?
>>
>> Everything is getting more "customizable". And those customizations are
>> becoming more *dynamic* in nature. It's not just a "set and forget"
>> sort of thing.
>
> And my question to that is "who the hell needs that?" For 250 years
> [the "refrigerator" was invented in 1755], the refrigerator was a dumb
> box and it worked just fine.

Then why aren't we all waiting for routine deliveries of *ice* (for our
"ice boxes")? Refrigerators have, for years, allowed the temperature of
the freezer and refrigeration compartments to be independently set (within
reason). I've owned refrigerators that allowed the butter compartment to
have yet another setting! Newer refrigerators add a third compartment
that can be used as additional freezer space, refrigerator space or
something between the two extremes. (i.e., an extra evaporator is
added along with another set of controls for it)

The *coming* refrigerators (as well as other appliances) go beyond this
and actually try to track *consumption*: "You're out of milk!" How
much of this is toy vs. utility? <shrug> How much is carrying a phone
in your pocket a "toy" vs. "utility"?

While I don't need an appliance to prepare my weekly shopping list, it
sure would be nice if, on an unexpected stop at the grocery store, I could
check to see if I had any broccoli on hand so I could exploit the unannounced
sale on flank steak (sure don't want to buy *more* broccoli if I don't need
it! OTOH, would be chagrined to return home and discover I had none and
now need to make another trip out if I want to prepare "beef with broccoli")

Should I, instead, discipline myself to ALWAYS carry a list of my "foodstuffs
inventory" on hand just in case the need arises? Or, shrug it off and just
resolve myself to making another (avoidable) trip back to the store?

> Despite what some people think, every goddamn thing does not need a
> computer brain, and for most people the majority of things need very
> little in the way of customization.

Sure! We can settle on a standard layout for furnishings in our homes,
a standard placement of items in kitchen cupboards/drawers, a standard
set of TV channels on all sets, ditto for radio stations, etc. Imagine
how much easier it would be to know you just had to hit "next station" 7
times to get to the station you *prefered* -- instead of having a
"favorite" -- REGARDLESS OF WHOSE HOME YOU WERE IN!

Homes should all be heated to 70F and cooled to 80F. These temperatures
should be in place over the period M-F7A-10P and allowed to drift lower/higher
by no more than 5 degrees during the "sleep hours". Everyone should work 9A-5P
lest they find themselves working when the HVAC assumes they are asleep.

We should all listen to the same music and in the same sequence. Heck,
maybe at the same *times* (so you would know what time to tune in when
you want to hear a particular song).

All phones should be black. No need for wallpaper on computer screens.
All text should be displayed in courier -- and the same size! Newspapers
(electronic or otherwise) should all be read in a fixed sequence. All
articles should be read in their entirety (no need for bookmarks).

>> When you discuss a piece of code with a colleague, do you pronounce
>> every punctuation mark? Chances are, you adapt your presentation
>> (discussion) style to your expectations of the other party's capabilities.
>
> I don't recite a piece of code to anyone - they look at it themselves.
> Likewise no one recites code to me - I look at it myself.

Then you're dealing with sighted people who are "connected" to your source
code in some way. You;ve never had to dictate a code fragment to someone
on a field service call across the country.

> I used to know a vision impaired programmer who used a braille reader
> and keyboard. I never worked directly with him, but he worked very
> much like I did (and do): when he collaborated with other people they
> would pass code back and forth with markup and comment.

Did you ever *look* at his "display"? Ever ask him what he would
change *if* he could change it? I.e., if he wasn't "forced" to
"adapt to it"?

A standard braille line is 40 cells. For *text*, this can be comparable to
a written line of text -- Grade 2 braille supports lots of contractions
that economize on space (along with reading and writing effort). Grade 1
braille would mean you have LESS THAN 40 "(text) characters" available
as a character maps to one (or two) cells.

A '[' requires 2 cells to represent. Amusingly, the *same* 2 cells are
used to represent ']'. The same applies for '(' and ')'! OTOH, open
and close single quotes have different representations. As is the
case for open/close *double* quotes. Curiously, single quotes take
2 cells while double quotes take *one*. And "ditto" marks differ from
each of the above (though require 2 cells). Apostrophe and "accent"
differ from all of the above.

Decimal point is not the same as "period". Numbers are introduced with
a special "number follows" sign (which eats a cell). *Individual* uppercase
letters are preceded with an "uppercase" sign (another cell). Strings of
uppercase letters are introduced with a different sign (two cells).
So, mixed case identifiers get long, fast. Expressions with parenthesized
subexpressions and array references? <frown>

There's no '_' representation.

And, forget about "indent level"! Waste a cell on each layer of indent??
(actually, the rule is to indent *two* cells per level) :<

"Math braille", "Computer braille", "Grade 2 braille", etc.

Then, we can address 8-dot cells -- which use a different set of rules for
encodings (and, which might not be available on all braille displays -- unless
designed with that in mind!).

The following:
/* This is one comment */
struct alist *xp, *findit();
EACH fill an entire braille "line" (ignoring the indent). Most braille
displays are *one* line!

This:
www.cbsnews.com/VIDEO/TV/1503/10/newsitem/some_silly_video.mov
takes *6* lines to represent! (in "print", a braille "page" consists
of 25, 40-cell lines on SINGLE SIDED -- think about it -- 11x11.5 paper)

The point of all this "silly detail" is to show you the consequences
of "adapting to" an existing "system" that was conceived without its
impact on this form of representation. Creating a scripting language
with the same ARBITRARY ignorance of these issues leads to results
that are just as clumsy!

You may want to *candidly* inquire of your blind programmer friend
just what its like dealing with the limitations of his output device.
And, ask him to think about what he *wished* he could impose on
the writers of any code that he's had to read/modify over the years.
If he thinks about it AS IF he really *had* that capability, you'll
be surprised at what issues come up!

[I did this with blind, deaf, physically handicapped, etc. users
many years ago. The biggest problem with those interviews was
getting folks to shed the "I have to adapt" mentality that has
been bred into them -- because they *have* no choice! Ask them
what things would be like if *they* could write the "rules" and
you end up with an entirely different set of criteria! E.g., one
that surprised me from a blind user was wanting products that
don't "look blind"... i.e., look like they were assembled from
off-the-shelf components -- a consequence of low production volumes
and avoidance of high tooling costs -- in someone's GARAGE!
"Make it look sexxy!" "Make it easy to clean (because it's going
to be in my hands a lot and get dirty/greasy from all that handling...
AND, I am unlikely to SEE just how 'disgusting' it LOOKS -- to
sighted folks around me!"]

> I doubt there are even a handful of people who could successfully
> write a non-trivial program via voice reader: it is too much context
> to hold onto.

You can't be serious? *You* couldn't write one of the scripts that
I've described, here? I imagine it would take you just a few minutes...
even dealing with the "audio navigation" issues!

> It is said that Stephen Hawking could hold and manipulate all the
> equations in his head. But he is a genius - most people are not.

Actually, what you learn to value most (with blindness) is MEMORY!
You can't "verify" something "on inspection" so have to REMEMBER how
you left it. And, discipline yourself to leave it the same way
each time (to reduce the number of things that you have to remember).

"Which is the blue shirt that goes best with those black slacks?
And, where the hell *are* those slacks??"

This makes blindness late in life doubly troublesome -- memory tends
to get worse with age; esp STM. (i.e., where you kept the scissors
when you were a CHILD doesn't help you remember where you left them
YESTERDAY!)

>> When you're dealing with a "casual user", you have to be more
>> explicit -- OR, use a language that doesn't introduce "unspoken"
>> items into the dialog (e.g., punctuation, whitespace, etc.).
>
> Show me a language with no (equivalent of) whitespace.

I meant the *significance* of whitespace. So, " " means something
notably different than "\t\t" or "\t ". If someone was reading
*this* to you, would you be aware of the locations of the line breaks?
The dual spaces (or not!) after each "full stop"? The paragraph
breaks?

> It's a fallacy to think that you somehow are reducing complexity by
> renaming what you consider to be "cryptic" symbols. It doesn't matter
> whether the symbol is represented by the character '=>*' or the word
> 'arrow-star' ... the person using it still has to understand what it
> means.

Of course you can reduce complexity! Information gets encoded in
data in a variety of ways.

For example, a language that implicitly terminates each statement/line
at the '\n' doesn't ALSO need an explicit line termination (e.g., ';').
A language that doesn't allow expressions like:
A = B = C = D = 4 + 3
means the "reader" need not be prepared for a second (third, fourth, etc.)
'=' after encountering the first.

A language that encodes data type in the (required) identifier itself
omits the need for explicit type declarations (e.g., FORTRAN i,j,k).

The statement:
A := 3;
"reads" with a lot more complexity than:
A gets 3
yet encodes the same information.

> And to repeat myself - why are you reciting it over the phone? Send a
> goddamn fax, or an email, or a tweet, or a text message and let them
> "read" it (for some definition of "read") for themselves.

I bump into you in the store. You ask how *you* could configure *your*
phone answering system to behave *like* mine. I can recite the pseudo-code
I described (upstream) and, chances are, it will "make sense" to you
(if you've written any code in that language). No need for me to
write it down. No risk that you'll forget that I said "colon equals"
instead of "equals" in some places. For an effective language, you
can "visualize" the algorithm:
"Yeah, that makes sense! Lookup the caller's phone number in a
database (I'll sort out how to build that database as a separate
project). Determine the 'contact category' for the caller.
Then, conditionally execute one of several different types of
actions based on that information. Maybe I'll use an if-tree...
or, perhaps a 'case' (switch) statement."

If the language is cluttered with lots of "magic" that the user
has to remember, then there is far less chance of him getting it
right "quickly".

>> The whole move towards the "safer" programming environments (and those
>> are really only intended for "REAL" programmers) indicates that programs
>> can't continue to be intricate, error prone creations. The system
>> designer/implementer(s) have to consider the abstractions that they
>> present to the "user" (programmer?) to maximize the chances of the
>> user "getting it right".
>
> That's one way to look at it. The other way is there are a whole lot
> of people who are charitably called "programmers" and who would be
> doing the world a favor if they did something else.

No argument, there! But, that's not what's happening. You don't
see employers dismissing lots of candidates and raising payscales
to compete for The Good Ones. Rather, you see them trying to make
use of The NotGood Ones to keep their costs low, reliance on "key"
staff minimized, etc.

I started this project with a bottom-feeding hardware approach: make
the hardware *dirt* cheap. Compensate with cleverer software -- within
the capabilities of that cheap hardware.

But, the reality of the cost differential between "dirt cheap" and
"cheap" made that criterion silly. With "cheap" I can make the
software a lot more capable, extensible and robust. I.e., more
suited to letting others extend it without breaking everything in
the process. (design of OS, complexity of comms, features in
scripting language, etc.)

> This isn't going anywhere. We should just agree to disagree.

Agreed. My goal is to show that systems *can* be accessible in
more than just superficial ways. *And*, to document the costs
of that accessibility in the design process! (it's not "free"
as those adherents would like to believe)

Or, should that be "disagreed"? :>

Time for C's biscotti -- else The Big Frown come morning! :-/

[Don Y]

On 3/20/2015 2:05 AM, David Brown wrote:
> On 20/03/15 07:38, George Neuner wrote:
>> On Thu, 19 Mar 2015 15:44:44 -0700, Don Y <th...@is.not.me.com> wrote:

>>> How many appliances require some sort of "customization"? How does
>>> a blind user configure his wireless router? Firewall? "Program"
>>> his TV/cable box/DVR/XM radio? (do they even *have* provisions to
>>> present data in a non-visual form?)
>>
>> This may sound insensitive, but I rather doubt many blind users
>> configure these things much at all.
>
> The reality is that very few users of any sort configure these things.

That's not the same thing as saying that there is no *need* for them
to be configured/customized.

> I'd
> guess that something like 95% of households in developed countries have a
> firewall/router device. And I would guess that 90% of these have never
> configured or customised anything on them beyond the bare minimum of picking a
> wireless SSID and password by following the "getting started" instructions.

That speaks to a lack of education on the part of the user. And, a
poor design from the manufacturer that *necessitates* such education;
coupled with the realization that sxposing the user to all that
complexity would PROBABLY intimidate the user (and cost the manufacturer
the "sale")

> And well more than half of /those/ will have been set up by a friend, other
> family member, or the neighbour's teenager.
>
> The great majority of people don't need "customisation" - they need things to
> work out of the box.

No, they *want* things to work "out of the box". But, they want them to
work the way *they* want them to work! E.g., the TV should receive the
channels *I* want to watch (and not be cluttered up with all those
extra channels in which I have no interest).

But, they don't want to *pay* (much) for this -- thinking it *should* be
"simple". When it (frequently) turns out that this is not the case
(often because the interface was poorly designed), they either live with
the "inconvenience" (and some level of "disappointment") *or* return
the product and search for something more suitable (or "none") -- see below.

[My first TV had a mute feature -- but one that wasn't "independent";
any other operation would unmute the audio -- so, you couldn't hit mute
and browse channels. My only remedy would have been to replace the
set with one that behaved as better suited *my* intended usage]

> And for the little that needs done, such as setting the
> time on the VCR, why would you need a special interface for blind people or
> other disabled users? They can do what most other people do - ask someone for
> help.

(sigh) In reality, they just "do without". Do *you* LIKE asking people
for help? Esp if it draws attention to your "inability/disability"?
IME, people (handicapped or otherwise) are more prone to hide their
ignorance/inabilities than expose them. How often do folks NOT ask
*their* M.D. for clarification of those "big words" he's using to describe
*their* medical condition?? Or, the side-effects/consequences of the
treatment regimen being indicated? Or, alternatives?? Do they not care?

"Ha! You mean you couldn't figure out how to change the wallpaper
on your monitor?"

[I have a neighbor whose monitor is set to a much lower resolution than
it is capable -- because he didn't KNOW that there was even an adjustment
available and didn't think to ask: "Gee, I've got this huge monitor
but there's never enough 'room' on the screen for everything!"]

Estimates (self-reported by folks in the consumer electronics industry)
suggest that a *huge* portion of product returns boil down to "I can't
figure out how to make this thing do what I *think* it should do".
People will fidget with a device for 15 or 20 minutes and then throw
up their hands in disgust: "Let's just get our money back..."

[Think about that. It approaches the cost of most GENUINE *warranty*
costs!]

People *know* not to use the same password in more than one place;
not to pick an "easy to guess" password; not to write it down anywhere;
etc. And, often, the things that are "at risk" in these cases are
their own *personal* property, information, etc. Yet, *setting*
(or changing!) a password has got to be one of the easiest things
(conceptually) to do!

So, why don't people do it? Would they rather the password be picked
*for* them ahead of time? Or, STANDARDIZED?? (Hey, how about "admin"
or "password"?)

OK, maybe they're just SUPER LAZY and can't bother to take the time
to figure out how to change their password. Yet, when FORCED to
change it ("password expired") -- and thus saved the effort of having
to figure out HOW to do this -- they simply type in the SAME PASSWORD,
again. Despite all the education AND MECHANISM telling them not to do
this!

> (This is not being callous - we all have things we can do ourselves, and things
> we need help for. I can configure firewalls, but if something goes wrong with
> the car I ask my car-enthusiast neighbour or take it to the mechanic.)

Do you live with whatever station presets were set on the radio when
you purchased the vehicle? Do you keep the seats in the same position
as the previous driver? Surely, neither of these things poses an
insurmountable issue that would prevent you from using the vehicle!

Why do people insist on picking a paint/interior color for a vehicle?
Or a cell phone *case*? Or, "wallpaper" for their monitor? (what's wrong
with "root weave"?) Or, big icons vs. small? (Do you really think
all the mechanism to support these changes/customizations was "invested"
without reason?)

People always want to tailor things to THEIR needs. The problem is
making sure it is easy for them to do so. E.g., some DTP tools
present a "fonts (typefaces)" menu as just a list of "font names".
Others present the list as *samples* of each of those fonts! Both
approaches allow the user to adjust the "font" to their desires
("perceived needs"). But, the first makes the task considerably
more difficult (esp for a casual/infrequent user!) than the second.

Devices (in this case, languages) have to be intuitive and not
needlessly complicated (why do I need a semicolon here but not
there?). Doing simple things should be simple.

At the same time, you don't want to cripple folks who are interested
and motivated in doing more.

[David Brown]

On 20/03/15 10:51, Don Y wrote:
> On 3/20/2015 2:05 AM, David Brown wrote:
>> On 20/03/15 07:38, George Neuner wrote:
>>> On Thu, 19 Mar 2015 15:44:44 -0700, Don Y <th...@is.not.me.com> wrote:
>
>>>> How many appliances require some sort of "customization"? How does
>>>> a blind user configure his wireless router? Firewall? "Program"
>>>> his TV/cable box/DVR/XM radio? (do they even *have* provisions to
>>>> present data in a non-visual form?)
>>>
>>> This may sound insensitive, but I rather doubt many blind users
>>> configure these things much at all.
>>
>> The reality is that very few users of any sort configure these things.
>
> That's not the same thing as saying that there is no *need* for them
> to be configured/customized.

True, but it means that you don't need to make it easy to configure
them. And you don't need to go out of your way to make it possible to
configure for those that can't do it the "normal" way (such as for blind
people) - that just makes everything more costly and more difficult for
everyone else.

If you are making something where it is /realistic/ to expect blind
people to want to configure the system, then by all means make a version
that can be configured by voice or Braille. But only where it makes sense.

>
>> I'd
>> guess that something like 95% of households in developed countries have a
>> firewall/router device. And I would guess that 90% of these have never
>> configured or customised anything on them beyond the bare minimum of
>> picking a
>> wireless SSID and password by following the "getting started"
>> instructions.
>
> That speaks to a lack of education on the part of the user. And, a
> poor design from the manufacturer that *necessitates* such education;
> coupled with the realization that sxposing the user to all that
> complexity would PROBABLY intimidate the user (and cost the manufacturer
> the "sale")

No, it shows quite clearly that the out-of-the-box defaults are fine for
most people, except for setting their SSID name and password.

Everything else is "advanced", for people who have extra requirements.

>
>> And well more than half of /those/ will have been set up by a friend,
>> other
>> family member, or the neighbour's teenager.
>>
>> The great majority of people don't need "customisation" - they need
>> things to
>> work out of the box.
>
> No, they *want* things to work "out of the box". But, they want them to
> work the way *they* want them to work! E.g., the TV should receive the
> channels *I* want to watch (and not be cluttered up with all those
> extra channels in which I have no interest).

And most people are fairly happy with the "out of the box" experience -
or they fiddle with a few basic settings (like channel selection).

>
> But, they don't want to *pay* (much) for this -- thinking it *should* be
> "simple". When it (frequently) turns out that this is not the case
> (often because the interface was poorly designed), they either live with
> the "inconvenience" (and some level of "disappointment") *or* return
> the product and search for something more suitable (or "none") -- see
> below.
>
> [My first TV had a mute feature -- but one that wasn't "independent";
> any other operation would unmute the audio -- so, you couldn't hit mute
> and browse channels. My only remedy would have been to replace the
> set with one that behaved as better suited *my* intended usage]
>
>> And for the little that needs done, such as setting the
>> time on the VCR, why would you need a special interface for blind
>> people or
>> other disabled users? They can do what most other people do - ask
>> someone for
>> help.
>
> (sigh) In reality, they just "do without". Do *you* LIKE asking people
> for help? Esp if it draws attention to your "inability/disability"?

Either you do without if it doesn't matter, or you ask for help when it
/does/ matter. Or someone else will just fix things when they are there
anyway. If a person is blind or disabled, and doesn't have able-bodied
visitors who are happy to sort out these small issues, then they have
vastly bigger problems than the time on their VCR!


You can argue all you want about how the world /should/ be, or how it is
a terrible thing that people don't configure their devices. But in the
real world, for the most part, people don't do much setup or
configuration - they do as little as they can get away with. That
applies to most "normal", able-bodied people - and doubly so for the
elderly, blind, disabled, etc. Thus any time or effort spent on making
it easier is mostly wasted, because the fiddlers and geeks will make
changes no matter how difficult it is, and the normal people will leave
it on default settings no matter how easy it is.

[Don Y]

On 3/20/2015 3:49 AM, David Brown wrote:
> On 20/03/15 10:51, Don Y wrote:
>> On 3/20/2015 2:05 AM, David Brown wrote:
>>> On 20/03/15 07:38, George Neuner wrote:
>>>> On Thu, 19 Mar 2015 15:44:44 -0700, Don Y <th...@is.not.me.com> wrote:
>>
>>>>> How many appliances require some sort of "customization"? How does
>>>>> a blind user configure his wireless router? Firewall? "Program"
>>>>> his TV/cable box/DVR/XM radio? (do they even *have* provisions to
>>>>> present data in a non-visual form?)
>>>>
>>>> This may sound insensitive, but I rather doubt many blind users
>>>> configure these things much at all.
>>>
>>> The reality is that very few users of any sort configure these things.
>>
>> That's not the same thing as saying that there is no *need* for them
>> to be configured/customized.
>
> True, but it means that you don't need to make it easy to configure them. And

Then why don't I do it the *easiest* way for me? Make everything "closed"
and sell "configuration services"?

> you don't need to go out of your way to make it possible to configure for those
> that can't do it the "normal" way (such as for blind people) - that just makes
> everything more costly and more difficult for everyone else.

How does the choice of how you represent "assignment", conditionals, etc.
in a scripting language make it more difficult for everyone else? Do you
*care* if I say:
Y = 3
instead of:
Y := 3;
or:
Y <- 3
or:
Y gets 3

> If you are making something where it is /realistic/ to expect blind people to
> want to configure the system, then by all means make a version that can be
> configured by voice or Braille. But only where it makes sense.

Only trivial things don't require configuration.

How would you set up an irrigation system if you wanted it to be "zero
configuration"? Put a moisture sensor at each plant? Sell those
moisture sensors in different "flavors": use a cactus sensor for cacti
because they have different water needs than embodied in the "tomato plant
sensor"? (Isn't that just moving "configuration" to "time of purchase"?)

You can make a set-back thermostat "learn" your *weekly* (not daily!)
sleep/wake, home/away schedule. But, how do you tell (configure) it
how to handle holidays? Days when you are home sick/vacation? Or,
do you just accept the INconvenience that comes from it's "smarts"
at those times? (Hmmm... it thinks I am at work so it has turned
off the hot water heater. I guess I won't be showering as soon as
I expected!)

You can design a telephone answering system to automatically discard/inhibit
incoming calls from folks whose previous calls you have (apparently) ignored.
But, how do you then tell it to "forget" that fact?

>>> I'd
>>> guess that something like 95% of households in developed countries have a
>>> firewall/router device. And I would guess that 90% of these have never
>>> configured or customised anything on them beyond the bare minimum of
>>> picking a
>>> wireless SSID and password by following the "getting started"
>>> instructions.
>>
>> That speaks to a lack of education on the part of the user. And, a
>> poor design from the manufacturer that *necessitates* such education;
>> coupled with the realization that sxposing the user to all that
>> complexity would PROBABLY intimidate the user (and cost the manufacturer
>> the "sale")
>
> No, it shows quite clearly that the out-of-the-box defaults are fine for most
> people, except for setting their SSID name and password.

Yet they can't seem to *do* those "simple" things? Why not design the
product so it doesn't work *until* you have set these parameters? (Ah,
but then you are forcing people to "do something").

> Everything else is "advanced", for people who have extra requirements.

Companies offer "concierge" services for items that they consider too
costly to risk "getting back" (because the user couldn't figure out how
to set it up as expected). These companies are effectively saying
"the product was designed poorly -- but we want to ensure we can make
a sale *stick*".

C'mon, how hard is it to set the time on a VCR? Or, in your car?
Is it really *that* much harder to plug some video cables into a
TV and your cable box? Is anything beyond the power cord considered
too difficult??

Products are designed with too much *apparent* complexity. So, it
intimidates users before they even make their initial attempt.
Complexity should expose itself only to intentional "probes"; you
shouldn't be aware of it unless (and until) you *need* to be
exposed to it.

E.g., the irrigation controller in my system is "naively" configured
like most COTS controllers: Ni minutes at time Ti on days Di for zone
Zi. As such, if you already own a COTS controller, the "setup" is
simply a matter of noting the times/days associated with each zone
on your current controller and transcribing those values to mine.
Doing this gives you *no* (added, immediate) benefit. But, it
sets the "price/complexity of admission" very low.

In the future, I'll be able to tell you when one of your valves
is defective (stuck, open, shorted) -- which your current COTS
controller can't (?) do.

If you opt to also include a weather station in your deployment,
then I can *save* you money (water) by noting when it's rained
(or raining) and inhibiting/postponing the watering cycle.
Now, Di and Ti may have changed (all the Monday events have now
moved to Tuesday because of rain on Sunday, etc.). So, you can't
expect the user model to remain identical to that of the (dumb)
COTS controller. Yet, it's relatively easy to relate to what has
happened and why.

Spend some extra effort (e.g., an institution having considerable
monies tied up in "landscaping") and tell me *what* is serviced
in each zone and I can get even cleverer in scheduling the resource!
Again, more complex -- yet still "makes sense" (to someone savvy enough
to *have* this information to provide).

*FORCING* all users to buy in at that level of commitment would
undoubtedly intimidate many. OTOH, *not* having that capability
("you need a software/hardware upgrade") is a disservice to those
folks who "started simply" and grow in their appreciation of your
capabilities.

>>> And well more than half of /those/ will have been set up by a friend,
>>> other
>>> family member, or the neighbour's teenager.
>>>
>>> The great majority of people don't need "customisation" - they need
>>> things to
>>> work out of the box.
>>
>> No, they *want* things to work "out of the box". But, they want them to
>> work the way *they* want them to work! E.g., the TV should receive the
>> channels *I* want to watch (and not be cluttered up with all those
>> extra channels in which I have no interest).
>
> And most people are fairly happy with the "out of the box" experience - or they
> fiddle with a few basic settings (like channel selection).

But a TV has few "settings". The "TV" function is relatively simple and
has a long history.

When I was interviewing "users" before I started on this, one (blind) gentleman
complained about the inadequacy of his "address book". (Cripes! It's an
address book. What the hell could be wrong with something as simple as
THAT??)

He asked about having multiple address books. (Huh?) Turns out, he had
*5,000* contacts recorded, there. (imagine sorting through 5000 names
with a braille/audio interface for a particular contact!) In his case,
he was servicing "clients" for his 9-to-5 and had all of their contact
information recorded in this database.

Splitting it into N address books would be *less* efficient than giving him
a mechanism to condition which contacts are "visible" at any given time.
E.g., if he happened to be in TownA servicing clients, then it would be
silly to even acknowledge any contacts NOT in TownA!

Additionally, he would *manually* make annotations for each client visited
(or contacted via phone) to track his most recent contact date (so he
would know which clients hadn't been contacted recently and could make
extra effort to reach them). Of course, the "content" of each of those
contacts was (manually) tracked, elsewhere.

So, he spent a lot of his "work time" just navigating to the data that
he needed and updating his "records". Wouldn't it be *so* much easier if
he could place a call, send an email, etc. *from* that address book;
have the address book record the date/time/duration of the contact; whether
it was "completed" successfully or not (no one home, etc.); provide an
automatic mechanism for him to add notes about the contact "then and there"
(instead of having to remember/record this "elsewhere" and do the data entry
at a later time) as well as leave instructions to himself as to any followup
required:
"Gee, it's been a busy day! Who did I visit? Did I accomplish
everything that I intended to? Are there any activities that I
need to schedule as a result of these contacts?"

Do you provide this sort of "built-in" capability for *every* user?
Do you "sell" it as a custom add-on (and spend your time customizing
products one-off for your customers)? Or, do you provide a mechanism
whereby the user (or someone HE selects) can implement his requirements?

>>> And for the little that needs done, such as setting the
>>> time on the VCR, why would you need a special interface for blind
>>> people or
>>> other disabled users? They can do what most other people do - ask
>>> someone for
>>> help.
>>
>> (sigh) In reality, they just "do without". Do *you* LIKE asking people
>> for help? Esp if it draws attention to your "inability/disability"?
>
> Either you do without if it doesn't matter, or you ask for help when it /does/

What happens is people convince themselves that "it doesn't matter" -- simply
because they have no choice (or, no applicable help). Imagine if I took the
approach of closing the design, entirely. Or, forced folks to write code
in C? ASM??

Would you *ever* think the ability to *read* "wouldn't matter"? Yet, chances
are, if you lose your vision *now*, you will have no choice but to rely
on "talking books" or "screen readers" (you aren't going to get access to
your "home owner's association newsletter" in any "accessible" form!).

You might want to try playing with a screen reader some day to see just how
*bad* this experience is! And, then realize how *wonderful* it is given
the alternative (of being cut off from "print", news, etc.). Here:
<http://www.freedomscientific.com/Downloads/>
No cost -- other than your *time*. JAWS is probably the most widely
recognized (highly developed?) product in use. Install it in a sandbox
(if you don't trust it), turn off your monitor. And see how much you
can do with it -- on websites, email, news, etc. that you would
typically indulge.

> matter. Or someone else will just fix things when they are there anyway. If a
> person is blind or disabled, and doesn't have able-bodied visitors who are
> happy to sort out these small issues, then they have vastly bigger problems
> than the time on their VCR!

You think these are the *only* things that these people "need help with"?
Do you think they will ask their caregiver to spend what limited time they
have available (due to cost for paid service or imposition on friends/family)
instead of: weekly grocery shopping, trips to doctor, "companionship", etc.
Increasingly, "blind" means "old". Not seeing is just one of many "issues"
they face. Many have no remaining family -- or, families that have families
of their own (or far away), limited/fixed income (unemployed), etc.

Instead, they'll just learn to "live without"; "adapt".

> You can argue all you want about how the world /should/ be, or how it is a
> terrible thing that people don't configure their devices. But in the real
> world, for the most part, people don't do much setup or configuration - they do
> as little as they can get away with. That applies to most "normal",
> able-bodied people - and doubly so for the elderly, blind, disabled, etc. Thus
> any time or effort spent on making it easier is mostly wasted, because the
> fiddlers and geeks will make changes no matter how difficult it is, and the
> normal people will leave it on default settings no matter how easy it is.

That speaks contrary to all the effort that is currently expended in most
products, software, etc. Do you have a ~/.profile or ~/.cshrc? Why don't
you just live with profile(5)? Why even support a system-wide profile(5)
instead of hard-coding those behaviors in the shell, itself? Why have more
than one choice of shells?

Why have different ringtones, wallpapers, display fonts, "annunciators", etc.?
Why allow a user to pick his own login name -- what's wrong with User1, User2,
etc.?

Yes, they do as little as they can get away with. But, they also get
annoyed if they *can't* change something that they *want* to change! As I
said previously, they all want it to work out-of-the-box... BUT, the way
*they* want that to be, not the way some developer decided it should be!
(especially when experience has taught them that developers are clueless)

[Mel Wilson]

On Fri, 20 Mar 2015 02:38:24 -0400, George Neuner wrote:

> I used to know a vision impaired programmer who used a braille reader
> and keyboard. I never worked directly with him, but he worked very much
> like I did (and do): when he collaborated with other people they would
> pass code back and forth with markup and comment.

Same here. There was a senior programmer in the department who was
totally blind. He once asked somebody to teach him the light switches so
he could tell by touch to turn the lights on when he was first one in,
and not terrify later people when they found out they weren't alone. For
fun at home he raised goats and rebuilt auto engines. He had dual
braille readers and could read one text with each hand at the same time.
Apparently eyes are trained to work in lock-step, but hands aren't.
The point, I think, is that blind people can do excellent work if they
have tools they can use. Whether the rest of us are wise enough and rich
enough to create tools like those is the question.

Mel.

[David Brown]

On 20/03/15 13:12, Don Y wrote:

> How does the choice of how you represent "assignment", conditionals, etc.
> in a scripting language make it more difficult for everyone else? Do you
> *care* if I say:
> Y = 3
> instead of:
> Y := 3;
> or:
> Y <- 3
> or:
> Y gets 3
>

I care that it is convenient, unambiguous, and clear. I don't care if
it is pronounceable. Symbols are better than letters because they stand
out better in comparison to the rest of the code - thus "Y gets 3" is
the only option here that does not work well as an assignment operator.


(I know you like writing long posts, but most of it seemed to be
rhetoric, so I snipped it.)

[Don Y]

On 3/20/2015 6:24 AM, Mel Wilson wrote:
> On Fri, 20 Mar 2015 02:38:24 -0400, George Neuner wrote:
>
>> I used to know a vision impaired programmer who used a braille reader
>> and keyboard. I never worked directly with him, but he worked very much
>> like I did (and do): when he collaborated with other people they would
>> pass code back and forth with markup and comment.
>
> Same here. There was a senior programmer in the department who was
> totally blind.

Programming is an ideal (high paying) occupation for blind/VI folks.
There's little need to navigate the physical environment: just sit
at your desk and rely on the *memory* you have honed, of necessity,
to remember what sighted programmers would "refresh" visually. Few
folks want to sit around waiting for a disability check and the
"kindness of others"!

> He once asked somebody to teach him the light switches so
> he could tell by touch to turn the lights on when he was first one in,
> and not terrify later people when they found out they weren't alone. For
> fun at home he raised goats and rebuilt auto engines.

The individual I spent most of my professional time with would drag me
out to play pinball whenever he knew a machine was nearby.

He would also push to learn how to service the Reading Machine as
a means of cutting his reliance on "factory service" (and the lost
time waiting for someone to hop on a plane) -- tricky as the machines
were physically large (washing machine sized), wire-wrapped, and
rather fragile.

(In the 40 years since, I think the functionality is now available in
a cell-phone sized device; maybe even integrated into the phone, by now!)

> He had dual
> braille readers and could read one text with each hand at the same time.

A single line braille terminal (just an I/O device) is about $3K
($70-100/cell). So, he was lucky enough to have the resources to
buy *two* (or, the purchase heavily subsidized by tax dollars).
OTOH, it's *just* a "display" so you need to carry a COTS laptop
as well (or have one accessible with appropriate software already
installed; you're not going to just plug it into any "random"
machine)

> Apparently eyes are trained to work in lock-step, but hands aren't.

Hands *want* to operate "synchronously" (try doing things at different
rates in different hands) but you can break that "connection" esp if
there is an incentive to do so. (e.g., rub your belly and pat your head)

Many of the things that we do (take for granted) aren't really hard-wired
but simply learned behaviors (least effort). When I initially thought
these folks had "sharper senses", I was met with a chuckle, told to close
my eyes and <whatever>: "See, there's no magic involved. You're just
relying on your vision because its *easiest* for you! *I* don't have that
option!"

> The point, I think, is that blind people can do excellent work if they
> have tools they can use. Whether the rest of us are wise enough and rich
> enough to create tools like those is the question.

Of course! Assuming the absence of additional "disabilities" (they
often are not singular things), there is no reason why you can't
perform similar tasks -- but in a different way. E.g., if you couldn't
*easily* look up and refresh your memory of the previous line of text,
you'd learn to hold it better in your memory (as the alternative is to
navigate up one line with your braille terminal, voice output, etc.).

Listening to synthetic speech (for someone who has no *need* to do so)
is tedious and slow. OTOH, folks who are used to listening to it
often complained that the maximum speaking rate was never fast enough;
that they were always "waiting" for the synthesizer. Imagine listening
to spoken word at rates approaching/exceeding your visual reading rate!

The problem is that folks don't consider the situations of others when
we design our products. We assume everyone has two hands, two working
eyes, adequate hearing, mobility, good motor skills, etc. EVEN IF THE
PRODUCT'S INTERFACE DOESN'T *require* THOSE ASSUMPTIONS.

The fallacy in the AT community is thinking that (designing for)
"accessibility is free"; that it doesn't cost anything (NRE or product
cost) to design "universal" interfaces (and, what, exactly, is meant
by "universal"?)

*My* goal is to put a number on that and provide a framework that
can act as a starting point -- so others don't have to recreate
similar libraries/mechanisms from scratch (what would your
development efforts be like if you didn't have preexisting GUIs
to rely on when creating a new product? If, instead, you had to
write your own before you could deliver a product??)

[George Neuner]

On Fri, 20 Mar 2015 05:12:39 -0700, Don Y <th...@is.not.me.com> wrote:

>How does the choice of how you represent "assignment", conditionals, etc.
>in a scripting language make it more difficult for everyone else? Do you
>*care* if I say:
> Y = 3
>instead of:
> Y := 3;
>or:
> Y <- 3
>or:
> Y gets 3

"add x to y giving z"

COBOL failed because it's syntax was designed primarily to be read by
non-programmers and the syntax was both cumbersome to use and was not
expressive enough to accommodate newer programming methodologies.

Yes, COBOL later introduced a more algebriac-like syntax, but it did
not abandon the problematic "readable" syntax - the newer syntax was
simply permitted as a substitute.

>How would you set up an irrigation system if you wanted it to be "zero
>configuration"?

Tell people to open a valve when they want it on and close the valve
when they want it off. That has worked remarkably well since the
invention of managed irrigation ~7000 years ago. 8-)

>You can design a telephone answering system to automatically discard/inhibit
>incoming calls from folks whose previous calls you have (apparently) ignored.
>But, how do you then tell it to "forget" that fact?

Why would you? Why are they suddenly worthy?

>C'mon, how hard is it to set the time on a VCR? Or, in your car?
>Is it really *that* much harder to plug some video cables into a
>TV and your cable box? Is anything beyond the power cord considered
>too difficult??

For a lot of people the answer is "Yes!" It has been estimated that
more than 1 billion VCRs flashed 12:00 for their entire lifetime.

>Products are designed with too much *apparent* complexity. So, it
>intimidates users before they even make their initial attempt.

No. Many people are unapologetically non-technical and get upset when
they discover things to be more complicated than using a doorknob.

>E.g., the irrigation controller in my system is "naively" configured
>like most COTS controllers: Ni minutes at time Ti on days Di for zone
>Zi.

That's already too complex for some people - it involves "zones" and
possibly even "setting a timer".


Don't you know the Zone is something to be avoided?
http://en.wikipedia.org/wiki/Spiral_Zone

[
SpiralZone.com seems to have closed shop, but the series is up on
kisscartoon.me. Interestingly, the series starts "in progress" and
the backstory unfolds as the series progresses. The episode
"Oversight" is the best short (20 min) introduction.
http://kisscartoon.me/Cartoon/Spiral-Zone/Episode-054-Oversight?id=28558
]

>Would you *ever* think the ability to *read* "wouldn't matter"? Yet, chances
>are, if you lose your vision *now*, you will have no choice but to rely
>on "talking books" or "screen readers" (you aren't going to get access to
>your "home owner's association newsletter" in any "accessible" form!).

Nope. I'd eat a bullet and be done with it.

YMMV,
George

[Don Y]

On 3/20/2015 6:55 AM, David Brown wrote:

> (I know you like writing long posts, but most of it seemed to be rhetoric, so I
> snipped it.)

Rhetoric, anecdotes, call it what you will.

Most folks replying to topics already have their mind made up. So,
the point of any further discussion isn't to try to "win an
argument" or "change their mind" but, rather, to speak to those
reading over their shoulders; to get *them* to think about the
issue and form their own opinions.

Or not. (many people avoid thinking about things that have difficult
"solutions")

I suspect most folks don't personally know (many!) blind/deaf/handicapped
individuals. And, probably haven't invested enough time on a "personal"
level to be able to engage them on what are very personal topics.

Ever asked a blind person what it's like not to see? Or, a deaf
person not to hear? etc. (Or, do those things never cross your
mind??)

So, people form opinions based on what they *think* the other person's
experience is like: he's not openly grumbling about his "condition"
(really? would that make a difference?? Or, would you just dismiss
him as a "whiner"??) so he must have figured out how to *adapt*!

End of problem.

Other people fail to realize there even *is* a problem! How many
people are color blind? Suffer from Parkinsonian tremor? Essential
tremor? Do you even *consider* these issues in your designs? Or,
do you just forget about them and expect they'll somehow "adapt"?
And, when your product return rate is higher than desired (desired being
warranty failures, only!), is it *your* fault? Or, the customers'?

I, OTOH, exploit every learning opportunity that I can. E.g., I've used
my relationship with the (deaf) couple across the street to get a better
understanding of *their* problems, solutions, culture, etc.

"How do you tell when someone comes to the door if you can't hear the
doorbell?"
Ans: doorbell flashes several lights in the house.

"What if you're asleep when someone comes knocking?"
Ans: the bed vibrates

"How do you know if the toilet is 'running on' (faulty valve)?"
Ans: our water bill NEXT MONTH will be higher than expected and
we'll have top figure out the cause

"How do you know when the washer/dryer is finished with a load?"
Ans: <frown> we *watch* it.

"So, obviously, the same applies to microwave oven, kitchen
timer, etc.?"
Ans: no, we've got a little "egg timer" that we can use -- if we
discipline ourselves to do so.

"What about the fire alarm?"
Ans: hopefully we see the light come on to help you find the exit

"And if you're asleep at the time?"
Ans: ??

"Why is your newborn *deaf* baby considered 'perfect'?"
Ans: they don't see deafness as a liability but, rather, as a "goal"

"How much is that cultural rationalization...?"

[Don Y]

On 3/20/2015 11:11 AM, George Neuner wrote:
> On Fri, 20 Mar 2015 05:12:39 -0700, Don Y <th...@is.not.me.com> wrote:

[language stuff elided as we've already "agreed to disagree"]

>> Would you *ever* think the ability to *read* "wouldn't matter"? Yet, chances
>> are, if you lose your vision *now*, you will have no choice but to rely
>> on "talking books" or "screen readers" (you aren't going to get access to
>> your "home owner's association newsletter" in any "accessible" form!).
>
> Nope. I'd eat a bullet and be done with it.

Amusingly, many people express sentiments like that -- esp when it comes
to various debilitating/terminal illnesses. Though, most often, it is
expressed as an imperative to *others*: "Shoot me when that happens!"
(as if the effort isn't something they could undertake, themselves)

In the past few years, I've watched several friends/colleagues die
pretty nasty deaths. All with forewarning. "The illness will progress
along these lines... ... until ultimately claiming your life. The
actual *cause* of death will be (asphyxiation, etc.)"

In each case, *yesterday* was the best day they were going to have
(and that same thing will be true again "tomorrow"). I.e., things
will only get *worse*. More painful. Loss of capabilities. etc.

Yet, no one has taken the "express exit"! And, had they been asked
prior to their Dx's, I suspect they all would have expressed a
statement like the above!

And, I don't consider any of them "cowardly". In fact, watching someone
struggle with ovarian Ca, esophageal Ca, stomach Ca, ALS, etc. seems
to me to be far more "courageous" than the other expedient!

I came closest to asking my friend with the esophageal Ca (prior to his
death) this very question: "What makes you want to wake up in the morning?
What are you thinking about *knowing* the inevitable outcome AND the
gruesome path ahead of you?"

But, it seemed selfish to ask. So, I remain in the dark.

Sadly, I later learned that he had confided far more in me about his
thinking about his illness, prognosis, treatment alternatives, etc.
than any "relative". Leaving me to wonder if I perhaps did *him*
a disservice by not giving him the chance to answer my unposed question!

(sigh)

But, I have two friends currently hording meds for their "Final Exit"
(reference to a text). And, very vocal about their efforts. So, perhaps
when *their* times draw near, I'll be more willing to broach the subject.

[OTOH, if you suddenly lose your vision, please drop me a line before
you put that one in the chamber! :> ]

Ain't growing old, fun??!

[George Neuner]

On Fri, 20 Mar 2015 10:20:00 -0700, Don Y <th...@is.not.me.com> wrote:


>Many of the things that we do (take for granted) aren't really hard-wired
>but simply learned behaviors (least effort). When I initially thought
>these folks had "sharper senses", I was met with a chuckle, told to close
>my eyes and <whatever>: "See, there's no magic involved. You're just
>relying on your vision because its *easiest* for you! *I* don't have that
>option!"

No, it actually *is* true that their senses are sharper: not because
their sensory modality is better, but rather because the brain cells
that would have been devoted to vision instead are devoted to
processing other modalities.
[The visual cortex is roughly 1/8 of your brain - there's a whole lot
of capacity there.]

It has been proven that the brain adapts to loss of a sense modality
by redirecting the cells that process that input to other tasks. It
has also been proven that it happens very quickly: there was a study
in which sighted people were blindfolded for several weeks and given
brain scans as they adapted to being sightless and tried to learn
braille. Their visual cortexes shifted to processing other inputs:
mainly touch because "reading" now involved their fingers, but also
some small areas shifted to processing hearing and smell. When the
blindfolds were removed, most of the cortex quickly shifted back to
processing vision, but in many of the subjects some enhanced sense of
touch remained.

The study did not continue long enough to see whether hearing and
smell eventually would improve similarly as did the sense of touch.

It was discovered in a second study using the same subjects that the
brain adapted more quickly to being blind when it happened again. The
subjects didn't experience the same disorientation as in the first
study.

A related study using other subjects discovered that an EM jolt given
to the visual cortex allowed it to transition more quickly to doing
something else [a possible aid for those who become suddenly blind].

George

[George Neuner]

On Fri, 20 Mar 2015 15:20:14 -0700, Don Y <th...@is.not.me.com> wrote:

>On 3/20/2015 11:11 AM, George Neuner wrote:
>> On Fri, 20 Mar 2015 05:12:39 -0700, Don Y <th...@is.not.me.com> wrote:
>
>[language stuff elided as we've already "agreed to disagree"]
>
>>> Would you *ever* think the ability to *read* "wouldn't matter"? Yet, chances
>>> are, if you lose your vision *now*, you will have no choice but to rely
>>> on "talking books" or "screen readers" (you aren't going to get access to
>>> your "home owner's association newsletter" in any "accessible" form!).
>>
>> Nope. I'd eat a bullet and be done with it.
>
>Amusingly, many people express sentiments like that -- esp when it comes
>to various debilitating/terminal illnesses. Though, most often, it is
>expressed as an imperative to *others*: "Shoot me when that happens!"
>(as if the effort isn't something they could undertake, themselves)

I have living will and health care proxy that stipulate no heroic
measures to save my life. I trust my family not to contest them
because they have the same provisions.

>In the past few years, I've watched several friends/colleagues die
>pretty nasty deaths. All with forewarning. "The illness will progress
>along these lines... ... until ultimately claiming your life. The
>actual *cause* of death will be (asphyxiation, etc.)"
>
>In each case, *yesterday* was the best day they were going to have
>(and that same thing will be true again "tomorrow"). I.e., things
>will only get *worse*. More painful. Loss of capabilities. etc.
>
>Yet, no one has taken the "express exit"! And, had they been asked
>prior to their Dx's, I suspect they all would have expressed a
>statement like the above!
>
>And, I don't consider any of them "cowardly". In fact, watching someone
>struggle with ovarian Ca, esophageal Ca, stomach Ca, ALS, etc. seems
>to me to be far more "courageous" than the other expedient!

In many ancient cultures, the elderly and infirm were *supposed* to
"go away" when they became a drain on the others. It isn't cowardly
to sacrifice yourself for the benefit of others. The herd survives by
leaving the slow behind.

Nor do I think it is courageous to battle on when there is no hope of
winning. I think it *is* cowardly to spend all your resources
fighting a losing battle and leave nothing for your family. Someone
who has no family can do whatever they want.

It's been estimated that, for all causes, in the US the last week of
life costs an average $200,000. The average cost of treating cancer
exceeds $1 million - more than most people will earn in their
lifetime. Who pays for that? "Other People's Money"[*] AKA insurance
AKA the biggest legal scam in history. Is every life worth the
expense?. Extremely doubtful ... I *know* mine isn't.

No matter what your sensibilities, the fact is that society does not
have the resources to carry those who don't contribute. We are
trillions in debt already because of bleeding hearts trying.


[*] a good movie, but not a role model for society.
http://www.imdb.com/title/tt0102609/

>[OTOH, if you suddenly lose your vision, please drop me a line before
>you put that one in the chamber! :> ]

You know that is a possibility 8-/ along with several other
potentially nasty outcomes. My health is stable and I'm not going
broke, but if that balance shifts negatively, I won't burden others to
care for me.

In case I forget, I'll leave a note in my will for someone to send you
an email. 8-)

>Ain't growing old, fun??!

Whatever you're smoking, send me some. Growing old sucks!!!

George

[Don Y]

On 3/22/2015 6:28 AM, George Neuner wrote:
> On Fri, 20 Mar 2015 15:20:14 -0700, Don Y <th...@is.not.me.com> wrote:
>
>> On 3/20/2015 11:11 AM, George Neuner wrote:
>>> On Fri, 20 Mar 2015 05:12:39 -0700, Don Y <th...@is.not.me.com> wrote:
>>
>> [language stuff elided as we've already "agreed to disagree"]
>>
>>>> Would you *ever* think the ability to *read* "wouldn't matter"? Yet, chances
>>>> are, if you lose your vision *now*, you will have no choice but to rely
>>>> on "talking books" or "screen readers" (you aren't going to get access to
>>>> your "home owner's association newsletter" in any "accessible" form!).
>>>
>>> Nope. I'd eat a bullet and be done with it.
>>
>> Amusingly, many people express sentiments like that -- esp when it comes
>> to various debilitating/terminal illnesses. Though, most often, it is
>> expressed as an imperative to *others*: "Shoot me when that happens!"
>> (as if the effort isn't something they could undertake, themselves)
>
> I have living will and health care proxy that stipulate no heroic
> measures to save my life. I trust my family not to contest them
> because they have the same provisions.

Yup, same here. But, one of "medicine's" dirty little secrets is
there's no *guarantee* that they will be honored, in practice.
The doctor's ignored C's dad's DNR on at least one occasion.
She had to read them the riot act to ensure it didn't happen
again.

And, of course, you always have the risk of your "advocate(s)"
not having the commitment to follow through on your wishes. E.g.,
C's mom had her *own* wishes regarding the dad's EoL; and it didn't
bother her that they were in direct conflict with *his* wishes!
(Hey, *he* can't do anything to fight for HIS desires; I win!)

I have a lady friend with her "DNR" tattooed on her chest. She
*probably* thinks that affords her some sort of "guarantee"
(They can't say they were unaware!) OTOH, I could see a lawyer
arguing that the cost of *her* changing her mind could have been
so high (tattoo removal) that, perhaps, she *had* changed her mind
but hadn't come around to having the tattoo removed.

<shrug> Screwed up society when *others* seem to think they have a
right to decide how *you* handle your own life...

>> In the past few years, I've watched several friends/colleagues die
>> pretty nasty deaths. All with forewarning. "The illness will progress
>> along these lines... ... until ultimately claiming your life. The
>> actual *cause* of death will be (asphyxiation, etc.)"
>>
>> In each case, *yesterday* was the best day they were going to have
>> (and that same thing will be true again "tomorrow"). I.e., things
>> will only get *worse*. More painful. Loss of capabilities. etc.
>>
>> Yet, no one has taken the "express exit"! And, had they been asked
>> prior to their Dx's, I suspect they all would have expressed a
>> statement like the above!
>>
>> And, I don't consider any of them "cowardly". In fact, watching someone
>> struggle with ovarian Ca, esophageal Ca, stomach Ca, ALS, etc. seems
>> to me to be far more "courageous" than the other expedient!
>
> In many ancient cultures, the elderly and infirm were *supposed* to
> "go away" when they became a drain on the others. It isn't cowardly
> to sacrifice yourself for the benefit of others. The herd survives by
> leaving the slow behind.

Yup.

> Nor do I think it is courageous to battle on when there is no hope of
> winning. I think it *is* cowardly to spend all your resources
> fighting a losing battle and leave nothing for your family. Someone
> who has no family can do whatever they want.

Yup. Talk to a financial planner about what you'll "need" for the rest
of your life. You'll discover that a huge portion of your assets are
"consumed" in the last ~2 years of your life. I guess folks EAT MORE
just before they die?? :-/

OTOH, I suspect our health care system couldn't abruptly handle having
all of that extra "service"/demand removed. I suspect it's all that
EoL care that pays many of *their* bills.

OToOH, I wonder how much of those funds come from the *patient*, his
family, etc.?

I think a movement towards assisted suicide, enhanced medical directives
for *all* would scare the hell out of that industry -- and its investors!
"37% of people have registered DNR's. That's up from the previous
year's figure. How are we going to make up for that loss of BUSINESS?"

> It's been estimated that, for all causes, in the US the last week of
> life costs an average $200,000. The average cost of treating cancer
> exceeds $1 million - more than most people will earn in their
> lifetime. Who pays for that? "Other People's Money"[*] AKA insurance
> AKA the biggest legal scam in history. Is every life worth the
> expense?. Extremely doubtful ... I *know* mine isn't.

Some 20+ years back, I was in England for business. Watching one of their
4 (?) TV stations to kill time in the hotel before a meeting. They had
an interesting, candid discussion re: health care resources (NHS). IIRC,
one of the comments offered was, "Do we fix this 80 year old (hypothetical)
woman's broken hip -- with the expectation that she's going to die soon,
regardless -- or, do we vaccinate 200(?) kids against something that
could make even *one* of their lives better?"

But, in this country, those topics are taboo. "Rationing", "Assisted
Suicide", etc. Kübler-Ross's seminal text on the subject (I'm sure more
has been written in the ~40 years since then!); texts like _Final Exit_;
etc. Anyone watching the sales of those as an indicator of societal
trends would have a greater insight (beyond the "If I get that way,
somebody SHOOT me" sorts of casual comments you encounter)

> No matter what your sensibilities, the fact is that society does not
> have the resources to carry those who don't contribute. We are
> trillions in debt already because of bleeding hearts trying.
>
> [*] a good movie, but not a role model for society.
> http://www.imdb.com/title/tt0102609/

There's a fine line between "don't/won't contribute", "can't contribute"
and "can't carry their full load".

At "retirement", has the individual stopped contributing? Or, do you
rationalize that their switch to 100% consumer is considered contributing??

How do you address the needs of the disabled? Do we euthanize infants born
with severe handicaps? Even a "science based, probabilistic model" as to
their expected societal contributions/costs would be a tough sell -- when
the infant is *yours*.

Is "inability to conceive/father" a genuine cause for resources to be diverted
to facilitate that? Does society *really* "need" your offspring? Can't
someone *else's* make up for that shortfall??

What about the flip side: being *able* to conceive yet being unable to
provide for their needs? Should that be criminal?

>> [OTOH, if you suddenly lose your vision, please drop me a line before
>> you put that one in the chamber! :> ]
>
> You know that is a possibility 8-/ along with several other
> potentially nasty outcomes. My health is stable and I'm not going
> broke, but if that balance shifts negatively, I won't burden others to
> care for me.

The fear is that you may not be (physically) capable of acting out those
wishes. And, reliant on others to make that judgement call IN YOUR INTERESTS
(ignoring their own concerns).

Consider mistakes that happen in the normal "practice of medicine" (e.g.,
don't you see the big red letters at thew top of the chart allerting you
to my allergies? then, why are you preparing to administer that med???)
and any expectation that this SIGNIFICANTLY MORE IMPORTANT (to you)
issue will be executed properly is wishful thinking.

> In case I forget, I'll leave a note in my will for someone to send you
> an email. 8-)

Heh heh heh... no, the point is to be able to grill you as to what you're
thinking while your grey matter is still "intact"! :>

>> Ain't growing old, fun??!
>
> Whatever you're smoking, send me some. Growing old sucks!!!

<shrug> The consolation is that it happens to most of us!

"I want to die peacefully, in my sleep, like grandpa; not screaming
in terror like the folks on the bus he was driving!"

Sunday lunch: finestkind!

[Don Y]

On 3/22/2015 5:12 AM, George Neuner wrote:
> On Fri, 20 Mar 2015 10:20:00 -0700, Don Y <th...@is.not.me.com> wrote:
>
>> Many of the things that we do (take for granted) aren't really hard-wired
>> but simply learned behaviors (least effort). When I initially thought
>> these folks had "sharper senses", I was met with a chuckle, told to close
>> my eyes and <whatever>: "See, there's no magic involved. You're just
>> relying on your vision because its *easiest* for you! *I* don't have that
>> option!"
>
> No, it actually *is* true that their senses are sharper: not because
> their sensory modality is better, but rather because the brain cells
> that would have been devoted to vision instead are devoted to
> processing other modalities.
> [The visual cortex is roughly 1/8 of your brain - there's a whole lot
> of capacity there.]

Sorry, I should have been more explicit; the common perception is that
there is an implicit offset that accompanies this (or any other)
disability: like a balloon squeezed at one end getting larger at the
other.

A newly blind person (adult/child/infant) has no sharper hearing (e.g.)
than any other person (adult/child/infant). You don't get magically
compensated for the loss of a sensory receptor (just like your right
arm doesn't magically get stronger if you're born without a left one).

Rather, the resources associated with that sense are freed up (there's
nothing "wired" to them). *You* choose to train them to adapt to other
uses. Or not.

Because ("normal people") "don't have to" in order to live our lives,
we don't. We don't *see* as much detail as we can -- simply because we
don't *need* to (UNTIL we need to). E.g., I can look at my hands and
see generic hands. Or, I can look "closer" (without actually bringing them
closer to my eyes) and notice all sorts of detail that was "not there"
in my previous inspection.

Watch TV (or your monitor) and you see "images". Look "harder" and you see
the individual dots/scan lines of which their composed.

When I interviewed VI folks, they almost universally exclaimed how glad
they were NOT to be deaf! (i.e., loss of vision being so much easier
to cope with than loss of hearing). OTOH, if you asked most sighted
folks, they would probably rate sight as more precious. <frown>

They're (VI) explanation is that you can do so much more with hearing
(esp once you learn "to hear") as it is omnidirectional (if you don't
see the bear creeping up behind you, you're LUNCH!) isn't obscured
by objects in its path, etc.

[This was made clear to me on an occasion when I was trying to get the
attention of a deaf neighbor who was gardening in her back yard with her
back to me. I was chagrined at how *impossible* that problem was to
solve without walking around the house, letting myself into her yard and
cautiously approaching her -- soas not to startle]

> It has been proven that the brain adapts to loss of a sense modality
> by redirecting the cells that process that input to other tasks. It
> has also been proven that it happens very quickly: there was a study
> in which sighted people were blindfolded for several weeks and given
> brain scans as they adapted to being sightless and tried to learn
> braille. Their visual cortexes shifted to processing other inputs:
> mainly touch because "reading" now involved their fingers, but also
> some small areas shifted to processing hearing and smell. When the
> blindfolds were removed, most of the cortex quickly shifted back to
> processing vision, but in many of the subjects some enhanced sense of
> touch remained.

Plasticity. But, it only works when you try to *make* it work.
(and, when you have the "other senses" on which to rely).

E.g., loss of vision due to something like diabetic neuropathy
is often complicated by other loss of sensitivity in the extremities
(finger tips) that render them unsuitable for the desired level of
"input". There was some work done on using the large surface of
a person's *back* as a "tablet" that could provide input when things
like fingertips weren't sensitive enough. Not very convenient, though.

The other problem is motivation. *Loss* of a sense is often accompanied
by depression and a sense of helplessness. Few people are motivated
to *learn* a new skill to replace a lost sense. Esp when that loss
comes late in life: they just resign themselves ("adapt"! :< ) to
living without.

It takes a fair bit of work to refine a "replacement" sense. Esp when
you are always subconsciously thinking of it in contrast to what you
*had*, previously.

I can sight read L1 braille about as fast as most typical (L1) braille
"tactile readers". (I use L2 so infrequently that my reading rate,
there, drops to a crawl -- folks learn to leave me notes in L1 if
they want me to be able to read and respond in any reasonable period!)

OTOH, when I try to read with my fingertips, (even L1) my reading
rate drops precipitously. I have to think about what's under my fingers
and convert those sensations to a visual representation -- i.e., construct
the braille cell in my mind -- and then "read" that "visually" (even though
my eyes aren't really "looking at it").

Navigation also becomes more tedious; I can't just dart my eyes back
(or up a row) to confirm -- or REEVALUATE -- what I "read" before.
Instead, I have to backpedal my hands over the cells that I've just
"read" (read backwards, so to speak). I.e., you learn to read
two-handed to be effective.

[In the context of writing code and programming languages, this is where
consistency can yield substantial rewards. I.e., if certain operations
are done in certain ways/styles, the reader can *infer* quite a lot
without having to actually verify all the details. Some of that comes
from language design choices; other comes from consistency on the part
of the *writer*]

A 60-ish person losing vision to MD or DR probably wouldn't have
the patience to deal with that level of frustration. They'd, instead,
replace print media with some other form -- which might also prove
challenging (e.g., my comprehension for audio modalities is much
less than visual ones).

It's only in these situations do you begin to realize how many products
and devices *require* sight -- even though they don't inherently *need* to!
(e.g., before touchscreens, you could make a phone call without looking at
your phone!)

[Reinhardt Behm]

On 23.03.2015 03:19, Don Y wrote:
>
> <shrug> Screwed up society when *others* seem to think they have a
> right to decide how *you* handle your own life...

Don, you are just describing, what religion is. ;-)

--
Reinhardt

[Don Y]

You might be amused by:

<http://www.sacred-texts.com/aor/twain/letearth.htm>

[I've not verified the page's content -- just hoping google
served up the correct response to my query. I have a paperback
in storage, somewhere...]