Xref: utzoo comp.arch:17032 comp.lang.misc:5130
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!iuvax!ethome.et.iupui.edu!noose.ecn.purdue.edu!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: It looks like he's at it again!
Summary: Some of these require a reply
Message-ID: <2336@l.cc.purdue.edu>
Date: 10 Jul 90 15:04:32 GMT
References: <2328@l.cc.purdue.edu> <1990Jul10.072443.4844@cs.UAlberta.CA>
Followup-To: comp.lang.misc
Organization: Purdue University Statistics Department
Lines: 64

In article <1990Jul10.072443.4844@cs.UAlberta.CA>, cdshaw@cs.UAlberta.CA (Chris Shaw) writes:
> In article <2328@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
> >In article <3627@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes:

		[ As much flaming as possible omitted. ]

> Plus assembler is a nightmare unless one of three things is true:
> 	1: The project is performed by 1 person.
> 	2: The project is small (less than 5000 lines)

I do not believe that even a 100 line program should be produced by one
person.  Anyone can miss too much.

> 	3: All modules adhere strictly to a call-return convention.

I have no difficulty with spaghetti code when I need it, and I often move
code blocks off for efficiency.  In fact, the call-return convention is
most annoying from the standpoint of efficiency, and I am quite aware of
this annoying fact.

Most of the present assemblers are horrors, but there are a few, like CAL
on the CRAYs, or COMPASS on the CDC 6x00 and related machines, which were
a step in the right direction.

> In other words, you can do it, but it's extremely hard work if you're building
> something non-trivial. Anywhere up to 1000 lines of code is trivial.
> Besides you're still going to suff a drop in productivity vs HLL's.

			.....................

> >Examples of simple instructions in hardware, much more expensive in software,
> >and for which I know of "reasonable" applications.

Examples omitted.  If you believe that the chips mentioned do this, how do
I get a description of these to verify this?  It is possible to see what 
hardware can do by reading the description.

> And if you're going to rant on (as you always do) about misfeatures in
> well-known programming languages, why don't you get off your duff and prove
> all us fools wrong? Show conclusively that modern HLLs stink by designing
> one that doesn't stink. Do the same for assemblers, too.
> So quit your bitching already.

If you have read what I have written, you would know that I do not believe
a good HLL is possible.  So, even if I had the resources (and they are very
scarce for things like this in an academic environment), why should I try?

As for assemblers, adding weak typing and good macro capabilities (the
macro should have an arbitrary syntax) to something like CAL would do
a good job.

Not everyone has flamed.  There are those who have been sympathetic.
If someone came to me with a statistical problem involving calculations
which the standard packages cannot do (a common situation), if he had the
programming resources, I would help him do it instead of just telling him
to stop complaining.  With the present situation in which funding is almost
entirely from the federal govennment, getting the necessary $30,000 or so
to produce the versatile macro translator is next to impossible.  It is
almost impossible to get graduate students to assist on faculty statistics
research projects.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)	{purdue,pur-ee}!l.cc!cik(UUCP)