[pdftex] pdftex compression -- proposed addition to manual

[Greg Black]

Hans Hagen wrote:

| At 03:12 PM 8/25/2001 +1000, Greg Black wrote:
| 
| >More comments does not mean good comments.  And excess comments
| >usually indicate poor code; and far too often they get out of
| >synch with the code, at which point they become a hindrance.
| 
| It depends, in tex and mfont there are sections explaining the principles 
| behind breaking pars into lines, hyphenation, curve construction etc. Lit 
| prog at least makes sure that such background info ends up in the source 
| [with typeset formulas].

No, LP does not ensure anything of the kind -- disciplined
authors ensure the information ends up somewhere useful.  If the
information is best provided in typeset form, there's nothing to
stop them from writing a suitable TeX document to accompany
their code --- this is something I frequently do.  But it's not
something that just magically happens with LP.
 
| >He was writing unstructured programs.  Many people still feel
| >that this was a bad choice.  It certainly resulted in one of the
| >worst programming languages ever invented --- I love using TeX
| >and I have taught myself to program it, but I loathe it.
| 
| Hm. Think of the hard and software of those days. Imagine that you have to 
| wait a night to get the tex book run. I assume that there are some reasons 
| why some code is fuzzy [like those z@ things in plain or efficient but 
| unreadable macros in teh texbook source]; even the over one Meg dvi file 
| must have been a problem.

This is all true, but it is really beside the point.  When I was
writing software for the hardware that was available back then,
it was most often assembler --- but that did not stop me from
using good practices in my coding, nor did it prevent me from
documenting those things that needed to be documented.  Sure,
things ran slowly --- but they did not run significantly more
slowly because they were well written.

| >I couldn't care less if he calls my code illiterate --- it's
| >maintainable, it works, it doesn't have bugs.  Pejorative terms
| 
| hm, quite a claim. I wonder how in 25 years from now, programmers [if still 
| around and not bypased by machines] will rate todays code

At the present rate of progress, programmers will still be
pretty busy in 25 years.  I believe they will rate well-written
code from any era with high regard.  I frequently have cause to
read code that various good programmers wrote 25 years ago and I
have nothing but esteem for their efforts.  I don't see that
changing.

| btw, nts is tex, redesigned and in oo style, some 1000 classes, non literal 
| etc etc, but 50-100 times slower than tex, pretty memory consuming, done in 
| java [and therefore at least for a couple of years considered to be a 
| modern thing].

Well, this will probably irritate some of the devotees of some
hyped-up languages that have been foisted upon us by people who
really should be doing something else, but I would suggest that
anybody who used either Java or C++ to write software was making
a huge mistake.  All they offer is empty promises and sloth and
bloat.  Modern things are not necessarily good things.

| Think of this: you have a 2035 type computer, actually it's a distributed 
| thing, so hardly visible. It understands natural language and permits you 
| to express your ideas and helps you sort out your problems. So, sitting 
| there, you tell it a story: i want to make a document, bla bla bla, it 
| should look like this, bla bla bla, and the output should be pdf etc etc. 
| Since this computer has a coouple of downloads of typographers and maybe a 
| copy of knuth and thanh stored, it can solve your problem and after a while 
| this nicely typeset book shows up as a 3d virtual image.

This is science fiction, and history shows that science fiction
is frequently wide of the mark when it comes to predicting the
future.  Perhaps something like this will happen, perhaps not.
It's not relevant to discussions in 2001 about the usefulness of
LP as the mechanism to ensure that pdfTeX remains maintainable
in the future.

| So, as soon as we can really communicate with computers, literate 
| programming may blossom, but code will be gone.

Code won't be gone.  Fewer people will see it, even fewer will
understand it, and perhaps much of it will be machine-generated.