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

Text File | 1992-12-21 | 17.8 KB | 344 lines

Newsgroups: comp.lang.misc
Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!usenet.coe.montana.edu!news.u.washington.edu!uw-beaver!cornell!rochester!udel!louie!gloin.cis.udel.edu!carroll
From: [e-mail] (Mark C. Carroll)
Subject: Re: Safety.  Was: Re: Pointers
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News Service)
Nntp-Posting-Host: gloin.cis.udel.edu
Organization: University of Delaware, Newark
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Fri, 18 Dec 1992 16:46:48 GMT
Lines: 331

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:
]]]In article <[e-mail]> [e-mail] (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,
]]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.

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?

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

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

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.


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


]]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.
]]
]My code needs to have the same properties, but I must assume that the
]person maintaining my code understands enough of the underlying mathematics
]to know why various things are there.  This can vary from elementary algebra
]to graduate material.  Also, I do worry about the interface, and that is one
]reason why I feel that pointers, or a darn good substitute for them, is
]readily available.

No, your code doesn't! You've demonstrated that in the code you've
posted to the net, and in your continual explanations of your
programming style. Your code is written *strictly* for efficiency, and
any other consideration goes out the window in order to save a clock
cycle. That's not necessarily a bad thing - for the problem domain
you're working in. But that doesn't mean that every other programmer
in the world has the same concerns that you do. Most of us have other
things that take preference. For the applications I'm writing, making
my code clear and safe is far more important than reducing my runtime
by 5%, or even by 50%. For the people who will be using my code, it's
much more important that they be able to *easily* build on top of it,
than that it take 5 minutes less to finish a simulation.

What you fail to understand is, there are many different problem
domains in the world. Your domain is only one of them, and it's a
relatively small niche. The things that are problems for may not
necessarily be problems in other domains - and the things that are
solutions for you may not be solutions for other domains. In many
domains, your solutions aren't solutions at all - they are *severe*
problems. That doesn't mean that the people working in the other
problem areas are idiots, or incompetents. It doesn't make the
solutions to their problems foolish. They're not solving the same
problems that you're solving!

]In the pre-Unix systems I used, the interfacing problem was usually fairly
]easy.  This was not always the case, and interfacing the two calling sequences
]on the CDC6x00 often required tweaking assembler code.  But I had no problem
]with names on that system; the name that somebody else gave to a program,
]module, entry point, etc., was readily apparent, and it also was relatively
]easy to edit if necessary.  Try doing this on the current systems, with all
]their introduction of underscores.  The pre-Unix systems were reasonably well
]designed to use separate compilation, and the transfer of binary modules.
]

And again I ask: what does this have to do with the design of current
programming languages? Yes, I'll be the first to admit to you that the
Unix linker has a fundementally brain-dead system of handling names.
But what does that have to do with *anything*?

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

]In that case, it means that you do not have to handle numbers whose
]magnitude is greater than 2^15 - 1 = 32767.

It depends on what I'm doing. In my network simulator, I rarely have
to deal with numbers larger than 100. In other things I code, I deal
with arbitrarily large numbers - and so I use a language that allows
me to use arbitrarily large numbers.


]...  And except for number
]theorists, who damn the current languages as much as I do, those
]doing numerical mathematics are concerned at least 99% of the time
]with non-integers, except for indices and exponents.  But except
]for Fortran, these are not well handled, anyhow.

Really? So what's wrong with the numeric system in Scheme, or
Commonlisp?

Or the numeric class system in Haskell?

Or the numeric type system in Sisal?

Or have you just never bothered to look at any of them??

]They are no more esoteric than decimal representations.  The importance
]of the "Arabic" numerals was not that they changed computation; in fact,
]they did not change computation much, if any.  But they provided a
]simpler notation.  Interestingly, the Babylonian system, using base
]60, was quite similar.

But I don't use decimal representations either. I use *integers*, and
I don't care if they are represented as binary, ternary, octal,
decimal, duodecimal - what do I care?

]From your statements, I feel it is safe to conclude that numerical computation
]is not an important part of what you do--at least numerical computation
]involving numbers of much precision.

True. And from your statements, I feel that it is safe to conclude
that implementing large software systems is not a part of what you do.
Surprise! We each do what we're good at.

]
]]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.
]
]So you are saying that numerical analysis is unimportant.  That is the
]only conclusion I can draw from your statements.  This agrees with the
]conclusions which others have drawn about what is going on in computer
]software and hardware.

No, I'm not saying that numerical anaylsis in unimportant. I *am*
saying that numerical analysis is only one of the many areas of
computation that is important. And I am further saying that your area
is only one niche in numerical analysis, and that your solutions
probably aren't broadly applicable outside your area.

]]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.
]
]If someone comes to me with a statistical problem and wants to know how
]to solve it with the "standard" tools provided, quite often I have to
]get the problem carefully formulated (usually the client has no idea
]what the assumptions being made are), and much of the time I have to
]invent a new procedure.  Much of the time this new procedure can be
]widely used; some of the time it cannot.  The inventing of new procedures
]IS the analog of bit twiddling, as you call it.

You're describing exactly what's wrong with your approach. You haven't
ever bothered to formulate your problem carefully, and you haven't
ever bothered to learn anything about the background of what you're
talking about.

No one has claimed that the languages that you're using are
well-suited to the problems your trying to solve. I really do believe
that none of the current languages that are available will do the job
you want done. But your arguments are so strongly rooted in what you
don't know that you're not managing to tell anyone what you need, and
you're offending a lot of people along the way. You're never going to
get what you need unless you stop flaming, and learn enough to be able
to describe what you need. I'm not studying to be a numerical analyst;
I'm studing to be a compiler specialist. If you want me to build you a
compiler that does what you want, you've got to be able to tell me
what you want.

If you can't be bothered to do that, then you're just wasting your
time flaming the language design community for not designing your
language. No one is going to do your job for you. You want it? Go
ahead and tell us what you want, and you'll get it.

    <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.
|| [e-mail]             || For sitting under" -Karen Peris