PostScript Control Structures (2003)(nedbatchelder.com)
nedbatchelder.com
PostScript Control Structures (2003)
https://nedbatchelder.com/blog/200312/postscript_control_structures.html
3 comments
An alternate universe where Berners-Lee built his hypertext viewer in NeWS:
Eventually, as more people got hypertext browsers, many desktop applications began to be distributed instead as client-side interactive PostScript documents, eschewing the NeWS network protocol altogether in favor of PSON, a text-based protocol which had the advantage of working correctly through corporate firewalls.
Someone developed a server-side runtime engine called Node.ps, and many people jumped on the bandwagon, claiming that it made sharing code between the client and server much easier. As PostScript development became more complex, preprocessor tools began proliferating, including a strongly-typed version of PostScript, known as TypeScript, which had a sophisticated type system that could handle the often-tortured function signatures of library authors.
Due to PostScript's lack of a good standard library, a company named "PPM" started a package repository, which was soon filled with tiny libraries for each PostScript procedure. This eventually lead to the “string-length debacle” when an upset developer unpublished a five-line package...
Eventually, as more people got hypertext browsers, many desktop applications began to be distributed instead as client-side interactive PostScript documents, eschewing the NeWS network protocol altogether in favor of PSON, a text-based protocol which had the advantage of working correctly through corporate firewalls.
Someone developed a server-side runtime engine called Node.ps, and many people jumped on the bandwagon, claiming that it made sharing code between the client and server much easier. As PostScript development became more complex, preprocessor tools began proliferating, including a strongly-typed version of PostScript, known as TypeScript, which had a sophisticated type system that could handle the often-tortured function signatures of library authors.
Due to PostScript's lack of a good standard library, a company named "PPM" started a package repository, which was soon filled with tiny libraries for each PostScript procedure. This eventually lead to the “string-length debacle” when an upset developer unpublished a five-line package...
> including a strongly-typed version of PostScript, known as TypeScript
you have made my day :)
I'm very curious about the form and content of the "PSON", which could actually contain a program that would output PostScript. But I like this universe where all the time I spent on PostScript hacking would be useful now.
you have made my day :)
I'm very curious about the form and content of the "PSON", which could actually contain a program that would output PostScript. But I like this universe where all the time I spent on PostScript hacking would be useful now.
I’m imagining PSON as the alt-universe equivalent of JSON, where it uses a reduced version of the syntax that can only represent data, not execute instructions. So you’d get /symbols, (strings), << /Key (value) >> dicts, [ (arrays) (of) (items) ], numbers, and booleans, but no { procedures }, % comments, or operators.
Just for fun, here's MDN's JSON example turned to PSON:
Just for fun, here's MDN's JSON example turned to PSON:
[
<<
/name (Molecule Man)
/age 29
/powers [ (Radiation resistance) (Turning tiny) ]
/inAlliance false
>>
<<
/name (Madame Uppercut)
/age 39
/powers [ (Million tonne punch) (Superhuman reflexes) ]
/inAlliance true
>>
]PSON as you're describing it is basically PDF, with a couple of differences:
1. PDF has an "object table" so that you can refer to objects by number, permitting random access to the object graph, instead of requiring the whole file to be parsed from end to end.
2. PDF does permit comments, because not permitting comments would be a stupid idea.
3. PDF page contents are not represented as just a PSON object, but rather as a sequence of drawing operations.
By way of example, here's object 1750 from a random PDF file, which you can read in exactly the same way as your example above (so 37/T is two tokens: the integer 37 followed by the symbol T):
1. PDF has an "object table" so that you can refer to objects by number, permitting random access to the object graph, instead of requiring the whole file to be parsed from end to end.
2. PDF does permit comments, because not permitting comments would be a stupid idea.
3. PDF page contents are not represented as just a PSON object, but rather as a sequence of drawing operations.
By way of example, here's object 1750 from a random PDF file, which you can read in exactly the same way as your example above (so 37/T is two tokens: the integer 37 followed by the symbol T):
1750 0 obj
<</Linearized 1/L 791096/O 1752/E 12322/N 37/T 790286/H [ 483 540]>>
endobj
0.001 Tc -0.005 Tw -10.747 -1.02 Td
[(I)2(n)2(vest)1(men)2(t)1( )1(Co)2(n)2(f)1(eren)2(ce)]TJ
Right; PDF is just a static record of whatever got generated by executing a PostScript program. So it doesn't try to represent anything about the PostScript program itself, which is why I was idly curious about PSON as a container for programs.
With PostScript being one of the few successful "mobile code" systems out there, I wonder if PSON will do better than JSON by allowing { procedures }.
With the explicit dictionary stack, couldn't that be used to sandbox the scope and reach of these procedures?
With the explicit dictionary stack, couldn't that be used to sandbox the scope and reach of these procedures?
I'd rather see DPS than the current hodgepodge of technologies, but that's part of having given up on the whole original concept and accepting that we're deep into the mire of the web as an application delivery system. For such a thing, sure, DPS would've been great, and we'd have gotten applications and Flash from the very beginning.
Marrying that to a hypertext-document-system is another deal entirely. We're moving away from that, too, but at least there's enough of the corpose visible to contain the raging beast of SPAs and animations.
But, well, "based" leaves some room, and maybe something between HyperCard and DPS would've been the best of both worlds.
Marrying that to a hypertext-document-system is another deal entirely. We're moving away from that, too, but at least there's enough of the corpose visible to contain the raging beast of SPAs and animations.
But, well, "based" leaves some room, and maybe something between HyperCard and DPS would've been the best of both worlds.
"HyperCard and DPS"
There was HyperNeWS - which was a HyperCard like environment written in Sun's NeWS PostScript based graphics environment.
I worked with HyperNeWS in the early 1990s and it was brilliant - I don't think NeWS had much of a security model (could well be wrong about this).
Edit: Because of the alleged difficulties of writing PostScript the HyperNeWS team created a C to PostScript compiler in PostScript:
https://news.ycombinator.com/item?id=12668668
There was HyperNeWS - which was a HyperCard like environment written in Sun's NeWS PostScript based graphics environment.
I worked with HyperNeWS in the early 1990s and it was brilliant - I don't think NeWS had much of a security model (could well be wrong about this).
Edit: Because of the alleged difficulties of writing PostScript the HyperNeWS team created a C to PostScript compiler in PostScript:
https://news.ycombinator.com/item?id=12668668
Thanks, I knew there was something like that already, but it's hard to keep all the Don Hopkins posts memorized ;)
(Speaking of whom: http://www.art.net/~hopkins/Don/hyperlook/index.html )
(Speaking of whom: http://www.art.net/~hopkins/Don/hyperlook/index.html )
HyperDraw was great:
http://www.art.net/~hopkins/Don/hyperlook/HyperDraw.gif
One thing that was particularly neat was that you draw a shape (any shape) and paste it as the shape of a window.
http://www.art.net/~hopkins/Don/hyperlook/HyperDraw.gif
One thing that was particularly neat was that you draw a shape (any shape) and paste it as the shape of a window.
HN considered "What Was Wrong with Display PostScript and NeWS?" in 2015 [1]. TLDR: Poor performance on mid-1980s hardware.
[1] https://news.ycombinator.com/item?id=10076724
[1] https://news.ycombinator.com/item?id=10076724
> The web should have been based on Display PostScript instead of HTML.
For all that I dislike HTML tag soup, the language does a lot of things right. It's reflowable, it can be rendered at any resolution (even a text terminal, see Lynx), it's flexible enough to support any document structure, and it can be picked up quickly by any 12-year-old with a text editor and no previous programming experience (and that's how we got ourselves the quirky and fun 90s Internet).
You'd be hard pressed to find another document markup language that can do the same. TeX, maybe? Certainly not a graphics language like PostScript.
For all that I dislike HTML tag soup, the language does a lot of things right. It's reflowable, it can be rendered at any resolution (even a text terminal, see Lynx), it's flexible enough to support any document structure, and it can be picked up quickly by any 12-year-old with a text editor and no previous programming experience (and that's how we got ourselves the quirky and fun 90s Internet).
You'd be hard pressed to find another document markup language that can do the same. TeX, maybe? Certainly not a graphics language like PostScript.
I wish the modern web was usably renderable by Lynx. Obviously there are still great sites which are, like HN and many tech blogs. But AFAIK none of the major platforms are particularly usable on Lynx.
I have fond memories of using Lynx and third party CLI messaging apps for AIM, IRC, etc when installing Gentoo on my iMac in 2004 for my first foray into linux. X needed modifications to the Gentoo bootloader to run on my hardware so it took a month or so of assistance from people[0] on #gentoo IRC before I had GUI running. But my digital life was entirely accessible with the CLI apps and 'screen' for multitasking. Living and breathing CLI for that long really went a long way to helping me learn Linux (as well as suffering Gentoo's propensity to require make configure for everything and its excellent guides to choosing between innumerable compile-time customizations of each package).
Nowadays that's very hard to do as iChat's XMPP has been replaced by iMessage's very closed system, IRC certainly isn't dead but Discord has taken front-and-center for many communities of high-interest, and websites are essentially impossible to navigate in CLI.
It's not necessarily a problem with HTML, but it is a "problem" with so much being moved to React / SPA architecture. A niche problem, to be sure. But it makes me sad that other young netizens can't have the same opportunities that I did.
0: Shoutout to Joseph Jezak ( https://developers.google.com/open-source/gsoc/2006 , https://blogs.gentoo.org/josejx/ ) -- your selfless help that summer sincerely changed my life.
I have fond memories of using Lynx and third party CLI messaging apps for AIM, IRC, etc when installing Gentoo on my iMac in 2004 for my first foray into linux. X needed modifications to the Gentoo bootloader to run on my hardware so it took a month or so of assistance from people[0] on #gentoo IRC before I had GUI running. But my digital life was entirely accessible with the CLI apps and 'screen' for multitasking. Living and breathing CLI for that long really went a long way to helping me learn Linux (as well as suffering Gentoo's propensity to require make configure for everything and its excellent guides to choosing between innumerable compile-time customizations of each package).
Nowadays that's very hard to do as iChat's XMPP has been replaced by iMessage's very closed system, IRC certainly isn't dead but Discord has taken front-and-center for many communities of high-interest, and websites are essentially impossible to navigate in CLI.
It's not necessarily a problem with HTML, but it is a "problem" with so much being moved to React / SPA architecture. A niche problem, to be sure. But it makes me sad that other young netizens can't have the same opportunities that I did.
0: Shoutout to Joseph Jezak ( https://developers.google.com/open-source/gsoc/2006 , https://blogs.gentoo.org/josejx/ ) -- your selfless help that summer sincerely changed my life.
Barns-Lee had nothing to do with Javascript. HTML was created as a display technology for static documents and for that purpose it is just fine. Javascript was an afterthought, and that's exactly why the web is the hodgepodge of technologies we see today.
The web works quite well as a document system. Unfortunately people wanted an application system and the web is not architected well for this. Most of the sins of the modern web are from this frankenstein effort to graft an application system onto a document system.
And for reference a properly architected applicaton system would start with a virtual machine designed for hostile input at the bottom, net requests would be a first class system call and the applications could be written in whatever language you want. if you were particularly insane your entry point could be something as stupid as "#!/dns/org/gnu/gcc4 mass of hideous c code here" but usually would be "#!/dns/com/sun/java/java4" or "#!/dns/org/python/python3"
and before anybody shouts webasm... no, webasm is stupid, you are now trying to jam another application system on top of the document system "lets build the virtual machine in javascript and use it on top of all the existing browser madness" is not a good solution.
And for reference a properly architected applicaton system would start with a virtual machine designed for hostile input at the bottom, net requests would be a first class system call and the applications could be written in whatever language you want. if you were particularly insane your entry point could be something as stupid as "#!/dns/org/gnu/gcc4 mass of hideous c code here" but usually would be "#!/dns/com/sun/java/java4" or "#!/dns/org/python/python3"
and before anybody shouts webasm... no, webasm is stupid, you are now trying to jam another application system on top of the document system "lets build the virtual machine in javascript and use it on top of all the existing browser madness" is not a good solution.
serverdict begin 0 exitserver
JS ended up being a compiler target anyway. Stack-based PostScript would have been fine for that and given the web a 15-year head start towards real applications and designs.
Of course Berners-Lee was familiar with DPS, since it was the display layer on NeXTSTEP and the original WWW was a NeXT app. The problem for Display PostScript was always Adobe's expensive and restrictive licensing policy. Worse but free beats sophisticated but proprietary.
(See also Sun NeWS, https://en.wikipedia.org/wiki/NeWS which suffered the same licensing fate)