Article View: comp.lang.misc
Article #1330Re: It looks like he's at it again!
From: Herman Rubin
Date: Fri, 13 Jul 1990 14:35
Date: Fri, 13 Jul 1990 14:35
90 lines
4994 bytes
4994 bytes
In article <2618@igloo.scum.com>, nevin@igloo.scum.com (Nevin Liber) writes:
> In article <2336@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>
> >I do not believe that even a 100 line program should be produced by one
> >person. Anyone can miss too much.
>
> Do you really believe that programming by committee is better? I feel
> that code should be REVIEWED and INSPECTED by someone other than the
> original author, but I have enough faith in my fellow colleagues to be
> able to produce 100 line programs reasonably well. Also, do you
> practice what you preach? Is all of your code written by a group of
> people instead of just yourself?
I mean that the programming should be done by two or three people working
together. Many years ago, I produced a random number package for the 6500
with the aid of an undergraduate CS major. This was written entirely in
assumbler, and was Fortran callable. The register quirks would have given
major problems in a HLL. It would have taken more than twice as long if I
did it by myself. BTW, it was not upgraded for the 6600, because it used
a particular calling sequence. The graphics package the computing center
used was also not upgraded for the same reason.
Most of my code is written by myself. That is why so little gets done.
> >I have no difficulty with spaghetti code when I need it,
>
> Are you the one who maintains the code that you write? When your code
> is moved to another machine/architecture/compiler, do you do the port,
> and if so, how quickly? There is already too much code out there which
> can't be changed because everyone is afraid that undocumented side
> effects were taken advantage of, and no one is quite sure how much
> other code will break if it is changed.
Spaghetti code can have a quite understandable simple structure. Algorithms
requiring spaghetti code even in HLLs available on request.
> >If you have read what I have written, you would know that I do not believe
> >a good HLL is possible.
>
> Then stop complaining that we can't do the impossible!
I have not complained about that. I have complained about making it difficult
to insert machine instructions in HLL code. For example, the asm on C,
besides having too many extra characters to type, does not allow (on the
compilers I have had to use) symbolic register designations. I have
complained about the horribly designed assembler format, and the lack of
macro facilities to simplify the inclusion of constructs.
> >So, even if I had the resources (and they are very
> >scarce for things like this in an academic environment), why should I try?
..................
> >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.
>
> How could you even justify spending $30K on this project? What makes
> this project so much more complex than a typical assembler or even a
> compiler? Maybe the government won't fund you because it can't see the
> value of the results of this project.
I have not asked the government for funding. I could probably get it. I
do not really wish to supervise a project which does not involve research
and is not in my field.
> >It is
> >almost impossible to get graduate students to assist on faculty statistics
> >research projects.
>
> Er, I thought that one of the things a grad student had to do was to
> help faculty on their research projects. Maybe the project just isn't
> rewarding enough.
This is definitely not the case in mathematics and statistics. One reason
is that a graduate student costs as much as a full professor (I kid you not),
and the current estimate is that only half the faculty who should be funded
are. In fields where there is a tradition of students assisting on faculty
projects on a regular basis, there is funding. This is also the case in
fields where equipment, rather than salaries, is the major cost.
Government red tape is worse than you think. On a project for the government,
a colleqgue and I wanted to hire a programmer. We could not do this, but we
could program ourselves at our consulting rates, which were much more than a
programmer would be paid.
--
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)
Technical Details
Message-ID:
<2347@l.cc.purdue.edu>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cikReferences:
<2328@l.cc.purdue.edu> <1990Jul10.072443.4844@cs.UAlberta.CA> <2618@igloo.scum.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!tut.cis.ohio-state.edu!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik From: cik@l.cc.purdue.edu (Herman Rubin) Newsgroups: comp.lang.misc Subject: Re: It looks like he's at it again! Message-ID: <2347@l.cc.purdue.edu> Date: 13 Jul 90 14:35:55 GMT References: <2328@l.cc.purdue.edu> <1990Jul10.072443.4844@cs.UAlberta.CA> <2618@igloo.scum.com> Organization: Purdue University Statistics Department Lines: 90