Oh man. I used PostScript a ton when I worked at hp 20 years ago. It's actually a pretty great language, like lisp/scheme but I found it to be more approachable somehow. Maybe because it's postfix instead of prefix?
Anyway, it had several fatal flaws. I don't think it could handle images natively, so instead it encoded them as vectors and those files took up MB. It probably just needed a metaphor like iframe.
I remember when Apple switched to the PDF engine in Quartz in preparation for OS X in the late 90s, I thought it was a mistake then. The QuickDraw it was replacing was actually quite good, in some ways the epitome of C-style rendering. And Cocoa was refreshing at first (it handled stuff like palettes and gamma in a data-driven way instead of through leaky abstractions) but without a way to transition off QuickDraw, it felt like more busywork that had to be done just to keep up.
Apple seems to have lost its academic roots, and suffers for it now. Or I should say, its customers suffer while it grosses almost half a trillion dollars per year. At least with vibe coding we can just whip up a Preview app in an afternoon, so maybe none of this matters anymore.
> Apple seems to have lost its academic roots, and suffers for it now. Or I should say, its customers suffer while it grosses almost half a trillion dollars per year. At least with vibe coding we can just whip up a Preview app in an afternoon, so maybe none of this matters anymore.
Eh, I'm with Apple on this one: we can just use Ghostscript. Apple's move effectively forces the few applications that need to use PostScript on macOS to migrate from a proprietary PostScript implementation to an OSS one, which strikes me as ultimately a good thing.
Yes, PostScript is a great general purpose high level programming language, kind of like a cross between Forth and Lisp, but a lot more like Lisp, with its polymorphic homoiconic data structures that were essentially JSON.
>PostScript is often compared to Forth, but what it lacks in relation
to Forth is a user-extensible compiler. You can write your own
PostScript control structures and whatnot, like case and cond, to
which you pass procedures as arguments on the stack, but the
PostScript scanner is not smart -- but there is no preprocessing done
to the PostScript text being read in, like the way immediate words in
Forth can take control and manipulate the contents of the dictionary
and stack while the text source is being read in and compiled, or like
the way Lisp macros work. This is one of the things I would like to
be able to do with something like LispScript.
>"Lisp is the language for people who want everything, and are willing to pay for it." -Russell Brand (the old school Lisp hacker "wuthel" from MIT, not the crazy MAGA rapist)
If you want to efficiently implement a PostScript interpreter with rendering in the web browser (or node), you just have to reach for the canvas 2d rendering context, which is essentially the full PostScript stencil/paint imaging model upgraded to the Porter/Duff compositing model with alpha channels, but without the user defined font rendering and halftoning machinery (which you could implement on top of it).
> .. with vibe coding we can just whip up a Preview app
why deflate your own position with this (worthless-untrue-spineless) statement? Which library is doing the work? who writes that library and maintains it?
Oh man. I used PostScript a ton when I worked at hp 20 years ago. It's actually a pretty great language, like lisp/scheme but I found it to be more approachable somehow. Maybe because it's postfix instead of prefix?
https://liucs.net/cs101s13/fixity.html
Anyway, it had several fatal flaws. I don't think it could handle images natively, so instead it encoded them as vectors and those files took up MB. It probably just needed a metaphor like iframe.
I remember when Apple switched to the PDF engine in Quartz in preparation for OS X in the late 90s, I thought it was a mistake then. The QuickDraw it was replacing was actually quite good, in some ways the epitome of C-style rendering. And Cocoa was refreshing at first (it handled stuff like palettes and gamma in a data-driven way instead of through leaky abstractions) but without a way to transition off QuickDraw, it felt like more busywork that had to be done just to keep up.
https://eclecticlight.co/2024/06/01/pdf-on-macs-the-rise-and...
Apple seems to have lost its academic roots, and suffers for it now. Or I should say, its customers suffer while it grosses almost half a trillion dollars per year. At least with vibe coding we can just whip up a Preview app in an afternoon, so maybe none of this matters anymore.
> Apple seems to have lost its academic roots, and suffers for it now. Or I should say, its customers suffer while it grosses almost half a trillion dollars per year. At least with vibe coding we can just whip up a Preview app in an afternoon, so maybe none of this matters anymore.
Eh, I'm with Apple on this one: we can just use Ghostscript. Apple's move effectively forces the few applications that need to use PostScript on macOS to migrate from a proprietary PostScript implementation to an OSS one, which strikes me as ultimately a good thing.
Yes, PostScript is a great general purpose high level programming language, kind of like a cross between Forth and Lisp, but a lot more like Lisp, with its polymorphic homoiconic data structures that were essentially JSON.
>You're welcome! OOPS (Object Oriented PostScript ;), I meant to say that PostScript and Lisp are homoiconic, but Forth is not. The PSIBER paper on medium goes into that (but doesn't mention the word homoiconic, just describes how PS data structures are PS code, so a data editor is a code editor too).
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989:
https://donhopkins.medium.com/the-story-of-sun-microsystems-...
PizzaTool Source Code (in object oriented NeWS PostScript using Owen Densmore's "class.ps"):
https://www.donhopkins.com/home/archive/NeWS/pizzatool.txt
NeScheme and Schlumberger's LispScript:
https://donhopkins.com/home/archive/NeWS/NeScheme.txt
>PostScript is often compared to Forth, but what it lacks in relation to Forth is a user-extensible compiler. You can write your own PostScript control structures and whatnot, like case and cond, to which you pass procedures as arguments on the stack, but the PostScript scanner is not smart -- but there is no preprocessing done to the PostScript text being read in, like the way immediate words in Forth can take control and manipulate the contents of the dictionary and stack while the text source is being read in and compiled, or like the way Lisp macros work. This is one of the things I would like to be able to do with something like LispScript.
>"Lisp is the language for people who want everything, and are willing to pay for it." -Russell Brand (the old school Lisp hacker "wuthel" from MIT, not the crazy MAGA rapist)
If you want to efficiently implement a PostScript interpreter with rendering in the web browser (or node), you just have to reach for the canvas 2d rendering context, which is essentially the full PostScript stencil/paint imaging model upgraded to the Porter/Duff compositing model with alpha channels, but without the user defined font rendering and halftoning machinery (which you could implement on top of it).
http://www.art.net/~hopkins/Don/art/cell.html ...]
> .. with vibe coding we can just whip up a Preview app
why deflate your own position with this (worthless-untrue-spineless) statement? Which library is doing the work? who writes that library and maintains it?
I don't know if it was done in an afternoon, but...
https://github.com/mist64/retro-ps
Author: Claude, directed by Michael Steil <mist64@mac.com>.
1 reply →