[Tfug] Language choices

Stephen Hooper stephen.hooper at gmail.com
Tue Oct 31 08:43:49 MST 2006


Logo! Logo!

On 10/31/06, 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.
>
> > 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.
>
>
> > This is something best handled by the customer himself:
> >
> >   "here's the scripting language;
>
> (but the customer wasn't going to modify the code. ;)
>
> >    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.
>   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.
>
> Brian
>
> The opinions or statements expressed herein are my own and should not be
> taken as a position, opinion, or endorsement of the University of
> Arizona.
>
>
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
>




More information about the tfug mailing list