[Tfug] Language choices

[Bexley Hall]

--- Brian Murphy <murphy+tfug at email.arizona.edu>
wrote:

> Ugh, I knew I shouldn't have jumped in.
> 
> Quoting Bexley Hall <bexley401 at yahoo.com>:
> > You missed the point of the example.  They aren't
> > modifying the code.  They are creating a script
> > that *extends* the device's functionality in ways
> > that would be difficult or cumbersome to
> anticipate.
> 
> So, in essence, they are modifying the code.

If you write a shell script under NT, are you
"modifying the code"?  If so, I think MS's
lawyers would like to have a word with you
as I am pretty sure that violates the EULA!  :>

If I give them a set of 100 toggle switches
where the UP position means "route tablets made
on this station to the SAMPLE chute" and the DOWN
position means "route tablets made on this station
to the ACCEPT or REJECT chutes based on the normal
'weight' criteria", you wouldn't consider it
"modifying the code", would you?  Yet, it gives
the example functionality (i.e. flip switch 27
up and you can sample all of the tablets made on
station 27).

If, instead of spending a lot of money on switches
and wiring and panel space, I let you toggle
"virtual switches" on a display screen, I assume
you would also agree this isnt modifying the code.
Instead, the code is *interpreting* those "settings"
and changing its behaviour to match -- just like
it changes the speed of the main drive motor when
you click on the "down arrow" by the "RPM indicator".

If I take the *states* of those virtual switches
and save them in a file -- called a "recipe" -- then
that, too, is no different.

If I make that an ASCII file and let the user
type in a list of numbers representing "stations
to be sampled", then that's just another form
of the saved Rx, right?

Ah, but now I need to parse that file for errors
to make sure the user doesn't do something silly;
like try to sample station 107 on a 65 station
press.  (Of course, I would have to do this on the
Rx saved from the virtual switches as well since
it could be corrupted when retrieved from storage).

If, instead of writing a list of station numbers,
I wrap them in a different syntax:

for station in {5,10,15,20,25,30,35,40,45,50}
  sample_tablet()

Is that any different?  Or,

if ((station % 5) == 0) then sample_tablet()

Note that control isn't transfered *to* that
script.  Rather, it is used to tell the machine
how it should behave.  I.e., the statement:

rpm = -25

is just an error.  It won't cause the machine to
run backwards.  In much the same way that pulling
*up* on your car's accelerator won't cause the
car to go backwards!  Because the design of the
control system enforces the basic rules of how
the product *can* behave.
 
> > E.g., products similar to the example have tried
> > to provide some flexibility that ends up being
> > terribly *rigid*.  So, customers want "specials"
> > designed for them.  Even if the system *had* such
> > a scripting ability "available only to
> developers",
> > you end up spending a LOT of time (money) debating
> > what features are wanted, how they should operate,
> > how exceptions are handled, etc.
> 
> This is called "Professional Services."  Buy a tool,
> like say an enterprise storage array, and
> professional services will come out and set it up
> to your environment.  In many cases you don't have
> the option to decline this service if you want
> future support.  It's the cost of working with
> complicated systems.

But it need *not* be the cost of many such systems.
Ages ago, you had someone come out and set up your
*television*.  Where has that "professional service"
gone?   It has gone *away* because it is too costly
to provide.  If your competitor can make a TV that
doesn't need to be "installed", then he has a
competitive advantage over you.

When I was a kid, you serviced TV's (tubes/valves).
In most cases, this *also* required a service visit.
Ah, but then things moved to solid state (the "Works
in a Drawer" ads, etc.).  And, eventually, to the
model of the service man picking up the set and
hauling it off to his shop for repair; then, the
*customer* assuming this responsibility (because
it is cheaper for customer to do it than the TV
repair man tomake the trip!).  Then, today's
model of "throw it away when it breaks"  :>

This happens in all (?) industries -- just at
differing rates of change. 
 
> > This is something best handled by the customer
> himself:
> >
> >   "here's the scripting language;
> 
> (but the customer wasn't going to modify the code.
> ;)

It isn't "The Code".  It is a scripting language that
the machine recognizes to configure its behaviour.  It
gives the user an abstract way of "setting parameters"
that would be impractical to implement with hardware
knobs and buttons.  Using that "scripting language",
you can do whatever the machine's control system
design will *let* you do.  (yuck, bad grammar).

E.g., even with root privileges, you can't cause the
disks in your machine to spin backwards!  :-/
(as you can't write a script that will cause the
turntable in the tablet press to spin backwards --
even
though some hae drives that are capable of doing so!)

> >    do what you
> >    want -- the machine will protect itself if
> >    you try to do something stewpit.  If you
> >    need help debugging *your* scripts, we can
> >    have a technician assist you (because our
> >    developers are way too busy working on
> >    products that can be sold to *several*
> >    customers instead of customizing *one*
> >    machine for you..."
> >
> >> Build a macro language that transforms the
> >> operator's requirements into the underlying code
> >> of your choice.
> >
> > That was the point of the discussion.  *Picking*
> > a suitable language to do this that would be
> > amenable to the users' needs -- and capable of
> > being implemented within the design criteria of
> > the system itself
> 
> For super simple, anything like expect.
> 
> The next step for non-hackers is any BASIC dialect
> without line numbers.

That was where I started my search.  BASIC
interpreters
are tiny, the language is well understood, etc.  But,
it still has problems that make it's syntax stilted.
E.g., pick a dialect with longer identifiers.  Remove
the type-ness of identifiers (so user doesn't have to
conciously convert "strings of digits" into
"numbers").
Support variable precision arithmetic (so user doesn't
have to worry about the order in which he applies
operators).  The DEFN syntax sucks.  READ'ing
initialization DATA sucks (and is prone to errors).
It has no IPC provisions.  File IO is clumsy.  Etc.

> While BASIC may not get a language connoisseur's
> juices flowing, the customer doing the modification
> may have seen BASIC before in school or MS
> environments.  Any technical problems fitting BASIC
> syntax to the design criteria is what system
> engineers are for.

Exactly.  But lots of laguages have big prtions of
their syntax that are as intuitive as those salvagable
portions of BASIC's.  So, the question becomes one of
finding which *best* provides the abilities I listed.

--don


 
____________________________________________________________________________________
Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates 
(http://voice.yahoo.com)