Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!intercon!news From: amanda@mermaid.intercon.com (Amanda Walker) Newsgroups: comp.lang.postscript Subject: Re: Compiled PostScript Message-ID: <1698@intercon.com> Date: 9 Jan 90 17:36:54 GMT References: <1666@intercon.com> <1690@intercon.com> <17601@rpp386.cactus.org> Sender: news@intercon.com Reply-To: amanda@mermaid.intercon.com (Amanda Walker) Lines: 85 In article <17601@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker) writes in response to my article <1690@intercon.com>: > > [PostScript] > > does an extremely good job of making the physical characteristics of the > > imaging medium irrelevant to the task of describing the image itself. > > true enough. some times to irrelevant. NO!! [there, now I feel better :-)]. This device independence is one of the biggest strength of PostScript. If you absolutely need to "get around" one of the principal design features of PostScript, then maybe you should be using another kind of printer. > I suppose that you would classify APL as a mud-ball language as well. No, not particularly. Change anything, and it's not APL any more... More like a "diamond" language. The main characteristic of a ball-of-mud languages is that they are syntax-poor and semantics-rich (relatively speaking). > I'm sure the Lisp people are gonna love you. Hey, I *am* a Lisp people :-). I take that as a compliment. > > The 'right' way to write something in PostScript that used > > a database would be to add primitives to the interpreter I was using to > > do the low-level memory and file management. > > That is another oversight in the design of the language. To paraphrase Monty Python, "The *language* don't enter into it." My approach would probably be to recompile the interpreter, since I wouldn't be running my DBMS on my printer :-). These extensions would be outside the PostScript language per se just as much as the color separation conventions or NeWS's event handling are. > Why tie up your computer doing something that the printer is perfectly > capable of doing. Why tie up your printer doing something that the computer is perectly capable of doing? I don't know about you, but my computers are useful for more things than being PostScript terminals... > I agree the file handleing does lack a LOT, but it is > not unusable. You did ask for deficiencies, dear, not things that were completely unusable :-). We've already established than you *can* write damn near anything in PostScript if you really want to... You'd probably have a lot of fun with NeWS, for example. > > Imagine describing > > pages in assembler, for example... > > I can, because I have done it. So have I, but I tend not to do it these days, because there are better tools for the job available. > You have definitly hit the problem areas of postscript. These are > definitly deficiencies, but with the exception of the I/O primatives, > can be gotten around. I won't argue with that. > I think that "hacks" are just fine, if they accomplish > their desired end. As long as they are well documented. Sigh. Woody, if they were documented, they'd be features, not hacks :-). Complaining that what Adobe documents as "PostScript" isn't enough for what you want to do (or how you think is the best way to do it) is silly. It's like buying a Corvette and complaining that it doesn't have enough leg room in the back seat. However true it may be, it's more of a problem with how you are trying to use it as with the manufacturer's design. Maybe we should agree to disagree. I agree with whoever said that this kind of fla... er, discussion is more approriate to comp.laser-printers than comp.lang.postscript. Getting a little tired of this, Amanda Walker Speaker to PostScript InterCon Systems Corporation --