🚀 go-pugleaf

In article <2249@pembina.UUCP> cdshaw@pembina.UUCP (Chris Shaw) writes:
>Frankly, I'm getting very tired of reading Herman Rubin's complaints about C,
>because he never seems to have a coherent solution. All I see is calls
>for someone else to solve his particular problem, coupled with the unspoken
>attitude that his particular complaint should have been taken care of long ago.
>"The meter's running, buddy! Get to work!"
>
>So what?
>
>Maybe people do seriously listen, but come to the conclusion that it isn't
>worth the time and effort to give Herman Rubin what he wants. I don't know, 
>but it seems to me that Herman Rubin is wasting his breath. Time for action, I
>think. Time for Herman Rubin to write "SL", for "Statistical Language", and
>to report on its results. Calling other people stupid is valuable only as 
>long as they are willing to listen. For me, time was up long ago.

     Hear!  Hear!  I was just thinking this morning about how the statistical
world would feel about a bunch of programmers announcing that they were
completely dissatisfied with the current state of statistical analysis, and
demanding that statisticians begin "doing statistics right!"

     I anxiously await release 1.0 of SL.  I'll need an implementation for
my Sun-3/60, of course, and I'm running SunOS 3.4, if that helps.

     I would suggest that Mr. Rubin get a firm grounding before beginning his 
project.  I would suggest as a basic curriculum a compilers course, including 
study of lexical analysis, grammar theory, top down and bottom up parsing, LL,
LR, and LALR grammar generation, basic code generation, code optimizations, 
and flow analysis.  Then, dive into a semester of machine architecture, 
including the fundamentals of stack, one, two, and three address machines, 
pipelining, the merits of CISC and RISC, and instruction set design. Since 
languages have users, you'll need some time in a few psychology courses, to 
study how people think about problems and perceive tools.  It is also helpful 
to take a language survey course, and write a few programs in about 10 or 15 
languages, just to get a feel for what is out there. A few operating systems 
courses will bring you up to speed on linkers and loaders, resource 
management, device interfacing, and I/O issues.  Finally, some training in 
software methodology, so that your compilers will be easy to build, modify, and
port, and so that you'll be able to include good design features in your 
language. 

     After you have done all this, like I and countless other computing
professionals have, then you are qualified to make the hard tradeoff decisions
that arise in language design and implmentation.  There is no perfect decision
and you can't please all users.  Like my old office mate used to say, you
can't be all tools for all fools.

     This may seem a little harsh, and I guess it is because I'm a little
peeved.  The point is, until you fully understand an issue, you are only
qualified to make suggestions.  When a more qualified professional overrides
your suggestion, you should defer to his or her opinion.  I don't try to
tell auto engineers how to build cars.  I might have some ideas about how
my car could be better, but if they say there is a good reason why not, that
pretty much closes the issue for me.  I'm simply not informed enough to 
dispute them.

     Chris Shaw also raises the point of effort versus payoff for a large
group of users.  I think Mr. Rubin is in a small majority of users, and it
simply does not behoove system designers to expend the effort to support
his desires.  Classic case of supply and demand in a free market.

Chuck Musciano			ARPA  : chuck@trantor.harris-atd.com
Harris Corporation 		Usenet: ...!uunet!x102a!trantor!chuck
PO Box 37, MS 3A/1912		AT&T  : (407) 727-6131
Melbourne, FL 32902		FAX   : (407) 727-{5118,5227,4004}