Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Donald Knuth Rips On Unit Tests and More

CmdrTaco posted more than 6 years ago | from the all-hail-knuth dept.

Programming 567

eldavojohn writes "You may be familiar with Donald Knuth from his famous Art of Computer Programming books but he's also the father of TeX and, arguably, one of the founders of open source. There's an interesting interview where he says a lot of stuff I wouldn't have predicted. One of the first surprises to me was that he didn't seem to be a huge proponent of unit tests. I use JUnit to test parts of my projects maybe 200 times a day but Knuth calls that kind of practice a 'waste of time' and claims 'nothing needs to be "mocked up."' He also states that methods to write software to take advantage of parallel programming hardware (like multi-core systems that we've discussed) are too difficult for him to tackle due to ever-changing hardware. He even goes so far as to vent about his unhappiness toward chipmakers for forcing us into the multicore realm. He pitches his idea of 'literate programming' which I must admit I've never heard of but find it intriguing. At the end, he even remarks on his adage that young people shouldn't do things just because they're trendy. Whether you love him or hate him, he sure has some interesting/flame-bait things to say."

cancel ×

567 comments

Sorry! There are no comments related to the filter you selected.

Literate programming... (3, Insightful)

Gordonjcp (186804) | more than 6 years ago | (#23207686)

... looks like it falls into the same trap as COBOL. The idea that by making programming languages incredibly verbose, they will somehow become easier to use is a fallacy.

Using "MULTIPLYBY" instead of "*" isn't going to make your code easier to read.

You misunderstand (4, Interesting)

Rix (54095) | more than 6 years ago | (#23207750)

Using "MULTIPLYBY" instead of "*" is asinine, because both are equally descriptive. Putting a comment above the line telling people why you're doing it isn't.

Re:Literate programming... (3, Insightful)

CastrTroy (595695) | more than 6 years ago | (#23207760)

I'm not sure if MultiplyBy is any better. It takes longer to type, and most people have understood that * (or X) meant multiply by since second grade. The thing I like about more verbose languages like VB.Net are that they force you to write out things that most good programmers would write out anyway as comments. At the end of a while loop, you write "End While". Most people using C++/Java/C# end up writing "} //end while" anyway, especially if the loop goes over 6 or 7 lines, and even more likely if there's a nesting construct like an if statement in there anyway. Seeing the "End While" let's you know what you are finishing off, without scrolling higher and trying to line up and see which bracket matches. Which even with visual brace matching, can sometimes be difficult.

Re:Literate programming... (4, Insightful)

Eunuchswear (210685) | more than 6 years ago | (#23207832)

Most people using C++/Java/C# end up writing "} //end while" anyway,
Pray god I never have to work on code written by these fictitious "most people".

I'd kill any colleague of mine who wrote such a vacuous comment. With a golf club, in front of its cow-orkers to drive the lesson home,

Re:Literate programming... (4, Insightful)

1729 (581437) | more than 6 years ago | (#23207856)

Most people using C++/Java/C# end up writing "} //end while" anyway,
Pray god I never have to work on code written by these fictitious "most people".

I'd kill any colleague of mine who wrote such a vacuous comment. With a golf club, in front of its cow-orkers to drive the lesson home,
I sometimes add comments like that if the brace is closing a deeply nested block, but then the comment indicates which particular loop or block is ending.

Re:Literate programming... (3, Interesting)

numbsafari (139135) | more than 6 years ago | (#23207990)

A better way to handle that is to turn the loop body into a function or group of functions. makes the code easier to read and a good compiler will inline the function so their's no performance loss.

Re:Literate programming... (1)

Monkeybaister (588525) | more than 6 years ago | (#23208138)

To say what numbsafari pointed out in a different way: If you're code is getting confusing enough to make it hard to know which block is getting closed, the solution is not labeling the closing of the blocks, but to encapsulate parts of your code into functions so the overall program flow is clear.

The only place where this could be appropriate is in C preprocessor statements or similar, but then you should be questioning if you're doing too much with them.

Re:Literate programming... (5, Insightful)

Swizec (978239) | more than 6 years ago | (#23207906)

I concur. Comments should tell WHY the while block is there and what it DOES. Not where it starts and where it ends, the code tells us that descriptively enough.

I've met code blocks several hundred lines long and it was never ambigious where they started and ended.

Re:Literate programming... (1, Funny)

Anonymous Coward | more than 6 years ago | (#23208010)

What's a cow-orker? A misspelled description of somebody who irritates cows?

Re:Literate programming... (0)

Anonymous Coward | more than 6 years ago | (#23208040)

Would you rather work on code that is a sea of brackets?

I think I would rather see comments like that to specify what a bracket does than deal with "MULTIPLYBY" "End while" etc. etc.

It depends on the case of where that close while bracket is whether it should be indicated as such, if it's in a sea of other close brackets it makes some sense, yes, you could collapse in a proper IDE and sort out which is which; but I think I would rather see at a glance where that bracket belongs before I go and start throwing code changes in-between random functions, loops, etc.

Re:Literate programming... (1)

MrSteveSD (801820) | more than 6 years ago | (#23208042)

Pray god I never have to work on code written by these fictitious "most people". I'd kill any colleague of mine who wrote such a vacuous comment. With a golf club, in front of its cow-orkers to drive the lesson home,


That sort of comment is often written by programmers who put far too much in one function. So much so that the top of the while loop is miles off the screen, so that they actually need the "//end while" to remind them what was going on. I've spent many an hour coming across such monster functions and refactoring them into digestible and reusable pieces.

Re:Literate programming... (1)

CastrTroy (595695) | more than 6 years ago | (#23208066)

Yeah, I'm not saying that it's the best thing to have huge loops that go on for pages, but at least when it happens, it's nice to have a little comment at the end to tell you what's going on. I really wish that every programmer I worked with could be an uber-elite programmer, and wouldn't create these 1000 line functions in the first place, but let's face it. Not all programmers are uber-elite, and many are only slightly better than not being there at all. Any construct of the language that forces them to be a little more explicit in what they are doing is a help to everyone.

Re:Literate programming... (2, Insightful)

davolfman (1245316) | more than 6 years ago | (#23207844)

I don't. It's pointless if you format your code decently. The bracket and the knockdown in tabbing should be enough. The only place I can see it being useful is when you have a truckload of nested brackets and even then you want something a lot more useful than "end while" it should at least name the stinking loop.

Re:Literate programming... (0)

Anonymous Coward | more than 6 years ago | (#23207870)

and the thing that I don't like about them is that they force you to write out things when they are not an absolute necessity for readability/maintenance, e.g. a loop with single statement. with C like syntax we have the choice and get rid of clutter when not needed.

Re:Literate programming... (0)

Anonymous Coward | more than 6 years ago | (#23208000)

I sort of understand the logic of using MultiplyBy. It is the same logic as using const T operator *(const T& arg1, const T& arg2) and A.operator *(int val) instead of *. It forces you to check type and not assume things.

E = (D = A * (B * C) * 5);

has a lot of things hidden. Are you passing by reference or value? Are you returning by reference or value? And how many times are constructors and copy constructors called? This statement could be rewritten:

E.operator =((D.operator =(operator *(A, (operator *(B, C)).operator *(5)))));

Awareness of this form is critical if you don't want to make a shitload of errors. And awareness of exactly how many times copy constructors and assignment operators are used is essential as well. The MultiplyBy or operator * forms reduce the need to explain the details hidden in the concise form and make it obvious when you need to pass by reference or by value.

Re:Literate programming... (1)

hedwards (940851) | more than 6 years ago | (#23207770)

That's not at all what he's referring to. It's the practice of using white space and proper comments to document the code in a clear way. Since nobody that's going to be reading code is going to need MULTIPLYBY for clarity over * that wouldn't be an appropriate choice. Further using the former rather than the later would cause further headaches by making the code more difficult to read.

As a general rule no matter where you are in the code no screen should be without at least a couple of codes, if you can scroll such that there aren't any comments on screen, you're probably doing something wrong.

The commenting, doesn't have to be terribly verbose, it's just enough to succinctly say what's going on, and variables, really ought to be commented at the top where they're defined for further clarity, when the variable name itself is insufficient. Variable and function names should of course also be a form of documentation, provided that it can be done adequately with a reasonable number of letters.

That's basically what he's getting at, and I can guarantee you that if you're writing code like that it's far more difficult for bugs to hide than in a terse obfuscated code base which is difficult for anybody to read.

Re:Literate programming... (0)

Anonymous Coward | more than 6 years ago | (#23208072)

"Literate Programming" simply refers to the same thing as "literate writing".
We're talking about an idea well expressed, and nothing more. It has nothing particular to do with how code is commented, or how whitespace is used (unless, as in the case of Lisp, whitespace is an integral part of the expression.)
When Knuth named a book "The Art of Computer Programming", he implied that there is an aesthetic in code. If something is ugly, it's wrong. Comments can't fix wrong. If something is elegant, it's right. Comments can't add much. If someone can't tell the difference, he shouldn't be a programmer.

Re:Literate programming... (4, Interesting)

1729 (581437) | more than 6 years ago | (#23207790)

... looks like it falls into the same trap as COBOL. The idea that by making programming languages incredibly verbose, they will somehow become easier to use is a fallacy.

Using "MULTIPLYBY" instead of "*" isn't going to make your code easier to read.
From what I've seen (particularly of CWEB), literate programming doesn't change the programming language itself, it just adds a TeX style markup to the comments so that detailed (and nicely typeset) documentation can be generated from the source code. Take a look at some of Knuth's CWEB code, such as his implementation of Adventure:

http://sunburn.stanford.edu/~knuth/programs/advent.w.gz [stanford.edu]

It appears to be ordinary C once the CWEB documentation is stripped out.

Re:Literate programming... (1, Insightful)

CastrTroy (595695) | more than 6 years ago | (#23207818)

So basically it's the same as the XML comments you can put in your .Net or Java code to create JavaDocs, or whatever they are called in .Net, based on the comments in the code?

Documentation is the source (5, Informative)

CustomDesigned (250089) | more than 6 years ago | (#23207864)

So basically it's the same as the XML comments you can put in your .Net or Java code to create JavaDocs, or whatever they are called in .Net, based on the comments in the code?
Not quite. In Javadoc (or the C/C++ equivalent) the C/Java code is the source, and documentation is generated from that. In literate programming, the documentation is the source, and it has code snippets, like you would see in a Knuth textbook.


The snippets have markup to indicate when some snippet needs to come textually before another to keep a compiler happy, but mostly this is figured out automatically. But in general, the resulting C code is in a different order than it appears in the source documentation. For instance, the core algorithm might come first, with all the declarations and other housekeeping at the end. (With documentation about why you're using this supporting library and not that, of course.)

Re:Documentation is the source (1)

Compholio (770966) | more than 6 years ago | (#23207896)

Hmmm, I must explore this - awk scripts to strip LaTeX from comments are not nearly so fancy.

Re:Literate programming... (1)

Goaway (82658) | more than 6 years ago | (#23207880)

No. It also allows re-ordering code for better readability.

Re:Literate programming... (5, Informative)

Basilius (184226) | more than 6 years ago | (#23207792)

That's not literate programming at all. A tad more research on your part is required. I actually remember when "web" in a computing context a literate programming tool rather than that thing you're surfing right now.

Literate Programming interleaves the documentation (written in TeX, naturally) and code into a single document. You then run that (Web) document through one of two processors (Tangle or Weave) to produce code or documentation respectively. The code is then compiled, and the documentation built with your TeX distribution. The documentation includes the nicely formatted source code within.

You can use literate programming in any language you want. I even wrote rules for Microsoft C 7.0's Programmer's Workbench to use it within the MSC environment.

I've frequently thought about going back. Javadoc and/or Sandcastle are poor alternatives.

Re:Literate programming... (1)

jinxidoru (743428) | more than 6 years ago | (#23207874)

Excuse my ignorance, but please explain how this this different (or superior) to doxygen or any of the many systems that do just this. I'm not meaning to be rude, I'm just asking.

Re:Literate programming... (2, Informative)

iMacGuy (199233) | more than 6 years ago | (#23207976)

In literate programming, the documentation is the default state and you have to escape it to write code. It's an important difference if you're going to write a lot of it.

Re:Literate programming... (2, Informative)

Sancho (17056) | more than 6 years ago | (#23208026)

From my brief look at doxygen, it looks like the biggest difference is semantic. Literate Programming with web is effectively documentation with code bits and metacode to indicate where the code bits should go. This means that the code bits can be (and should be) in the order that makes the most sense for the documentation. This is not necessarily the order that makes the most sense for the code.

Doxygen looks like it just extracts properly formatted comments in code in order to generate documentation. Web extracts properly formatted bits of code in order to generate a semantically correct C file.

Re:Literate programming... (2, Informative)

Coryoth (254751) | more than 6 years ago | (#23208034)

Excuse my ignorance, but please explain how this this different (or superior) to doxygen or any of the many systems that do just this. I'm not meaning to be rude, I'm just asking.
I think the prime difference is that literate programming allows you to re-order the code; that is, you include snippet of code within the documentation, and attach tage to the snippets that allow them to be reassembled in a different order. That doesn't sound like much, but it means that you can just write the documentation have code appear as i is relevenat to the documentation rather than having the program structure dictate things. Take a look at some [literateprograms.org] examples [literateprograms.org] (in various languages [literateprograms.org] ) to see what I mean. The key here is that documentation is (or should be) first and foremost in the writers mind, and it is the documentation that dictates presentation structure. This means that you are concentrating on writing the documentation, and will thus write it well, as opposed to concentrating on code, and adding documentation as an afterthought if you get around to it. Well, that's the principle at least.

Re:Literate programming... (2, Informative)

sholden (12227) | more than 6 years ago | (#23208038)

It predates it.

And the philosophy is different, literate program is essentially embedding the code in the documentation. Doxygen is more about embedding documentation in the code.

So doxygen gives you fancy comments and a way of generating documentation from them and from the code structure itself. CWEB lets you write the documentation and put the code in it deriving the code structure from the documentation, sample cweb program: http://www-cs-faculty.stanford.edu/~knuth/programs/prime-sieve.w [stanford.edu]

Literate programming is more suited for "dense" programs, which surprise, surprise is the type of stuff Knuth does.

Re:Literate programming... (1)

jared9900 (231352) | more than 6 years ago | (#23207794)

I think that you're misunderstanding the example provided, and literate programming as a result. Literate programming is a language agnostic technique of writing a program essentially as a paper or book, where the book provides a fairly complete description of the behavior of the code, algorithms used, expected input formats, etc. For instance, if you were to use this technique when writing a compiler you could detail the language you'll be compiling alongside the code that will handle that portion of the parsing/interpreting/translating. On his website (Knuth's programs page [stanford.edu] ) he presents a number of programs written using CWEB, C combined with TeX to generate both compilable C code and a fully documented program. He's also written books using this technique, specifically "TeX: The Program" and "METAFONT: The Program", both make use of Literate programming, and both programs are written in Pascal.

Re:Literate programming... (0)

Anonymous Coward | more than 6 years ago | (#23207806)

In my experience, software created with literate programming has turned out to be significantly better than software developed in more traditional ways. Yet ordinary software is usually okayâ"Iâ(TM)d give it a grade of C (or maybe C++),
I love this subtle dig on C++, that it's only ever marginally readable and not suitable for literate programming. Hah. Nice one, Knuth.

Re:Literate programming... (1)

Junta (36770) | more than 6 years ago | (#23207814)

I read a sample and I must confess that I think the sample was more confusing than most typical code. I'm talking about how multiply gives only one operand, and seems to be using an implicit default variable. Perl also can do this, and when I see people use it in complex situations, it's hard to tell when the last time default would have been set at times.

I do agree making the primitives verbose doesn't help. Ultimately, it isn't the fact that '*' is hard to understand, or that braces enclose blocks, the primitives used in conjunction with clear variable names is sufficient for that to be comprehensibe. You don't see (at least shouldn't):
$total = $subtotal * (1+$tax) # Mulitply the subtotal by 1 plus the sales tax

Because it's so simple. Comments come in to explain things in certain cases. The 'black box' description of the function with what it expects and what it will spit out, without talking about intermediate steps. And to explain potentially convoluted blocks.

Re:Literate programming... (1)

harlows_monkeys (106428) | more than 6 years ago | (#23208004)

That has nothing to do with literate programming. That Wikipedia article is very poorly written.

You can find an example of the old classic ADVENTURE game, ported to C, here [literateprogramming.com] , in the file adventure.zip.

Run that through the appropriate tools, and you end up with code to feed the compiler, and a listing to give humans. The listing for humans is here [literateprogramming.com] .

Re:Literate programming... (0)

Anonymous Coward | more than 6 years ago | (#23208006)

If that were what Knuth advocates it would be stupid.

Re:Literate programming... (1)

Cal Paterson (881180) | more than 6 years ago | (#23208090)

The idea that by making programming languages incredibly verbose, they will somehow become easier to use is a fallacy.
Assumptions, they make an ASS out of...etc

Umm, Not Quite... (1)

reallocate (142797) | more than 6 years ago | (#23208140)

It's been some time, but it seems to me the notion of literate programming is that anyone who knows the language can read the code and understand what's going on.

So, whether you use "*" or "MULTIPLYB" is no more a mark of literacy than if you say "Thank you" or "Merci".

Verbosity has nothing to do with it. Cobol code that is readable is better than C code that's not.

Re:Literate programming... (0)

Anonymous Coward | more than 6 years ago | (#23208150)

You are complety fucking clueless. Who are the morons modding this shit up?

Shocked (5, Interesting)

gowen (141411) | more than 6 years ago | (#23207690)

He pitches his idea of "literate programming" which I must admit I've never heard of
I'm shocked to discover that Knuth is taking an opportunity to push literate programming, given that he's been pushing literate programming at every opportunity for at least 25 years.

Now, I've no problem with literate programming, but given that even semi-literate practices like "write good comments" hasn't caught on in many places, I think Don is flogging a dead horse by suggesting that code should be entirely documentation driven.

Re:Shocked (5, Insightful)

Coryoth (254751) | more than 6 years ago | (#23207912)

Now, I've no problem with literate programming, but given that even semi-literate practices like "write good comments" hasn't caught on in many places, I think Don is flogging a dead horse by suggesting that code should be entirely documentation driven.
To be fair to Knuth, I don't think the failure to write good comments detracts from literate programming. What Knuth wants is an inversion of thr traditonal code/documentation relationship: you write the documentation and embed the code within that, as opposed to concentrating on code, and incidentally embedding documentation (as comments) within the code. Ultimately the failure of good comments and good documentation is because people are focussing on the code; as long as documentation and comments are an afterthought they will be forgotten or poorly written. If you switch things around and focus on the documentation and insert the code, comment-like, within that, then you're focussing on the documentation and it will be good.

The reason I think literate programming doesn't catch on has mostly to do with the fact that a great many programmers don't bother to think through what they want to do before they code it: they are doing precisely what Knuth mentions he does use unit testing for -- experimental feeling out of ideas. Because they don't start with a clear idea in their heads, of course they don't want to start by writing documentation: you can't document what you haven't thought through. This is the same reason why things like design by contract [wikipedia.org] don't catch on: to write contracts it helps to have a clear idea of what your functions and classes are doing (so you can write your pre-conditions, post-conditions and invariants) before you start hammering out code. The "think first" school of programming is very out of favour (probably mostly because it actually involves thinking).

Did anyone claim the bug prize on TeX? (1)

140Mandak262Jamuna (970587) | more than 6 years ago | (#23207692)

It is probably folklore. But the story during my grad school days was that, Knuth offered 1000$ prize to anyone fining a bug TeX and he doubled it a couple of times. And it was never claimed. If that was true, it is very unlikely he was just flame baiting.

Re:Did anyone claim the bug prize on TeX? (4, Informative)

paulbd (118132) | more than 6 years ago | (#23207748)

the prize was not US$1000. it started out very small. Knuth did indeed pay out, and indeed doubled it, several times. From wikipedia: "The award per bug started at $2.56 (one "hexadecimal dollar"[24]) and doubled every year until it was frozen at its current value of $327.68. This has not made Knuth poor, however, as there have been very few bugs claimed. In addition, people have been known to frame a check proving they found a bug in TeX instead of cashing it."

Re:Did anyone claim the bug prize on TeX? (0)

Anonymous Coward | more than 6 years ago | (#23207758)

http://en.wikipedia.org/wiki/Knuth_reward_check

Re:Did anyone claim the bug prize on TeX? (2, Interesting)

nuzak (959558) | more than 6 years ago | (#23207766)

> But the story during my grad school days was that, Knuth offered 1000$ prize to anyone fining a bug TeX and he doubled it a couple of times.

The $1000 bounty was from Dan Bernstein with respect to qmail. He's always found a reason to weasel out of ever paying.

Knuth started the bounty at $2.56 (one "hexidollar") and doubled it every year til it reached $327.68. Several people have claimed it, most people never cashed the checks. One of the first bug finders had his check framed.

Re:Did anyone claim the bug prize on TeX? (3, Interesting)

TheRaven64 (641858) | more than 6 years ago | (#23207772)

The original prize was $2.56 (i.e. 2^8Â), and he doubled it every time someone found a bug until it reached $327.68. Over 400 bugs have been fixed in TeX, and that's just counting the core VM and typesetting algorithms - all of the rest is in metaprogrammed packages, many of which contain numerous bugs. I'm fairly sure that most programmers could write bug-free code if the only place where bugs counted was in a simple VM with a few dozen instructions that interpreted all of the rest of the code...

Re:Did anyone claim the bug prize on TeX? (4, Interesting)

1729 (581437) | more than 6 years ago | (#23207822)

It is probably folklore. But the story during my grad school days was that, Knuth offered 1000$ prize to anyone fining a bug TeX and he doubled it a couple of times. And it was never claimed. If that was true, it is very unlikely he was just flame baiting.
He offers rewards for reporting errors is his books and for finding bugs in his code:

http://en.wikipedia.org/wiki/Knuth_reward_check [wikipedia.org]

Many people save these (usually small) checks as souvenirs. My father -- a frugal mathematician -- received a few $2.56 checks from Knuth, and he promptly cashed each one.

Reminds me of a Wired article (0, Troll)

AssCork (769414) | more than 6 years ago | (#23207696)

Go fuck yourself nerds.

Youth and trendiness (1)

CSMatt (1175471) | more than 6 years ago | (#23207710)

At the end, he even remarks on his adage that young people shouldn't do things just because they're trendy.
They shouldn't, but we all know that they do it anyway. Peer pressure has a big impact on the lives of "young people."

Re:Youth and trendiness (0, Offtopic)

Anonymous Coward | more than 6 years ago | (#23207734)

YOU KIDS GET OFF MY LAWN!

I saw "Donald Knuth Rips One" (1, Funny)

Anonymous Coward | more than 6 years ago | (#23207716)

I misread the headline. I was looking forward to a good Fart story from Donald "Structured Programming" Knuth. Oh well...

What? (5, Interesting)

TheRaven64 (641858) | more than 6 years ago | (#23207732)

You've heard of TeX, written in Web, the language designed for Literate Programming, but you've not heard of Literate Programming?

I have a lot of respect for Knuth as an algorithms guy, but anything he says about programming needs to be taken with a grain of salt. When he created the TeX language, he lost all credibility - designing a language in 1978 which makes structured programming almost impossible is just insane. TeX gets a lot of praise as being 'bug free,' but that's really only half true. The core of TeX is a virtual machine and a set of typesetting algorithms, both of which are very simple pieces of code (they'd have to be to run on a PDP-10). Most of the bits people actually use are then metaprogrammed on top of the virtual machine, and frequently contain bugs which are a colossal pain to track down because of the inherent flaws in the language (no scoping, for example).

If you want to learn about algorithms, listen to Donald Knuth and you will learn a great deal. If you want to learn about programming, listen to Edsger Dijkstra or Alan Kay.

Re:What? (5, Insightful)

gowen (141411) | more than 6 years ago | (#23207780)

Amen about TeX (and even LaTeX). I consider myself pretty knowledgeable about many computing languages, but every time I've hit a non-trivial problem with making TeX do what I want, I've had to consult with a TeXpert (i.e. the utterly invaluable comp.text.tex). And, sadly, in almost every case the solution has been either insanely baroque, or there's been no real solution at all. LaTeX makes brilliant looking documents, but Jesus wept, it's hard to make your documents look like YOU want, as opposed to how it thinks they should look.

Re:What? (0)

Anonymous Coward | more than 6 years ago | (#23207802)

I tried taking the TeX LaTeX plunge and decided it wasn't worth the time. Professional printers I use all accept PDFs happily.

Re:What? (1)

gowen (141411) | more than 6 years ago | (#23207846)

I've still found nothing better looking for mathematics, kerning, ligatures, or smarter for indexing and footnotes. But almost everything is easier to work with.

Maybe LyX and its like is the answer, but I haven't tried it for years.

Re:What? (0)

Anonymous Coward | more than 6 years ago | (#23208058)

LyX, if anything, is even less flexible. Just as others have said, TeX and friends are fantastic, elegant tools if your layout fits exactly into one of their templates. Otherwise, good luck.

Re:What? (0)

Jimmy_B (129296) | more than 6 years ago | (#23207798)

designing a language in 1978 which makes structured programming almost impossible is just insane
TeX is not a programming language, it's for typesetting. HTML doesn't support structured programming either, and nobody cares. If you need structured programming in TeX, you're doing it wrong.

Re:What? (1)

djmurdoch (306849) | more than 6 years ago | (#23207944)

TeX is not a programming language, it's for typesetting.
TeX is a programming language for typesetting. And the GP is right, it's a horrible design for a language.

Re:What? (1)

FranTaylor (164577) | more than 6 years ago | (#23207946)

You need a "real" computer language for typesetting, which is why they invented Postscript. If TeX had fulfilled its promise, Postscript would not have been necessary.

Re:What? (1, Interesting)

LizardKing (5245) | more than 6 years ago | (#23207996)

I think that the grandparent poster was referring to the dissecting and reordering of code that generally occurs with Literate Programming. Take the code from the book "A Retargetable C Compiler: Design and Implementation", which uses Literate Programming. The code is written as snippets and in an order that makes describing the purpose of the compiler easier, but the code itself loses its "integrity" (individual functions are split up and reordered) and is effectively unmaintainable in its source form - it needs to be preprocessed into a more logical order for the programmer to follow, but in doing so you're no longer editing the source in its Literate Programming form!

I know this will annoy those who believe he's some saint just because they've heard he is from anecdotes, but Knuth is somewhat irrelevant. An academic who has written no significant code (no, TeX doesn't count as it's just a simple interpreter), and who rails against the real world from his ivory tower. Even his books are a waste of time, with code written in an idealised assembly language that glosses over a number of practical considerations, they're dated, unbelievably boring and of no practical use compared to something like the "Numerical Recipes" or "Algorithms in ..." books.

Re:What? (5, Interesting)

cbart387 (1192883) | more than 6 years ago | (#23207932)

If you want to learn about algorithms, listen to Donald Knuth and you will learn a great deal. If you want to learn about programming, listen to Edsger Dijkstra or Alan Kay.
For those that didn't read the article, Knuth expressed criticism on several of the questions asked, but he didn't want to just duck the question. For instance, the 'trendy question' he said this.

With the caveat that thereâ(TM)s no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development

Re:What? (1)

cbart387 (1192883) | more than 6 years ago | (#23207938)

With the caveat that theres no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development
Sorry, hit submit instead of edit (why does preview turn into submit). Bah!

Programming for the human VM (4, Insightful)

TuringTest (533084) | more than 6 years ago | (#23207746)

Literate programming is an old friend for developers of functional programming languages. I see it like "code for the human mind": it provides a source code that is well adjusted to the needs of the developer, not just the machine.

It interleaves code and documentation in the same files, and provides a specialized compilator to tell the two kinds of codes apart. Just like Doxygen and Javadoc can extract the comments from a source code project, the "tangle" process can extract all the code from a Literate program and pass it to a clasic compiler.

Now that C and C++ seem to have a declining popularity [slashdot.org] , maybe we can look for better ways of getting away from the bare metal (which, don't forget it, is why those languages become popular at the beginning). Don't get me wrong, they served us well for 36 years, but I think it's time again to begin caring more for the developers' requirements and less for the hardware requirements.

Re:Programming for the human VM (0)

Anonymous Coward | more than 6 years ago | (#23207940)

if you start doing that you end up with vista :)

Adm. Hopper is ... (0)

Anonymous Coward | more than 6 years ago | (#23207762)

Dead. Sad. But Knuth is knocking on that door now, too. I pre-ordered IV about 5 years ago on Amazon. It's a race between it and Duke Nukem (3D was my fav game) For/n/ever.

Long Live COBOL !!

he's from another era (-1, Troll)

zrodney (253699) | more than 6 years ago | (#23207764)

skimmed the article -- he says unit tests and immediate compilation are bad because of all the cpu resources it would take to do something like that (!)

my dualcore laptop really has no problem with that.

debugging ALGOL on punch cards as he has done would be brutally painful, of course, but here we are in 2008 with no punch cards or ALGOL.

Re:he's from another era (1)

lekikui (1000144) | more than 6 years ago | (#23207934)

No he doesn't. He says they're unnecessary in most cases, and that he only uses them when he's ``feeling my way in a totally unknown environment''.  Otherwise he simply doesn't need to.

The ALGOL on punch cards story is quite separate.

Dismissive of DAK (3, Insightful)

symbolset (646467) | more than 6 years ago | (#23207982)

That's a brave stance. He's old, but he hasn't reached his dotage yet. The good doctor has contributed more to the science of information than most, and almost certainly more than you.

debugging ALGOL on punch cards as he has done would be brutally painful, of course, but here we are in 2008 with no punch cards or ALGOL.

One of the reasons why we're reinventing so much over and over with nuisances like VB and C# is that developers are architecting grand toolchains based on ideas that were in the 1960's proven incorrect. They get a lot profits from their workarounds, and then we burn it all down and start over because they all contain the same fatal flaws.

my dualcore laptop really has no problem with that.

That would be because you haven't installed Vista on it yet.

Having watched this tragedy unfold for a quarter century I've often shook my head and wondered what y'all were thinking. And then I remember that I once thought my parents were fools too. If you can read TAOCP and understand a good fraction of it you will come away with a firmer foundation for the way all things work. It's a tough slog, though, and not everybody is capable.

Re:he's from another era (2, Informative)

Not The Real Me (538784) | more than 6 years ago | (#23208184)

"...but here we are in 2008 with no punch cards..."

Yes and no. Yes, the physical punch cards are gone, but they live on in financial institutions in the form of Automated Clearing House (ACH) debits and credits which use the 96 column IBM punch card format. So, the next time you use your credit card, ATM card, e-check or pay a bill online through some company's web site, on the backend they are probably using ACH upload files (aka NACHA format) which was based on IBM's 96 column punch card to transfer financial data. Magnetic tape may be used on a contingency basis but it has to have an additional header record, be EBCDIC encoded and use 9 track tape. The IRS and many state tax agencies use ACH transfers, as an option, to refund personal income taxes instead of sending taxpayers a physical check.

Unit Tests are not wasteful (5, Insightful)

LargeWu (766266) | more than 6 years ago | (#23207774)

The reason for his dismissive attitude of unit tests - that he knows exactly how all of his code works, and what impact a change will have - is exactly the reason you need them. In the real world, most programmers do in fact have to share their code with others. You're not always going to know the ramifications of refactoring a particular block of code, even if you wrote it yourself. And if you can keep all of that in your head at once, either your program is trivial, or you are some sort of supergenius. Now while I think the TDD guys are a little bit overzealous sometimes with their "100% coverage or die" attitude, unit testing is still a good habit to get into, regardless of what Knuth thinks.

Re:Unit Tests are not wasteful (4, Insightful)

CodeBuster (516420) | more than 6 years ago | (#23207876)

Unit tests, especially if written and organized in an intelligent fashion, can be of tremendous value in eliminating small coding errors that were not inteded but are bound to creep in if the project is large enough. If you are clever about your tests then you can usually inherit the same test multiple times and get multiple uses out a test or part of a test. If unit tests are not used then it is more likely that several small errors in seemingly unrelated classes or methods can combine in an unforseen way to produce nasty and unexpected emergent behavior that is difficult to debug when the whole system is put together. Unit tests will not make up for crappy design, but they will help detect minor flaws in a good design that might otherwise have gone undected until final system integration where they could be much more difficult to debug.

I actually have a great deal of respect for Knuth, but I think that he is wrong about unit tests. Perhaps it is the difference between the academic computer scientist and the career programmer who admires the ivory tower, but is willing to make concessions in the name of expedience and getting work done on time.

Re:Unit Tests are not wasteful (3, Insightful)

ivan256 (17499) | more than 6 years ago | (#23208124)

I think that the arguments about unit tests often go too far in one direction or the other. People either treat unit tests as a religion, or they disavow them entirely.

People in the first group end up with a project full of tests where many are valid, many end up testing basic language functions, and many end up not helping due to oversimplication of behavior in the mocked interfaces.

People in the second group end up missing simple problems that could have been caught had they exercised their code.

Both groups waste a lot of time.

Perhaps this is what you were trying to say when you said "TDD guys are overzealous". I think there are other problems with TDD. Namely that you can only use it when you don't need to learn how to solve a problem as you go... Most interesting programs fall into that category.

Really, people need to use good testing judgement.

Re:Unit Tests are not wasteful (1, Insightful)

Jeff DeMaagd (2015) | more than 6 years ago | (#23207930)

I would agree. I was probably doing "unit tests" in programs before it was given a name. As far as I'm concerned, not doing them is a waste of time, I think I learned it the hard way, so I got in the habit of writing code to test code to make sure it was providing all the right results for several different circumstances. If I make changes, the test is re-run to be sure I didn't miss something.

I think it's possible that this person, despite his earlier genius, has ceased to be as useful as his previous self. Genius is very often like that, they make a good body of work at one point in their life, and their previous success seems to alter them to the point that later work is suspect or just wrong. Sometimes it's ego, other times it's just being stuck in a mental rut, or whatever other reason there may be.

and, arguably, one of the founders of open source? (2, Informative)

xx_chris (524347) | more than 6 years ago | (#23207840)

No, that isn't arguable.

Tex got started in 1977 after Unix (1974), well after SPICE (1973), and about even with BSD.

Re:and, arguably, one of the founders of open sour (1)

heffrey (229704) | more than 6 years ago | (#23207886)

Are you saying that TeX is the first thing that Knuth wrote?

Re:and, arguably, one of the founders of open sour (1)

mfnickster (182520) | more than 6 years ago | (#23208064)

Unix(TM) was never open source. The source was available under certain restrictions, but it failed on the "free distribution" requirement at the very least.

"Open source" and Stanford policy (2, Interesting)

Animats (122034) | more than 6 years ago | (#23208126)

There's a relevant quirk of Stanford University employee policy. For Stanford academic employees, software usually is considered "work for hire" and an "institutional work", with Stanford holding the copyright. But books and papers are considered to be the property of the author. [stanford.edu] (Policy on this changed in the late 1990s; there's a long history here, primarily involving the founding of Sun and Cisco.) However, Stanford permits the creator to place a work in the public domain, unless external funding prohibits this.

Knuth's code is open source. But his books are not.

His comment on unit tests (2, Interesting)

free space (13714) | more than 6 years ago | (#23207848)

...the idea of immediate compilation and "unit tests" appeals to me only rarely, when Iâ(TM)m feeling my way in a totally unknown environment and need feedback about what works and what doesnâ(TM)t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be "mocked up."


I'm not sure, but I think he's talking personally about his own work on his code. Remember that he comes from an era where people had the goal of mathematically proving that the code is indeed correct. He isn't necessarily doing this now but my persaonal guess is that he prefers statically checking the code to checking a running program. In certain kinds of mathematic/scientific applications this could make sense.

if i had a big brain like he does... (0)

Anonymous Coward | more than 6 years ago | (#23207894)

i wouldn't waste time on unit tests, either.

He's right (4, Insightful)

Brandybuck (704397) | more than 6 years ago | (#23207904)

He's right about unit tests... sort of. Just as most coders shouldn't be designing interfaces, most coders don't know how to test. It can often be more work writing the unit tests than writing the code.

If you have a function that multiplies two integers, most coders will write a test that multiplies two numbers. That's not good enough. You need to consider boundary conditions. For example, can you multiply MAX_INT by MAX_INT? MAX_INT by -MAX_INT? Etc. With real world functions you are going to have boundaries up the whazoo. In addition, if you have a function that takes data coming from the user, check for invalid cases even if another function is validating. Check for null or indeterminate values. Write tests that you expect to fail.

Re:He's right (3, Insightful)

Brandybuck (704397) | more than 6 years ago | (#23207918)

Conclusion: Knuth is somewhat right, in that most unit tests written by coders are useless. But unit tests themselves are not.

Re:He's right (4, Interesting)

clap_hands (320732) | more than 6 years ago | (#23208094)

The thing about unit testing is that it's subject to the law of diminishing returns. A simple test of the basic functionality gets you a lot for minimal effort. Writing dozens of carefully chosen tests to examine boundary conditions etc. gives you a little bit more, but for a great deal more effort. Whether or not it's worth it depends very much on the situation and the nature of the code you're writing.

Re:He's right (1)

sydneyfong (410107) | more than 6 years ago | (#23208104)

I also have this doubt about unit test: If the coder is already aware of the possible failures, then he should be fixing the code instead of writing a test.

And after a "unit" of code is written correctly, it shouldn't be changed a lot. Any big changes means a change in semantics, which means the original unit tests are useless anyway.

Re:He's right (1)

clap_hands (320732) | more than 6 years ago | (#23208186)

There's a whole school of thought that advocates refactoring as one of the primary activities in writing software. The purpose of unit tests is then to give you confidence that you haven't changed the semantics.

Re:He's right (0)

Anonymous Coward | more than 6 years ago | (#23208174)

In the hardware world, that's why there are verification engineers; people who do not write any RTL but are aware of the corner cases. What Knuth says has some relevance here. In hardware design, standalone block-level tests are used to eradicate the most obvious bugs. Also these tests are extremely fast. But the most difficult bugs in my experience have been discovered in tests that are more on the top-level module level or even at the full-chip level.

Re:He's right (1)

jordyhoyt (1013713) | more than 6 years ago | (#23208194)

It can often be more work writing the unit tests than writing the code.
Yeah, I think this underscores one of the main advantages of test-first coding. Once you've written all the tests, you have a really good idea how to go write the actual code and that process will be much quicker and easier.

To test code for literate programming compliance.. (1)

3seas (184403) | more than 6 years ago | (#23207914)

.... use a spell checker.

Ultimately literate programming is a matter of translation.
When you boil it all down to what the machine understands, it comes out binary.

To achieve the literate programming goal its clear there needs to be a programming language designed for it and a translator, be it a compiler or interpreter, that can take the results and convert it to machine understandable binary that runs as intended by the programmer/writer.

On multicore (2, Insightful)

cryptoluddite (658517) | more than 6 years ago | (#23207948)

Making a program parallel will always be too hard for most programmers. But that's exactly why you don't have normal programmers do it... have the libraries do it automatically. Functions like qsort(2) are already black boxes, so they can be made to always run in parallel when the input is large enough. Other functions like say Ruby's .collect can run in parallel. For things like .each there can be a parallel and a sequential version that the programmer can pick which is appropriate.

But to do this we need operating systems that can efficiently and reliably schedule code across cores. Add an ability to 'bind' threads together, so that they schedule always at the same time but on separate real processors. This gives the program the ability know when running an operation split between these threads will always complete faster than sequentially, without vagaries of scheduling possibly starving one thread and making it run much slower.

Once you have this then you can automatically get some speedups from multiple cores on programs that are designed to only run sequentially, and more speedup on programs with just minor tweaks. You aren't going to get perfect scaling this way, but you will get substantial improvements at virtually no cost to the programmer.

In other news, Chuck Norris rips on safety gear... (5, Insightful)

CaptKilljoy (687808) | more than 6 years ago | (#23207968)

The headline is misleading. Donald Knuth represents the epitome of the solitary super-programmer stereotype, so it's only natural that he sees no need for unit tests to catch mistakes or extreme programming to improve team development practices. I don't think he's necessarily saying that those things are without value for ordinary programmers.

A sample literate program (2, Interesting)

Lengyel (1082385) | more than 6 years ago | (#23207970)

I cannot resist including my own literate program [cuny.edu] . The original was written in reply to a programming test, posed by a prospective employer. During the interview I was told that the company contained their costs by keeping salaries low. In keeping with the spirit of literate programming, this story is recounted within the body of the program.

Literate programming might be more popular if it had support for interactive debugging, with the standard features common in contemporary interactive development environments.

erlang rocks with parallel cells! (0)

Anonymous Coward | more than 6 years ago | (#23208012)

erlang is the balm to ease you pain mr knuth.
Tri it youll like it.

-AC

I've only proven that it works... (3, Funny)

DirtySouthAfrican (984664) | more than 6 years ago | (#23208016)

"I've only proven that it works, I haven't tested it" - Knuth

The Summary Exaggerates the Interview (5, Informative)

Cal Paterson (881180) | more than 6 years ago | (#23208022)

Knuth said many of these supposedly outrageous things in passing, and does it while noting that he is an academic. Most of these claims in the summary vastly exaggerates the strength of the claims in the interview. Knuth specifically states;

there's no reason anybody should care about the opinions of a computer scientist/mathematician like me regarding software development.
Knuth doesn't claim that unit testing is a waste of time for everyone, just that it is a waste of time for him, in his circumstances. This makes sense, considering he follows his own (diametrically opposed) doctrine of "literate programming", which, if the summary author has never heard of, should cause him to be cautious about interpreting Knuth.

Mod parent up!! (1)

gwniobombux (941420) | more than 6 years ago | (#23208152)

The headline as well as the summary have quite a lot of spin in it. If you want to know what Knuth actually says, you should RTFA. Yes, I know this /., but you won't regret it, it's a good read. By the way, Knuth uses Ubuntu.

computer programming (1, Interesting)

nguy (1207026) | more than 6 years ago | (#23208028)

Knuth's view of programming seems to be that of clever tricks and fast algorithms. That may have been true when he got into the field, but it isn't anymore. Today, it's about creating big systems that need to be maintained by many programmers, not all of whom are as smart as Knuth. Algorithms come in libraries and are implemented by specialists. So, maybe Knuth doesn't need unit tests for his projects, but real-world projects do.

beg to differ (1)

mevets (322601) | more than 6 years ago | (#23208146)

It has always been about trying to avoid making big systems. Unit tests have many of the limitations of spell checking; they are know replacement four vigorous review.

those damn kids (2, Funny)

superwiz (655733) | more than 6 years ago | (#23208092)

and their unit test. in my days, if you needed a language, you wrote your own assembly. and when you couldn't document it, you wrote your own mark up language.... and your own fonts. phew... multiple cores. who needs them?!

Uhh ... who hates Knuth? (1)

khaladan (445) | more than 6 years ago | (#23208110)

It's pretty inane to end the post with "whether you love him or hate him". Who hates him? For what? Maybe you're confusing him with someone else. He's not a controversial figure in the CS world, and he's not part of the Free Software or Open Source punditry.

I hope he lives to 100+ so he can keep writing.

200 times a day? (1)

PipingSnail (1112161) | more than 6 years ago | (#23208116)

Well, if you are testing your code 200 times a day, you are almost certainly wasting time. Lets run some numbers:

Assuming you work an 8 hour day, that means you are testing your code every 2 minutes and 24 seconds. Given that most of your tests will take this long to run (you've got a suite of them right?), that leaves you with zero time to actually do the work you are testing.

Frankly, if you are using Unit Tests you should be using them after major chunks of work, not in a trial and error fashion. Now if you were using them in a trial and error fashion - "lets change this, run the tests and see if they pass, no that didn't work, lets try this", etc, I could understand how you hit the 200 times per day mark.

If you are coding in a trial and error fashion and using unit tests that way, I'd advise getting some tuition or changing career.

If you aren't doing a trial and error, then I'd suggest that you've perhaps exaggerated the 200 times figure.

I'm a highly productive individual, in terms of writing software and I'd guess I'd have cause of getting out the unit tests a few times a day down to maybe once every few days. The rest of the time I'm actually implementing the design thats in my head/on paper etc.

I believe in incremental development, but that doesn't mean blowing huge wads of time needlessly running unit tests. Which means, by implication, the unit tests ARE NOT part of the build process. They are something I run at times of my choosing when I think the work I'm doing is at a point that may benefit from such tests.

Making the unit tests part of the build process is like requiring a roadworthiness test for you car every one mile you drive it. Sure the car is safe, but its not very productive at getting you from A to B, you could walk faster.

What counts is that when you run the unit tests, they pass, and that they accurately test the conditions that need testing.

erlang rocks for multi-cell (0)

Anonymous Coward | more than 6 years ago | (#23208120)

erlang is the balm for your multicell blues.
tri it youll like it.

erlang rocks for multicell programming (0)

Anonymous Coward | more than 6 years ago | (#23208156)

try it youll like it
erlang is the balm for your multicell pain, mr Knuth

Knuth is hardcore (2, Insightful)

Sits (117492) | more than 6 years ago | (#23208166)

FVWM on Ubuntu Linux. Emacs with special modes using a homemade bitmap font. Mac OSX for Illustrator and Photoshop...

Now that's breadth AND depth.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>