Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!execu!sequoia!rpp386!woody From: woody@rpp386.cactus.org (Woodrow Baker) Newsgroups: comp.lang.postscript Subject: Re: Compiled PostScript Message-ID: <17601@rpp386.cactus.org> Date: 9 Jan 90 04:45:23 GMT References: <1666@intercon.com> <1690@intercon.com> Organization: River Parishes Programming, Plano, TX Lines: 66 In article <1690@intercon.com>, amanda@intercon.com (Amanda Walker) writes: > In article <17581@rpp386.cactus.org>,ntwoody@rpp386.cactus.org (Woodrow Baker) writes: > > Well, I look at it as a quite nice two-dimensional imaging language. It > 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. > Now, it is a lot like Lisp in being a ball of mud language (i.e., whatever > you add to a ball of mud, it's still a ball of mud), principally because I suppose that you would classify APL as a mud-ball language as well. Extensible langues (of which APL is not) could fall into that catagory. I'm sure the Lisp people are gonna love you. u > I challenge you to pinpoint *ANY* major deficiency of PS for > general purpose programming. > > - Named and lexically scoped local variables and parameters. These can > > - A more sophisticated model of memory management. A garbage-collecting > storage management subsystem would make it much easier to implement > > 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. > - A more sophisticated I/O model. Things like random access to file > contents become important for general purpose programming. The file > There is no reason that one *could* not, but there are many reasons why > one *would* not, not the least of which is that since you probably are > using a computer of some sort to give the printer commands, you may as > well use it for what it's good at. Why tie up your computer doing something that the printer is perfectly capable of doing. I agree the file handleing does lack a LOT, but it is not unusable. g > > Drawing labels and forms is quite appropriate for PostScript. Database > management, however possible in a theoretical sense, is not, given > the current set of primitives that are defined as "PostScript." > > The fact that many languages are Turing-equivalent does not mean that > they are equally suited for any given task :-). Imagine describing > pages in assembler, for example... I can, because I have done it. Everyone who has done any kind of screen graphics package has done it either in assemlber, or in 'C' or perhaps some other non-PS language. One of the first programs I ever wrote was a cassete label printing program in assembler. It did shadowprinting, bolding, underlining, etc, and used a 4800 baud JPC interface (it was a SWTP 6800 system with 4k of ram) for a cassette based file system. It does not perhaps sound like describing a page, but it essentialy was is some sense. It was neither pretty, nor easy, so I certainly. 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 think that "hacks" are just fine, if they accomplish their desired end. As long as they are well documented. Cheers Woody s