🚀 go-pugleaf

In article <BzCxs6.9oC@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
]In article <724478076@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
]]Again, these points are so simple and so clear that it is
]]remarkable indeed to have anyone capable of reading and writing
]]disagree with them as Herman has.   And so I remark upon it.
]
]]] This is a chicken-and-egg phenomenon.  Most software development does
]]] not do certain things because the languages, compilers, and the training
]]] of the programmers does not mention them.  
]
]]That doesn't answer the question.  Herman specifically requested that
]]students be exposed to situations where code would "really crawl" unless
]]heroic and often architecture-specific measures are used to optimize it. 
]]Such cases are extremely rare, whether or not you believe in a catch-22
]]deadlock between hardware features and language features, or between
]]developer capabilities and language features. 
]
]If the actual code is not used, this may be difficult, but even the 
]initial idea that a computer manipulates objects, and that how it does
]this, and what objects it manipulates, are important.  But the idea of
]bit-twiddling, etc., seems to have been "obvious" to the early people
]in computing, and the use of binary in the mathematical literature
]before that time was extremely small.

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,
debig, and maintain such programs were completely unknown to them.

Things have changed. We've learned a lot about programming since then,
and we've discovered problems that they wouldn't have dreamed of. The
solutions to their problems aren't necessarily the solutions to ours.
What was natural to them, isn't necessarily natural to us. 

]]] Unlearning
]]] provides major obstacles for students in mathematics and statistics, and
]]] I see no good reason why CS and programming languages should be any
]]] different in this matter.
]
]]Precisely my point.  CS students under Herman's regime would have
]]much to unlearn before they could read, write, or even think about
]]portable, maintainable software.  These issues may not be important
]]to Herman, but Herman is the exception.
]
]They would have to unlearn nothing.  Starting out with the idea that
]there is a large variety of objects, and that machines operate on them
]in various ways, WILL cause them to question why the languages place
]obstacles in their use.

They would have to unlearn a *lot*.

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.

Most programming doesn't care about the internal representations of
its information. In most cases, *it doesn't matter*. For example, I'm
writing a program that does a graphical simulation of a network
protocol. I'm not worried about speed, because I've already got to
slow down the execution of my system to let a human being follow it.
What I am worried about is *correctness* and *maintainability*. 6
weeks from now, I'll be done with this project, and some other poor
schmoe is going to have to take it over, and continue work on it. When
that guy gets hold of it, it's absolutely crucial that
    (a) my code be understandable, so that he can expand on it
    (b) my code be correct, so that when he tries to expand it, he isn't
      forced to waste time discovering my bugs;
and (c) my code be *clean*, so that when he extends it, my code doesn't
      break his, and his code doesn't break mine.
     

]]] The student who takes a typical cookbook mathematics course seems to
]]] be farther away from eventually understanding than the one who starts
]]] out with the concepts and theory.
]
]]But the concepts of and theory of mathematics do not have much to do
]]with the bit-bumming he recommends early exposure to, so Herman's point
]]is obscure in the extreme.
]
]The bit operations are just the binary version of the "standard" decimal
]operations, and are by no means esoteric, except in the minds of those
]who would have people grow up ignorant of them.  The goto-laden code I
]posted was obtained from consideration of how to efficiently use "coin
]tosses", or other sources of random bits, to produce exponential random
]variables, and this topic is by no means of recent origin.  Base 2 is
]useful because it is useful, and not because of arcane considerations.

The bit operations *are* esoteric, because the bit representations are
generally esoteric. In most programs, the programmer writes code to
deal with *integers*, not 16bit 2s complement quantities. It's true
that the concept the programmer wants to deal with may get represented
in the machine by 16bit 2s complement quantities, but for the purposes
of the program being written, it doesn't matter. To go back to the
example of my current project, if I shifted to a machine which used
64bit 1s complement numbers instead of 32bit 2s complement, it
wouldn't affect my code a whit.

It's true that in *your* problem domain, these things matter. But your
domain is one, small, narrow niche. The overwhelming majority of us
who program don't share your concerns - we have our own worries, which
don't matter to you. But that doesn't mean that we're imcompetent or
negligent - the problems we're solving are the problems that need to
be solved for the work done by the largest number of people.

As I've said before, you're *terribly* ignorant about computer
science. You don't understand what problems we're trying to solve, and
you don't care. That's all right - you have your own work to do. But
so do we. We don't tell you what's wrong with the way you do
statistics - we're far too ignorant of statistics to be able to
intelligently comment on your methods. But equally - you're *far* to
ignorant of computer science, programming languages, and compilers to
be able to intelligently comment on ours.

	<MC>
-- 
|| Mark Craig Carroll: <MC>     ||"I prize the cloudy, tearing sky,
|| Univ of Delaware, Dept of CIS|| for the thoughts that flap and fly.
|| Grad Student/Labstaff Hacker || For staying in and reading by.
|| carroll@udel.edu             || For sitting under" -Karen Peris