🚀 go-pugleaf

In article <BzKCIn.Gr0@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
]In article <1992Dec18.164648.1857@udel.edu> carroll@gloin.cis.udel.edu (Mark C. Carroll) writes:
]]In article <BzD7q3.KHr@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
]]]In article <1992Dec16.164456.6939@udel.edu> carroll@bifur.cis.udel.edu (Mark C. Carroll) writes:
]]]]In article <BzCxs6.9oC@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (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. 

You're doing nothing but revealing how completely out of touch you are
with any area of computing outside of your own domain.

Programs have grown in side dramatically, and it's not just creaping
featuritis. The problems that we're working on solutions to are
dramatically larger than those we would have even attempted to work on
a few years ago. Solving more complicated problems requires writing
more complicated code.

] 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.

This is yet another non-sequitur. If the packages that are available
don't do the job, then don't use them. If the packages you want to use
don't provide source code, then find one that does. If there isn't
one, then write your own. (If the currently available packages are so
bad, and they waste so much of your time, then surely it is worth your
time to create one that will do the job!)

]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. 

Non-sequitur, and not even true.

]... 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. 

Again, not even true. WYSIWYG software is available on just about any
machine you want. If you don't want to buy it, that's your business -
but don't complain that it's the fault of the people teaching computer
science.

And still - none of your points so far have *anything* to do with the
issue that we are supposedly discussing: that being whether or not
computer science is being taught correctly. 

]]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.

No, you are *not* familiar with the problems of simulations. You are
familiar with the problems of simulations of statistical problems. My
simulation is not statistical; I don't *need* perfect random number
sequences; in fact, I don't need *any* random number sequences. My
problem domain is *not* the same as yours; the problems that I
encounter in my work are not the same as the problems that you
encounter in yours, and your solutions to problems in your domain
introduce significant new problems in mine.

Computer science shouldn't teach people to solve problems in one
specific domain. I don't want to see computer science taught
specifically from the viewpoint of network protocol programming,
because people trained in that specific domain will be useless in all
others.

If we taught CS your way, perhaps we'd create a crop of superb
statistical programmers (I very strongly doubt it, because they'd
focus too much on the low-level implementation and not enough on the
algorithm design and optimization), but they'd be perfectly dreadful
at working at anything else.

]]]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.

And possibly, we had trouble because you fed us dreadfully written,
convoluted, undocumented spaghetti code, written to solve problems in
a domain with which none of us are familiar. (But you'll notice that
still, after some time working out what you were trying to accomplish
with that code, many people have suggested alternatives and
improvements.)

Perhaps, just perhaps, the reason that no one understood what you
were doing wasn't because you're so much smarter at computing than the
rest of us. Perhaps it was because you didn't understand how to write
code that clearly, effectively represented the algorithm that you
were implementing.

]]]]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.  

No. The first step in good programming IS NOT PROGRAMMING. It is
designing the correct algorithm. The second step is deciding how to
represent that algorithm using the tools you have available. The last
step is actually writing the code.

]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.

I claim that this paragraph states *exactly* what you are trying to
do. You are concerned with nothing but the tools for doing low-level
operations, a job for which the computer is far better qualified than
you are. The people teaching computer science are teaching students to
solve problems - and not to waste time on twiddling the lowest level
of the implementation unless there is a significant gain to be had.
Most of the time, there is no significant benefit in hand-tuning the
code generated by the compiler; the stupid computer can do a very
adequate job on the low level; the intelligent human should be doing
the hard work.

]]]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.  

Programming languages are designed independent of operating systems.
The linker that is provided by Unix is fundamentally braindead.
There's no doubt of that, and I don't know of anyone who'll argue that
point. But that's got nothing to do with the design of programming
languages. The language is designed independent of any one
implementation. It's true that we've got to deal with the brain-death
of the Unix linker if we want to implement a language on Unix. But
that still doesn't say anything about the quality (or lack thereof) of
the languages that we design. (And, quite frankly, many of the newer
languages have provided very elegant ways around the problems of
cross-language linkage, even though they do use the Unix linker. Take
a look at externals in C++, Eiffel, Sather, Modula-3, the glhc haskell
compiler, T, and others) 


]And what if the modules cannot be interfaced without going through the 
]big nuisance of storing intermediate results in what are often massive 
]files?  

That's probably the result of poor program design. 

I've *never* used an intermediate file to pass results from one module
of a program to another module of that same program. I've used
intermediates for linking together two programs (when that's an
appropriate way of doing so), but within a single program? 

]... 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.  

First, the implementation of two statistical packages has nothing to do
with the issue we were discussing. Please stick to one subject at a time,
please!

And second, if you have the Fortran or C source for the code, then you
can generate the assembly code, so what are you babbling about? 

]]]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.  
]] .....
] 
]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.  

The ways of using information that the compiler designer didn't
envisage are usually algorithmic changes that can be represented at
the high level. In general, low-level optimizations are fairly simple
- and the optimizations that you want are peephole, which means that
they are well within the set of optimizations that a good compiler can
and will perform.

]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. 

Perhaps if you studied a little bit about compilers and optimizations,
you'd understand why this is a foolish statement.

Compilers routinely perform transformations that you could not do by
hand, because you cannot keep track of a sufficient quantity of
information. 

How often do you unroll your loops? How often do you do software
pipelining? How good are you at keeping track of pipeline fills and
interlocks?  How good are you at maximizing cache hits? Do you think
that you'll be as good at all this as the compiler? It's the kind of
work that the computer is very well suited to, but that people aren't.


]... 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 
]in a reasonable manner, teaching someone who learns how to program in 
]Basic or C to do good programming will not be possible.

I agree. But this paragraph again contradicts what you're claiming to
want. We don't teach people to program in a particular language, or
for a particular architecture. We teach people *how to program*.  Your
claim is that that's wrong, and we should be much more
hardware/language specific. Make up your mind...

	<MC>
-- 
|| Mark Craig Carroll: <MC>     ||"We the people are getting tired of your lies
|| Univ of Delaware, Dept of CIS|| We the people now believe that it's time
|| Grad Student/Labstaff Hacker || We're demanding our rights to the answers
|| carroll@udel.edu             || We elect a precedent to state of mind"-Fish