po 8. 6. 2020 v 10:48 odesílatel Philip Taylor <p.tay...@hellenic-institute.uk> napsal: > > > > Hallo again Benct — > > > Dijkstra was a great theoretician, and in principle it is of course > > right that the spec/documentation should dictate the behavior, but > > as we all know there is usually, for practical reasons, more or less > > distance between theory and practice, and in practice a piece of > > software does what the code tells it to do, no more no less. > > Personally I hate it when the spec/documentation describes some > > feature only to be told that it is "not (yet) implemented", yet > > partial or divergent implementations are quite common, and at the > > end of the day a partial implementation is usually better than no > > implementation at all. I am myself involved in a project which has > > several implementations for different languages and it is very hard > > to keep them all in synch, not least because the different > > implementations depend on different libraries which dictate how and > > if things can be done more or less easily. In practice one > > implementation is ahead of the other two while another is more or > > less stalled. No fun but a fact of life, especially in a volunteer > > project where time is limited. > > Dijkstra was indeed a /very/ great theoretician, and I think that the > IT world is a far poorer place not only for his passing but for the > passing of the generation of computer scientists that he epitomised. > Dijkstra, I think, saw computer programming purely as an intellectual > exercise, one that did not require access to a physical computer in > order to be practised — all one had to do was to write the program, > prove that it was correct, and one's task was done. These days > computer programming has become just a pragmatic exercise, which is > one reason why now we have such a plethora of programming languages, > libraries, implementations, etc., from which we are expected to make > an informed choice. And for those of my generation (I am now 73), > this is simply an impossible task. I have no idea what "react" > is/does, why no two Unices are the same, why (in general) open braces > no longer appear vertically above the brace that closes them, etc. > The world has moved on, and I have been left behind. But that does > not prevent me from yearning for "the good old days", when /enormous/ > thought went into the specification of a new programming language, and > when there was rigour where now there is chaos. But I digress (also > an artifact of old age). My point is simply that there /must/ be a > specification for something, otherwise that "something" is at best > unreliable and at worst completely useless. If I have a specification > for (say) colour \specials, and (e.g.,) xdvipdfmx (2021 release) does > not honour those specials in the same way that the 2020 release did, > then I have a definitive document which will allow me to determine > which (if either) is the correct/compliant behaviour, and which is the > incorrect/deviant. Without such a specification, then what works > today may not work tomorrow, and no-one will be able to say whether > this is evolutionary or retrograde. > I am probably a similar kind of man. I started to work with computers at a time when I had to leave a pack of punch cards and wait a few hours before the operators put it to the computer and gave me the printed results. I could have two runs per day, if I was lucky, I managed to have the program run three times a day. Under such situation I could not afford to write a program that does not work at the first attempt, even a misprint caused a loss of one day of work. Thus I learnt to write what the program is supposed to do and then make a program which worked. Nowadays everybody has a computer and I am afraid that the programmers just write some code and then look for bugs. I do not understand the significance of a debugger. Of course, I tried it but I never used it. My programs work and if occasionally something does not where, I know where to look for the reason without trying a debugger. I talked with a man from a computer company, he is slightly older than me. He told me that debugging is an expensive process. He must earn money by programming, therefore he had to learn how to write programs that work without the need of debugging. This means that I always have a description of a program but it does not mean that it can serve as a user manual. And it does not mean that I have it in a separate document. I can have it in the source code in comments written in a human language, usually in English, sometimes in Czech. And for this reason I like perl because POD can extract these comments into a user manual and it does not require additional work from me.
The request of supporting dvips specials in xdvipdfmx is not very fair. PDF is modelled after PostScript but not the same. PostScript is a linear language, PDF lacks programming structures but makes use of streams, even indirect streams and indirect objects. PostScript has one current colours, PDF has two current colours, one for fill, another for stroke. PostScript can directly set both the colour and the colour model by setgray, setrgbcolor, setcmykcolor or first change the model and then set the colour by setcolor the number of parameters of which depend on the current colour model, while PDF needs k and K for CMYK, rg and RG for RGB, g and G for greyscale. The colour stach is neither a feature of PostScript nor PDF, they are implemented in the driver. It is more difficult in PDF, it is more likely to destroy something, thus I understand that it is not implemented the same way as in dvips. Correspondence between PostScript and PDF is not 1:1 hence the drivers must convert the same TeX specials in a very different way to the target language. > > > > [snip] > > > > I doubt that any one implementation used in 2020 is from 1992, and > > each new implementation may bring with it new difficulties. > > Yes, it may. But if we have a specification (even one dated 1992), we > can definitively know and state whether each new implementation is > compliant or abberant. This must, surely, be a Good Thing [tm], must > it not ? > > ** Phil. Zdeněk Wagner http://ttsm.icpf.cas.cz/team/wagner.shtml http://icebearsoft.euweb.cz
