TeX -at my opinion- in his mind is intended to be untouched after is death as a legacy to all software devs that will claim:
- you can do software bug free;
- you can do software that stand the test of time;
- you can do software that you can measure to be correct in regard to the problem it addresses. (Here: everlasting document typesetting).
It is the only source format/code I have from the 1996 that still compile and gives exactly the same output.
And we all claim that softwares always have bugs, and must evolve. Sometimes I think we are just justifying our own lack of dedication and hard work for a perfect design that is stable and does the whole job correctly since beginning.
This software is the one that makes me realize I am fraud and every time I print something with LaTeX I wonder how broken «progress» is when all the bloatware we have fail in so many aspects where TeX succeeds.
I think that many good developers today, given 10 years of receiving grants, and an unchanging problem set could write high-quality, very stable, very solid code, especially with a large community providing bug reports.
To be clear, I celebrate Knuth's achievement, but I don't view it as a commentary on how software is written today.
To give one example where TeX hasn't evolved, and which I think is a wrong decision rather than "perfect design": its Unicode handling is atrocious. Of course, this is because Unicode didn't exist when TeX was designed. But now it does. In fact it not only exists, but is the default text encoding on most contemporary machines. My locale is set to en_US.UTF-8, for example, and I'd therefore expect my toolchain, from grep through TeX, to be able to handle UTF-8 text. But TeX chokes on it.
(Fortunately, the developers of pdfTeX aren't as averse to adding new features as Knuth is, so I've switched to that.)
This is actually a fantastic illustration of the gap between academic and industry concepts of computing.
Also, isn't TeX limited to the .tex -> .dvi transformation? I'm not sure the transformation from .dvi to .ps/.pdf is even part of TeX proper. And that's where the bitmapped fonts come in.
In summary, all of this may just be a fantastic illustration of the gap between Don Knuth and you.
OT, but things can also gradually turn from features into bugs, or --what the parent probably meant-- liabilities.
Not having an presice date for when something stopped being a useful feature does not prove it still is.
I was about to say: "Good question. At one point everyone who had access to a computer was a programmer, as using an OS required programming skills. As that slowly phased away, considering issues which lead users into bad paths, documentation errors, and usability issues as bugs became more common."
Then I saw:
> "Do you imagine it magically became a bug on a particular date?"
> In summary, all of this may just be a fantastic illustration of the gap between Don Knuth and you.
Snark is unwelcome here. See http://ycombinator.com/newsguidelines.html
But I thought that your first statement was questionable, and that therefore your second statement was rather facile.
> Knuth's definition of 'bug' is a limited one, that seems to be mainly about logic errors. Allowing a user to incorporate bitmap fonts in a document (which very few users actually wish to do in 2014) would be considered a bug in other typesetting software.
Certainly, people sometimes use "bug" loosely, but it seems to me there is a strict sense in which a "bug" means something that was not intended by the writer of the code. And the issue you describe clearly does not fit this description.
I would call what you describe a "design flaw", at best. But as I alluded to, it wasn't even a design flaw at the time it was introduced. So it's really more of an anachronism than anything else.
And again, it's not really clear that it's even an anachronism in TeX, since it's more of an issue with the DVI-to-PS (or DVI-to-PDF) transformation.
And then you went on to conclude, from this highly questionable chain of reasoning, that this "bug" is "a fantastic illustration of the gap between academic and industry concepts of computing". Which I just find galling. Here you're talking about one of the most celebrated computer scientists of all time, someone who is almost certainly a lot smarter than you (or I), and you chalk up a difference between what you and he call a bug to the difference between industry and academia. As if Knuth is just some kind of ivory-tower crackpot who wouldn't understand the real-world exigencies of industry.
So: I think your definition of "bug" is highly questionable, and I think that in the future, when you find yourself in disagreement with some celebrated academic computer scientist, you should perhaps linger a bit longer on the possibility that you might be mistaken, rather than chalking it all up to the difference between industry and academia.
You can't handle UTF 8, the default $LANG for almost every OS it is installed on? That's a bug. It needs to be fixed.
Your output quality is poor because it uses a custom font system that pushes users towards non-scalable fonts? That's a bug. It needs to be fixed.
Something not being a flaw at a time a piece of software was introduced is also irrelevant. Unmaintained software is generally considered to be poor software. While bitmap fonts were acceptable until the mid nineties, they really aren't now.
If you still think it's just me that holds these opinions, let's test it: try and argue for the 'strict' definition of bug outside academia and see how far you get.
I didn't criticise Knuth at all. I was fairly careful not to do that, and the original moderation on the comment (+3) reflected that. I merely note that academia simply works differently from industry.
I'm aware of Knuth and his contributions. I'm sure he's a lot better at computer science than I am. That doesn't mean he can't be questioned, and you finding it 'galling' seems very much to be a case of hero worship.
"I assumed that most of HN knew that", huh? This is the same kind of tendentious nonsense as "this is a fantastic illustration of the different between industry and academia".
Not only do I _not_ know that "the non-'strict' sense of bug is the one used by almost everyone in our industry", I don't think you know it either, because I think you're mistaken. (Maybe you're in a different industry than I am.) The people I deal with (in industry) regularly make distinctions between bugs, design flaws, and possible feature enhancements. And so do most issue trackers (e.g. GitHub, JIRA), for pete's sake. So I really don't think your use of "bug" as a catchall term for all of these things is universal at all, in industry or out of it.