Somewhere in the introduction of "Mastering Algorithms with Perl",
the authors point out that many text-books use pseudo-code to teach
algorithms. The authors prefer to use a real language, they think
pseude code has not much to do with reality.
I think "Mastering Algorithms with Perl" is an excellent example of
why you should prefer boooks using pseudo-code. MAP gets side tracked
over and over again, having to explain syntax, showing cute tricks,
discussing language specific efficiency, or promoting CPAN modules,
discussing API's instead of algorithms.
It might be good to quote Knuth:
Many readers are no doubt thinking, ``Why does Knuth replace MIX by
another machine instead of just sticking to a high-level programming
language? Hardly anybody uses assemblers these days.''
Such people are entitled to their opinions, and they need not bother
reading the machine-language parts of my books. But the reasons for
machine language that I gave in the preface to Volume 1, written in the
early 1960s, remain valid today:
- One of the principal goals of my books is to show how high-level
constructions are actually implemented in machines, not simply to show
how they are applied. I explain coroutine linkage, tree structures,
random number generation, high-precision arithmetic, radix conversion,
packing of data, combinatorial searching, recursion, etc., from the
ground up.
- The programs needed in my books are generally so short that their
main points can be grasped easily.
- People who are more than casually interested in computers should have
at least some idea of what the underlying hardware is like. Otherwise
the programs they write will be pretty weird.
- Machine language is necessary in any case, as output of many of the
software programs I describe.
- Expressing basic methods like algorithms for sorting and searching in
machine language makes it possible to carry out meaningful studies of
the effects of cache and RAM size and other hardware characteristics
(memory speed, pipelining, multiple issue, lookaside buffers, the
size of cache blocks, etc.) when comparing different schemes.
Moreover, if I did use a high-level language, what language should it
be? In the 1960s I would probably have chosen Algol W; in the 1970s,
I would then have had to rewrite my books using Pascal; in the 1980s,
I would surely have changed everything to C; in the 1990s, I would
have had to switch to C++ and then probably to Java. In the 2000s, yet
another language will no doubt be de rigueur. I cannot afford the time
to rewrite my books as languages go in and out of fashion; languages
aren't the point of my books, the point is rather what you can do in
your favorite language. My books focus on timeless truths.
Therefore I will continue to use English as the high-level language in
TAOCP, and I will continue to use a low-level language to indicate how
machines actually compute. Readers who only want to see algorithms that
are already packaged in a plug-in way, using a trendy language, should
buy other people's books.
The good news is that programming for RISC machines is pleasant and
simple, when the RISC machine has a nice clean design. So I need not dwell
on arcane, fiddly little details that distract from the main points. In
this respect MMIX will be significantly better than MIX
Abigail
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.
|
|