Yes, he created NeWS PostScript. That's NeWS to me, but I explicitly spelled it out "NeWS PostScript" to be unambiguous. And I purposefully wrote "created" to be specific, not "invented" to give him too much credit, nor "implemented" to give him too little credit.
James Gosling said: "There is really nothing new here. It's just putting it together in a different way."
NeWS was a clean room implementation of a dialect of PostScript that went far beyond Adobe's PostScript in many important ways, including lightweight processes, process groups, multitasking support (fork, pause, killprocess, etc), monitor synchronization locks, strong synchronization guarantees, object oriented programming, packages, networking, synchronous event handling (sendevent, expressinterest, unblockinputqueue, etc), interest event handler templates, multiple arbitrarily shaped canvas drawing surfaces, more built-in data types, magic dictionaries (integrating native code via dictionary getters/setters), reflection and introspection (exposing lightweight processes, events, canvases and other native code and data structures as magic PostScript dictionaries), debugging support (see my PSIBER paper linked above), completely different memory model (no more heap based "save" and "restore" like single threaded printers), reference counting garbage collection, soft references, obsolete events, etc.
All of those are ideas that influenced Java (the topic of this discussion) one way or another, which the original Adobe PostScript didn't have. I'd say the most important NeWS feature that influenced Java was multithreading, which led to Green threads (at the time, Unix didn't support light weight processes yet). Followed by garbage collection (by the negative example of NeWS's reference counting garbage collection), and synchronization (which was where NeWS really shined in comparison to X-Windows).
And NeWS's object oriented programming system was an original addition to PostScript by Owen Densmore. Because it was cleanly and simply implemented in terms of PostScript's existing dictionary stack, it was portable enough that it could run on Adobe PostScript, but NeWS had optimizations and extensions to support it efficiently (and eventually integrated magic dictionaries like canvases and processes as first-class objects, but not at first). We used it extensively and developed it further to implement several different generations of user interface toolkits and clients. It was more dynamic like Smalltalk than static like Java, in that it supported multiple inheritance and instance specialization (prototypes). See Chapter 6, Object-Oriented PostScript, in The NeWS Book (1989):
https://donhopkins.com/home/The_NeWS_Book_1989.pdf
NeWS wasn't just a knock-off of Display PostScript as some temporally confused people believe, because it came first, and did a lot more, and had a totally different purpose and design. Display PostScript is just "Fake NeWS". ;)
Why aren't you also pointing out that he didn't invent Lisp either, or Emacs itself? Didn't you think I was implying that too? That's not what I meant, either.
So yes, James Gosling created NeWS PostScript and Emacs MockLisp, and the lessons from their mistakes and successes directly influenced Java. (Not only technical issues, but also licensing issues -- just ask RMS about "Evil Software Hoarder Emacs".)
Here are some details of his original design, which he called SunDew before (unfortunately) renaming it to NeWS:
Methodology of Window Management: F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams, 29 April 1985.
http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm
This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme.
The Proceedings were later published by Springer-Verlag in 1986.
5. SunDew - A Distributed and Extensible Window System - James Gosling
http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm
5.1 INTRODUCTION
SunDew is a distributed, extensible window system that is currently being developed at SUN. It has arisen out of an effort to step back and examine various window system issues without the usual product development constraints. It should really be viewed as speculative research into the right way to build a window system. We started out by looking at a number of window systems and clients of window systems, and came up with a set of goals. From those goals, and a little bit of inspiration, we came up with a design.
[...]
DESIGN SKETCH
The work on a language called PostScript [1] by John Warnock and Charles Geschke at Adobe Systems provided a key inspiration for a path to a solution that meets these goals. PostScript is a Forth-like language, but has data types such as integers, reals, canvases, dictionaries and arrays.
Inter process communication is usually accomplished by sending messages from one process to another via some communication medium. They usually contain a stream of commands and parameters. One can view these streams of commands as a program in a very simple language. What happens if this simple language is extended to being Turing-equivalent? Now, programs do not communicate by sending messages back and forth, they communicate by sending programs which are elaborated by the receiver. This has interesting implications on data compression, performance and flexibility.
What Warnock and Geschke were trying to do was communicate with a printer. They transmit programs in the PostScript language to the printer which are elaborated by a processor in the printer, and this elaboration causes an image to appear on the page. The ability to define a function allows the extension and alteration of the capabilities of the printer.
This idea has very powerful implications within the context of window systems: it provides a graceful way to make the system much more flexible, and it provides some interesting solutions to performance and synchronization problems. SunDew contains a complete implementation of PostScript. The messages that client programs send to SunDew are really PostScript programs.
Two pieces of work were done at SUN which provide other key components of the solution to the imaging problems. One is Vaughan Pratt's Conix [53], a package for quickly manipulating curve bounded regions, and the other is Craig Taylor's Pixscene [63], a package for performing graphics operations in overlapped layers of bitmaps.
Out of these goals and pieces grew a design, which will be sketched here. The window system is considered in four parts. The imaging model, window management, user interaction, and client interaction. The imaging model refers to the capabilities of the graphic system - the manipulation of the contents of a window. Window management refers to the manipulation of windows as objects themselves. User interaction refers to the way a user at a workstation will interact with the window system: how keystrokes and mouse actions will be handled. Client interaction refers to the way in which clients (programs) will interact with the window system: how programs make requests to the window system.
What is usually thought of as the user interface of the window system is explicitly outside the design of the window system. User interface includes such things as how menu title bars are drawn and what the desktop background looks like and whether or not the user can stretch a window by clicking the left button in the upper right hand corner of the window outline. All these issues are addressed by implementing appropriate procedures in the PostScript.
[...]
5.4 DISCUSSION
Bono:
When you use the word PostScript, do you mean literally that PostScript is in some way your virtual machine instruction set? It has not been extended or generalized?
Gosling:
It has been extended. It is a superset. We are committed to implementing everything in the PostScript telephone book that makes sense. They have a few commands that are particular to their storage allocation and to the fact that they are going to a printer and these are not implemented. We have imported some things that are peculiar to a display and a small number of incompatible changes to the language have been made which we spent a long time talking to the people at Adobe about to make sure that was reasonable. In particular, we added garbage collection and lightweight processes. There are very tiny ways in which the semantics of PostScript's memory allocation strategy shows through in the printer version because they have a quick and dirty storage allocation mechanism and that wasn't really useful in this system.
Bono:
The virtual machine was not virtual enough.
Gosling:
Right. When we made the generalization to multiple processes, their storage allocation mechanism just completely broke and so we had to use garbage collection instead and that necessitated some small semantic changes but they are not things you are likely to see. All of the important things such as how you specify a curve, whether you can render an image rotated 37 degrees, all of that is there or intended to be there.
Hopgood:
How do you handle input?
Gosling:
Input is also handled completely within PostScript. There are data objects which can provide you with connections to the input devices and what comes along are streams of events and these events can be sent to PostScript processes. A PostScript process can register its interest in an event and specify which canvas (a data object on which a client can draw) and what the region within the canvas is (and that region is specified by a path which is one of these arbitrarily curve-bounded regions) so you can grab events that just cover one circle, for example. In the registration of interest is the event that you are interested in and also a magic tag which is passed in and not interpreted by PostScript, but can be used by the application that handles the event. So you can have processes all over the place handling input events for different windows. There are strong synchronization guarantees for the delivery of events even among multiple processes. There is nothing at all specified about what the protocol is that the client program sees. The idea being that these PostScript processes are responsible for providing whatever the application wants to see. So one set of protocol conversion procedures that you can provide are ones that simply emulate the keyboard and all you will ever get is keyboard events and you will never see the mouse. Quite often mouse events can be handled within PostScript processes for things like moving a window.
Teitelman:
The innovation here is not that we are using PostScript. The reason we chose PostScript is due to a lot of historical connections and proximity to the people who are doing it.
The interesting thing is that all these processes look as though they are executing in one of those old single address environments. It is a single user process that James has been able to implement lightweight processes in. You don't have lightweight processes in Unix systems, which you really need to implement realistic user interfaces.
Gosling:
There is really nothing new here. It's just putting it together in a different way.
(NeWS was an implementation/extension of PostScript, but PS was invented by an entirely different group of people).
James Gosling said: "There is really nothing new here. It's just putting it together in a different way."
NeWS was a clean room implementation of a dialect of PostScript that went far beyond Adobe's PostScript in many important ways, including lightweight processes, process groups, multitasking support (fork, pause, killprocess, etc), monitor synchronization locks, strong synchronization guarantees, object oriented programming, packages, networking, synchronous event handling (sendevent, expressinterest, unblockinputqueue, etc), interest event handler templates, multiple arbitrarily shaped canvas drawing surfaces, more built-in data types, magic dictionaries (integrating native code via dictionary getters/setters), reflection and introspection (exposing lightweight processes, events, canvases and other native code and data structures as magic PostScript dictionaries), debugging support (see my PSIBER paper linked above), completely different memory model (no more heap based "save" and "restore" like single threaded printers), reference counting garbage collection, soft references, obsolete events, etc.
All of those are ideas that influenced Java (the topic of this discussion) one way or another, which the original Adobe PostScript didn't have. I'd say the most important NeWS feature that influenced Java was multithreading, which led to Green threads (at the time, Unix didn't support light weight processes yet). Followed by garbage collection (by the negative example of NeWS's reference counting garbage collection), and synchronization (which was where NeWS really shined in comparison to X-Windows).
And NeWS's object oriented programming system was an original addition to PostScript by Owen Densmore. Because it was cleanly and simply implemented in terms of PostScript's existing dictionary stack, it was portable enough that it could run on Adobe PostScript, but NeWS had optimizations and extensions to support it efficiently (and eventually integrated magic dictionaries like canvases and processes as first-class objects, but not at first). We used it extensively and developed it further to implement several different generations of user interface toolkits and clients. It was more dynamic like Smalltalk than static like Java, in that it supported multiple inheritance and instance specialization (prototypes). See Chapter 6, Object-Oriented PostScript, in The NeWS Book (1989):
https://donhopkins.com/home/The_NeWS_Book_1989.pdf
NeWS wasn't just a knock-off of Display PostScript as some temporally confused people believe, because it came first, and did a lot more, and had a totally different purpose and design. Display PostScript is just "Fake NeWS". ;)
Why aren't you also pointing out that he didn't invent Lisp either, or Emacs itself? Didn't you think I was implying that too? That's not what I meant, either.
So yes, James Gosling created NeWS PostScript and Emacs MockLisp, and the lessons from their mistakes and successes directly influenced Java. (Not only technical issues, but also licensing issues -- just ask RMS about "Evil Software Hoarder Emacs".)
Here are some details of his original design, which he called SunDew before (unfortunately) renaming it to NeWS:
Methodology of Window Management: F R A Hopgood, D A Duce, E V C Fielding, K Robinson, A S Williams, 29 April 1985.
http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm
This is the Proceedings of the Alvey Workshop at Cosener's House, Abingdon that took place from 29 April 1985 until 1 May 1985. It was input into the planning for the MMI part of the Alvey Programme.
The Proceedings were later published by Springer-Verlag in 1986.
5. SunDew - A Distributed and Extensible Window System - James Gosling
http://www.chilton-computing.org.uk/inf/literature/books/wm/p005.htm
5.1 INTRODUCTION
SunDew is a distributed, extensible window system that is currently being developed at SUN. It has arisen out of an effort to step back and examine various window system issues without the usual product development constraints. It should really be viewed as speculative research into the right way to build a window system. We started out by looking at a number of window systems and clients of window systems, and came up with a set of goals. From those goals, and a little bit of inspiration, we came up with a design.
[...]
DESIGN SKETCH
The work on a language called PostScript [1] by John Warnock and Charles Geschke at Adobe Systems provided a key inspiration for a path to a solution that meets these goals. PostScript is a Forth-like language, but has data types such as integers, reals, canvases, dictionaries and arrays.
Inter process communication is usually accomplished by sending messages from one process to another via some communication medium. They usually contain a stream of commands and parameters. One can view these streams of commands as a program in a very simple language. What happens if this simple language is extended to being Turing-equivalent? Now, programs do not communicate by sending messages back and forth, they communicate by sending programs which are elaborated by the receiver. This has interesting implications on data compression, performance and flexibility.
What Warnock and Geschke were trying to do was communicate with a printer. They transmit programs in the PostScript language to the printer which are elaborated by a processor in the printer, and this elaboration causes an image to appear on the page. The ability to define a function allows the extension and alteration of the capabilities of the printer.
This idea has very powerful implications within the context of window systems: it provides a graceful way to make the system much more flexible, and it provides some interesting solutions to performance and synchronization problems. SunDew contains a complete implementation of PostScript. The messages that client programs send to SunDew are really PostScript programs.
Two pieces of work were done at SUN which provide other key components of the solution to the imaging problems. One is Vaughan Pratt's Conix [53], a package for quickly manipulating curve bounded regions, and the other is Craig Taylor's Pixscene [63], a package for performing graphics operations in overlapped layers of bitmaps.
Out of these goals and pieces grew a design, which will be sketched here. The window system is considered in four parts. The imaging model, window management, user interaction, and client interaction. The imaging model refers to the capabilities of the graphic system - the manipulation of the contents of a window. Window management refers to the manipulation of windows as objects themselves. User interaction refers to the way a user at a workstation will interact with the window system: how keystrokes and mouse actions will be handled. Client interaction refers to the way in which clients (programs) will interact with the window system: how programs make requests to the window system.
What is usually thought of as the user interface of the window system is explicitly outside the design of the window system. User interface includes such things as how menu title bars are drawn and what the desktop background looks like and whether or not the user can stretch a window by clicking the left button in the upper right hand corner of the window outline. All these issues are addressed by implementing appropriate procedures in the PostScript.
[...]
5.4 DISCUSSION
Bono: When you use the word PostScript, do you mean literally that PostScript is in some way your virtual machine instruction set? It has not been extended or generalized?
Gosling: It has been extended. It is a superset. We are committed to implementing everything in the PostScript telephone book that makes sense. They have a few commands that are particular to their storage allocation and to the fact that they are going to a printer and these are not implemented. We have imported some things that are peculiar to a display and a small number of incompatible changes to the language have been made which we spent a long time talking to the people at Adobe about to make sure that was reasonable. In particular, we added garbage collection and lightweight processes. There are very tiny ways in which the semantics of PostScript's memory allocation strategy shows through in the printer version because they have a quick and dirty storage allocation mechanism and that wasn't really useful in this system.
Bono: The virtual machine was not virtual enough.
Gosling: Right. When we made the generalization to multiple processes, their storage allocation mechanism just completely broke and so we had to use garbage collection instead and that necessitated some small semantic changes but they are not things you are likely to see. All of the important things such as how you specify a curve, whether you can render an image rotated 37 degrees, all of that is there or intended to be there.
Hopgood: How do you handle input?
Gosling: Input is also handled completely within PostScript. There are data objects which can provide you with connections to the input devices and what comes along are streams of events and these events can be sent to PostScript processes. A PostScript process can register its interest in an event and specify which canvas (a data object on which a client can draw) and what the region within the canvas is (and that region is specified by a path which is one of these arbitrarily curve-bounded regions) so you can grab events that just cover one circle, for example. In the registration of interest is the event that you are interested in and also a magic tag which is passed in and not interpreted by PostScript, but can be used by the application that handles the event. So you can have processes all over the place handling input events for different windows. There are strong synchronization guarantees for the delivery of events even among multiple processes. There is nothing at all specified about what the protocol is that the client program sees. The idea being that these PostScript processes are responsible for providing whatever the application wants to see. So one set of protocol conversion procedures that you can provide are ones that simply emulate the keyboard and all you will ever get is keyboard events and you will never see the mouse. Quite often mouse events can be handled within PostScript processes for things like moving a window.
Teitelman: The innovation here is not that we are using PostScript. The reason we chose PostScript is due to a lot of historical connections and proximity to the people who are doing it. The interesting thing is that all these processes look as though they are executing in one of those old single address environments. It is a single user process that James has been able to implement lightweight processes in. You don't have lightweight processes in Unix systems, which you really need to implement realistic user interfaces.
Gosling: There is really nothing new here. It's just putting it together in a different way.
A point he didn't mention is that PostScript is directly descendent from Interpress, which was developed at Xerox PARC and reincarnated as PostScript at Adobe by Chuck Geschke and John Warnock:
https://en.wikipedia.org/wiki/Interpress
Brian Reid's deep detailed historic dive "PostScript and Interpress: a comparison":
https://tech-insider.org/unix/research/1985/0301.html
I also think PostScript owes a lot to Lisp (it's dynamic, homoiconic, polymorphic, symbolic), even more so than Forth.
http://wiki.c2.com/?ForthPostscriptRelationship
Tom Stambaugh wrote:
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_Qj0LPSR6e/monterey86.pdf [fixed link]
It would require some modification to run in other postscript environments, but not much, I think. It was developed after the 1st Edition Postscript manual but before the second, so it's considered a Level 1.5 Postscript environment. It uses dictionaries freely, but the << /Level-2 (syntax) >> had not yet been invented. So it uses a number of nonstandard operators for dictionary construct. These would need to be simulated or the routines rewritten to use Level 2 syntax. -- luserdroog
comp.lang.forth discussion on "Why is Postscript not Forth?":
https://donhopkins.com/home/archive/forth/ps-vs-forth.txt
Forth/PostScript discussion with Mitch Bradley:
https://donhopkins.com/home/archive/forth/forth-postscript.txt