[Tfug] Language choices

[Bexley Hall]

--- t takahashi <gambarimasu at gmail.com> wrote:

> On 10/29/06, Bexley Hall <bexley401 at yahoo.com>
> wrote:
>>> at the low level, i'm not convinced that modern
> gc
> > > languages are quite as bad as you imply.  even
> if
> > > they are, there are subsets of at least one of
> those
> > > languages (scheme) that avoid gc.  you might
> want to
> > > check them out.
> >
> > Would you write a web page cgi in scheme?  :>
> > Would you expect others to embrace that approach?
> > Etc.
> 
> huh?  i thought that you were concerned that gc
> languages would fall
> afoul of your embedded system's memory limitations. 
> i told you that
> you might not want to dismiss some normally gc
> languages.  so what is
> it with your rhetorical questions about something
> completely different?

Because I just don't see people embracing something
like scheme as a scripting language.  Just like I
don't expect to see people embracing *Latin* to
write formal product specifications. Sure, both
are *possible*; but I consider neither *likely*.

> to answer your questions, 1) sure, why not? and 2)
> no, i expect people
> to do whatever they want to do.  if people want to
> write them in
> microsoft PYTH-COBOL++, hey, good for them.

If you are developing a product and want it to be
well-received, you have to consider what likely
users *and* customers (they may be different) will
be happy and/or comfortable with.  If you have
MS's clout, you can *try* to convince people to
use something that they would normally consider
undesirable.  But, even MS's big stick doesn't
guarantee success on that score.

> to answer what is probably your reason for throwing
> those rhetorical
> questions at me, no, scheme isn't my SHITLANG.  i

Sorry, I didn't mean to suggest that at all.  :<
Rather, I was pointing out what I considered a
fundamental "problem" with languages like scheme --
you'll note I applied similar comments to ML.

> opined that you might want to consider it again
> since the vast majority of your stated desires
> point more to scheme than any other language that
> somes to mind at the moment (although forth had me
> going).  the major desires against scheme are gc,
> functional family, and the apparent desire to
> have no symbols at all in the syntax including
> parentheses.

Note that I had previously commented that, were it
not for parens, LISP would be an ideal choice in
that regard.  I also commented that parens *seem*
to be impossible to do away with.

> i really don't care what language you use.  really.

I don't expect you to!  :>

> i REALLY just wanted to help.  believe it or not.

Wow, I'm sorry you reacted this way -- it was not
my intent.  And, I don't really see the justification
for it.  :<  But, *your* perceptions govern *your*
reactions -- so I can only express my regret.
 
> i'm out of this discussion.  i sense that soon there
> will be heat and little light in it.  i thought i
> might have been of help to you.  i wasn't.  too bad.

On the contrary, I find *all* comments helpful in that
they encourage dialog.  I'm sorry youve been "set off"
on this one.  :<

> good luck.  i hope you find exactly the language
> you need.  no worries mate.
> 
> > I find most languages are *not* well thought out.
> > Rather, they tend to be collections of ideas that
> > "seemed good" to someone at some time (e.g., read
> 
> true.
> 
> most != all.  do you agree?

Of course!  I found Wirth's presentation of Modula2
to be well thought out and consistent with *his*
stated goals.  OTOH, I find C makes far too many
concessions to hardware, legacy implementations
and applications, etc.  C++ probably justifiably
worse!  Ada so "pent up" that you expect the
pages of the text to be made of thin sheets of STONE.

> (oh, great, now the perl crowd will put on their
> larry costumes and bark at us).
> 
> > And, they are languages designed for general
> purpose
> > (or specific purposes).
> 
> truer words have never been spoken.  they are indeed
> designed for, um, general purpose or specific
> purposes.
> 
> :-)

Perhaps I was too subtle?  Too general often carries
baggage that I'd like to avoid; too specific often
misses the intended application domain entirely!

> > OTOH, I can decide which features are important to
> > the types of applications that I need to address
> > and cull those that are superfluous.
> 
> indeed.
> 
> have fun.
> 
> > *I* like recursion.  I don't think the folks who
> > will be *writing* these applets would, though!
> 
> seems to me i addressed that point.
> 
> > Look at all of the folks out there who "build
> > web pages".  Using Flash, or perl scripts, or...
> > how many of those would embrace scheme?  Why
> > haven't they?  :-(
> 
> if it comes down to that, then look at autocad or
> emacs.
> 
> or not.

But the people who use ACAD and emacs are not the
mainstream.  I've been actively using ACAD since
v2.52 (!) and I've yet to write anything "serious"
in AutoLISP.  My needs aren't specific enough to
drive me to develop any particular tools therein.

If I was writing web pages "for a living", I would
start building a toolkit of useful scripts, idioms,
etc. geared towards the types of pages/forms that
I was being called upon to create (I don't do web
pages  :> ).  I would *invest* in whatever language(s)
were available to me in that application domain.

My target audience will have no choice but to adopt
whatever language I support for use on these devices.
They are unlikely to develop something on their own!
Given little flexibility in this regard, people often
are overly quick to develop a distaste for a "bad"
product (i.e. their opinion of *their* interface to
the product) if it isn't "accommodating" to their
needs and abilities.  When competitors arise, your
market disappears  :<  *And*, while it's disappearing,
you are spending time/money at an increased pace
to try to stem the tide!

So, you think REAL HARD about what to provide to
the user and *how*.  The criteria I mentioned in
my earlier posts aren't "arbitrary".  They come 
from talking with potential users/customers,
looking at how they do their work currently,
listening to their wishlists, etc.  Then, filtering
all of that through a bit of sanity (some things
aren't realistic), economics (some things aren't
affordable) and "gut feel" (some things *sound*
like good ideas but you *know* they won't really
make a notable difference if they do/don't exist).

A sample application domain to put things in context:
[this is lengthy  :<  but, I suspect most folks have
no experience with this sort of application and may
be interested in how these things are made...]

"Tablets" (e.g., "pills") are made on large "tablet
presses".  Most manufacturing is done on *rotary*
tablet presses.  These exist in various sizes,
production rates, with various features and
compression techologies, etc.  At the high end,
they produce ~1,000,000 tablets PER HOUR.  I.e.
a couple hundred PER SECOND.

Imagine a "turntable" holding ~50 - 100 identical
"molds".  As the turntable spins, each mold passes
under/through a pile of "granulation" (the powder
from which the tablet will be made).  If the powder
is flowing properly and the turntable is rotating
at the right rate, a certain *volume* of powder
will fill each mold (called "die") as the turntable
rotates it out of the "feeder" area.  Of course,
other die are right behind it *in* the feeder
being filled while it exits that area.

Once full, the die passes under a "plunger" (called
a punch) that tamps down the granulation -- exerting
a *light* force... maybe half a ton (!).  It then
moves on to another area (as the turntable continues
its rotation) in which a much *greater* force is
applied to compress the granulation in the die -- as
much as 10 or 20 tons.  The turntable keeps rotating
until that mold (die) comes to the "ejection"
station.  Here, the plunger that had been compressing
the granulation is lifted out of the way and the
bottom of the mold is pushed upwards to eject the
tablet.

But, tablets (at least *pharmaceuticals*!) have
*weight* criteria, not *size* criteria!  I.e.
that does of aspirin is supposed to weigh 100mg
(with a given tolerance) as the weight determines
the amount of active ingredient in the tablet.

Ah, but you can't *weigh* individual tablets at
a rate of 200+ per second!  :<  So, you cheat.
You know the volume of the cavity in which the
tablet was formed (i.e. the volume of the mold
when the top plunger is fully inserted) and,
you *learn* what the compressibility of the
particular granulation is.  From these, you
can either *measure* the actual thickness (size)
of the tablet formed under a given compression
force *or* measure the force exerted to compress
the tablet to a fixed *size* (different manufacturers
use different technologies -- for different reasons).

Measuring tablet thickness or compression force is
something you *can* do at a 200Hz rate.  And, you
can then develop criteria to accept or reject
individual tablets based on those observations.
The tablet press has a mechanism located where
the tablets are ejected that essentially diverts
individual tablets into one of two bins:  good
and bad.  (there is usually a "sample" ability
as well that is used by quality control staff
to pull tablets out of the production stream
for manual testing)

Keep in mind that this is happening at a rate of
a few *milliseconds* per tablet.  And, that 50-100
tablets are in various stages of production at
any given instant (i.e. mold 1 is being filled
while mold 15 is being "tamped" and 27 is being
compressed and 62 is being ejected, etc.).

There are several different types of people who
play with this machine:  some folks monitor it
during production; some folks provide *quality*
control during production; some do repairs on
the mechanisms; some maintain the control
systems (electronics); etc.  And, a class of
pharmacologists who have to develop the granulation
mixtures in such a way that they include the
required "active ingredients" as well as the other
materials necessary to *manufacture* the tablets
in this way.  (e.g., you will find "magnesium
stearate" in the list of ingredients of many
tablets...
it is a lubricant to help eject the tablet from the
die!)

In production, they may notice a problem with
one particular "station" (mold+plunger combination)
producing out-of-spec tablets.  E.g. the control
system may indicate that station 27 is always
producing underweight tablets.  So, it would be
nice to be able to *sample* that station's
tablets without disturbing the normal operation
of the tablet press.  (recall that if you shut
the press down for 5 minutes to check on something,
you have lost 50,000+ tablets worth of production!)
It sure would be nice to be able to say:

  if (station == 27)
  then sample();

and hang a bucket under the "sample" chute to catch
the tablets -- without affecting the "good" and "bad"
tablets coming off the tablet press.  You can then
have the quality folks manually examine the tablets
to determine if they are, in fact, out of tolerance.
And, if so, you can examine them KNOWING THEY ALL
CAME FROM STATION 27 for clues as to the possible
cause for this (e.g., perhaps the plunger is worn
out and not compressing hard enough; or, perhaps
air is getting trapped in the tablet and, once the
compressive force is released, the top half of the
tablet is popping off, etc.).

The pharmacologist responsible for developing the
granulation formula may need to tweek it to add
more "binder", or, more lubricant, etc.  But, he
often works with very small batches of granulation.
If he were to operate the tablet press in it's
normal configuration, he would use up all of his
granulation in a matter of minutes (recall that
he has to run the press at the same tableting
rate that they are running it in production -- else
it is not a valid experiment!).  So, he cheats and
removes 4 out of every 5 plungers from the press.
This means 4 out of every 5 molds will not be
compressed when the machine is running (and, the
granulation will simply be sit in the mold, unused,
instead of being ejected in a tablet!)

Ah, but the control system will see 80% of the
tablets as being out of tolerance.  This will
cause the press to be shutdown automatically
(since there is too much waste being produced!).
It sure would be nice to say:

if ((station % 5) != 0)
then ignore();

and still avail himself of all the "normal"
control features present in the system (e.g., so
the press automatically shuts down when the
filling station has run out of granulation, etc.)

If the maintenance technician wants to perform
routine calibration of the pressure sensors,
he can mount a NBS traceable load cell under
a particular mold+punch station and tether it
to his data acquisition system.  But, he can
neither *afford* one such sensor for each station
concurrently; nor can he physically fit that
many on the machine at one time!  It sure would be
nice if he could:

if (station == X)
then log(compression_force[X]);
else ignore;

which gives him a record of the forces measured
by the control system which he can then correlate
with the observations that his diagnostic tools
have made.  Yet, the system continues to operate
as it would IN A PRODUCTION ENVIRONMENT (i.e.
at the same speeds, etc. without "shutting down"
because the control system thinks that bad tablets
are being produced).

There are even wilder combinations of things that
can be done/desirable as there is a lot of data
available that I haven't mentioned -- for the
sake of *brevity* (ROTFLMFAO!  :>)

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.  *And*, a correct answer in 5.0001ms is
an *incorrect* answer -- the tablet is "gone" by
then!  Of course, it is not acceptable to say,
"out of memory" and stop the press if the user
writes something that uses too much memory and you
can't *reliably* determine that a priori :-/

Does this put things in better perspective?
"Lightweight scripting language" seemed an
ideal way of describing it...

--don


 
____________________________________________________________________________________
Access over 1 million songs - Yahoo! Music Unlimited 
(http://music.yahoo.com/unlimited)