Knuth Releases Another Part of Volume 4 260
junge_m writes "Donald Knuth has released another of his by now famous pre-fascicles to Volume 4 of his epic:
Pre-fascicle 2c is all about 'Generating all Combinations' supplementing his pre-fascicles 2a and 2b.
Furthermore he challenges us all to do more of his daunting exercises and report our success. He thinks we are way too lazy in this respect! So come on slashdot crowd: Do your homework and get the credit from the grandmaster himself!"
Tshirts (Score:3, Funny)
Thats just what I need (Score:2, Funny)
A series of books like this for higher lvl coding? (Score:5, Interesting)
No flames please. This is just an honest question.
Thanks
Re:A series of books like this for higher lvl codi (Score:5, Insightful)
To quote:
"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. "
Re:A series of books like this for higher lvl codi (Score:5, Informative)
For the intro:
In his book series The Art of Computer Programming (published by Addison Wesley), D. Knuth uses an imaginary computer, the MIX, and its associated machine-code and assembly languages to ilustrate the concepts and algorithms as they are presented.
The MIX's architecture is a simplified version of those found in real CISC CPUs, and the MIX assembly language (MIXAL) provides a set of primitives that will be very familiar to any person with a minimum experience in assembly programming. The MIX/MIXAL definition is powerful and complete enough to provide a virtual development platform for writing quite complex programs, and close enough to real computers to be worth using when learning programming techniques. At any rate, if you want to learn or improve your programming skills, a MIX development environment would come in handy.
The MDK package aims at providing such virtual development environment on a GNU box. Thus, MDK offers you a set of utilities to simulate the MIX computer and to write, compile, run and debug MIXAL programs.
oops (Score:1)
Re:A series of books like this for higher lvl codi (Score:1)
Knuth introduced the MIX back in the 60s and all the reasons why it was the wrong choice back then remain valid today. He well knows that, but leaves it in the text to follow his own theological observations and not make his books perfect.
A friend of mine suggested printing post-it notes with Java code to paste over MIX code in the tAoCP.
Re:A series of books like this for higher lvl codi (Score:2)
>mistake in their tile designs, as it would be
>presumptous for a mere mortal to attempt
>perfection.
I've heard that about Navajo rugs too, but have never been able to verify it.
Re:A series of books like this for higher lvl codi (Score:5, Funny)
A friend of mine suggested printing post-it notes with Java code to paste over MIX code in the tAoCP.
Suggesting that Knuth should implement his algorithms in Java is the strongest argument for MIX I've ever heard.
MIX (Score:1, Interesting)
I don't buy that argument. And the business about TAoCP being like the Encyclopedia Britainica, a work for the ages is a bit of a crock. As compendiums of algorithm's go I prefer the one written by Ron Rivest and friends. I can't remember whether it is written in Pascal or C and I really don't mind because I can easily read both.
My ideal algorithms book would be written in a modified version of C# or Java. First I would get rid of the unnecessary braces and semicolons. All they do is to make the code fragments longer. Indentation shows block structure much better, continuation lines are not actually ambiguous in algol like languages.
I would also add in statement of the loop invariants, pre and post conditions which as a formal methods person I regard as an important part of an algorithm.
Re:MIX (Score:2, Interesting)
You've just reinforced his argument (Score:2)
The point of a bare bones old language is that it favors nothing. If you have to see an idea in C# or Java to understand it, then you are a piss poor programmer.
Re:You've just reinforced his argument (Score:2)
If you use a high level enough language you can do that with a script.
My point was however that if you are going to invent languages to describe algorithms it is better to invent a high level language than a low level language.
And although Java and C# have only just been introduced, the format is readily accessible to anyone who has used CPL or one of the algol family of languages.
If you have to see an idea in C# or Java to understand it, then you are a piss poor programmer.
I can still code 6502 machine code (i.e. without an assembler), I could probably learn MIX, but I very much doubt I will bother. If I want to use an algorithm from Knuth's book I will give the book to an engineer and tell him to give me C# or Java classes that implement the ones I might want to use. Privilege of rank.
You call yourself a programmer?!? (Score:2)
If I want to use an algorithm from Knuth's book I will give the book to an engineer and tell him to give me C# or Java classes that implement the ones I might want to use. Privilege of rank.
Seems like you don't want to LEARN, you just want to ape the procedure and never have to exercise the gray cells.
Knuth's book are for learning IDEAS not copying code blindly.
Re:You call yourself a programmer?!? (Score:2)
Seems like you don't want to LEARN, you just want to ape the procedure and never have to exercise the gray cells.
I get plenty of exercise in that area solving real problems without having to solve other people's invented puzzles.
The process of engineering is knowing which details are important and which are not. I don't care about how an algorithm works unless there is a good reason to care.
I consider the value of a book lies in both the ideas it presents and the ability of the author to communicate them. Unfortunately Knuth appears to be going for the Heidegger/Habbermass school of presentation which is in my view indefensible when you are presenting other people's ideas.
If I want to spend time on something that is a badly written presentation of interesting ideas I'll read a continental philosopher.
Re:You've just reinforced his argument (Score:2)
Knuth was working on volume 4 before I started my thesis which was considerably earlier than Java.
I did not suggest that he write the book in Java or C#, I suggested that if he is going to invent a language a high level language is more convenient than an invented assembler code. Moreover examples that provide the loop invariants, pre and post conditions can be put through automatic proof checkers which is kinda useful if you want to be sure that the algoriths are correct.
The point of a bare bones old language is that it favors nothing. If you have to see an idea in C# or Java to understand it, then you are a piss poor programmer.
It isn't that long ago that I used to write 6502 machine code without the need for an assembler. I probably could understand Don's examples if I wanted to but to be honest I'm not that insecure about my technical ability that I need to decode other people's obscurantism.
At this point a compendium of algorithms does not in my view justify the title 'the art of computer programming'. There is much more to the art than knowing which algorithms to apply.
Re:MIX (Score:2)
The pre and post conditions are no more or less trivial than the algorithm they describe.
And given the number of folk who can specify a sort and forget to state that the output must be a permutation of the input I don't think that using formal methods is as trivial as you make it out.
Re:MIX (Score:2)
This statement doesn't stand up to even trivial analysis. The pre- and postconditions set up the purpose of the algorithm and the assumptions behind it -- but for a nontrivial algorithm that's a far different thing than the actual meat; an algorithm with a simple purpose may easily have a complicated execution.
Strange Instruction - SRI?? (Score:3, Funny)
3C SR shift right (1) rA
3D SRI Stanford Research Institute (2) rA
3E SRU shift right unsigned (1)
What's that do then?
Re:Strange Instruction - SRI?? (Score:3, Interesting)
Re:Strange Instruction - SRI?? (Score:3, Funny)
It's indeed one of the most complex instructions ever found in a CISC processor. What Stanford returns as value is a well-hidden secret. There are certainly rumors about it being related to a right shift, but probably those came up just because of the irrelevant fact that this instruction is placed in between two right shifts. Don't get confused by this. It's just coincidence. Really. And of course it's also unrelated to the instructions SLI (shift left immediate (2) rA) and SRUI (shift right unsigned immediate (2)). It's tempting to think different, but it really doesn't mean anything.
Warning: Don't use this instruction unless you are absolutely sure the arguments don't contain security relevant or confidential data!
Re:A series of books like this for higher lvl codi (Score:3, Interesting)
That said, I feel it's a mistake. I have seen a large subset of C that was implementable via macros as a M68000 assembler language program. This would be a vehicle that would possess all of the virtues of MIX, while being readily understandable by most skilled programers. (They might not be able to compose in it without study, but they could understand algorithms written in it with reasonable ease.) In addition, the timings would be experimentally verifiable (if you could lay your hands on an old Mac
N.B.: If you don't insist on an actual hardware version of the machine, such as would be provided by the 68000, then I still don't see any advantage of MIX over a selected subset of C.
Additionally: MIX doesn't have much similarity to a recent-generation CPU chip. There are a multitude of reasons that Assembler has fallen out of fashion. Lack of portability was one of the major ones. But an even better reason has been the increasing complexity of the chips themselves. Hand-optimizing has become increasingly counter-productive for most people. (It's also become generally less necessary, but that's a separate argument.)
As always, however, there will be exceptions. There exist specialists who need this kind of skil, CPU version dependant though it be. Somebody needs to design the chips. Somebody needs to desigh the compiler optimization strategies. But even for these people, MIX will be a suboptimal choice.
Right on! (Score:4, Insightful)
They DO NOT UNDERSTAND the concept of finite resources, that machine cycles cost time.
I believe the first programming course should be a very few weeks of something akin to LOGO, or BASIC, just to get the concept of bugs and such out of the way, weed out those who can't stand thinking. Then a good grounding in a z80 or some other simple 8 bitter, where counting cycles and bytes is part of the course (learn how expensive those cute index registers really are). Only then, when an understanding of machine cycles and bytes has been established, should students move on to a higher level.
Too many ivory towers out there, too many straight-A-can't-tie-their-shoelaces types.
They will :-) (Score:2)
Much more recently, worked on some code from the 1990s, where someone had written some semi-cute memory allocate / free routines. You passed a size and the address of a free routine. It allocated 8 bytes extra, storing the free routine address and size there, but returned the address + 8 to skip the semi-hidden header. The main free routine called the saved routine address if not NULL, then freed the actual memory.
Some bozo had to compare two data structures. Instead of simply comparing various fields, he built up a string representation of each. About a dozen times for each, he determined how many extra bytes to add to the built up string, allocated that many more bytes, used strcat and sprintf to append the conversion representation, and finally used strcmp to tell if the strings differed! Then freed the two built up strings. Gaaak! Gave me the shudders every time I saw crap like that, but it was a legacy product, soon to be obsoleted.
Re:They will :-) (Score:2)
Yikes, 5-25MB of data, indexed and sorted with a few casual commands. (I'm allowed to do this, the performance/coding time tradeoff was well justified and I understand the inefficiency of my choices.)
A far cry from my days of programming ASM on the Apple 2 where I could often fit what I was writing into the two-hundred or so bytes at 0x300 and without using more than a few 4k buffers for data.
But when I pointed this out to a co-worker I didn't get the "yeah, times have changed" that I expected. He didn't even really understand how much that sort routine was costing, or the overhead of using a hash. Ugh. Children these days. (And I'm only 27!)
I completely agree with the OP that new programmers should have to learn some ASM. Not to design an entire app in it, but just to understand how the machine sees things and why some operations are more expensive than others. Too many people are blaming the hardware for being too slow these days when writing things I've seen done quickly in 4k on a 6502. Much like that strcmp instead of integer compare thing...
Re:A series of books like this for higher lvl codi (Score:2)
You remind me of a good point. Most of the people bitching about MIX are only bitching because they can't cut-and-paste the code into their favorite programs. Knuth does provide psuedocode, flowcharts, and the mathematical definitions of all the algorithms in the book! What more can you ask? The MIX code is just one more layer to ground the algorithms to real life.
If one doesn't understand MIX, then he should look at all the other resources avaialable for understanding the algorithm! If he can't understand the mathematics, then you still have the flowcharts and pseudocode. If he can't understand that, even when combined with the lengthy English discussion/explaination that goes along with it, then he shouldn't be reading the book!
use GCC (Score:5, Informative)
regards
john 'mips64' jones
Re:A series of books like this for higher lvl codi (Score:3, Informative)
Further, while MIX may well be showing its age, Knuth's newer MMIX assembly language is anything but outdated; its features should map well to new processors released for years.
Re:A series of books like this for higher lvl codi (Score:1)
At the very least these books represent the magnum opus of one of the pioneers of our field. I think they are worth reading for that reason alone.
However, my thoughts were similar to yours until I actually read AoCP. It's not so much learning algorithms as it is learning to think algorithmicly. I rarely get to code at the low level shown in AoCP. Even so, my SQL based reports in PHP and two-bit perl programs benefit from an algorithmic approach.
I am certain that I am better programmer for reading AoCP, and I never did any of the exercises. ;)
Re:A series of books like this for higher lvl codi (Score:2)
And most of the languages you mention will not be modern at the time when the last books comes out.
Most of the languages you mention hides so much of the underlying hardware that it is hard to see how changes in the software can be influences by the hardware.
On the other hand there is none stopping you from rewriteing the examples in Java if you feel up too it.
C is already an language on its way out, Python seams destined to forever be a minor language and if MS manage to kill Java - in 10 years time the book will be just another antique.
By using a made-up language the books will never become old and out-fashioned.
If you want to write a clsssic you can't fathom towards todays fashion but most go your own way.
Re:A series of books like this for higher lvl codi (Score:2)
Re:A series of books like this for higher lvl codi (Score:1)
Re:A series of books like this for higher lvl codi (Score:2)
But it's the "Algorithms for Busy Programmers" version that is more geared towards showing you a few choices of algorithms to use to solve your particular problem, instead of showing you algorithms and formal proofs like tAoCP does.
So I'd keep Sedgewick's book on my desk, but when I found something I wanted to really understand, I'd read more about it in Knuth's book.
I thought it was a good trait... (Score:4, Funny)
Necessity is the mother of invention, but laziness is the father.
Re:I thought it was a good trait... (Score:3, Insightful)
Being lazy means that instead of doing something "manually" we'll find some way to make the computer do it for us. Sure, doing it by hand may only take 5 minutes and we'll spend 15 minutes just trying to convince the computer to do it, but that's not the point. The point is that - 1) you just learned something new, 2) you avoided doing a repetitive task repeatedly (yes, yes, I know), 3) odds are you'll do the same damn thing, or something similar in the future, and then you'll know how to do it in 3 seconds.
Which is why programmers gravitate to complex but programmable tools, like vi/vim/emacs/ultraedit, to Unix, to scripting languages, etc.
It's also why we don't understand the user more often then not. Most users just want to get the job done. Sure, there may be a more efficient way to do it if you spend some time learning the system, but they either don't view the system as their job or have been burned by it too many times to trust it. So they do things the way they know, or the way they think it should work. Which is often not the way the lazy programmer thinks.
Laziness does have downsides though. Documentation tends to be banal. Comments are almost never as good as you'd like them to be 3 months later. And while algorithmic simplicity is a noble goal, it's often the wrong one - too simple of an algorithm can be wasteful of resources (bubble sort is a whole lot simpler than quicksort) simply because the programmer didn't learn the underlying hardware or didn't think through the implications of a design. Which leads to the issue of too simple of a design meaning massive rework as the system grows.
Of course the more experienced programmers have learned these things and discovered that spending the time up front means you can be lazier in the long run.
Knuth is one of these experienced programmers. There are gems of wisdom throughout his writings.
Wish the bastard didn't want us to work to find them though.
Re:I thought it was a good trait... (Score:1)
Re:I thought it was a good trait... (Score:1)
As my old maths teacher once said, "All good mathematicians are lazy but, unfortunately for you, not all lazy people are good mathematicians."
Proving his hypothesis (Score:2)
too lazy (Score:4, Funny)
No no no... He's right [yawns, stretches, checks for new
from his web page (Score:1, Funny)
Damn, and I thought I was a nerd!
Well, actually (Score:4, Funny)
Re:Well, actually (Score:3, Insightful)
Not quite. 256 *anything* equals $100. Several symbolic assemblers represent hexadecimals with a $ prefix. This has nothing to do with money. Claiming that the number is in fact a fixed point decimal representation is just semantics, not visible in the assembly code.
Just to make it completely clear.
For the ignorant... like me! (Score:4, Informative)
fascicle Pronunciation Key (fs-kl) n.
1. A small bundle.
2. One of the parts of a book published in separate sections. Also called fascicule.
3. Botany. A bundle or cluster of stems, flowers, or leaves.
4. See fasciculus.
I believe the definition used here is #2.
Second, a quick definition of what this is all about: it appears to be a collection of great scientific and programming works to be used as a primer for new programmers.
Hopefully, that allays some of the confusion I was having among others out there.
Re:For the ignorant... like me! (Score:2, Informative)
A collection of great programming works? Yes. To be used as a primer for new beginners? Not really.
TAOCP (The Art Of Computer Programming) is one of the best advanced computer science books ever written. It doesn't teach you how to write object-oriented code, or even "hello world". Instead it sets down algorithms, and techniques to create algorithms to solve problems elegently.
Giving this to a new programmer would be pretty much a worthless exercise, as the code in the book isn't even written in a real (as in used in the real world) language, but rather one made up in academia to be Turing Complete and demonstrate algorithms. I keep all three volumes on my desk, and find that they can be incredibly useful in assisting with some problems. However, they're never going to tell me why my program has a memory leak, or the difference between reference and value.
The previous volumes of TAOCP have had numberous errors (Knuth pays $2.56 for every one you find) just due to the complexity of the material they cover, combined with the changing world of computer science. Hopefylly getting out pre-prints of the book, bit by bit, will help get alot of these fixed before the 1st edition.
I have no idea how you were expecting to "allay" the confusion of others, when you don't even seem to understand it yourself.
Adam Pennington
Re:For the ignorant... like me! (Score:2, Informative)
The root word is the Latin "fasces" -- a bundle of sticks -- which was used as a symbol of authority in Ancient Rome, by people empowered to beat those acting illegally. This is where the notion of "fascism" comes from -- order through the strength of the dominant group.
I really should do more study of etymology, it can be fascinating...
Paying people to find bugs doesn't cost him (Score:2, Interesting)
Re:Paying people to find bugs doesn't cost him (Score:2, Interesting)
A far better interview can be found at Folio [www-x.nzz.ch] the magazine of the Neue Zuricher Zeitung which can also be translated by Google [google.com] into something like a beginners version of english.
Re:Paying people to find bugs doesn't cost him (Score:3, Funny)
guess it would be bad (Score:1)
"oh my god! my retirement money is gone!"
Could it be... (Score:2, Funny)
Re:Could it be... (Score:2, Troll)
Programming is a craft dependent on experience and routine. Sure, knowing your big-O might come in handy when you need to make a kick-ass algorithm; but this has probably already been done by somebody else.
Flashing your l33t CS skillz is going to get you nowhere when you don't know the Nintendo Graphics API (tm) and I do, and spend all my time making Zelda while you're still trying to implement the ultimate sort() and forget about structure and testing.
To quote a slashdot quote : "Fluid dynamics is to plumbing as science is to programming."
$2.56 worth. (Score:1, Flamebait)
This suggestion should be worth $0.32
It doubles (Score:2)
What about inflation Prof. Knuth!?
Knuth routinely doubles the bounty for finding an error in his TAoCP books or in his TeX program. This bounty doubles each time an error is found and corrected.
Knuth and the French Language (Score:2)
As an English example, at the end of Chapter 7 of The TeXbook, he quotes
Some bookes are to bee tasted,
others to bee swallowed,
and some few to bee chewed and disgested.
--FRANCIS BACON, Essayes (1597).
He will presumably not accept "corrections" to the spelling of "bee," "bookes," "disgested," or "Essayes," because they are spelled as Bacon did originally.
Most English speakers freely acknowlege that spelling and usage have changed in the last 400 years. Probably most French nit-pickers are less realistic, but that is a whole other topic.
This guy is hard core (Score:4, Funny)
The Art of Computer Programming, Volumes 1-3 [amazon.com]
From the Inside Flap
"The bible of all fundamental algorithms and the work that taught many of today's software developers most of what they know about computer programming."-- Byte, Sept 1995
"If you think you're a really good programmer,...read [Knuth's] Art of Computer Programming....You should definitely send me a resume if you can read the whole thing." -- Bill Gates
This does not sound like it is aimed at the core slashdot crowd, based on the Amazon reviews I am reading. Honestly I have never heard of the guy before. He is without a doubt more for the "hard core" among us. Volume 1 seems to have been written in the 1960's, so this guys been at it a while.
Plenty of reader reviews. Many with comments like:
This timeless classic is bound to make the student (Yes you ought to be a dedicated one..no casual reading here!) proficient in the art and science of constructing programs. -Ganapathy Subramaniam
Be prepared for your brain to do some crunching if you really want to get into this guys work.
-Pete
(amazon affilate like to the book...just so ya know.)
Re:This guy is hard core (Score:1)
Honestly I have never heard of the guy before.
Neither had the librarians at my local library. They were puzzled as to why I was so angry about the disappearance of the three yellow computer books. That was years ago and I still get somewhat mad about it.
Re:This guy is hard core (Score:5, Insightful)
Reading the Art of Computer Programing is like translating the Bible from the original greek. You know there is something profound there, but until you've done it a few times and looked back on it, you are more concerned with trying to figure out each word.
I'm a little awestruck by him.
By the way, the Paul reference is not a flippant one, check out his other books,Things a Computer Scientist Rarely Talks About [amazon.com], and 3: 16: Bible Texts Illuminated [amazon.com], for explanations of why not every christian is a fool.
Re:This guy is hard core (Score:2)
Re:This guy is hard core (Score:4, Interesting)
Devon
Re:This guy is hard core (Score:3, Interesting)
There are many others, but that's a good start.
Re:Marvin Minsky? (Score:2)
Re:This guy is hard core (Score:2)
Ever heard of context-free languages? yacc grammars? parsing [accu.org]?
Thought so.
TeX (Score:5, Interesting)
"Be careful with this code; I have only proven it correct, not tested it."
A demonstration of Hacker Nature:
He wasn't happy with the typesetting on his first book, and decided this should be done by computer, so he wrote a markup language for typesetting.
Of course, he wanted to do it right, so this took him... well... about a decade. And when he was done, he had written TeX. He was very pleased; his publishers thought this was odd, as the new typesetting looked worse than the old.
A few years later, high-resolution laser printers became available; TeX already suppported them, and lo and behold, the new version did look better.
TeX is a huge monster of a programming language/application. Knuth offered a cash prize of $(2^N) for the Nth unique bug report. TeX is now, like, 20 years old, and that system cost him under $1K.
If programmers were Jedi, he would be Yoda.
If programmers were wizards, he was be Gandalf.
He is the serious, friendly grandfather who can kick the butts of all us whippersnapers. So pay attention!
Re:TeX (Score:5, Interesting)
Take a look at the version number of TeX: 3.14159 ('tex --version'). Each release adds a new digit towards Pi and someday when he dies the release number will be bumped to be exactly Pi. After that every new bug will be declared a feature
Re:TeX (Score:5, Informative)
That would be METAFONT. It's a companion program to TeX, for making fonts.
Re:TeX (Score:2, Funny)
Why spend 10 days doing something when you can spend 10 years automating it?
(If you don't approve profoundly with the above sentence you don't belong to the software development profession.)
Re:TeX (Score:2)
He was very pleased; his publishers thought this was odd, as the new typesetting looked worse than the old.
I agree. I have always thought that TeX looks like shite. If yOU waNt YouR paPErS tO LOoK lIke THEy wEre WRitteN On a JAnGly OlD tYPewRiTEr THeN TeX MaY bE riGHt foR YOu!! Why do you think it is capitalized as "TeX"?
Re:TeX SuX (Score:3, Insightful)
What do you consider a good system now -- docbook? If so, remember that your docbook renderer uses TeX as its backend. If you consider (say) Word a good document preparation system, you have no room to speak on the subject.
TeX is an amazingly reliable, high-quality piece of software -- I doubt that anything on its scale has ever been created with as few bugs. Yes, the input syntax is a bit dated -- but in its day, it kicked ass. No doubt if Knuth were doing it today, it'd kick ass by modern standards as well.
Re:TeX SuX (Score:3, Interesting)
My particular take:
1) The Computer Modern fonts are not very pretty unless you have a very high resolution typesetter; even then, the letters look too thin and spidery for my taste. Sure, you can use other fonts. But most users never do, or use even uglier ones, usually sticking with Computer Modern for the formulas. Do any other really complete and compatible math fonts even exist?
2) The programming features were hacked on as an afterthought. The syntax is fine, perhaps even near optimal, for straight mark-up, but for developing actual algorithms, it makes Perl code look self-explanatory. Right up there with Intercal. This means that packages like LaTeX or formats are very hard to modify or extend in any kind of robust way. So everyone uses the default format, borrows one that works from somebody else, or works very hard to roll their own. Making even slight adjustments or fixes is a real nightmare.
3) The whole TeX program is terribly monolithic. Sure, the text description and commentary talks about various stages of TeX, but the code says otherwise. Knuth's optimization of the "inner loop" means there is no intermediate description of the TeX syntax.
The program itself was written in very low-level Pascal. The data structures are defined in terms of byte layouts, with explicit memory management. All sorts of tricky details insinuate through the code. Sure, it runs great even on 1980-era machines, but God help you if you want to re-implement it in a modern high-level language. As far as I know, this has only been done using web2c, which is a hack specially made to translate TeX. What's going to happen when C compilers are as rare as Pascal compilers are today?
4) Likewise for the file formats. Laid out with great care, byte-for-byte. Easy to read, but tough to translate into something higher-level.
My part-time project/dream is a modern re-implementation, where the TeX typesetting algorithms are embedded in a modern (Common Lisp) environment--so you can code TeX formats and macros in a heavy-duty honest-to-god programming language, and have an high-level, truly modular implementation using real data structures that could actually be tweaked and modified to do even funkier typesetting tasks.
Part of me says this will be easy, because something like 60% of TeX: The Program is doing stuff like memory management that Lisp will do for free, and accounting for funky character encodings (EBCDIC and 6-bit Pascal character sets) that probably can be ignored now that almost everyone is now in ASCII, or headed toward Unicode. The other part of me says this will be difficult for exactly the same reason.
Re:TeX SuX (Score:2)
Do any other really complete and compatible math fonts even exist?
Yes. MathTime and Lucida Math, to name the two most complete sets. A consortium of publishers has a third set in the works. And there are numerous math implementaions that exist but don't pass muster as "complete".
Making even slight adjustments or fixes is a real nightmare
Do you know about, e.g., ConTeXt?
As far as I know, this has only been done using web2c
Wrong again. Google Kasper Peeters for a complete recode of TeX in C or C++. And NTS, a Java TeX.
Laid out with great care, byte-for-byte.
Whatever, dude.
Re:TeX SuX (Score:2)
My concerns are more with the internals of TeX; namely, how can it be made easier for people to develop things like LaTeX or pdfTeX in a way that can be easily customized.
Like many people, my experience in TeX was writing my thesis in LaTeX. But when I wanted to adjust the format that I borrowed from a friend, either to cope with changed thesis format requirements, or to typeset a certain kind of program documentation, I found the process of understanding and modifying LaTeX macros to require true wizardry, without the rewards that wizardry brings in modern, powerful programming languages.
OK, so TeX has been recoded by a few people in a few languages. But from what I've seen, these people haven't really attacked the complexity and inflexibility of things like LaTeX's implementation macros. I.e., they maintain the same distinction between TeX internals and the TeX language.
Why is it that some people have to write packages like LaTeX, other people have to write enhanced versions of the TeX processor, and yet other people have to write DVI drivers, each using different languages? I find that the modularity of TeX is too coarse---format files, TeX processor, DVI processor, none of which really communicate with each other, or can be programmed together.
I think the possibility of doing typesetting in a programmatic way (like TeX) is very powerful, especially when coupled with aesthetically good algorithms (like TeX). But I want to have an implementation where the *programmability* is given higher priority, and the programmer is given access to the entire typesetting flow in a modern way.
My point about the DVI file formats is that it is really a machine language for a generic typesetter. It has lost much of the sense of the document. Sure, by liberal use of specials, you can include intelligence in your documents, but that requires you to have a new implementation of the TeX processor, and a new DVI processor, possibly integrated into the TeX processor. What if you could produce the same effect simply by changing or defining a new format file?
Re:TeX SuX (Score:2)
2) TeX is hardly Lisp-like. It's more like a macro assembler language. Its internal variables are a fixed number of registers, arranged in several banks, each of one "type," some of which have special behavior; its named variables are really only replacement strings (control sequences) or aliases to built-in registers; and its control structures are heinous.
For a truly Lisp-like language, I would want variables to be unlimited, support modern data structures, true parameter passing to user subroutines, for the state of the TeX process to support full introspection, be completely customizable (e.g. be able to write new paragraph and spacing routines as part of TeX modules), and for new control and data structures to be defineable.
3) What I mean is that there is no easily accessible representation for "parsed" TeX input. The processing into the internal representation is driven by a few different "modes" of the TeX engine (e.g. vertical mode, horizontal mode, math mode) which consume tokens and produce internal data structures. I would like for users to be able to redefine or add additional modes in add-on modules, rather than having to recode TeX's internals directly.
How do you change TeX's pagination or paragraph-building? Right now it is a total hack job. You have to generate the right tokens to create the right amount of glue and space to have the built-in routines do what you want, tweaking several internal variables along the way.
Here's an example of what I had a desire to do: I was trying to typeset a table where some of the table cells would have multiple text lines. I.e. if the text was long, instead of insisting on a super-wide column, I wanted TeX to break the text into several lines, making the table cell span a larger number of text lines. Then, the other columns with short text will float to the center of this "expanded row."
I don't think you can do that easily. I ended up doing the breaks by hand. Why is that necessary? Why can't I code a table where the vertical direction is as flexible as the horizontal direction, and call the line-breaking algorithm on individual cells? Ideally, I'd like to be able to *easily* code any kind of table-generating macros I want.
4) what I mean is that there is no built-in data structure representing a DVI file. The reason is that TeX was made to run without using much core memory, so only a page or so of output is held in internal form before being squeezed out of the toothpaste tube into the DVI bucket. Once it is out of the tube, the DVI toothpaste can't be sucked up again. I would like more flexibility in processing the final DVI results, without having to write a different dvi2blah driver that has to support everything that dvi2pdf or dvips already supports.
What I want in general is a system where the entire input-tokens to output-DVI is accessible to user programs written in a high-level language, using real high-level data structures, and where the TeX control sequences can be defined in the *same* language (so that I could code a LaTeX-type package in a programmer-friendly language like Lisp, if I wanted.) I basically want the whole Common Lisp language available to do my typesetting, while maintaining the excellent aspects of TeX, including the usually-convenient mark-up syntax.
Sorry if this is not quite clear, but it is, after all, just a vague dream-like urge. Programming in Common Lisp, for me, is pretty much painless. Programming TeX/LaTeX macros is like doing my own dental work. I get the same feeling that I get when I use a 1980's-era line editor (ED) vs. using Emacs. I want TeX to be a 21st century environment, instead of a 1980's environment.
Re:TeX SuX (Score:2)
Still, it looks like the TeX language and the implementation language (Java) are separate.
I would like a system where there are two syntaxes for the same language. One is the mark-up syntax, which would be the default syntax for writing your documents. Hopefully, compatible with or easily translated from existing TeX documents. This syntax is optimized for writing documents.
The other syntax would be oriented toward re-programming TeX. This would be optimized for describing custom layout algorithms or other processing of user input. Personally, I would want it to look like Lisp.
For simple substitution-type macros, you could use either syntax, like in TeX today with simple
\def\TeX{T\kern-.2em\lower.5ex\hbox{E}\kern-.06
when things are simple, or a more program-like form
(define-control-sequence TeX ()
#\T
(kern (lower #\E (* 0.5 ex)) (* -0.2 em))
(kern #\X (* -0.6 em)))
Then use (TeX) (or \TeX in the markup syntax) to typeset this definition. Sure, this looks more complicated--ideally, you would be able to do
(define-control-sequence TeX ()
"T\kern-.2em\lower.5ex\hbox{E}\kern-.06em X")
as well. But with the Lisp-like syntax, I know that I can use all the powerful Lisp macro and programming capabilities to do typesetting. (E.g. trig functions for typesetting at angles, TeX control sequences that take Lisp data structures as arguments) Wow!
When you look at TeX's definition for \settabs with all its \sett@b and \s@tt@b special names, or LaTeX definitions, I think being able to do things in Lisp would be a real win. And, if it really is Lisp, it won't be hard to write translators that slurp up currently existing formats (like LaTeX) and spew out the new Lispified version automatically, so I don't lose any of today's formatting abilities.
Re:This guy is hard core (Score:2, Funny)
Try going to englishlitereature.com and saying you've never heard of this Shakespeare guy, but based on Amazon reviews it sounds like he's pretty deep.
Troll=2, Insightful=1, Funny=2, Total=5 (Score:2)
Not sure if I should be proud or ashamed. Obviously the moderators aren't either. Honestly, I never even considered it would be modded as funny.
Watching the moderations of this post has been an interesting lesson in Slashdot psycology.
-Pete
Re:Troll=2, Insightful=1, Funny=2, Total=5 (Score:2)
-Pete
Knuth loosing the /. crowd? (Score:1)
Although, these challenges do sound a little dry, don't they?
- Claus
rats! (Score:5, Funny)
Don't have a postscript viewer? (Score:4, Informative)
Cached version of the Knuth document is here [samurajdata.se].
Re:Don't have a postscript viewer? (Score:3, Insightful)
Ghostscript is free as in speech, with a GNU release and a release under AFPL, a slightly different license (the GNU code is older than the AFPL code). GSview is available, as far as I can tell, under the AFPL only, which is still free but not GPL.
With both of these properly installed on Windows, one click on the link provided by Slashdot will launch the viewer. (It must gunzip on-the-fly.)
Finally (Score:3, Interesting)
I was a junior in college when I first read The Art of Computer Programming, and it really opened up my mind to what computer science is all about. It challenged me to think outside the HLL box. Knuth's work has become a timeless classic because he concentrates on the higher level concepts of computer science that transcend the currently popular architectures.
What really blew me away about Knuth's work is that he implements all of the features found in modern HLL's in his own variant of assembler. Someone who can work through and solve the exercises in his books will find themselves able to write programs in any language, and write them well at that. He does not concern himself with the Language Wars, or the Platform Wars, but instead presents the problems and solutions which are common to all computer systems. Too many programmers have been babied intellectually by their colleges and universities, which taught them how to program in a high level language rather than teaching them the fundamentals underlying computer science. Knuth does a good job in getting down to the underlying problems of computer science without bothering the user with the details of arcane architectures that will soon be obsolete.
For this reason, I look forward to his forthcoming work. I look forward to the new challenges which will expand my mind even farther.
ToastScript - Java .PS Reader and Printer (Score:2)
Industrial song titles (Score:2, Funny)
decoding the octacode
Gray binary clusters of subcubes
medians of bit strings
Gray fields
constructing large-gap codes
an infinite Gray path that fills n-dimensional space
loopless generation of fence-poset ideals
Privacy violation? (Score:2)
Yes, I know they are hypothetical...
Does anyone besides me... (Score:2)
As evidence of this, I point to Dick Feynman, who was incredibly smart, amassed a decent body of work, both in terms of theories created and teaching books/lessons written, but at the same time took time out to play in a native Brazillian band.
I might be a computer scientist, but I look up to Dick Feynman, and I shake my head at Donald Knuth.
Re:Does anyone besides me... (Score:3, Interesting)
I'm not sure what your point is about Feynman taking time out to play in a band - Knuth takes time out to play the organ if that makes a difference to you.
Given the contents of his books, don't you think that Knuth expresses a significant amount of respect for his readers? Name another author who gives cash rewards for reporting problems with books, or even for offering suggestions for improvements. You might think that this is ego driven since the majority of the checks aren't cashed, but this is a choice made by his audience and not by Knuth himself.
---
Not just played -- built! (Score:2)
While I have a lot of respect for Feynman, I don't believe he ever designed and built a pipe organ in his own home.
As for the pipe organ, somewhere there's a photo of Knuth sitting at home in front of it. It's not a small instrument. :-)
you don't program machines anymore (Score:2)
Re:you don't program machines anymore (Score:2, Informative)
Re:you don't program machines anymore (Score:2)
Assembly will always be valid. And even if you don't like MIX, then just ignore MIX. Knuth's books are filled with pseudocode, flowcharts, mathematical descriptions, and English descriptions of the algorithms. If you can't understand at least one of those views, then you don't deserve to be a programmer!
Re:you don't program machines anymore (Score:2)
Bob needs to write a Windows app, to, let's say, perform a certain mathematical function on a number when he types it in the box and presses the button. Bob must use Visual C++ for this. Bob then uses VC++ to write the program and design the forms. He puts a textbox on the form, and a button, and ties the click event of the button to a method that performs the math on the text property of the textbox. It then copies the result into a label component. The program has an event loop, managed by the OS interface, and an X button.
My point is that Bob does not care, nor does he NEED to care, what the opcodes are that did this. He wrote the program to make the button, textbox, and Windows do something. This is where 90% of the programming is done these days.
Even on Unix, most apps are nothing but firing off library calls to things you didn't write. You're at the mercy of the library implementors.
There are always exceptions, such as super-low-level simulation code, and other things that must run as fast as possible. THAT IS NOT WHAT I'M TALKING ABOUT.
Is that clear or is that too high-level for you, o mighty god of the shift right?
Knuth's Power (Score:2)
Generating all permutations (Score:2)
perl -e '@a=1..pop;sub a{@a?map@a=(a(@_,pop@a),@a),@a:print"@_\n";pop}a' 4
* I'm just counting the perl code, not the 'perl -e' and quotes for the shell.
hopefully he'll live to 120 (Score:2)
Of course then I'll have to update my review of The Art of Computer Programming [dannyreviews.com].
Danny.
Re:unfortunately... (Score:2)
As far as
Re:unfortunately... (Score:1)
Re: Ghostscript (Score:1)
That's the big problem with .ps.gz (Score:2)
In my opinion, every single person who posts anything on the web should never post something online in *.ps.gz format ever, ever again! *.ps.gz format used to be fine a long time ago, when researchers and academics exchange papers using UNIX boxes. *.ps.gz is terribly Windows unfriendly. More than that, it's Web-unfriendly. Nothing is a bigger turn off than encountering a interesting document/paper in the archaic
Even if somebody posts a Postscript file or gzipped Postscript file online, they could at the very least put up a PDF version too. If they can produce a Postscript file and gzip it, they definitely have the technical ability to produce a PDF file from Ghostscript's ps2pdf or Acrobat.
Now before you think I'm a Windows-only person, who have no clue about using Winzip or installing Ghostscript, let me assure you that I'm not. I use Linux all the time.. but I still prefer my files in PDF. There are a few occassions when I use Windows, such as when I'm at a friend's place or the like. And when I encounter a
Of course, the typical geek excuse (or advice depending on how you see it) would be to say "you can always install Winzip, Ghostscript and Ghostview, or some Postscript viewer browser plugin." Please. Users would want their files opened right away. No hassles, no messing around with weird programs, and no installing megabytes worth of stuff just to view a single file.
And even if PDF files are provided, there are many occassions when the PDF files have jagged fonts which don't display well on Acrobat Reader.. especially if they've been produced by LaTeX. There are ways to solve that, but that's a different story.
So paradesign, thanks once again for bringing this up.
Moderators, remember that moderation is not a measure of how much you agree with somebody's post.
Re:Old books still applicable? (Score:2)
Most of the irrelevent 2% involves tweeking algorithms to save memory so it might still be relevent if you are working on an embedded system.
Re:That's a shame... (Score:2)