
Sun's NeWS was a mistake, as are all toolkit-in-server windowing systems (2013) - kick
https://utcc.utoronto.ca/~cks/space/blog/unix/NeWSWasAMistake
======
nibbula
Although I admire and frequently agree with this blog, I think this article
exhibits some common misconceptions about NeWS. NeWS had what amounted to
uploadable toolkits, and therefore could and did have multiple toolkits. A
client could decide how it wanted to separate processing between the client
and server, which seems truly more flexible and allows for much more efficient
communication. Also NeWS had threads which if done today would certainly use
multiple processors. Clients could, but didn't have to, use a separate address
space and language even. But the graphics API was so much better, it's
ridiculous, and is basically the same as now in SVG, html canvas, and most
other decent things.

The big drawbacks of NeWS in my opinion are not having an MIT license, and
being quite difficult to implement well. Also PostScript isn't the nicest
language to program in, which I say from years of programming in it. But it's
far from the worst, and if one changed the to postfix syntax to prefix, it
would be mostly a Lisp.

~~~
kick
What do you not like about PostScript? It's basically a worse Forth, which,
when compared to most languages, is comparatively wonderful to write in.

~~~
DonHopkins
In what way is PostScript worse than Forth? Please answer with specific
details, and provide links to code if you can. I programmed a lot of Forth
code before learning and moving on to programming a lot of PostScript code, so
I've used each of them extensively, and much prefer PostScript, and I'm happy
to show you why and explain by showing you code.

PostScript is much higher level than Forth, and a lot more like Lisp than
Forth, and has much better data structures than Forth, like polymorphic arrays
(that can be used as code), dictionaries (that can be used as objects),
strings, floating point numbers, and NeWS "magic dictionaries" that can
represent built-in objects like canvases, processes, events, fonts, etc.

Yet Forth doesn't even have dynamically allocated memory, although in a few
pages of code you can implement it, but it's not standard and very few Forth
libraries use it, and instead use the linear Forth dictionary memory (which is
terribly limited and can't be freed without FORGETting everything defined
after you allocated it):

[https://donhopkins.com/home/archive/forth/alloc.f](https://donhopkins.com/home/archive/forth/alloc.f)

PostScript is homoiconic. Like Lisp, PostScript code IS first class PostScript
data, and you can pass functions around as first class objects and call them
later.

[https://en.wikipedia.org/wiki/Homoiconicity](https://en.wikipedia.org/wiki/Homoiconicity)

PostScript lets you define local variables with names in dictionaries, and use
stacks of those dictionaries as objects and classes, while Forth requires you
to keep track of everything on the stack without giving it a name. Forth
variables are effectively globals. The fact that PostScript is homoiconic
means you can write PostScript functions that dynamically create and transform
other PostScript functions, like Lisp macros.

In October 1986, before I ever used NeWS or learned of Owen Densmore's
Smalltalk-like PostScript object system, I had just used PostScript on the
LaserWriter and invented my own simple object system like Lisp Machine Flavors
(which was quite easy and obvious) for drawing pie menus, I wrote the
following to Mitch Bradley comparing Forth and PostScript. (Mitch was the
Forth guru at Sun who developed ForthMacs / Sun Forth / CForth / Open Firmware
/ etc -- I worked with him at Sun on Forth as his summer intern, then later
with James Gosling at Sun on NeWS as a full time employee):

[https://github.com/MitchBradley](https://github.com/MitchBradley)

[https://donhopkins.com/home/archive/forth/forth-
postscript.t...](https://donhopkins.com/home/archive/forth/forth-
postscript.txt)

>After having programmed in PostScript for some time, how do you feel about
its relation to Forth? Have your feelings about Forth changed any?

>They are somewhat different languages, suitable for different applications,
but there is a lot of overlap, however. There are features and problems that
each has that the other lacks. I have thought a lot about doing in PostScript
some of the things one can do in Forth, as well as Lisp.

>In writing the code for the PieMenus on the Laser Writer, I had to come up
with some way to make objects, not unlike flavors. It would also be
interesting to make objects in the manner of <builds and does>. Objects are
obviously implemented as dictionaries. Instance variables and messages are
just bindings in the dictionary. The question is how do you build the
dictionaries?

>You can have PostScript functions that build them by hand, or you can have it
more data driven. (Not to say that PostScript functions aren't data. Weee!)
But how do you represent the data? You want to specify defaults when creating
a class, and values when instantiating objects.

>Should the creation of classes and objects be the same operation? (As with
XLisp.) The required instance variable values could be taken as arguments when
instantiating an object of some class, and the optional ones

>How about object instantiation consuming required values? right off the
stack? How would inheritance work? By concatinating dictionaries, or by
nesting them?

>It sure doesn't take much code to do this stuff. This is because PostScript
has a very general set of building blocks for just such things.

PostScript makes it easy to efficiently implement a flexible dynamic object
oriented programming system like Smalltalk's, with multiple inheritance, and
prototype objects that you can dynamically promote both methods and instance
variables from classes to instances. Tom Stambaugh described how Smalltalk
inspired Owen Densmore's PostScript object oriented system in NeWS:

[https://news.ycombinator.com/item?id=18696116](https://news.ycombinator.com/item?id=18696116)

>It seems to me that Forth is to stacks what LispLanguage is to lists. Forth
demonstrated the advantages of a stack-centric paradigm in which each pushed
or popped item could be evaluated as an expression or a primitive. Postscript
reflects the application of that paradigm to the world of typography, 2-d
graphics, and page layout. My own recollection is that Postscript's primary
contribution was the use of splines to describe character glyphs, allowing
them to be effectively rendered at virtually any resolution desired. If
anything, Postscript owes more to TexLanguage and DonaldKnuth than to Forth. I
view the stack-based language paradigm as a convenient afterthought rather
than a central organizing principle.

>I also think we should note the contribution that OwenDensmore, at Sun, made
in demonstrating how to use Postscript dictionaries to create a dynamically-
bound object-oriented runtime environment. This was the fundamental premise of
the Sun window server that ultimately became the
NetworkExtensibleWindowSystem. Owen and I discussed his "crazy" idea at a
poolside table at the now-demolished Hyatt Palo Alto, on El Camino. I told him
that it made sense to me, we scribbled furiously on napkins, and I helped him
see how he might adopt some learnings from Smalltalk. It was one of those
afternoons that could only have happened at that time in that place in that
culture. -- TomStambaugh

>I've extracted Owen Densmore's paper from the news.tape.tar (marked PD),
"Object Oriented programming in NeWS", and uploaded it:

[https://ia802600.us.archive.org/5/items/pdfy-1U9Ry1_Qj0LPSR6...](https://ia802600.us.archive.org/5/items/pdfy-1U9Ry1_Qj0LPSR6e/monterey86.pdf)

Like Lisp or Scheme, you can easily write a metacircular PostScript evaluator
in a few pages of PostScript:

[https://news.ycombinator.com/item?id=21968842](https://news.ycombinator.com/item?id=21968842)

>Also, here is a metacircular PostScript interpreter, ps.ps: a PostScript
interpreter written in PostScript! Since PostScript is homoiconic and so much
like Lisp, it was as easy as writing a metacircular Lisp interpreter (but
quite different in how it works, since PostScript and Lisp have very different
execution models).

[https://www.donhopkins.com/home/code/ps.ps.txt](https://www.donhopkins.com/home/code/ps.ps.txt)

[https://donhopkins.com/home/archive/psiber/cyber/ps.ps.reaso...](https://donhopkins.com/home/archive/psiber/cyber/ps.ps.reasons)

    
    
        Obvious Question:
          Why would anybody ever write a PostScript interpreter in PostScript?
    
        Possible Answers:
          To use as a debugging tool.
          To trace and single step through the execution of PostScript code.
          To serve as a basis for PostScript algorithm animation.
          To gain a deeper understanding of how PostScript works.
          To try out some ideas from Structure and Interpreteration.
          To experiment with extensions to the PostScript language.
          To demonstrate that PostScript isn't just for breakfast any more.
          To make PostScript run even slower (but thicker).
          To avoid programming in C (the portable assembly language of the 80's).
          To use to interpret its self.
          To have something nerdish to talk about at parties.
    

And you can use NeWS PostScript to implement a visual programming system and
debugger to itself:

[https://medium.com/@donhopkins/the-shape-of-psiber-space-
oct...](https://medium.com/@donhopkins/the-shape-of-psiber-space-
october-1989-19e2dfa4d91e)

NeWS not only supported multiple loadable toolkits, but it had "packages" to
keep them safely separated and modularized so clients could request whatever
versions of whatever toolkits they needed, and the same code and data would be
properly shared between all compatible clients. (See "findpackage" /
"beginpackage" at the beginning of every X11/NeWS program, like this X11
window manager for NeWS implemented in PostScript:)

[https://www.donhopkins.com/home/archive/NeWS/owm.ps.txt](https://www.donhopkins.com/home/archive/NeWS/owm.ps.txt)

In case you would rather program in a Lisp-like syntax than PostScript, David
Singer and Rafael Bracho at Schlumberger wrote ListScript, a Lisp to
PostScript compiler:

[https://donhopkins.com/home/archive/NeWS/NeScheme.txt](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.

And in case you are suffering from poor taste in programming languages, and
you don't like Lisp but would rather program in a C- or Java-like syntax than
PostScript, Arthur van Hoff at the Turing Institute wrote PdB, an object
oriented C to PostScript compiler, which let you subclass PostScript classes
in PdB, and also subclass PdB classes in PostScript:

[https://news.ycombinator.com/item?id=21968842](https://news.ycombinator.com/item?id=21968842)

>And later on around 1990-1993, Arthur van Hoff wrote PdB at the Turing
Institute in Glasgow, an object oriented C to PostScript compiler called PdB
(for Pure dead Brilliant), which is kind of like TypeScript, conceptually. We
used PdB to develop HyperLook (Networked PostScript based HyperCard for NeWS),
which I used to port SimCity to NeWS on Unix. (A few years after that, Arthur
wrote the Java compiler in Java at Sun in 1995, and lot of other cool stuff
since then!)

~~~
gnufx
Thanks for all this stuff, some of which I wish I'd been aware of at the time,
like LispScript.

I don't remember the details, like how it was used, but I recall the
metacircular evaluator in HyperNeWS (or do I mean HyperLook?) being called out
as a (the?) major pain point in the system for speed of the interpreter.

~~~
DonHopkins
I wrote a metacircular evaluator, ps.ps, but I only used it in PSIBER for
debugging (single stepping through code, which the normal PostScript
interpreter didn't support directly, and also drawing visualizations of code
execution). So the fact that it was slow wasn't really an issue, since it
wasn't used in any speed critical situation.

[https://www.donhopkins.com/home/code/ps.ps.txt](https://www.donhopkins.com/home/code/ps.ps.txt)

Nether GoodNeWS aka HyperNeWS aka HyperLook nor TNT (The NeWS Toolkit) used a
metacircular evaluator themselves.

HyperLook could copy the image of windows to the clipboard as a PostScript
drawing, but didn't need to use "PostScript capture" for that [below], because
it represented drawings in its own format as a display list of PostScript
data, that PostScript code interpreted to draw, and when you printed an image,
it would just send a header with the drawing interpreter to the printer,
followed by the drawing data and a call to the interpreter.

Maybe it was the speed of the structured drawing interpreter that people were
complaining about. There is some overhead of course, but it's washed out by
the fact that actually performing the drawing itself takes much more time than
interpreting the data.

Or maybe you're thinking of "PostScript capture", which is effectively
"partial evaluation" of arbitrary PostScript code, with respect to the imaging
model (making paths, filling and stroking them, and rendering text)? You can
efficiently implement PostScript capture without resorting to a metacircular
evaluator, simply be redefining a few key operators like "fill", "stroke",
"show", etc.

[https://en.wikipedia.org/wiki/Partial_evaluation](https://en.wikipedia.org/wiki/Partial_evaluation)

PostScript capture is the technique of executing some arbitrary PostScript
code that produces a drawing (which could be a traditional document in a
PostScript file meant for the printer, or even a window system object like a
menu), and capturing the drawing commands as another PostScript program,
without any computation, conditionals, and loops. It would capture the effects
of the drawing commands as another simple, flat PostScript program with all
the conditionals and loops unwound (so a small recursive drawing procedure
would produce an enormous flat drawing file, but most normal documents would
be optimized to be smaller and even print faster), in the same global
coordinate system, with unnecessary graphics state changes removed.

That's the essence of Adobe Acrobat's "Distiller", or Glenn Reid's "PostScript
Distillery". I wrote distill.ps "in the spirit of Glenn Reid's Distillery" for
PSIBER, and the NeWS Toolkit had its own /capture method built in, but they
weren't actually used for much besides making a few illustrations.

[https://medium.com/@donhopkins/the-shape-of-psiber-space-
oct...](https://medium.com/@donhopkins/the-shape-of-psiber-space-
october-1989-19e2dfa4d91e#3209)

>Printing Distilled PostScript

>The data structure displays (including those of the Pseudo Scientific
Visualizer, described below) can be printed on a PostScript printer by
capturing the drawing commands in a file.

>Glenn Reid’s “Distillery” program is a PostScript optimizer, that executes a
page description, and (in most cases) produces another smaller, more efficient
PostScript program, that prints the same image. [Reid, The Distillery] The
trick is to redefine the path consuming operators, like fill, stroke, and
show, so they write out the path in device space, and incremental changes to
the graphics state. Even though the program that computes the display may be
quite complicated, the distilled graphical output is very simple and low
level, with all the loops unrolled.

>The NeWS distillery uses the same basic technique as Glenn Reid’s Distillery,
but it is much simpler, does not optimize as much, and is not as complete.

Here's more about the metacircular interpreter and distilled PostScript:

[https://news.ycombinator.com/item?id=13705664](https://news.ycombinator.com/item?id=13705664)

>What you've described sounds exactly like a PostScript interpreter! You can
easily write a metacircular PostScript interpreter in PostScript!

[http://www.donhopkins.com/home/psiber/cyber/ps.ps.txt](http://www.donhopkins.com/home/psiber/cyber/ps.ps.txt)

>And here is a PostScript quine:

    
    
        {{[ exch /dup load /exec load ] cvx} dup exec}
    

>If you wanted to produce "safe" PostScript file for printing, that used a
standard header file and didn't require a Turing complete printer with loops,
conditionals, functions, etc, you could write a partial evaluator for
PostScript that projects it against the stencil-paint imaging model, optimizes
the graphics, and prints out another "safe" PostScript program using a
standard header, with all the loops unrolled and conditionals evaluated and
functions called and graphics in the same coordinate system. That would enable
you to capture anything you draw on the screen, independent of the PostScript
algorithmic procedures and classes and libraries and application required to
draw it.

[http://www.donhopkins.com/home/psiber/cyber/distill.ps.txt](http://www.donhopkins.com/home/psiber/cyber/distill.ps.txt)

>Glenn Reid, who also wrote books on PostScript like Thinking in PostScript,
pioneered that idea in his "PostScript Language Distillery", which is the idea
that grew into PDF.

[http://donhopkins.com/home/archive/postscript/newerstill.ps....](http://donhopkins.com/home/archive/postscript/newerstill.ps.txt)

Glenn tells me that the PostScript distillery was actually John Warnock's
idea!

------
radiator
To my eyes, NeWS does not look like a mistake. On the contrary, it looks
beautifully engineered.

Among other advantages, I can imagine a world where PostScript would be used
for building user interfaces: a document in screen and print would look the
same, without need for writing conversions like, e.g. HTML+SVG -> PDF when
someone needs to somehow print a web form quickly. And perhaps the old
principles of typography and the experience in typesetting beautiful books
with PostScript could be more easily applied to UI design.

~~~
crooked-v
> a document in screen and print would look the same

This only works if all the screens are the same size as a sheet of paper.

~~~
triska
A key advantage of PostScript is that you can scale all output using
_transformations_ , so that you internally work with the same coordinate space
(called _user space_ ) on all devices, and implicitly scale — and also for
example _rotate_ — all graphics when they are actually drawn.

This extends to fonts too, since PostScript letters are drawn using the same
graphic primitives as other graphs.

~~~
arethuza
I worked on a project in the early 1990s where we used the utterly wonderful
HyperNeWS for most things - we used to play tricks on each other by doing
silly things like logging into someone else's NeWS server using psh and
setting the rotation in the transforms for a terminal window to be _slightly_
off as people were using them - eventually people would notice of course but
things would just work.

Another neat trick that HyperNeWS supported was drawing a shape in its
graphical editor and then pasting that shape as the shape of a window...

~~~
nibbula
My friend and I had an ongoing competition / psychological experiment to psh
into each other's NeWS servers and see how long it was before we would notice
a some semi-subliminal or mildly psychedelic window system hack.

------
paol
I believe X Windows owes much of its incredible longevity to the "provide
mechanism not policy" mantra that its designers took very seriously.

Having the toolkit in the server would necessarily force it to define and
enforce lots of policy. This increases complexity, increases dependency
(coupling) on part of the clients, and after all that you still have the
problem that policy simply doesn't age well.

It still boggles my mind a bit that a display stack designed in the 1980s has
remained viable to this day. Sure, it's a patchwork, and it's finally being
replaced, but _it works_.

~~~
pjc50
The WinForms API also survives from the mid 80s, and is interestingly
different. I believe the classic controls were originally drawn in the kernel?

~~~
codeflo
You probably mean Win16/Win32, not WinForms. But it only survives in the sense
that it’s still there, not in the sense that it’s still useful. How many
applications created in the last five years use Win32 for anything but
creating a top-level window (usually via Chromium/Electron)?

~~~
my123
> How many applications created in the last five years use Win32 for anything
> but creating a top-level window (usually via Chromium/Electron)?

I think that you're in a bubble for that one. Many business domain-specific
applications are still directly written against Win32 even today. UWP didn't
manage to catch up for now either.

Electron usage is mostly only in startup-y apps and some IDEs.

~~~
codeflo
No experience is universal, so I'm curious in what industry you encounter
Win32. Or do you mean WinForms? I often work with industrial manufacturing
companies in Europe, with a mindset about as far from that of Silicon Valley
startups as you can imagine. You usually won't find Electron there. Many
"legacy" projects are in WinForms. But for newer stuff, I see lots of WPF and
Qt projects, both of which don't use native controls.

~~~
pjmlp
That is also my experience.

Outside games, most modern Windows applications, specially in the areas you
mention, I have also seen WPF/Qt, with plain old Win32 just as glue for
underlying OS APIs.

There are still some odd ones that keep doing MFC, or enjoy a mix of
Delphi/C++ Builder.

The only old style C Win32 applications I have seen in the wild during the
last decade tend to be surviving applications from the 90's, done by companies
not so much into Windows C++ frameworks.

------
ggm
It could have been JavaScript 10 years before we had JavaScript. It demanded
more dedication to use.

Turns out round window with stroke path text alpha and reimplemented xeyes was
not compelling.

People should have shown NeWS doing complex client side form field checks.

Sun also didn't go downmarket. Windows PCs happened with hummingbird xceed X
not decent in Microsoft X

~~~
DanielKehoe
Every day that I program in JavaScript I wish we had Display Postscript or
NeWS in the web browser. Imagine if browsers had evolved with Postscript
instead of JavaScript.

~~~
mhd
It's not PostScript instead of JavaScript. It's PostScript instead of HTML,
JavaScript and CSS. That's (IMHO) the more important point. One programming
language to write and structure everything instead of a bastardized SGML plus
a bastardized Java plus an ad-hoc config add-on.

I'd much rather have (a slightly saner) JS for everything than PostScript plus
HTML plus CSS, if I would have to choose.

~~~
ptx
Netscape 4 actually had JavaScript-based stylesheets, before everyone settled
on the CSS standard:
[https://en.wikipedia.org/wiki/JavaScript_Style_Sheets](https://en.wikipedia.org/wiki/JavaScript_Style_Sheets)

~~~
mhd
Neat, I wasn't aware of that. Ah, the things that could've been.

------
sprash
> In the increasingly multi-core world you desperately want as much concurrent
> processing as possible and it's much easier to run several clients in
> parallel than it is to parallelize a single server.

There is nothing more multi-core than a modern GPU. Actually the existence of
modern GPUs is an argument FOR toolkit-in-server windowing systems. All you do
is writing shaders that help you to keep the communication over the PCIe bus
(and potentially network, if you want network transparency) as minimal as
possible.

The NeWS system failed for none of the reasons described in the article. It
failed because of bad performance. There never was custom silicon out there to
render Postscript. Unlike today where you have vastly underused GPUs at your
disposable just waiting to be stuffed with intelligence in form of shaders.
Just have a look at [https://shadertoy.com](https://shadertoy.com) to see what
is possible even on low-end GPUs.

Edit: as cpach pointed out shadertoy.com and not .org

~~~
fulafel
In modern graphics applications (=games) people do try to reduce CPU-GPU
communication, but it is still done a lot and is frequently a bottleneck.
Increasing GPGPU work means CPU and GPU code communicate in both directions.
Making it slower than it already is doesn't make sense from performance
engineering POV unless there are some dramatic advantages from the tradeoff.

~~~
sprash
> Increasing GPGPU work means CPU and GPU code communicate in both directions.

Only if you make the wrong abstractions. Using a shader based toolkit is not
about increasing the GPGPU work but to use the GPU for things that it is
intended to do namely drawing. And if you make the right abstractions you can
severely reduce CPU-GPU communications. In fact a toolkit is exactly the
perfect type of abstraction in that scenario. Most of the input is mouse and
keyboard data and a bunch of drawing commands which means extremely low
bandwidth, less CPU-GPU communication, more performance and faster
applications. I'm not sure what you mean by "tradeoff". Look for example at
the shaders of sahdertoy. For the most part the only data they receive from
the CPU is a timestamp of the current frame and occasionally mouse and
keyboard data which is in the worst case literally just a bunch of bytes per
frame.

~~~
fulafel
Shadertoy is pretty far removed from actual games. Both in tje problem domain
and technological complexity, not to mention the time capsule of webgl.

I'm not sure what you mean by shader based toolkit. Anyway in games the GPU is
not just for graphics anymore (since many years) and this naturally leads to
tight coupling.

------
GeorgeRichard
"One of the great white hopes of the part of the Unix world that never liked X
Windows was Sun's NeWS."

I searched Wikipedia and found that "Great White Hope is a nickname or epithet
originally applied to boxers who were the hope of the "White Race" to beat
African American boxer Jack Johnson."

That seems an odd way to characterize the situation.

~~~
projektfu
It makes sense when you consider that white people were wringing their hands
because they were convinced of their total superiority.

While obviously more benign, there is inherent bigotry in the “X sucks and the
better solution is Y or Z and why won’t they catch on?” mindset. Surely this
next technology will take over from the unacceptable popular one.

(Edited because QuickPath has a long way to go before it’s as functional as
Swype)

~~~
DonHopkins
Actually, the predecessor to X was called W. And many people have proposed the
next version of X should be called Y, because X12 wasn't different enough, and
some even have suggested skipping Y and going directly to Z to get even more
distance from X. But the one thing they all agree on is that X sucks.

~~~
projektfu
I was using X in the sense of a variable, sorry.

------
carapace
Reminds me of the classic "Wheel of Reincarnation" paper: "On the Design of
Display Processors" [http://cva.stanford.edu/classes/cs99s/papers/myer-
sutherland...](http://cva.stanford.edu/classes/cs99s/papers/myer-sutherland-
design-of-display-processors.pdf)

(Good work getting traction on this kick! ;-)

I'm kind of dealing with something like this now myself. I have an
implementation in Prolog of a Forth-like language called Joy and I want to
make a GUI for it that might actually be used by normal people.

I could use e.g. SDL and draw everything myself and handle mouse events etc.
(I have a crude demo in PyGame that does that.)

Or I could use some sort of widget toolkit (I've got a Tkinter demo too.)

Or I can use the browser and treat it like a smart display processor. There
are editors and spreadsheets and libs and all kinds of stuff. The Prolog/Joy
code can stay nice and high-level, with HTML and CSS as the "display
language".

\- - - -

Which brings me to my main point: How in the heck is this not more nailed down
in 2020!?

I first wrote a DSL for GUI layout in the late 90's, I used Delphi was even
earlier, and I known that's all late to the party: we could go back to The
Mother of All Demos or even earlier.

The mouse and hi-res raster displays and GUIs are _old_ but usage is nowhere
near _settled_ yet. Is that because the domain is really so intricate and
challenging or are we just milling around and mistaking it for progress?

Whither React?

(By which I mean maybe functional reactive programming or better yet
Kowalski's Logic Production Systems (LPS
[http://lps.doc.ic.ac.uk/](http://lps.doc.ic.ac.uk/) ) might finally start to
reduce the churn and nail things down.)

(
[https://en.wikipedia.org/wiki/Delphi_%28IDE%29](https://en.wikipedia.org/wiki/Delphi_%28IDE%29)
)

------
RajuVarghese
It may have been a mistake but it did add an important innovation: Postscript
in the display system. This would be an innovation even now, having an
interpreter for an embedded language right in the windowing system.

~~~
cpach
AFAICT Apple does something similar in Quartz…?

[https://en.m.wikipedia.org/wiki/Quartz_(graphics_layer)](https://en.m.wikipedia.org/wiki/Quartz_\(graphics_layer\))

~~~
DanielKehoe
NeWS (developed at Sun) and Display Postscript (developed at NeXT) were each
adaptations of Postscript to the screen. Apple (after the NeXT takeover)
developed Quartz to avoid paying licensing fees to Adobe for Display
Postscript. So yes, Quartz does something similar to NeWS.

~~~
setpatchaddress
Two corrections:

\- Adobe was uninterested in supporting Display PostScript by 1997. The cost
was secondary.

\- Quartz / Core Graphics is based on the PDF rendering model, which is
derived from PostScript. You use C graphics routines to draw; there is no
programming language.

------
tinus_hn
From what I remember the choices were NeWS and it only runs on Sun hardware,
or X and it runs everywhere. Ultimately Sun no longer had enough advantages to
compensate for their half compatibility, shipping incompatible ancient
compilers and out of date libraries.

------
DonHopkins
Owen Densmore recounted John Warnock's idea that PostScript was actually a
"linguistic motherboard".

(This was part of a discussion with Owen about NeFS, which was a proposal for
the next version of NFS to run a PostScript interpreter in the kernel. More
about that here:)

[https://news.ycombinator.com/item?id=17077721](https://news.ycombinator.com/item?id=17077721)

Owen Densmore's discussion of John Warnock's "Linguistic Motherboard" idea for
PostScript:

[https://donhopkins.com/home/archive/NeWS/linguistic-
motherbo...](https://donhopkins.com/home/archive/NeWS/linguistic-motherboard-
owen.txt)

    
    
        Date: Tue, 20 Feb 90 15:20:52 PST
        From: owen@Sun.COM (Owen Densmore)
        To: don@cs.UMD.EDU
        Subject: Re:  NeFS
    
        > They changed the meaning of some of the standard PostScript operators,
        > like read and write, which I don't think was a good idea, for several
        > reasons... They should have used different names, or at least made ..
    
        Agreed.  And I DO see reasons for the old operators.  They could
        be optimized as a local cache for NeFS to use in its own calcs.
    
        > Basically, NeFS is a *particular* application of an abstraction of
        > NeWS. The abstract idea is that of having a server with a dynamically
        > extensible interpreter as an interface to whatever library or resource
        > you want to make available over the network (let's call it a generic
        > Ne* server).
    
        Very true.  This has been particularly difficult for me to get across
        to others here at Sun.  I recently wrote it up for Steve MacKay and
        include it at the end of the message.
    
        > It's not clear to me if NeFS supports multiple light weight PostScript
        > processes like NeWS.
    
        I asked Brent about this, and he agreed that it's an issue.  Brent
        has been talking to a guy here who's interested in re-writing the
        NeWS interpreter to be much easier to program and debug.  I'd love
        to see them come up with a NeWS Core that could be used as a generic
        NetWare core.
    
        I think you should send  your comments off to nfs3 & see what happens!
        I agree with most of your points.
    
        Owen
    
        Here's the memo I consed up for MacKay:
    
    

======================================================================

Window System? ..NeWS ain' no stinkin' Window System!

-or-

Swiss Army NeWS: A Programmable Network Facility

======================================================================

Introduction

NeWS is difficult to understand simply because it is _not_ just a window
system. It is a "Swiss Army Knife" containing several components, some of
which contribute to its use as a window system, others which provide the
networking facilities for implementing the client-server model, all embedded
in a programmable substrate allowing extremely flexible and creative
combination of these elements.

During the initial implementation phase of the Macintosh LaserWriter software,
I temporarily transfered from Apple to Adobe working closely with John Warnock
and other Adobe engineers. At lunch one day, I asked: "John, what do you plan
to do after LaserWriter?" His answer was interesting:

    
    
            PostScript is a linguistic "mother board", which has "slots"
            for several "cards".  The first card we (Adobe) built was a
            graphics card.  We're considering other cards.  In particular,
            we've thought about other network services, such as a file
            server card.
    

He went on to say how a programmable network was really his goal, and that the
printing work was just the first component. His mentioning using PostScript
for a file server is particularly interesting: Sun's next version of NFS is
going to use PostScript with file extentions as the client-server protocol!

This paper explores NeWS in this light: as a Programmable Network Facility, a
major part of Sun's future networking strategy.

NeWS Networking Components

NeWS has realized John's notion of a programmable network facility. It has
populated the initial PostScript mother board with several cards vital to
netwoking:

    
    
        -Device Independent Graphics Primitives: The key importance of the
         PostScript graphics model for networking is that it is device
         independent, able to represent with one file the same drawing on
         *all* the network hosts.  The Folio fonts contribute to this: they
         can be rendered at a given point size on all screens, regardless
         of resolution.
    
        -Host Independent Interpreter: PostScript is an interpreted language
         that runs on all Sun workstations without recompilation.  The
         significance of this for networking is that small code fragments
         can run on any host without any knowledge of the host's
         architecture.  Thus one host sending a code fragment to another
         host need not be concerned whether that host is a Sun-3, Sun-4, or
         even Macintosh!  This extends to client programming languages as
         well: all client languages have the same interface to the host.
         As an illustration of this point, both C and Lisp clients use
         the TNT toolkit with no special interfaces for each language.
    
        -Network Socket Primitives: NeWS has added primitives for listening
         for connection requests, for socket files, for host name and
         internet number management, and for reading and writing on the
         network connection.  In fact, the NeWS "server" code is not
         written in C, it is written in PostScript.  The initial version,
         and the one I run on my own machine today, is 10 lines of code!
    
        -Light Weight Processes (LWP): A network host has many independent
         activities taking place at one time.  Each of these uses a
         separate LWP.  These activities need not be window oriented,
         and in fact most are not.  Consider WUE alarms, for example.
         A LWP could be created on each WUE NetStation whose only task
         was to listen for activities on other WUE NetStations and to
         cause a WUE Alarm to occur when an interesting event occurs.
    
        -Garbage Collection: When data is allocated within NeWS, it is
         returned to the free memory pool when no process references it.
         This is needed in a multiprocessing network host because separate
         LWPs can reference the same shared data.  (No process can safely
         free data itself, because other processes might reference it.)
         Garbage collection manages this problem for the processes, and
         thus is an important Network facility.
    
        -Programmable Events: NeWS has a flexible, very easy to use
         event management scheme.  Processes fill out templates of events
         they are interested in.  When these are matched by events occuring
         within the system, they are delivered to the interested process.
         Events are *far* more useful than simple keyboard and mouse events.
         They can be artificially manufactured for any sort of inter-LWP
         communication.  For the previous WUE Alarm, for example, the WUE
         "Listening" process would communicate to WUE-Friendly applications
         by filling out a WUEAlarmEvent and sending it.  The interested
         applications would have filled out a template which would "catch"
         the event.
    
        -Programmable Error Handling: NeWS uses the standard PostScript
         exception handling, extended to work within the context of LWPs.
         Thus an error in one LWP is isolated to that process only.
         Network programs can "wrap" incomming code inside of the special
         "stopped" error handler which will catch errors occuring inside
         the code fragment.  This is vital to safe network programming.
    

What IS NeWS Anyway!

"Well, I'm glad NeWS has all these useful parts, but just what IS NeWS anyway;
how do I get at and use all this stuff."

Well you may ask! It does seem confusing.

Formally, NeWS is simply a Unix command, just like "ls" and "cd". Its syntax
is:

    
    
        xnews [PostScript-code]
    

i.e. it is a command that executes PostScript code fragment. If the xnews
command is given without an explicit argument, it defaults to executing
"(NeWS/init.ps) run", which simply looks for the file "init.ps" in the
"$OPENWINHOME/etc/NeWS" directory. It is _this_ file that uses the NeWS
components to setup the X11/NeWS window system.

As a silly example of handing in your own commands to NeWS, we can do this:

    
    
            bigmac% xnews "1 1 add ="
            2
    

This simply tells xnews to add 1 & 1 and print the results. Oddly enough, I
have written a somewhat more complex script to fill out my Traval Advance
forms, adding up all the rows and columns and printing out a version of the
form!

Now that we've gotten though the fundamentals, the rest of the paper will look
at individual examples of using NeWS in novel ways. Although we present
programs to illustrate how things are done, the reader may skip over them, the
accompaning text will explain what the program does.

The Ten-Line Server

As mentioned above, "xnews" is simply a Unix command that executes a
PostScript program, defaulting to "(NeWS/init.ps) run". Init.ps performs
several initialization tasks and executes the commands in various other files.
When its done with all of that, it defines and executes a small procedure
called "server". This program uses the NeWS networking facilities to build a
LWP which listens for connection requests from "client" programs. Whenever a
request is heard, the LWP awakens and creates and initializes a new LWP just
for the client's usage.

Here's the ten line version of the server. This actually works (I've run it
for quite some time!), and is explained in Chapter 10, Networking NeWS, of the
Unix Networking book published last year.

    
    
        /server { % - => -; create the NeWS client-server listner process
            {   clear newprocessgroup           % -;    Clean stack, init process group
                (%socketl2000) (r) file         % soc;  Open socket for listening
                {   dup acceptconnection        % soc f;Loop forever creating clients
                    {   exch pop 200 dict begin % f;    Create userdict
                        initmatrix newprocessgroup % f; Init graphics & process
                        cvx exec                % -;    Execute the connection!
                        currentprocess killprocessgroup%Cleanup client & children
                    } fork pop pop              % soc;  Clear process & file
                } loop                          % soc;  Loop forever creating clients
            } fork pop                          % -;    Fork server & toss process
        } def
    

The significance of this is that we can just as easily build other network
services with NeWS, using code much the same as the above. NeWSPrint, for
example, uses a similar PostScript program to provide network printing
facilities. NeWSPrint does not require a special, modified version of xnews;
it simply uses the standard OpenWindows product.

ps2bits: A PostScript to Rasterfile Program

A second use of running xnews as a Unix filter is illustrated by the ps2bits
probram. This Bourne shell script reads a PostScript file on its "standard
in", and emits the resulting Sun raster file on its "standard out". The shell
script does this by having xnews:

-Read in a few standard PostScript initialization files,

-Initialize the PostScript environment (& fix a Folio bug!)

-Build an 8.5 by 11, color, 72 dpi resolution "page" canvas

-Execute the PostScript stdin file to draw that page

-Write the resulting image to stdout as a raster file

Here is the program:

    
    
        #! /bin/sh
        xnews "
            (NeWS/pack.ps)      (r) file cvx exec
            (NeWS/basics.ps)    (r) file cvx exec
            (NeWS/redbook.ps)   (r) file cvx exec
            500 dict begin false setautobind () stringwidth pop pop
            612 792 8 [1 0 0 -1 0 792] null buildimage setcanvas
            (%stdin) run clippath (%stdout) (w) file writecanvas
        "
    

Note: The line with the "buildimage" command may be modified to convert the
program to black & white, or to change the resolution to 300 dpi, or to change
the page size. See Appendix A for a more general script.

Once the image is made, it can easily be looked at in SunView, XView, or NeWS
using any of their raster file viewers. Here's a trivial viewer, "bitwin",
using the TNT toolkit:

    
    
        #! /bin/sh
        psh <<BITS
            /win [ClassCanvas] [] framebuffer /new OpenLookBaseFrame send def
            {   clippath pathbbox scale pop pop
                (${1}) readcanvas imagecanvas
            } /setpaintproc /client win send send
            (${1}) /setlabel win send
            100 100 425 550 /reshape win send
            /activate win send
            /map win send
        BITS
    

This Bourne shell script takes a single command line argument naming the
raster file. It uses the NeWS "PShell" to sent a short program to the running
xnews server. The program will put the file name in its header, and will fill
itself with the raster file image. Stretching the window will stretch the
image.

To use these on the demo file "tiger.ps" which was initially created on the
Mac using Adobe Illustrator, these two steps are taken:

    
    
        bigmac% ps2bits < $XNEWSHOME/demo/PostScript/tiger.ps > /tmp/bits
        bigmac% bitwin /tmp/bits &
    

The first command converts the tiger drawing into a raster file. The second
creates a window for viewing the raster file.

Although the complexity has been fairly minor in the previous examples, we've
illustrated some powerful capabilities:

    
    
        -We can easily use NeWS to provide a simple Unix facility for
         converting PostScript drawings into Sun raster files.  The
         PostScript may come from any of the many widely available sources,
         even the Macintosh.
    
        -These raster files can be used by any toolkit, including SunView.
         They can even be used by other raster devices such as printers.
    
        -Using the networking primitives used in the 10-line server, we
         could easily build a similar server for providing raster files
         to anyone on the network.
    

Using these NeWS facilities in similar creative ways is exactly what NeWSPrint
does. The documentation folks use a similar "filter" to strip out all the
general header information in Mac PostScript files to gain an average 8-1
compression, vastly reducing their disk storage requirements. A homework
assignment in our Usenix NeWS tutorial is to create a generalized Image Server
for the network using these facilities.

WUE Alarms with Programmable Events

WUE has the notion of "alarms" which can be used to alert applications of
changes in status of network objects. Applications can use this for anything
from "hot links" to file status alarms. One of the WUE examples is on file
status: I want to know when the monthy report reaches 90% completion. Hot
links are similar: I want this graph to change whenever the associated
spreadsheet changes.

Here is one way to implement WUE file alarms using NeWS programmable events:

    
    
        -WUE provides a Property Sheet which includes a file completion
         field holding a percentage quantity.
    
        -When the Property Sheet is completed, it creates and sends a
         WUEStatusEvent for the given file.  The network name of the object
         is stored in the event's Action field.  The event includes
         auxillary information about the file in the ClientData of the
         event.
    
        -Applications following WUE object status changes use the NeWS
         "expressinterest" primitive to catch all WUEStatusEvent's for the
         desired file.  It then looks at the ClientData to determine
         whether or not further action should be taken.
    

The WUE Property Sheet would build and send the event this way:

    
    
        createevent dup begin
            /Name   /WUEStatusEvent def
            /Action (/home/project/status/january) def
            /ClientData 1 dict dup begin
                /Completion .70 def
            end def
        end sendevent
    

The application builds an interest for its TNT event manager to handle. It
does so by building a matching event template for WUEStatusEvent and the
/home/project/status/january filename. It also includes a "callback" procedure
which decides what to do with the completion information. In this case, we
want the alarm to occur when the file is more than 90% complete:

    
    
        createevent dup begin
            /Name 1 dict dup begin
                /WUEStatusEvent { % event => -; check if complete yet
                    /ClientData get /Completion get .90 ge {
                        AlertApplication
                    } if
                } def
            end def
            /Action (/home/project/status/january) def
        end MyEventMgr expressinterest
    

This results in the AlertApplication procedure being called when the
/home/project/status/january report is within 10% of completion.

Puny WOF (Workgroup Object Facility)

The above alerting works only for applications running on the same
workstation. This is because the event that is sent is only visible to
interests expressed on the same workstation. We can easily extend our model to
include sending the event to many network workstations by using the same
techniques as the 10-line server:

    
    
        -WUE friendly workstations start a WUE event listening service when
         they start up NeWS.  This uses exactly the same techniques as the
         10-line server, but using a different socket file.  They also
         regester themselves with a centralized list of WUE friendly
         workstations.
    
        -The WUE event listening service starts a second process which
         expresses interest in all local WUE events.  When any WUE
         event is caught, it is "forwarded" to each of the workstations
         listed in the central list.  It does this by opening a socket
         file to each workstation, and sending a small program down
         the socket which sends the WUE event on the remote machine.
    
        -The Property Sheet sends the WUEStatusEvent exactly as before.
         Local applications running on the same machine operate exactly as
         before.  In addition, however, the local WUE event forwarder
         causes the same event to be sent on each of the regestered
         workstations.  Applications on those machines would now catch the
         forwarded event exactly as if it were local.  The application need
         not be modifed!
    

This basically implements a Puny WOF (Workgroup Object Facility). And it can
be done very easily indeed! Admittedly that this is quite puny and many
details about robustness etc. have to be managed. On the other hand, using
xnews as a WOF prototyper is extremely appealing. (I plan to prototype a
versions of Puny WOF as soon as I get a second host set up and running in my
office.)

Multi-Media: NeWS Device Control

Multi-media devices can be managed by NeWS, using programmable events to
interface to applications. This provides a logical division between the device
"driver", which may be implemented in any of several ways, and the application
API to the device, which is via NeWS events.

As an example, consider a graphics tablet input device with an RS232
interface. This device emits x,y data in a well-known format to the serial
device when the tablet's stylus moves. As an initial implementation, the
driver half of the device was written in PostScript as a process which opens
and reads the file /dev/tty. When there is no data on the device, the process
blocks, pausing until data arives for the device. When the data arives, the
read returns with the device data. This is packaged into an event as in the
WUE Alarm example.

Typically the device data needs processing that is better suited to C
programming. The solution is to rewrite the device manipulation as a NeWS
client using either CPS or the TNT Wire Service. The application interface,
however, continues to be the same event interface. The improved performance
incurrs no change in the application interface. The notion of this variety of
client "daemon" has been used in TNT for providing shared text service among
applicaions. A voice interface to EMacs was also made in AD using the same
technique.

Another significant advantage to this division of labor into a device layer
using an event interface to applications is that it gracefully evolves into
sharing the single device among multiple applications. The device is
temporarily "owned" by one application, and is given to another application
using an agreed upon protocol. Two common styles are used:

    
    
        -The keyboard uses a "focus" model where certain UI events not
         associated with the keyboard determine which application owns it.
    
        -The mouse is typically owned by the application in which it was
         last "clicked".
    

In the case of the graphics tablet, applications wanting to use the tablet
would express interest in the tablet's button being clicked within it. From
then on, that application will receive the motion change events for the
tablet.

Although device ownership may seem like a trivial problem, fairly complex
systems are typically needed to solve it for a given device. The VOX server
from Olivetti for voice is used for just this kind of thing: negociation
between applications for ownership of the voice device. Because VOX is not
integrated into a more general event system, however, it cannot manage the
_user interface_ for which application currently owns it. It can only provide
the regestry. When OpenLook defines the "focus" model for ownership of the
voice device, a NeWS oriented voice service will much more easily integrate
into the rest of the system.

Just as WUE Alarms had a network component, certain multi-media devices will
be expensive enough to warrent sharing on the network. Scanners and fax
machines will be attached to individual machnes, but we may want them to be
temporarily owned by other workstations. The same "server" technology used by
the 10-line server and the Puny WOF can also be used here.

Summary and Vision

The interesting software architectures of the next decade will leverage
network technologies. We will see WUE become the Net Finder, replacing the
simplistic Mac Finder in the network intensive workstation world. WUE will
manage network resources among WUE-Friendly NetStations, workstations with
advanced, easily configured network software platforms. NeWS is such a network
tool: a programmable network facility. Another is the newly proposed NFS which
uses file server extended PostScript as its client-server language.

We hear far too many NeWS vs. X arguments based on window and UI toolkit
arguments alone. These, in my opinion, miss the main strengths of NeWS. It is
a programmable network facility which can be used for many purposes. It can
prototype new network services. It can be a universal device controler. It can
be used to integrate multiple hosts. All these elements also need to be
evaluated when considering NeWS.

References

[1] PostScript Language Reference Manual, Adobe Systems, Addison Wesley, 1985

[2] The NeWS Book, Gosling & Rosenthal, Springer-Verlag, 1989

[3] Unix Networking-ch 10: Networking NeWS, Owen Densmore, Hayden Books, 1989

[4] NFS-3 Design Document, Brent Calaghan, Sun internal document, 1990

Appendix A: A more general ps2bits shell script.

    
    
        #! /bin/sh
        # Parse cmd line args: ps2bits [-size W H] [-dpi X Y] [-color]
        X=72; Y=72; W=8.5; H=11; Z=1
        while [ ${#} -gt 0 ]; do
            case "${1}" in
                -dpi)   shift; X=${1}; shift; Y=${1} ;;
                -size)  shift; W=${1}; shift; H=${1} ;;
                -color) Z=8 ;;
            esac; shift
        done
        # Run NeWS as Unix filter. Note use of Bourne shell variables!
        xnews "
            (NeWS/pack.ps)      (r) file cvx exec
            (NeWS/basics.ps)    (r) file cvx exec
            (NeWS/redbook.ps)   (r) file cvx exec
            500 dict begin false setautobind () stringwidth pop pop
            $X $W mul $Y $H mul $Z [$X 72 div 0 0 $Y -72 div 0 $H] null buildimage
            setcanvas
            (%stdin) run clippath (%stdout) (w) file writecanvas
        "

~~~
DonHopkins
By 1990 or so, we could see the writing on the wall that Sun wasn't going to
support NeWS for very much longer, no matter what they claimed.

[https://donhopkins.com/home/images/X11NeWSPorscheHitsSunSoft...](https://donhopkins.com/home/images/X11NeWSPorscheHitsSunSoftBrickWall.jpg)

So there was an ongoing discussion about the best way to do it all over again
from scratch. Scheme was obviously an excellent language to use instead of
PostScript. Here are some notes from February of 1990 (before the abomination
that is CORBA was thrust upon the world), discussing how to apply John
Warnock's "linguistic motherboard" ideas to other languages like Scheme, and
how to implement them on top of something like Xerox PARC's "PCR" (Portable
Common Runtime, essentially the virtual operating system runtime that Cedar
and other Xerox software like Interpress required to run on other platforms
like Unix).

(But first here's some other stuff I wrote recently about Cedar and PCR, for
context. And I've inserted some links into the notes.)

[https://news.ycombinator.com/item?id=22378457](https://news.ycombinator.com/item?id=22378457)

>I believe that stuff is the port of Cedar to the Sun. Xerox PARC developed
"Portable Common Runtime", which was basically the Cedar operating system
runtime, on top of SunOS (1987 era SunOS, not Solaris, so no shared libraries
or threads, which PCR had to provide). He demonstrates compiling a "Hello
World" Cedar shell command, and (magically behind the scenes) dynamically
linking it into the running shell and invoking it.

>Experiences Creating a Portable Cedar.

>Russ Atkinson, Alan Demers, Carl Hauser, Christian Jacobi, Peter Kessler, and
Mark Weiser.

CSL-89-8 June 1989 [P89-00DD6]

[http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-8...](http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-8..).

>Abstract: Cedar is the name for both a language and an environment in use in
the Computer Science Laboratory at Xerox PARC since 1980. The Cedar language
is a superset of Mesa, the major additions being garbage collection and
runtime types. Neither the language nor the environment was originally
intended to be portable, and for many years ran only on D-machines at PARC and
a few other locations in Xerox. We recently re-implemented the language to
make it portable across many different architectures. Our strategy was, first,
to use machine dependent C code as an intermediate language, second, to create
a language-independent layer known as the Portable Common Runtime, and third,
to write a relatively large amount of Cedar-specific runtime code in a subset
of Cedar itself. By treating C as an intermediate code we are able to achieve
reasonably fast compilation, very good eventual machine code, and all with
relatively small programmer effort. Because Cedar is a much richer language
than C, there were numerous issues to resolve in performing an efficient
translation and in providing reasonable debugging. These strategies will be of
use to many other porters of high-level languages who may wish to use C as an
assembler language without giving up either ease of debugging or high
performance. We present a brief description of the Cedar language, our
portability strategy for the compiler and runtime, our manner of making
connections to other languages and the Unix operating system, and some
measures of the performance of our "Portable Cedar".

>PCR implemented threads in user space as virtual lightweight processes on
SunOS by running several heavy weight Unix processes memory mapping the same
main memory. And it also supported garbage collection. Mark Weiser worked on
both PCR and the Boehm–Demers–Weiser garbage collector.

[https://donhopkins.com/home/archive/NeWS/linguistic-
motherbo...](https://donhopkins.com/home/archive/NeWS/linguistic-motherboard-
owen.txt)

Linguistic motherboard metaphore

hardware/software metaphore

A motherboard is a nicer metaphore than a ball of wax.

PostScript as a linguistic motherboard

We need non-proprietary bus in order for this idea to succeed

Vendor supplied cards - software modules. Motherboard extends over the net.
PCR allows tightly coupled modules on the same card (or compatible, closely
linked cards) to communicate in one address space, through local procedure
calls. PostScript allows cards to communicate in memory through PCR and over
the net through remote procedure calls. Polylith is a software bus.
Generalization of client-server model: both ways. send code, not just data.

PCR is like the data, address, and control lines.

PCR:

[http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-8...](http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-8_Experiences_Creating_a_Portable_Cedar.pdf)

[https://news.ycombinator.com/item?id=22378457](https://news.ycombinator.com/item?id=22378457)

[https://news.ycombinator.com/item?id=22456720](https://news.ycombinator.com/item?id=22456720)

PostScript is like Mitch Bradley's Forth for the S-Bus.

Open Firmware:

[https://en.wikipedia.org/wiki/Open_Firmware](https://en.wikipedia.org/wiki/Open_Firmware)

Allows device independant bootstrapping (binding of hardware on cards to
software on the net). Device drivers. Jack Callahan's paper describes how once
you are bootstrapped and communicating with your virtual hardware modules, you
can generate and put into place optimized device specific drivers (automatic
dynamic stub generation).

Many of the ideas originated at adobe, and have made the rounds throughout the
industry and academia.

Adobe has proven PostScript's applicability to page description. Sun has
proven PostScript's applicability to network extensibility.

Adobe and Sun have demonstrated that these concepts work for particular
applications, using a propriatary bus, like DEC's BI bus, i.e. a proprietary
language implementation. They are not nearly as useful as they could be were
they based on an open bus -- a public domain language implementation. PCR is a
tightly coupled open bus, we need a public domain PostScript (and Scheme, and
other languages) interpreter to go along with PCR.

Witness all the people complaining about problems with NeWS (like non-
availability, not running on particular pieces of hardware, server core
dumps), and Adobe PostScript (like the 9600 baud 7 bit printable ascii data
bottleneck), because of problems that would be easy to fix if they had
sources. The failure of NeWS as a window system has demonstrated that it can
fail simply because it's controled by Sun. The failure of PostScript as a ??
general purpose programming language ?? some people might argue is due to poor
design, but I don't think most people I have heard criticize PostScript know
what they're talking about, because they have attacked the cosmetic problems
of "backward" syntax, but not addressed the real problems of dynamic binding.
PostScript is very well designed, and very powerful. Postfix notation is as
backward as prefix (cf big/little endian battles), both of which are simpler
than infix. PostScript's main problem is dynamic binding. Reverse polish
notation is a cosmetic problem, which is addressed by LispScript. There are
extensions to PostScript that would make it a lot more useful, and the dynamic
binding problem might even be solvable. PIX and NetScript come very close, and
are (or will be) in the public domain.

PIX:

[https://ieeexplore.ieee.org/document/301934/](https://ieeexplore.ieee.org/document/301934/)

[https://news.ycombinator.com/item?id=17637483](https://news.ycombinator.com/item?id=17637483)

[https://news.ycombinator.com/item?id=15327211](https://news.ycombinator.com/item?id=15327211)

Right now, Scheme addresses this issue beautifully, and I think it may be
quite applicable to the problem, given a good enough implementation (designed
for the task). ELK comes close.

ELK:

[https://en.wikipedia.org/wiki/Extension_Language_Kit](https://en.wikipedia.org/wiki/Extension_Language_Kit)

Scheme and PostScript in combination (in different address spaces, in the same
address space, or a synthesis of the two) might be an interesting approach.
Scheme with PostScript data types and NeWS extensions. Scheme on a PostScript
virtual machine (the byte code that Scheme compiles into -- so you can device
independant compiled scheme code).

Try to pinpoint what it is about PostScript that makes it better than Scheme
for this problem. First of all, I think it's easier to interpret. Less
overhead. Easier for machines to generate? Or is that BS? The data types.
Magic dictionaries as an interface to data structures (like memory mapping
device registers instead of having i/o instructions). Dynamic binding is
simpler, but you could implement closures on top of that, I think (by making
it extremely easy to switch dictionary stacks, the way class.ps does) and even
continuations (by switching execution stack).

Disadvantages of PostScript: Dynamic binding, addressed above. Polymorphic
operators, so built-in operators have to do type checking. Provide type
specific operators as primatives that the polymorphic ones are built in terms
of, not unlike Crispin Goswell's PostScript interpreter.

Crispin Goswell's PostScript interpreter:

[https://news.ycombinator.com/item?id=13198492](https://news.ycombinator.com/item?id=13198492)

[http://computer-programming-
forum.com/36-postscript/46e6f5fc...](http://computer-programming-
forum.com/36-postscript/46e6f5fcc616fac3.htm)

[http://www.chilton-computing.org.uk/inf/se/mmi/p004.htm](http://www.chilton-
computing.org.uk/inf/se/mmi/p004.htm)

Advantages of NeWS, PIX, NetScript: light weight processes, event queue,
interprocess communication, magic dictionaries, garbage collection, ...

PCR would be an excellent base. PostScript would be a good first step, and
would be extended towards scheme in an upward compatible manner. Proprietary
vendor supplied (or public domain) cards could plug right in (Cedar graphics,
Folio fonts, Andrew editor, X protocol, etc...)

------
fulafel
Picking parallelization of clients as the #1 reason seems like a miss to me. X
never took advantage of it much. The asynchronity in X was motivated by
network latency.

------
DonHopkins
[https://en.wikipedia.org/wiki/NeWS](https://en.wikipedia.org/wiki/NeWS)

NeWS was architecturally similar to what is now called AJAX, except that NeWS
coherently:

\- used PostScript code instead of JavaScript for programming.

\- used PostScript graphics instead of DHTML and CSS for rendering.

\- used PostScript data instead of XML and JSON for data representation.

FTFY:

Web Browsers were a mistake, as are all toolkit-in-browser JavaScript
libraries

April 1, 2020

One of the great white hopes of the part of the Web world that never liked
Gopher was Netscape's web browser. Never mind all of its practical flaws, all
sorts of people held web browsers up as the better way and the bright future
that could have been if only things had been different (by which they mean if
people had made the 'right' choice instead of settling for Gopher). One of the
reasons people often give for liking web browsers is that it put much of the
JavaScript libraries into the web browser instead of forcing every server to
implement it separately.

Unfortunately for all of these people, history has fairly conclusively shown
that web browser was a mistake. Specifically the core design of putting as
much intelligence as possible into the web browser instead of the web server
has turned out to be a terrible idea. There are at least two big reasons for
this.

The first is parallelization. In the increasingly multi-core world you
desperately want as much concurrent processing as possible and it's much
easier to run several web servers in parallel than it is to parallelize a
single web browser. Even if you do get equal parallelization, separate web
servers are inherently more resilient because the operating system
intrinsically imposes a strong separation of address space and so on,
something that's very hard to get in server where everything is jumbled
together.

(I believe that this is one reason that modern HTML CSS rendering has been
moved from the web browser to the web server. WebFont rendering is
increasingly complex and CPU-consuming, so it's better to stick web servers
with that burden than dump all of it on the web browser. After all, all Web
Servers should have multiple GPUs for drawing and accelerating graphics and
numeric computing for all their clients, but there is no rational reason
anyone would ever want to program the GPU in the web browser, or push that
processing off from the honking big accelerated server farms that you're
renting from Amazon by the minute, to the millions of web browsers run by your
users whose electricity you don't need to pay for. Plus, users enjoy waiting
for their graphics to download over the internet in response to every mouse
click and movement they make. It gives them time to think and reflect.)

The second is that if you put the toolkit in the web browser you make evolving
the toolkit and its API much more complicated and problematic. The drawback of
having everyone use the web browser toolkit is that everyone has to use the
same web browser toolkit. Well, not completely. You can introduce a mechanism
to have multiple toolkit versions and APIs all in the same web browser and
allow web servers to select which one they want or need and so on and so
forth. The mess of a situation with the current web browser and its JavaScript
libraries make a very educational example of what happens if you go down this
path; not very much of it is good.

(Some JavaScript libraries are in practice mandatory but still must be probed
for and negotiated by the web servers, while others are basically historical
relics but they still can't be dropped because some web server somewhere may
ask for them.)

JavaScript libraries in the web browser push the burden of dealing with the
evolution of the library into the web server. It is the CDN and web browser
cache that carries around old or new versions of the library, with various
different APIs, and you naturally have old library versions (and even old
toolkits) go away entirely when they are no longer used by any active web
servers (or even any installed web servers, when things get far enough).

(I'm ignoring potential security issues for complex reasons, but they may be a
good third reason to be unhappy with browser-side libraries.)

~~~
agumonkey
Web browsers might not be "fully" a mistake but only a curb on the path to
evolution. Old tech with good genes (lisp, news) wasn't fit for mass
acceptance for devs without the historical background and only desire to
explore a new market with what is cheap on shelves.

Swings and roundabouts

------
pjmlp
Not at all, alongside NeXTSTEP, it made UNIX actually interesting as
workstation OS.

------
mwfunk
"X Windows"

