[Tfug] Language choices

[Bexley Hall]

Hi, Brian,

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

> Quoting Bexley Hall <bexley401 at yahoo.com>:
> > Note that none of these personnel are particularly
> > "computer literate".  None are "hackers".  But,
> > they all have real needs to imppose on the control
> > system.  So you think they want to dick with
> > declaring variables before use?  Or, counting
> > nested parens?  Or, compiling/linking their code?
> > Or, even having to bracket their code with:
> >
> > int main(int argc, char *argv[])
> > {
> > ...
> > }
> >
> > And, their code has to run fast.  Sure, 5ms sounds
> > like an eternity -- until you realize there are
> > lots of other things happening in each of those
> > 5ms windows.
> 
> I just got back from my weekend in Phoenix so I'm
> going to jump in late
> in the thread without reading the previous 10,000
> lines of argument.
> (or even the original requirements! lol)
> 
> Really, if the ppl who have to modify the system
> don't have the skills to modify the code, don't
> give them the code.

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.
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 something
best handled by the customer himself:

  "here's the scripting language; 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 (the details of which are
embedded in those 10,000 lines)

--don


 
__________________________________________________________________________________________
Check out the New Yahoo! Mail - Fire up a more powerful email and get things done faster. 
(http://advision.webevents.yahoo.com/mailbeta)