NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/lang/misc/4069

Text File | 1992-12-21 | 11.5 KB | 210 lines

Newsgroups: comp.lang.misc
Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!spool.mu.edu!news.cs.indiana.edu!noose.ecn.purdue.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: [e-mail] (Herman Rubin)
Subject: Re: Safety.  Was: Re: Pointers
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News)
Organization: Purdue University Statistics Department
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Sun, 20 Dec 1992 15:03:59 GMT
Lines: 198

In article <[e-mail]> [e-mail] (Mark C. Carroll) writes:
>In article <[e-mail]> [e-mail] (Herman Rubin) writes:
>]In article <[e-mail]> [e-mail] (Mark C. Carroll) writes:
>]]In article <[e-mail]> [e-mail] (Herman Rubin) writes:

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

>]]The idea of bit-twiddling was obvious to the early people in
>]]computing. But then, the problems of programming weren't very clearly
>]]understood by them. The idea of a writing a program which required
>]]hundreds of thousands of lines of machine code was almost beyond their
>]]imagination, and the problems caused by trying to write, understand,
>]]debug, and maintain such programs were completely unknown to them.

>]It is true that they did not envision such large machine programs.  Maybe
>]they were right about it; too often one is confronted with a "package"
>]which has a few wanted things, lots of items about which one does not
>]care, and a fair number of supposedly "user friendly" gadgets, which
>]are often quite "user inimical."

>Stick to the issue. We aren't talking about user interfaces here...
>Programs have grown in size - we do things on our computers every day
>that require incredible amounts of code to support - even if we
>completely ignoring the quantity of code that supports user
>interfaces.  Programs have grown, dramatically.

Programs, designed essentially for non-numerical purposes, have grown in
size.  But they have grown by attempting to provide too much, while at
the same time not providing enough.  This is even true with many of the
numerical "packages", such as the statistics packages which can provide
far too many of the usually inappropriate cookbook procedures, without
providing for the use of procedures not in the cookbook which are the
ones appropriate for the problems.  An example was the time I needed
to compute exp(z)*erfc(x).  Now I KNEW that often this would be infinity
times 0 if I used the functions as is, so I tweaked the source code to do
this all at once.  This is an easy tweak, and someone who did not even know
the source language would have no problem with it, even with an assembler
source, provided a little programming knowledge was present.  For example,
I could tweak the Lisp code, or APL, and I am barely familiar with those
languages.  But if only the package was available, the situation would
have been hopeless, and I would have had to get an alternate source for
the function, or reprogram it from scratch, using a less efficient
algorithm, and even facing roundoff problems.

Now I am told that using multiple fonts in the same window can be done
in X windows, but that it is a major undertaking.  We have elaborate
typesetting devices, but on the machines accessible to me, we have no
approximation of WYSIWYG, although this has been feasible at low cost
for more than a decade.  I doubt that many of the readers of the net
can write their material half as fast as they could type it with any
remotely readable approximation of WYSIWYG.

I see these brilliant packages providing 10000 "features" which I do not
want, some of which I have found to be more bugs than features, and which
do not privide the 10 which I want.  I include the numerous mouse features,
all of which I would prefer to do from the keyboard; I doubt that anyone
can move and position the mouse, hold down the relevant buttons and release
them at the right times, etc., as quickly and as accurately as using
appropriate keyboard manipulations, some of which would have to be added
as additional keys.

>Just for example: I'm using a network protocol specification system
>called Estelle. I've got an Estelle protocol analyzer based on a
>system called Pet. The complete Pet system, including analysis and
>simulation of protocols is well over a megabyte of object code. That's
>a HUGE amount of code to deal with.

>I have to extend Pet to do a particular kind of simulation. I've got
>over 1 megabyte of code written by someone else to deal with. That
>megabyte includes not one line of user-interface code, because I'm
>using the stripped down command-line system. Now - what's going to be
>more important to me? Knowing that my simulations will run 20% faster,
>or knowing that I can build on top of pet without having to dig into
>its internals to understand every facet of its implementation?

I am familiar with the problems of simulations.  I hope you are not using
any of the currently popular crude pseudo-random numbers to do it.

>]But the types of operations, etc., required do not change merely because
>]one has lots of them.  Bits are twiddled because some useful operations
>]require twiddling bits.  Virtually all branches are binary, with a few
>]ternary such as sign.

>Why does this seem to be a non-sequitur to me? What does bit-twiddling
>have to do with the binary nature of most branches?

People like me, who have no problem understanding them, use the binary
nature of branching, and otherwise.  Possibly the problems that many have
had in the code which gave rise to the "hrubinstones" have been do to the
lack of binary thinking, which is implicit in the algorithms I proposed.
Now I grew up before binary thinking was of importance; maybe that is why
I can see how to use it profitably :-)

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

>]]Good programming almost never requires bit-twiddling. It does require
>]]clarity, modularity, documentation. A good programmer worries about
>]]how difficult the code s/he writes will be to understand and maintain.
>]]In general, the maintainability of the code is by far the most
>]]important concern. Most of the time (virtually all of the time), the
>]]speed of the code generated by the compiler is more than adequate, and
>]]any gains to be made by adding bit-twiddling into the programming will
>]]be more than outwieghed by the additional difficulty in understanding
>]]and maintaining the code that takes advantage of them.

The first step in good programming is to produce code which will work well
for an adept, and which will do what a pundit will want to accomplish.
Only then should we put in the bells and whistles and blocks for someone
stupid, who will do stupid things anyhow.  You seem to be concerned ONLY
with providing tools for those doing low-level and routine operations.
This is teaching them to do what the computers will eventually take over.
This is the bane of the present day educational curriculum; the computer
should do what computers can do well, and not try to keep humans from
being innovative.

>]Nothing you have stated here is new.  Unfortunately, much of what is done
>]now is the opposite of modular.  We have these massive operating systems
>]which do millions of things, and certainly the user can do nothing about
>]separating them most of the time.  So we impose restrictions like object
>]files have to have their names end in .o, C source files in .c, etc.  This
>]is NOT modular, it is the reverse of it.  We have moved from 5 or 6 bits/
>]character to 8, and few systems allow the direct reading and writing of
>]these 8-bit characters.


>Another non-sequitur. You're confusing several different, completely
>independent issues.

>File naming conventions have nothing to do with language design. The
>fact the Unix prefers you to name your C code files *.c, and your C
>header files *.h doesn't have _any_ relationship to the modularity or
>lack of it in the C language.

Prefers is one thing, but having compilers which INSIST on it is another.
Now it must have been language, or compiler, designers who implemented
the systematic butchering of user names by adding underscores; the
facilities I used before encountering a UNIX-based system did no such
horror.  This is another example of trying to do too much; someone doing
anything different certainly does not want names changes by the system,
expecially if different languages and compilers are being used.

>The fact that the brain-dead operating system that most of us are
>forced to use has a monolithic kernel has nothing to do with whether
>or not we write modular programs.

>Those are two different issues, which have absolutely *nothing* to do
>with what I was talking about. Regardless of the OS kernel being used,
>and regardless of the file system naming conventions being used, a
>good program is still written modularly.

And what if the modules cannot be interfaced without going through the
big nuisance of storing intermediate results in what are often massive
files?  Try interfacing two statistical packages.  Try changing the
names in object libraries for which one does not have the assembler
source; the Fortran or C source is not even adequate.  Try making minor
changes without going through a compiler which assumes it knows better
than you what you want to do.

>]The speed generated by the compiler is only adequate if the facilities
>]are underused.  Now in many cases, this is not unusual.  It is not often
>]that the file management mechanism has to be quick in locating files.
>]And interactive editors do not have to be faster than the typist, EXCEPT
>]that a shared computer can have many typists on at the same time.  I have
>]often had to wait for editor response because of system load; doubling the
>]speed of the executing code would often help a lot.

>Not at all true.

>In many cases, the code generated by the compiler is faster than the
>code you'd write. The compiler can keep track of more information than
>you can, and it can use that information in ways that you probably
>wouldn't. So, regardless of whether or not the machine is being used
>to its full potential, the compiler generated code may be better than
>the human generated code. In most other cases, the speed difference
>between hand tuned code and machine optimized code is negligable. (In
>a code without a deeply nested, tight inner loop, saving 2
>instructions in a sequence of 10 does not produce a significant speed
>difference.)

The compiler can keep track of more information than I can, but it cannot
use the information in a manner which its producer did not envisage.  Nor
can it use information which it does not have.

That generally compilers can produce code which runs faster than that
produced by a programmer who only knows what has been taught in the
courses, or is explicit in the manuals, and who does not know how to
think in the symbolism and manner of someone with an undestanding of
the simplicity of abstract mathematics, should be a red flag in the
eyes of the curriculum designers.  Just as I cannot teach someone who
does not understand probability and statistical concepts, but instead
"learns"  statistics from the usual methods courses, how to do statistics
n a reasonable manner, teaching someone who learns how to program in
Basic or C to do good programming will not be possible.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: [phone]
[e-mail] (Internet, bitnet)
{purdue,pur-ee}!snap.stat!hrubin(UUCP)