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.
However, fashions in languages are a thing. While PostScript was hot by the mid 1980s, few were using it 10 years later, as there were now WYSIWYG PostScript editors like Illustrater, XPress, Page Maker, etc. Now, these were the days of C(++) and Perl, as may be observed in the JS syntax. But it would have been nice, if it had started with ECMA script (as opposed to LiveScript) and SVG had been already around.
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.
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.
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.
- 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.
Which brings us to the silliest part of the post: the idea that X won, or proved much of anything at all. X is basically noise in the computing world: the atrophied stump of the ix GUI market. The most popular Unix-like OS in the world is rooted in display PostScript. The most popular OS with a Linux kernel doesn't use X, or indeed a *ix-like userland.
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.
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)?
> 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.
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.
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.
Sorry for the pedantry, but you're thinking of the Windows API, specifically the user interface bit (user32.dll as of Windows 95 and NT but it existed before) which is based on GDI which is hardware accelerated. It still exists but it rarely used for new applications today, but it was certainly in use for a very long time.
WinForms was briefly promoted as a successor, based on GDI+. It was quickly abandoned, as was GDI+ which never got hardware acceleration, in favour of WPF which is based on DirectX which is obviously hardware accelerated. But in that small time it caught on and continues to be used for new projects because it's a simpler programming model than WPF and it's not obvious in Visual Studio that it's been abandoned (it's not quite deprecated).
One can use WPF just like WinForms, with code behind and plain drag-and-drop of components.
The problem is that when beginners start searching for tutorials they usually land on MVVM, data binding and how WinForms style is a bad practice and they end up feeling overwhelmed.
Ironically MVVM is also possible to do in WinForms, but the capabilities aren't as rich as in WPF, so very few end up going that route.
WinForms is much more recent than that. It was introduced along with the .NET Framework around 2000.
The original classic controls were implemented in USER.EXE (which was actually a DLL) starting in Windows 1.0 around 1985. WinForms wrapped these controls and others in a .NET interface.
MS Windows is definitely a good counterpoint to this blog post. Whatever the kernel/userspace split (which has changed over time), the basic Windows model is that the logic & code of the windowing system is all in the 'server' (i.e. the OS libraries, sometimes including kernel-space code).
The 'clients' (Windows applications) don't have to do their own font rendering, widget drawing, etc, they can use several different 'server' APIs to do so. Even so, the framework has proved remarkably long-lasting, with decades-old programs still capable of running on modern systems.
Actually the logic and windowing happens in each client in user space, which is why you can’t build alternative window managers, and Microsofts policy of compatibility ‘shims’ and hacks that allow chosen old software (and they choose a lot of software) to work on modern systems has nothing to do with it.
Have a quick search online, and you'll find plenty of alternative window managers for Windows. But it's besides the point, because both styles of graphical windowing systems can support alternative window managers.
The Windows ‘solution’ is really fragile and dangerous because it involves injecting code into all programs.
If there’s a vulnerability the whole system is compromised, if there’s instability the whole system crashes and if part of the system is separated out, like what Windows does with windows belonging to elevated processes, these windows follow the original rules set by Microsoft.
A lot of software seems to work best just before it's replaced, and the replacement takes years to catch up. I hope for the best but fear for the worst in the X case.
I get your point, but see it completely differently as GUI programmer. X was steaming pile of s*t. Its "longlevity" was spend cleaning up the mess.
Designers had this stupid idea to do drawing over remote connection, and produced broken design around that. Direct memory access, DRI, OpenGL, screen buffers... Non of that was part of X, but is vitally necessary for GUI.
There is no compatibility in X server design. Good luck running remote X session today. Everyone uses VNC.
Apart from thin clients, X remote display has historically been used for combining applications from multiple systems on a single display. Those systems could be computers, lab hardware, or anything else.
Indeed, over 25+ years that I've known, and I'd be surrounded by that in the office, not VNC (but some X2go).
The single rubbish X server I've known is (or was) Xceed (or however it's spelt) which people inexplicably used rather than Cygwin's; the first question to ask someone with classes of Emacs problems was whether they were using it.
Or the other way around: multiplexing one X11 application across multiple displays.
On the Usenix trade show floor one year, somebody made a horse racing client that opened connections on multiple X11 servers, and animated horses racing from screen to screen. Many different companies with X11 workstations or terminals were running it at the same time, and horses were running between different brands of computers on the trade show floor, which made a nice point! (About network race conditions ;) It was just black and white, and the graphics were dead simple, so it worked great on everybody's hardware.
Multi Player SimCityNet was implemented in TCL/Tk on X11, which supported opening multiple X11 servers at the same time, even with different kinds of displays, and using shared memory if running locally. Of course there was a limit to how many people could play at once, and it required a reasonably fast network, and every player had to grant full access to their server to the client. And anyone could type TCL expressions into the chat window and hit escape to execute them, so it probably wasn't very secure, and certainly was easy to cheat: "sim Funds 9999999<esc>"
>SimCityNet: a Cooperative Multi User City Simulation
>SimCityNet is an animated interactive system simulation game, providing a set of rules and tools for planning and building a complex dynamic simulated city. Several people on different workstations can participate in the same game, cooperating and coordinating their actions over the net.
Working together, you can zone land use, hook up the power grid, build roads, bridges, parks and stadiums, raise taxes, and even summon disasters, causing the city to grow and thrive, or crumble and die. SimCityNet features multiple city views and maps with overlays, simultaneous editing and user interface interaction, "voting panels" for group decision making, and multimedia communication and annotation features ("bridges between players").
>The multi user interface supports communication via three media in parallel: text, sound, and graphics. It includes a scrolling text log for telegram messages, a networked audio server for sound effects and voice intercom, and shared cursors and graphical overlays for pointing, gesturing, annotating and editing the map.
We had effective direct-manipulation GUIs long before OpenGL, so that can't be it, though we did have DMA and graphics buffers in the '80s and DRI wasn't relevant.
It makes a lot of sense for multiple applications share the same toolkit implemented in a "user interface manager", the same way they all share a "window manager", running locally with the window server. Of course the browser is now a "user interface manager" itself. It also makes a lot of sense to use a web browser as the window manager and user interface manager itself: instead of running it on top of another window system, the web browser should be the window system and window manager.
Simon Schneegans, the author of Gnome Pie, and creator of the Coral Menu and Trace Menu, wrote some interesting thoughts about "Open Pie", and the evolution of Gnome-Pie for Wayland towards being a shared "pie menu user interface manager" that applications use via D-Bus.
Gnome-Pie: Homepage of Gnome-Pie, the slick application launcher for Linux.
>On Wayland, there are at least six major issues which make applications such as Gnome-Pie basically impossible. I have described these issues in one of my previous posts in more detail - here they are listed again:
>No client side window placement - Menus cannot be opened at cursor location
>No global input grabbing - When a menu is opened, you will still be able to Alt-Tab to another application, etc.
>No global key bindings - No global hot-keys from within Gnome-Pie. Only cumbersome configuration in your window manager
>No mouse pointer warping - Leads to problems when menus are opened close to screen edges
>No client side application management - No Alt-Tab window list features
>No sending fake keyboard events - No simulated key strokes or deferred activation anymore
>However, I still believe that many users would benefit from efficient and eye-candy (pie-) menus on Linux. Particularly, the very inspiring article on pie menus by Don Hopkins convinced me, that creating a follow-up project for Gnome-Pie would be a pretty awesome idea.
>"My goals are to enable developers, designers, and users to easily create and edit their own pie menus, and provide free software, tested designs, smart editors, automatic layout, support and guidance to help people come up with fun, easily used, memorable, Fitts-friendly designs." - Don Hopkins
>I got reminded that I once had the idea of OpenPie, a novel architecture for Gnome-Pie. Now I realized that this new architecture can solve at least some of the problems listed above.
>Introducing: OpenPie
>The main component of OpenPie will be a daemon running in the background listening on the D-Bus for incoming menu-open requests. Any application can send such a requests - a menu will pop up, the user is going to make a selection and the OpenPie daemon will report the selected menu item back to the application.
[He goes on to describe how OpenPie will use the D-Bus interface, and support new menu types.]
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.
How is PostScript a "worse Forth"? I find PostScript great fun to program in, and I think the type errors one gets from the system to indicate mistakes are a great help when writing PostScript code.
It's much higher level, chooses the worst bits of high-level languages to throw in, NeWS's spin of it was object-oriented which has since been shown to be a mistake, it's not as extensible, has too many stacks, introduces significant complexity for dubious benefit, so forth.
Of course, whether or not PostScript is like Forth at all is a matter of debate, some religiously disagree. I'm somewhere in the middle on that. Old flamewar topic:
I did a fair bit of PostScript development in NeWS/HyperNeWS and while I really liked PostScript I've never been able to get into Forth - I actually thought that PostScript was rather like the Common Lisp that the rest of the project used (one of the things I wrote for the project being the glue code in C to link the PostScript world of NeWS to Common Lisp - which is a nice mix of approaches to syntax!).
NB: It was particularly neat that Sun shipped a set of Adobe blue/green/red(?) books with OpenWindows.
PostScript does take a lot from Lisp, too. And (kind of) Smalltalk. 'DonHopkins has posted a lot about it on here; I really love hearing him talk about it:
Object oriented programming has since been shown to be a mistake??! That's NeWS to me. Can you provide a citation please?
What do you mean that NeWS or PostScript classes are not extensible? The little "e" in NeWS stands for "extensible".
And what is the correct number of stacks, in your opinion?
Please quantify what you can, and provide examples and links to code, and citations of other people who agree with your personal opinions like the number of stacks a language is supposed to have, the meaning of extensibility, or that object oriented programming languages are a mistake.
But maybe that capital N is for Non .. (kidding obviously)
I've always been curious about NeWS but the web is quite short of demos about it (not helped by newspapers called Sun either). Do you know sites with videos about it ?
Thanks for asking! ;) I've put up some old demos on youtube, and made illustrated transcriptions of some, and written some papers and articles. Sorry the compression is so terrible on some of the videos. Here are some links:
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989
PSIBER Space Deck and Pseudo Scientific Visualizer Demo. Demo of the PseudoScientific Visualizer and NeWS PSIBER Space Deck. Research performed under the direction of Mark Weiser and Ben Shneiderman. Developed and documented thanks to the support of John Gilmore and Julia Menapace. Developed and demonstrated by Don Hopkins.
Ben Shneiderman introduces Pie Menus developed by Don Hopkins at UMD Human Computer Interaction Lab.
University of Maryland Human Computer Interaction Lab Pie Menu Demos.
Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser.
By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland. Published in Hypermedia, vol. 3, 2 (1991)101–117.
HCIL Demo - HyperTIES Browsing. Demo of NeWS based HyperTIES authoring tool, by Don Hopkins, at the University of Maryland Human Computer Interaction Lab.
HCIL Demo - HyperTIES Authoring with UniPress Emacs on NeWS. Demo of UniPress Emacs based HyperTIES authoring tool, by Don Hopkins, at the University of Maryland Human Computer Interaction Lab. Tabbed window management with pie menus.
Just the Pie Menus from All the Widgets. Pie menu demo excerpts from "All The Widgets" CHI'90 Special Issue #57 ACM SIGGRAPH Video Review, produced by and narrated by Brad Meyers.
How To Choose with Pie Menus. Early pie menu demo by Don Hopkins, on NeWS 1.0, running on a Sun 3 workstation. Featuring the World's Most Enormous Pie Menu, and Direct PacManipulation!
I haven't had a chance to look at the videos for old time's sake, and they may make the point: a big part of it, as a developer experimenting with things, was the mode-less Smalltalk-like environment which allowed you to modify the system on the fly. (I don't know how much like, since I never used Smalltalk.)
The ability to "psh" to the NeWS server and play around with PostScript (much like the Chrome Developer Tools now lets you do with JavaScript) was crucial to making NeWS fun.
The PSIBER Space Deck was trying to make a visual Smalltalk-like or Lisp-Machine-like development and debugging environment for NeWS, that let you visually browse and edit PostScript code and data structures and objects and processes in the system.
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989
Written by Don Hopkins, October 1989.
University of Maryland Human-Computer Interaction Lab, Computer Science Department, College Park, Maryland 20742.
Abstract
The PSIBER Space Deck is an interactive visual user interface to a graphical programming environment, the NeWS window system. It lets you display, manipulate, and navigate the data structures, programs, and processes living in the virtual memory space of NeWS. It is useful as a debugging tool, and as a hands on way to learn about programming in PostScript and NeWS.
Here's some fun stuff about NeWS and screen snapshots of the HyperTies hypermedia browser and Emacs authoring tool that I scanned (after printing them out as slides for a talk, then losing the original images) -- HyperTIES supported formatted hypertext, raster, and PostScript graphics, with plug-in extensible interactive "applets" programmed in PostScript, including pie menus, pop-up embedded image targets, widgets, form controls, scrolling text editors, etc. These screen snapshots were slides for a talk about building user interfaces in NeWS, using HyperTIES to explain and demonstrate itself and the technology it was implemented with:
And here are some ideas about visual programming and programming by demonstrations that I was thinking about while developing PSIBER, like a visually programmable window shell environment:
Yeah, I'd say GUI development is one of the places OOP really shines. I think a lot of the OOP was a mistake opinions come from its ubiquitous use in the enterprise, even in domains for which it was not well suited.
I would venture game development as well - UE4's actor and component model is a good example of this, it's a very flexible system that allows you to strike a good balance between inheritance and composition.
I remember that pre-1990, PostScript seemed like a miracle. "Computer Shopper" of all things, used to have a PostScript Guru column with all kinds of interesting stuff. All the computer I had access to was an Atari ST with GFA Basic, so really only the math and ideas translated, but it really was like seeing the future. Path-clipping in particular was mind-blowing.
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):
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.
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):
>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 ...
Here is an example of making Lisp-like macros with PostScript, using a technique like "backquote", to compile PostScript code templates into more efficient drawing functions, and promote customized dynamically generated code into the instances (NeWS had a prototype based object system that made that possible).
This is a design document I wrote for Open Look Sliders for The NeWS Toolkit 2.0.
The tNt 1.0 slider implementation was a subclass of ClassDialControl,
which was a subclass of ClassControl. It needed to be reimplemented,
directly as a subclass of ClassCanvas (with ClassTarget mixed in), and
had to be taught to play games with the services architecture, and
brought in line with the controls architecture. All that hot air from
the collapse of the ParentDictArray had to go somewhere, so the slider
was graphically "puffed up" with a fake 3-D look. It is hoped that the
result of this transfer of energy will result in a net decrease in
size and increase in speed. To cope with the increase in complexity of
drawing special effects, a form of inlining or macro expansion similar
to "backquote" in lisp was used, to promote fast drawing procedures
into slider instances.
* DESIGN CHOICES:
space/time tradeoffs
The backquote technique speeds up drawing but takes up space. But
the macro templates (defined as methods that are inlined and
promoted) can still be executed even if they haven't been promoted.
There is a small hit for executing "," which is defined as "/,
{exec} def" (since it can't be defined as "/, /exec load def"
because of autobind). And of course the templates are slower than
the their inlined promoted expansions, because they're calculating
the values each time instead of just pushing constants. Right now,
the promotion happens upon /reshape, when the size is known and the
layout can be calculated. Another space saving trade-off might be to
only expand and promote the macros at the start of tracking, during
which parts of the control must be frequently repainted, and
unpromote it upon completion of tracking.
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.
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.
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.
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.
>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...
PostScript is a much more advanced and easier to program language than Forth. Just how you can use def in all its forms makes a lot of things easier. Hand written PostScript code is very easy to read.
Writing bigger programs I struggled to understand what I wrote without comments on every line describing the stack. One could use more variables to make it easier to understand, but in the old days that would also make it less efficient. I would frequently have to reverse engineer my code.
Interestingly, object oriented PostScript would tend to help make your code seem more like prefix code, because it would be like more like "object method argument ... send" rather than "... arg arg function".
> 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 to see what is possible even on low-end GPUs.
Edit: as cpach pointed out shadertoy.com and not .org
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.
> 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.
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.
I didn't notice performance was a problem on something like a SPARCstation 1+, though it was definitely slower than the blindingly-fast GEC4000-driven vector displays we needed to replace.
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.
I can print the same PS file to different printers (inkjet, laser, dot matrix) and (subject to resolution constraints) obtain similar documents from each device.
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.
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...
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.
Circa 1990 I was working/studying in university on a mix of 1024x1024 1 bit per pixel XTerminals and workstations (Sun, Apollo?) with somewhat better resolutions and colors. We had one NeXT too. Printers where mostly dot matrix, with some lasers, A4 format (Europe here). Nothing would have prevented sending a Postscript screen output to a printer, with some white space around due to different geometries. Actually I learned Postscript in 1996 to print some stuff directly instead of drawing it using Word or whatever.
- Is it necessary that the document should take the whole screen?
- Is it possible to render a PostScript document in different sizes and resolutions?
- Do any people today read PDFs on their screens? If some do, are all their screens the same size as a sheet of paper?
Anyway, that was not the spirit of my comment. I meant, doing design in HTML, CSS, SVG and then working out again, all from the beginning, how to convert the document to a printable version of professional quality, is more work than writing PostScript for both, even if some configuration necessarily differs between screen and print.
There are definitely a lot of difficult issues and trade-offs about implementing true "WYSIWYG" editors that let you layout text and graphics that looks exactly the same on the screen and when printed.
This Cedar demonstration video has some great examples of many of these issues. The Tioga text editor was "WYSIMOLWYG": what you see is more or less what you get.
Some problems were due to technology and aren't as bad any more. Cedar and NeWS used black-and-white screens and didn't have anti-aliased fonts. CPUs were much slower and memory was much tighter and graphics were not accelerated, so even with color displays (which were usually only 8 bits with a colormap that makes anti-aliasing very difficult), anti-aliased text wasn't practical.
And fonts rendered at screen resolutions have totally different measurements than high resolution printed fonts, so words have different widths and get flowed and wrapped differently, so the formatting is quite different.
NeWS had a "setprintermatch" primitive that makes the font rendering machinery use the official precise printer measurements for fonts, instead of the actual pixel screen measurements. That was useful for the PostScript previewer, and for editors previewing how formatted text will look. (There was a nice port of FrameMaker to NeWS, but I don't remember how its preview features worked.) But text rendered with printer metrics looks terrible and is hard to read, so you wouldn't want to actually edit text like that.
>setprintermatch: (boolean setprintermatch - ) Sets the current value of the printermatch flag in the graphics state to boolean. When printer matching is enabled text output to the display will be forced to match exactly text output to a printer. The metrics used by the printer will be imposed on the display fonts. This will usually cause displayed text to look bunched up and generally reduce readability. With printer matching disabled, readability will be maximized, but the character metrics for the display will correspond to the printer. See also: currentprintermatch
Windows are resizable, and while text is scalable, you still want to be able to read and edit text in narrow windows, and not waste screen space or get giant text in wide windows. So reflowing text differently for the screen while editing is very useful.
Also, rendering text in a wysiwyg previewer that precisely scales text is slow the first time and uses a lot of memory, because the particular point size of that font must be rendered into the cache, since it can't just round the point size to a whole number that may already be in the cache (like the scalable "jet" NeWS terminal emulator did to avoid blowing the cache). So it's better if the system renders all text in the same restricted set of point sizes, instead of scaling it continuously.
Also it's costly in terms of screen space to edit two columns of text at once, or pages at a time.
It's just ergonomically easier and wastes less screen space to edit formatted text in one continuous non-paginated column, resizable to any window width you want to use at the time, formatted as close as possible to how it will look on the printer, but without the exact same measurements.
And in this day and age, most text that people write is intended to be read in many different media, formats, screen and font sizes, and layouts. Now it's about WYSIWYG editing text and graphics in the way they will appear in a web browser, and those come in all shapes and sizes (thus Chrome Developer Tool's device preview mode).
The Acorn Archimedes had anti-aliased text using 8 grey levels on a 4 or 8 bit display, on computers with 0.5MB RAM in 1990... http://telcontar.net/Misc/GUI/RISCOS/#text so in theory it could have been practical for Sun ...
If your display only has gray levels, then anti-aliasing is easy since you don't need to worry about rendering text over non-white backgrounds, and you don't need to worry about a colormap. But 8 bit displays with colormaps make it much harder to support anti-aliased text practically, especially over arbitrary backgrounds (because it would look terrible as well as being slow).
NeWS used a color cube with only a certain number of grays, and those were only useful for anti-aliasing black text against a white background (or the other way around), and you didn't have a lot of colors to choose from for antialiased color text or against colored backgrounds. It's much easier to render anti-aliased text in 24 bits, or with pure gray scale, since you aren't restricted to an 8 bit color palette, and you can efficiently mathematically blend colors together, instead of looking up rgb values in a colormap, blending to get the ideal desired color, and then searching for the nearest color to each pixel in the colormap (or indexing the color cube for the nearest color) (which won't be very near, and will look flat and washed out without dithering).
Better visually to render the whole image with antialiased text in full 24 bits, then use error diffusion dithering over the entire image at once (to avoid flat washed out regions, and distribute the error over space) to make an 8 bit palletized version, but that's quite slow and memory intensive.
Of course your application (like a monochrome PostScript previewer) could switch in an all-gray ramp colormap for efficiently rendering and beautifully displaying anti-aliased text, but then all the other windows on the screen would be shown in the wrong colormap, and the colormap would flash back and forth when you moved your focus between windows.
Ah, yes, Acorn didn't try to anti-alias properly over varying backgrounds. ArtWorks did full anti-aliasing but it was quite a lot slower to render https://en.wikipedia.org/wiki/ArtWorks
In this video of Eric Bier and his colleagues from Xerox PARC demonstrating Cedar, they discuss writing resolution independent applications, and the problem and approaches to matching the text and formatting displayed on the screen, with how it looks when printed:
>Eric Bier Demonstrates Cedar. Computer History Museum, Recorded on January 24, 2019.
>This interpretive production was created from archival footage of Eric Bier, PARC research scientist, demonstrating the Cedar integrated environment and programming language on January 24, 2019. Cedar was an evolution of the Mesa environment/language, developed at PARC’s Computer Science Laboratory originally for the Xerox Alto. Mesa was modular and strongly-typed, and influenced the later Modula family of languages. Cedar/Mesa ran on the D-machine successors to the Alto (such as the Dorado) and added features including garbage collection, and was later ported to Sun workstations. Cedar/Mesa’s integrated environment featured a graphical window system and a text editor, Tioga, which could be used for both programming and document preparation, allowing for fonts, styles, and graphics to be embedded in code files. The editor and all its commands were also available everywhere, including on the command console and in text fields. The demo itself is running through a Mac laptop remotely logged into Bier’s Sun workstation at PARC using X Windows. Bier demonstrates the Cedar development environment, Tioga editor, editing commands using three mouse buttons, sophisticated text search features, the command line, and the Gargoyle graphics editor, which was developed as part of Bier’s UC Berkeley Ph.D. dissertation. Bier is joined by Nick Briggs, Chris Jacobi, and Paul McJones.
Here are some notes about that I took:
There were several window systems developed for Cedar: Warren Teitelman developed Docs. Lots of functionality, but slow. Scott McGregor developed Viewers. It was lean and fast, in response to Docs. Michael Plass built the Cedar imager.
The Experimental Programming Environment Research Project looked at different competing projects to decide which to standardize on. Cedar/Mesa came out of that and played a dominant role in the 80's. The Smalltalk people contributed ideas but were (not railroaded but) frustrated.
Cedar had a ubiquitous almost-wysiwyg structured text and code editor called Tioga. It was important in Cedar, because it's everywhere, even the text fields. The terminal window has a stripped down text editor with subset of commands.
Setting the so-called "clipping level" in Tioga (like a folding outliner) goes back to Englebart's NLS. Bill Paxton and Doug Wyatt were NLS people who also worked on Tioga.
Key ideas were applicable in any possible place in both systems. The Alto had small memory, and each program took over the entire system. It was not integrated. Simple little editors for code. Fancier editors for documents. Using the same component everywhere is something Smalltalk was pioneering even on the tiny Alto. When Cedar came along, running on a much bigger more powerful 1 megabyte D-Machines, it pulled together those ideas, and added so much more, including much more advanced graphics, way beyond what the Alto could do.
Tioga could display and edit formatted code with different levels of indentation and formatting. Tioga was not completely WYSIWYG. Print mode shows two columns, but you edit one column. You could get a pretty good idea of what it would look like, but in the early times it did not have smooth fonts. Bitmap fonts measure differently on the printer, so text is necessarily broken and flowed differently. The printer used Interpress, the predecessor of PostScript. You could preview Interpress files in Cedar. (The video shows a demo of both editing a document in Tioga, and previewing the Interpress file that it produced for t...
Someone taking a verbose format for writing text and adding feature and feature to it until it supports UI applications? Jesus, that's a horrific vision.
Hope something like that will never see the light of day.
>ManaGeR or MGR was an early windowing system originally designed and developed for Sun computers in 1984 by Stephen A. Uhler, then at Bellcore.
>MGR featured overlapped, asynchronous windows and an applications interface that was both machine and network independent.
>Each MGR window had support for both character terminal operations as well as basic graphics operations. It was controlled by mousing pop-up menus, by keyboard interaction, and by escape sequences written on pseudo-terminals by client software.
>The system was presented at the USENIX Fourth Computer Graphics Workshop in 1987 as "MGR - a Window System for UNIX".[1] The entire MGR source code was posted to the comp.sources.unix Usenet newsgroup, Volume 17, Issue 1, in January 1989.[2]
MGR was the largest posting to ever appear in comp.sources.unix:
Also Chris Torek, Mark Weiser and others developed "Maryland Windows" at the University of Maryland Computer Science Department, based on the Gosling Emacs screen redisplay code and terminal drivers. It was very good over slow modems because it used Emacs's intelligent redisplay algorithm aka "Ultra-hot screen management package" -- the one with the skull and crossbones.
Even worse would be a window system or browser built on SGML or one of its mutant derivatives. Imagine a world where servers download tag soups of structured text with angled brackets and attributes to define formatted text, styles, and interactive users interfaces! It could only be worse if nobody could agree on which mutant derivative of SGML to use, so there were several different ones, and then a totally different style language that was completely syntactically unique, so you could not use the same syntax and tools to write and edit all the almost-but-not-quite-entirely-unlike-SGML syntaxes mish-mashed together.
That said imagine if the SGML working group had held their ground and used s-expressions! At least the soup would be easy to slurp. (I can’t find a reference right now so maybe I just had a fever dream once?)
Speaking of DSSSL, I love the Doctor Dobb's Journal interview with James Clark, who helped design and implement DSSSL and many other SGML and XML technologies.
>A Triumph of Simplicity: James Clark on Markup Languages and XML
>By Eugene Eric Kim, July 01, 2001
>If you peek under the hood of high-profile open-source projects such as Mozilla, Apache, Perl, and Python, you'll find a little program called "expat" handling the XML parsing. If you've ever used the man command on your GNU/Linux distribution, then you've also used groff, the GNU version of the UNIX text formatting application, troff. If you've ever done any work with SGML, from generating documentation from DocBook to building your own SGML applications, you've undoubtedly come across sgmls, SP, and Jade.
>Whether you've heard of him or not (and mostly likely, you haven't), James Clark (below right) has made your life easier. In addition to authoring these and other widely used open-source tools (see http://www.jclark.com/ for a complete list), Clark served as the technical lead of the original W3C XML Working Group and as the editor of the XSLT and XPath recommendations. He recently founded Thai Open Source Software Center ( http://www.thaiopensource.com/ ). His latest project is TREX, an XML schema language. Clark sat down with Eugene Eric Kim to discuss markup languages, the standardization process, and the importance of simplicity.
>The mighty programmer James Clark wrote the de-facto reference SGML parser and DSSSL implementation, was technical lead of the XML working group, and also helped design and implement XSLT and XPath (not to mention expat, Trex / RELAX NG, etc)! It was totally flexible and incredibly powerful, but massively complicated, and you had to know scheme, which blew a lot of people's minds. But the major factor that killed SGML and DSSSL was the emergence of HTML, XML and XSLT, which were orders of magnitude simpler.
>There's a wonderful DDJ interview with James Clark called "A Triumph of Simplicity: James Clark on Markup Languages and XML" where he explains how a standard has failed if everyone just uses the reference implementation, because the point of a standard is to be crisp and simple enough that many different implementations can interoperate perfectly.
>He's not that famous outside of hard core geek circles, but I am a huge fan of James Clark (not the SGI guy, but he's awesome too for different reasons), ...
In 1992/3, right after I got the University of Washington's Computer Science & Engineering dept. onto the web (after faculty outrage based on a NYT article about physics departments and this cool new thing) ... I wrote an extension for Netscape that allowed it to display DVI files natively :)
What NeXT missed out on is what we now call "AJAX": the advantages of implementing the user interface toolkit and the front-end parts of the application in PostScript, so it runs right next to the user, can can implement an efficient application specific networking protocol to communicate between the client and server. NeXT didn't have any of the advantages of NeWS and AJAX when run over the network. Just the stencil/paint imaging model. But no light weight processes, local event handling, object oriented programming, etc.
Consider this. As we know, Tim Berners-Lee developed the first web browser on a NeXT computer, with Display Postscript to render HTML (and print it, too). Two years later, Marc Andreessen and Eric Bina developed the NCSA Mosaic web browser for the X Window System and Microsoft Windows. Another 2 years, and Brendan Eich made the Netscape Navigator web browser programmable with JavaScript.
What if Sun had open sourced NeWS in the early 90s? Could NCSA or Netscape have used an open source NeWS to build a web browser that renders HTML using NeWS on X11 or Windows? With no need for JavaScript or CSS, just Postscript?
Don Hopkins? Is it plausible that we’ve had 25 years of JavaScript hell because Sun management didn’t open source NeWS? Or were there insurmountable technical obstacles as well?
Ah, yes, Netscape Navigator was available for 16 bit Windows 3.1. Even if NeWS was open source, the vast majority of personal computers at the time weren't powerful enough to run it. I only ever saw it running on a $10K Sun SPARCstation.
That's a good point. PostScript needs floating point numbers and lots of memory. At one point in history, for the typical "Desktop Publishing" setup of a Mac and a LaserWriter, the LaserWriter actually had more CPU power and memory than the Mac!
>The LaserWriter used the same Canon CX printing engine as the HP LaserJet, and as a consequence early LaserWriters and LaserJets shared the same toner cartridges and paper trays. PostScript is a complete programming language that has to be run in a suitable interpreter and then sent to a software rasterizer program, all inside the printer. To support this, the LaserWriter featured a Motorola 68000 CPU running at 12 MHz, 512 kB of workspace RAM, and a 1 MB frame buffer.
>At introduction, the LaserWriter had the most processing power in Apple's product line—more than the 8 MHz Macintosh. As a result, the LaserWriter was also one of Apple's most expensive offerings. For implementation purposes, the LaserWriter employed a small number of medium-scale-integration Monolithic Memories PALs, and no custom LSI, whereas the LaserJet employed a large number small-scale-integration Texas Instruments 74-Series gates, and one custom LSI. The LaserWriter was, thereby, in the same form factor (for its RIP), able to provide much greater function, and, indeed, much greater performance, all within the very same LBP-CX form factor, although the external packaging was, for marketing purposes, somewhat different.
... and the LaserWriter's 68000 wasn't even top of the line for custom RIPs. I worked at a company in Seattle in the early 1990s that had a custom RIP engine based on the Motorola but faster, with more memory and better connectivity to the CPU. I don't remember it's name - I just had to write the device driver for Interactive Linux to make it work :)
We certainly fought hard to convince Sun to make NeWS free.
James Gosling fought very hard for NeWS, but in the end failed to convince Sun to do the right thing. He was optimistic when he talked me into going to Sun to work on NeWS after I'd already given up on it by 1990, saying that Sun had turned over a new leaf, and was soon going to announce their commitment to NeWS:
Date: Tue 6 Mar 1990 08:37:51 PST
From: James Gosling <jag@Eng.Sun.COM>
Subject: Re: Sun's response to the net
To: Don Hopkins <don@cs.UMD.EDU>
In-Reply-To: Don Hopkins's message of Tue, 6 Mar 90 05:03:31 -0500
> When is the message from Sun coming out? Will it be from you, or
> someone else who will be believed?
It'll be from me, and it'll come out today or tomorrow.
> Will it mention the possibility of Sun putting xnews in the public
> domain, or is it too early to say anything about that?
It's too early to say. It looks good so far, but there are still some
possible legal problems that we need to check out.
> How are the changes at Sun related to making xnews free? Is it a
> central point or just a side issue?
It's a pretty central issue.
> I'm afraid that a renewed commitment to NeWS or internal changes at
> Sun just won't mean that much to me or the rest of the world, unless
> Sun does something substantial that will benefit everyone, like making
> xnews free. As long as Sun keeps NeWS proprietary, any effort they put
> into it will just be seen as self serving...
We'll get it out, even if I have to spill some real blood on the floor.
> What do you think of the theory about DEC making unlimited funds
> available for shooting down NeWS? If there's any merit to that, would
> they try to keep the X Consortium from accepting the donation of xnews
> server source code?? I'm sure DEC couldn't do anything to keep Sun
> from donating GNeWS/X11 to the Free Software Foundation, and I know
> FSF would take it. (I suspect DEC would much rather NeWS die a slow
> painful proprietary death, dragging Sun down with it.)
It has been very clear for a long time that DEC explicitly targeted
NeWS as something to be trashed. That was probably the major reason
for giving NeWS such a ridiculously low profile. There were folks at
sun who didn't want to give DEC a bigger target. The folks running the
show now have more guts.
James.
But in the end Sun redefined the meaning of the word "free" by announcing that OpenWindows source code was "Free for $1000": it cost $1000 for the tape media, and nobody was allowed to put it on an FTP server.
Here is a link to my flamey-poo on that sensitive topic, followed by the official announcement to which I was reacting. I'll include some choice excerpts, and a couple more links on the topic.
>I have been following the messages on the network in the aftermath of
the OWPS "free for $1000" disaster... The big problem was not the
$1000. It was the word "free".
>In short: If you were a slave, what how would you feel if your master
announced you could go "free", but he really meant he was selling you
down the river for a media cost of only $1000?
>[...] For years, we (customers, software developers, and employees) have
been asking Sun to make Open Windows available for free, in such a way
that it could be distributed on the X11R4 tape or through other public
channels, but that has not happened yet. Our biggest concern is not
that we don't have to pay money!! The most important thing is that we
can make changes to the source code, and g...
I was guessing you might come through and give us an awesome and thorough exposition on the parallel universe that might have been. Thanks!
I still wish anything had the features of NeWS. I wish people could currently be able to feel freedom, power, expressiveness of such environments, where you could change the look and behavior of anything on your screen with a couple of lines typed in a REPL.
Even though the browser has been creeping every day towards it, it seems impossible to escape the constriction of it's haphazard evolution. Browsers have all the hard parts of a NeWS server already worked out inside them (but in C/C++ code), but even if you could magically transform it, it seems it would still be horribly constrained by many other layers of cruft.
> We certainly fought hard to convince Sun to make NeWS free.
After reading your "flamey-poo" I'm wondering how much other non-technical, meddlesome corporate baggage would have come along for a ride even if someone somehow could have convinced them to make "free" === "free".
If it was more than none, I have a hard time seeing how a strong enough "View Source" philosophy could have sprouted from it no matter how strong the tech was/is. From what I understand the web started with that philosophy, and it only partially made it out of the battle with copy/paste intact.
The fact that you were apparently already burned out once before this flame tells me that there was a lot of such baggage. Am I in the ball park here?
Yes you're definitely in the ball park with a beer and a hot dog -- there was a huge amount of corporate baggage.
The hype and corporate bullshit that surrounded Java is a good example of what that corporate baggage would have been like if it had been deployed for NeWS's benefit instead of Java's.
If Sun had put as much energy into promoting and supporting NeWS as they did with Java, we would probably live in a very different world today.
Sun turned a corner when they abandoned their Berkeley hippie BSD roots and got into bed with AT&T / SVR4 / Solaris, and that changed a lot of stuff for the worse, making it a lot harder to do things like give away the source code to X11/NeWS. A lot of people from different companies who used to be Sun's enemies, and who had extremely different philosophies and antithetical approaches to "open software", joined Sun and started influencing and managing its policies and projects. A disastrous example was the Distributed Objects Everywhere project and CORBA fiasco, which was originally the crazy idea of a bunch of people from HP and DEC, Sun's former nemesis's, who then came to Sun and started pushing it into everything, to the detriment of NeWS and other older projects at Sun. Some of the problematic people and armchair architectural astronauts that Sun imported and put in charge of DOE/CORBA, like Steve MacKay and Michael Powell, were worthless corporate bullshitters whose main goals were to establish and maintain a hegemony, and they kept their grandiose plans in their head and never wrote anything down or made any hard decisions or came up with anything concrete, because they didn't want to be pinned down to committing to something, when they were actually in way over their heads. The whole point of the incredibly complex software they finally developed was interoperability with other company's compatible software, but in reality none of it actually worked together. It only talked to itself. SLOWLY.
Since DOE was intended to run everywhere and talk to everything but actually didn't, they should have called DOPE for Distributed Objects Practically Everywhere.
DOPE was a complete failure at its stated mission, and it had ridiculously costly overhead and complexity. When they finally delivered something years behind schedule and lacking crucial promised features, it actually required TWO CDROMs to install. (You'd think they could have distributed a distributed network object system over the network, instead of via CDROM, but nooooo: it was just too big to download.) And in the end, nobody actually used "DOE" or "NEO" for anything consequential. They wasted a spectacular amount of time, energy, money, careers, and good will on that crap.
And then when Java finally came along, the same meddlesome corporate baggage handlers and armchair architectural astronauts went into overdrive to evangelize and promote the Java Juggernaut. And even more of them flocked in droves to Sun to jump on the Java bandwagon. If it was bad after the invasion of System V / AT&T / HP / DEC minions, things got much worse once the Java zombies started arriving in teaming brain-eating hoards to get their part of the action in response to all the hype. The original Java team was brilliant, and there were some extremely excellent people working on it, but they were totally outnumbered by the dead weight of all the hangers-on who didn't want to work hard to make a struggling company great, but just wanted an easy job at a secure company that was already great...
Sun knew how to make mistakes. Sun made so many mistakes it's hard to list them all.
Here's a handy guide to when to use open source:
- when you're trying to gain mindshare and you're behind
- when closed-source == product death
- when your customers won't purchase from you if you don't
- when it helps you upsell to other more proprietary /
less-open products and services
- when you need it to retain talent and it doesn't
compromise the business
Open source is a business tool, not necessarily an end (though it can be an end too).
> NeXT didn't have any of the advantages of NeWS and AJAX when run over the network. Just the stencil/paint imaging model. But no light weight processes, local event handling, object oriented programming, etc.
Not in Display PostScript, perhaps, but NeXT definitely had OOP pervasively; where do you think the modern Apple use of Objective-C came from?
Yes, I mean no object oriented PostScript programming. The NeXT user interface toolkit was entirely implemented in Objective C, and the PostScript code it sent to the Display PostScript server was very simple and flat, not a customized per-application protocol, and didn't do much more than drawing.
That's why it was such a natural progression for Apple to switch from Display PostScript to Cocoa, which was the moral equivalent of PDF, which is just PostScript without the Turing-complete programming language part.
My "hyperTeX" documents under NeWS looked pretty much the same on screen as printed, modulo hyperlinks, but I wouldn't want to write documents directly in PostScript. I'm unconvinced generally about the trades-off of markup in a non-macro programming language.
Incidentally, the nascent web looked horribly primitive when you already had fairly rich networked hypermedia and missed the significance of the web architecture.
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.
"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.
"great white hope" is an English idiom. While originally having racist connotations, it's entered common usage and is no longer tied to racism, or anything in particular.
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)
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.
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.
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 toolk...
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.
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:)
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:
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 fi...
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.)
>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.
>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.
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/ ) might finally start to reduce the churn and nail things down.)
128 comments
[ 3.9 ms ] story [ 197 ms ] threadTurns 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
Adobe would have a stranglehold on the market instead of Google.
I'd much rather have (a slightly saner) JS for everything than PostScript plus HTML plus CSS, if I would have to choose.
https://en.m.wikipedia.org/wiki/Quartz_(graphics_layer)
- 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.
But of course we now have GPU shading languages..
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.
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.
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.
I still mourn the days of shareware.
WinForms was briefly promoted as a successor, based on GDI+. It was quickly abandoned, as was GDI+ which never got hardware acceleration, in favour of WPF which is based on DirectX which is obviously hardware accelerated. But in that small time it caught on and continues to be used for new projects because it's a simpler programming model than WPF and it's not obvious in Visual Studio that it's been abandoned (it's not quite deprecated).
The problem is that when beginners start searching for tutorials they usually land on MVVM, data binding and how WinForms style is a bad practice and they end up feeling overwhelmed.
Ironically MVVM is also possible to do in WinForms, but the capabilities aren't as rich as in WPF, so very few end up going that route.
The original classic controls were implemented in USER.EXE (which was actually a DLL) starting in Windows 1.0 around 1985. WinForms wrapped these controls and others in a .NET interface.
The 'clients' (Windows applications) don't have to do their own font rendering, widget drawing, etc, they can use several different 'server' APIs to do so. Even so, the framework has proved remarkably long-lasting, with decades-old programs still capable of running on modern systems.
If there’s a vulnerability the whole system is compromised, if there’s instability the whole system crashes and if part of the system is separated out, like what Windows does with windows belonging to elevated processes, these windows follow the original rules set by Microsoft.
I get your point, but see it completely differently as GUI programmer. X was steaming pile of s*t. Its "longlevity" was spend cleaning up the mess.
Designers had this stupid idea to do drawing over remote connection, and produced broken design around that. Direct memory access, DRI, OpenGL, screen buffers... Non of that was part of X, but is vitally necessary for GUI.
There is no compatibility in X server design. Good luck running remote X session today. Everyone uses VNC.
The single rubbish X server I've known is (or was) Xceed (or however it's spelt) which people inexplicably used rather than Cygwin's; the first question to ask someone with classes of Emacs problems was whether they were using it.
On the Usenix trade show floor one year, somebody made a horse racing client that opened connections on multiple X11 servers, and animated horses racing from screen to screen. Many different companies with X11 workstations or terminals were running it at the same time, and horses were running between different brands of computers on the trade show floor, which made a nice point! (About network race conditions ;) It was just black and white, and the graphics were dead simple, so it worked great on everybody's hardware.
Multi Player SimCityNet was implemented in TCL/Tk on X11, which supported opening multiple X11 servers at the same time, even with different kinds of displays, and using shared memory if running locally. Of course there was a limit to how many people could play at once, and it required a reasonably fast network, and every player had to grant full access to their server to the client. And anyone could type TCL expressions into the chat window and hit escape to execute them, so it probably wasn't very secure, and certainly was easy to cheat: "sim Funds 9999999<esc>"
https://www.youtube.com/watch?v=_fVl4dGwUrA
https://www.donhopkins.com/home/catalog/simcity/simcity-anno...
https://www.donhopkins.com/home/catalog/simcity/simcitynet.h...
>SimCityNet: a Cooperative Multi User City Simulation
>SimCityNet is an animated interactive system simulation game, providing a set of rules and tools for planning and building a complex dynamic simulated city. Several people on different workstations can participate in the same game, cooperating and coordinating their actions over the net. Working together, you can zone land use, hook up the power grid, build roads, bridges, parks and stadiums, raise taxes, and even summon disasters, causing the city to grow and thrive, or crumble and die. SimCityNet features multiple city views and maps with overlays, simultaneous editing and user interface interaction, "voting panels" for group decision making, and multimedia communication and annotation features ("bridges between players").
>The multi user interface supports communication via three media in parallel: text, sound, and graphics. It includes a scrolling text log for telegram messages, a networked audio server for sound effects and voice intercom, and shared cursors and graphical overlays for pointing, gesturing, annotating and editing the map.
Simon Schneegans, the author of Gnome Pie, and creator of the Coral Menu and Trace Menu, wrote some interesting thoughts about "Open Pie", and the evolution of Gnome-Pie for Wayland towards being a shared "pie menu user interface manager" that applications use via D-Bus.
Gnome-Pie: Homepage of Gnome-Pie, the slick application launcher for Linux.
http://schneegans.github.io/gnome-pie
Gnome-Pie
https://vimeo.com/30618179
The Trace-Menu
https://vimeo.com/51073078
The Coral-Menu
https://vimeo.com/51072812
OpenPie! Gnome-Pie will die.
http://schneegans.github.io/news/2018/05/31/openpie
>On Wayland, there are at least six major issues which make applications such as Gnome-Pie basically impossible. I have described these issues in one of my previous posts in more detail - here they are listed again:
>No client side window placement - Menus cannot be opened at cursor location
>No global input grabbing - When a menu is opened, you will still be able to Alt-Tab to another application, etc.
>No global key bindings - No global hot-keys from within Gnome-Pie. Only cumbersome configuration in your window manager
>No mouse pointer warping - Leads to problems when menus are opened close to screen edges
>No client side application management - No Alt-Tab window list features
>No sending fake keyboard events - No simulated key strokes or deferred activation anymore
>However, I still believe that many users would benefit from efficient and eye-candy (pie-) menus on Linux. Particularly, the very inspiring article on pie menus by Don Hopkins convinced me, that creating a follow-up project for Gnome-Pie would be a pretty awesome idea.
>"My goals are to enable developers, designers, and users to easily create and edit their own pie menus, and provide free software, tested designs, smart editors, automatic layout, support and guidance to help people come up with fun, easily used, memorable, Fitts-friendly designs." - Don Hopkins
>I got reminded that I once had the idea of OpenPie, a novel architecture for Gnome-Pie. Now I realized that this new architecture can solve at least some of the problems listed above.
>Introducing: OpenPie
>The main component of OpenPie will be a daemon running in the background listening on the D-Bus for incoming menu-open requests. Any application can send such a requests - a menu will pop up, the user is going to make a selection and the OpenPie daemon will report the selected menu item back to the application.
[He goes on to describe how OpenPie will use the D-Bus interface, and support new menu types.]
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.
Of course, whether or not PostScript is like Forth at all is a matter of debate, some religiously disagree. I'm somewhere in the middle on that. Old flamewar topic:
http://wiki.c2.com/?ForthPostscriptRelationship
The syntax is also slightly less nice, which is relevant for their question, but less quantifiable.
NB: It was particularly neat that Sun shipped a set of Adobe blue/green/red(?) books with OpenWindows.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...
What do you mean that NeWS or PostScript classes are not extensible? The little "e" in NeWS stands for "extensible".
And what is the correct number of stacks, in your opinion?
Please quantify what you can, and provide examples and links to code, and citations of other people who agree with your personal opinions like the number of stacks a language is supposed to have, the meaning of extensibility, or that object oriented programming languages are a mistake.
But maybe that capital N is for Non .. (kidding obviously)
I've always been curious about NeWS but the web is quite short of demos about it (not helped by newspapers called Sun either). Do you know sites with videos about it ?
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989
https://medium.com/@donhopkins/the-shape-of-psiber-space-oct...
PSIBER Space Deck and Pseudo Scientific Visualizer Demo. Demo of the PseudoScientific Visualizer and NeWS PSIBER Space Deck. Research performed under the direction of Mark Weiser and Ben Shneiderman. Developed and documented thanks to the support of John Gilmore and Julia Menapace. Developed and demonstrated by Don Hopkins.
https://www.youtube.com/watch?v=_fqCeuue5Ac
Pseudo Scientific Visualizer. Demo of the NeWS PseudoScientific Visualizer and the PSIBER Space Deck.
https://www.youtube.com/watch?v=GatM3s2S75Q
Mousee Demo. Demo of Mousee running in the NeWS Window System.
https://www.youtube.com/watch?v=PRP2QorRDUw
Ben Shneiderman introduces Pie Menus developed by Don Hopkins at UMD Human Computer Interaction Lab. University of Maryland Human Computer Interaction Lab Pie Menu Demos.
https://www.youtube.com/watch?v=kxkfqgAkgDc
Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser. By Ben Shneiderman, Catherine Plaisant, Rodrigo Botafogo, Don Hopkins, William Weiland. Published in Hypermedia, vol. 3, 2 (1991)101–117.
https://medium.com/@donhopkins/designing-to-facilitate-brows...
HCIL Demo - HyperTIES Browsing. Demo of NeWS based HyperTIES authoring tool, by Don Hopkins, at the University of Maryland Human Computer Interaction Lab.
https://www.youtube.com/watch?v=fZi4gUjaGAM
HCIL Demo - HyperTIES Authoring with UniPress Emacs on NeWS. Demo of UniPress Emacs based HyperTIES authoring tool, by Don Hopkins, at the University of Maryland Human Computer Interaction Lab. Tabbed window management with pie menus.
https://www.youtube.com/watch?v=hhmU2B79EDU
Just the Pie Menus from All the Widgets. Pie menu demo excerpts from "All The Widgets" CHI'90 Special Issue #57 ACM SIGGRAPH Video Review, produced by and narrated by Brad Meyers.
https://www.youtube.com/watch?v=mOLS9I_tdKE
Precision Pie Demo.
https://www.youtube.com/watch?v=c0scs59va4c
Handy Pie Menu Demo.
https://www.youtube.com/watch?v=TuA_yylYwjM
How To Choose with Pie Menus. Early pie menu demo by Don Hopkins, on NeWS 1.0, running on a Sun 3 workstation. Featuring the World's Most Enormous Pie Menu, and Direct PacManipulation!
https://www.youtube.com/watch?v=MOJaY6Xu7ao
NeWS Tab Window Demo. Demo of the Pie Menu Tab Window Manager for The NeWS...
I haven't had a chance to look at the videos for old time's sake, and they may make the point: a big part of it, as a developer experimenting with things, was the mode-less Smalltalk-like environment which allowed you to modify the system on the fly. (I don't know how much like, since I never used Smalltalk.)
Edit: "Scott McNealy ate my window system" :-(
http://bitsavers.trailing-edge.com/pdf/sun/NeWS/The_NeWS_Boo...
The ability to "psh" to the NeWS server and play around with PostScript (much like the Chrome Developer Tools now lets you do with JavaScript) was crucial to making NeWS fun.
The PSIBER Space Deck was trying to make a visual Smalltalk-like or Lisp-Machine-like development and debugging environment for NeWS, that let you visually browse and edit PostScript code and data structures and objects and processes in the system.
https://medium.com/@donhopkins/the-shape-of-psiber-space-oct...
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989
Written by Don Hopkins, October 1989. University of Maryland Human-Computer Interaction Lab, Computer Science Department, College Park, Maryland 20742.
Abstract
The PSIBER Space Deck is an interactive visual user interface to a graphical programming environment, the NeWS window system. It lets you display, manipulate, and navigate the data structures, programs, and processes living in the virtual memory space of NeWS. It is useful as a debugging tool, and as a hands on way to learn about programming in PostScript and NeWS.
https://donhopkins.com/home/documents/NeWS/BuildingUserInter...
https://medium.com/@donhopkins/designing-to-facilitate-brows...
And here are some ideas about visual programming and programming by demonstrations that I was thinking about while developing PSIBER, like a visually programmable window shell environment:
https://donhopkins.com/home/documents/NeWS/spike.txt
And a few more PSIBER screen snapshots:
https://donhopkins.com/home/documents/NeWS/PSIBER.pdf
It's partly archived online, and weirder than I remember! https://www.tinaja.com/glair01.shtml
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
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
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://donhopkins.com/home/archive/forth/forth-postscript.t...
>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 ...
https://github.com/IanDarwin/OpenLookCDROM/blob/master/NeWS/...
https://github.com/IanDarwin/OpenLookCDROM/tree/master/NeWS/...
https://github.com/IanDarwin/OpenLookCDROM/tree/master/NeWS
Also a paper by Arthur van Hoff about "Syntactic Extensions to PdB to Support TNT Classing Mechanisms":
https://www.donhopkins.com/home/archive/NeWS/PdB.txt
More LispScript stuff (compiling Lisp to PostScript):
https://www.donhopkins.com/home/archive/NeWS/NeScheme.txt
And to compare some window management tasks in Forth and PostScript:
X10 window manager in Forth:
https://www.donhopkins.com/home/code/fuwm-main.forth.txt
X11 window manager in PostScript:
https://www.donhopkins.com/home/archive/NeWS/owm.ps.txt
NeWS tabbed pie menu window manager in PostScript for TNT 2.2 (which "owm" could wrap around X-Windows):
https://www.donhopkins.com/home/archive/NeWS/tab-3.0.2.ps.tx...
NeWS Tab Window Demo: Demo of the Pie Menu Tab Window Manager for The NeWS Toolkit 2.0.
https://www.youtube.com/watch?v=tMcmQk-q0k4
This is a design document I wrote for Open Look Sliders for The NeWS Toolkit 2.0.
https://www.donhopkins.com/home/archive/NeWS/tnt-sliders-des...
* THE PROBLEM:
The tNt 1.0 slider implementation was a subclass of ClassDialControl, which was a subclass of ClassControl. It needed to be reimplemented, directly as a subclass of ClassCanvas (with ClassTarget mixed in), and had to be taught to play games with the services architecture, and brought in line with the controls architecture. All that hot air from the collapse of the ParentDictArray had to go somewhere, so the slider was graphically "puffed up" with a fake 3-D look. It is hoped that the result of this transfer of energy will result in a net decrease in size and increase in speed. To cope with the increase in complexity of drawing special effects, a form of inlining or macro expansion similar to "backquote" in lisp was used, to promote fast drawing procedures into slider instances.
* DESIGN CHOICES:
space/time tradeoffs The backquote technique speeds up drawing but takes up space. But the macro templates (defined as methods that are inlined and promoted) can still be executed even if they haven't been promoted. There is a small hit for executing "," which is defined as "/, {exec} def" (since it can't be defined as "/, /exec load def" because of autobind). And of course the templates are slower than the their inlined promoted expansions, because they're calculating the values each time instead of just pushing constants. Right now, the promotion happens upon /reshape, when the size is known and the layout can be calculated. Another space saving trade-off might be to only expand and promote the macros at the start of tracking, during which parts of the control must be frequently repainted, and unpromote it upon completion of tracking.
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.
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
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...
>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...
Interestingly, object oriented PostScript would tend to help make your code seem more like prefix code, because it would be like more like "object method argument ... send" rather than "... arg arg function".
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 to see what is possible even on low-end GPUs.
Edit: as cpach pointed out shadertoy.com and not .org
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.
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.
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.
This only works if all the screens are the same size as a sheet of paper.
This extends to fonts too, since PostScript letters are drawn using the same graphic primitives as other graphs.
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...
- Is it necessary that the document should take the whole screen?
- Is it possible to render a PostScript document in different sizes and resolutions?
- Do any people today read PDFs on their screens? If some do, are all their screens the same size as a sheet of paper?
Anyway, that was not the spirit of my comment. I meant, doing design in HTML, CSS, SVG and then working out again, all from the beginning, how to convert the document to a printable version of professional quality, is more work than writing PostScript for both, even if some configuration necessarily differs between screen and print.
This Cedar demonstration video has some great examples of many of these issues. The Tioga text editor was "WYSIMOLWYG": what you see is more or less what you get.
https://www.youtube.com/watch?v=z_dt7NG38V4
Some problems were due to technology and aren't as bad any more. Cedar and NeWS used black-and-white screens and didn't have anti-aliased fonts. CPUs were much slower and memory was much tighter and graphics were not accelerated, so even with color displays (which were usually only 8 bits with a colormap that makes anti-aliasing very difficult), anti-aliased text wasn't practical.
And fonts rendered at screen resolutions have totally different measurements than high resolution printed fonts, so words have different widths and get flowed and wrapped differently, so the formatting is quite different.
NeWS had a "setprintermatch" primitive that makes the font rendering machinery use the official precise printer measurements for fonts, instead of the actual pixel screen measurements. That was useful for the PostScript previewer, and for editors previewing how formatted text will look. (There was a nice port of FrameMaker to NeWS, but I don't remember how its preview features worked.) But text rendered with printer metrics looks terrible and is hard to read, so you wouldn't want to actually edit text like that.
NeWS 1.1 manual, page 146:
http://www.bitsavers.org/pdf/sun/NeWS/NeWS_1.1_Manual_198801...
>setprintermatch: (boolean setprintermatch - ) Sets the current value of the printermatch flag in the graphics state to boolean. When printer matching is enabled text output to the display will be forced to match exactly text output to a printer. The metrics used by the printer will be imposed on the display fonts. This will usually cause displayed text to look bunched up and generally reduce readability. With printer matching disabled, readability will be maximized, but the character metrics for the display will correspond to the printer. See also: currentprintermatch
Windows are resizable, and while text is scalable, you still want to be able to read and edit text in narrow windows, and not waste screen space or get giant text in wide windows. So reflowing text differently for the screen while editing is very useful.
Also, rendering text in a wysiwyg previewer that precisely scales text is slow the first time and uses a lot of memory, because the particular point size of that font must be rendered into the cache, since it can't just round the point size to a whole number that may already be in the cache (like the scalable "jet" NeWS terminal emulator did to avoid blowing the cache). So it's better if the system renders all text in the same restricted set of point sizes, instead of scaling it continuously.
Also it's costly in terms of screen space to edit two columns of text at once, or pages at a time.
It's just ergonomically easier and wastes less screen space to edit formatted text in one continuous non-paginated column, resizable to any window width you want to use at the time, formatted as close as possible to how it will look on the printer, but without the exact same measurements.
And in this day and age, most text that people write is intended to be read in many different media, formats, screen and font sizes, and layouts. Now it's about WYSIWYG editing text and graphics in the way they will appear in a web browser, and those come in all shapes and sizes (thus Chrome Developer Tool's device preview mode).
Now printing text on paper is only a...
NeWS used a color cube with only a certain number of grays, and those were only useful for anti-aliasing black text against a white background (or the other way around), and you didn't have a lot of colors to choose from for antialiased color text or against colored backgrounds. It's much easier to render anti-aliased text in 24 bits, or with pure gray scale, since you aren't restricted to an 8 bit color palette, and you can efficiently mathematically blend colors together, instead of looking up rgb values in a colormap, blending to get the ideal desired color, and then searching for the nearest color to each pixel in the colormap (or indexing the color cube for the nearest color) (which won't be very near, and will look flat and washed out without dithering).
Better visually to render the whole image with antialiased text in full 24 bits, then use error diffusion dithering over the entire image at once (to avoid flat washed out regions, and distribute the error over space) to make an 8 bit palletized version, but that's quite slow and memory intensive.
Of course your application (like a monochrome PostScript previewer) could switch in an all-gray ramp colormap for efficiently rendering and beautifully displaying anti-aliased text, but then all the other windows on the screen would be shown in the wrong colormap, and the colormap would flash back and forth when you moved your focus between windows.
https://www.youtube.com/watch?v=z_dt7NG38V4
>Eric Bier Demonstrates Cedar. Computer History Museum, Recorded on January 24, 2019.
>This interpretive production was created from archival footage of Eric Bier, PARC research scientist, demonstrating the Cedar integrated environment and programming language on January 24, 2019. Cedar was an evolution of the Mesa environment/language, developed at PARC’s Computer Science Laboratory originally for the Xerox Alto. Mesa was modular and strongly-typed, and influenced the later Modula family of languages. Cedar/Mesa ran on the D-machine successors to the Alto (such as the Dorado) and added features including garbage collection, and was later ported to Sun workstations. Cedar/Mesa’s integrated environment featured a graphical window system and a text editor, Tioga, which could be used for both programming and document preparation, allowing for fonts, styles, and graphics to be embedded in code files. The editor and all its commands were also available everywhere, including on the command console and in text fields. The demo itself is running through a Mac laptop remotely logged into Bier’s Sun workstation at PARC using X Windows. Bier demonstrates the Cedar development environment, Tioga editor, editing commands using three mouse buttons, sophisticated text search features, the command line, and the Gargoyle graphics editor, which was developed as part of Bier’s UC Berkeley Ph.D. dissertation. Bier is joined by Nick Briggs, Chris Jacobi, and Paul McJones.
Here are some notes about that I took:
There were several window systems developed for Cedar: Warren Teitelman developed Docs. Lots of functionality, but slow. Scott McGregor developed Viewers. It was lean and fast, in response to Docs. Michael Plass built the Cedar imager.
The Experimental Programming Environment Research Project looked at different competing projects to decide which to standardize on. Cedar/Mesa came out of that and played a dominant role in the 80's. The Smalltalk people contributed ideas but were (not railroaded but) frustrated.
Cedar had a ubiquitous almost-wysiwyg structured text and code editor called Tioga. It was important in Cedar, because it's everywhere, even the text fields. The terminal window has a stripped down text editor with subset of commands.
Setting the so-called "clipping level" in Tioga (like a folding outliner) goes back to Englebart's NLS. Bill Paxton and Doug Wyatt were NLS people who also worked on Tioga.
Key ideas were applicable in any possible place in both systems. The Alto had small memory, and each program took over the entire system. It was not integrated. Simple little editors for code. Fancier editors for documents. Using the same component everywhere is something Smalltalk was pioneering even on the tiny Alto. When Cedar came along, running on a much bigger more powerful 1 megabyte D-Machines, it pulled together those ideas, and added so much more, including much more advanced graphics, way beyond what the Alto could do.
Tioga could display and edit formatted code with different levels of indentation and formatting. Tioga was not completely WYSIWYG. Print mode shows two columns, but you edit one column. You could get a pretty good idea of what it would look like, but in the early times it did not have smooth fonts. Bitmap fonts measure differently on the printer, so text is necessarily broken and flowed differently. The printer used Interpress, the predecessor of PostScript. You could preview Interpress files in Cedar. (The video shows a demo of both editing a document in Tioga, and previewing the Interpress file that it produced for t...
This was followed by a vision of a window system built on ROFF.
Hope something like that will never see the light of day.
And Doom. Definitely Doom.
https://hack.org/mc/mgr/
https://en.wikipedia.org/wiki/ManaGeR
>ManaGeR or MGR was an early windowing system originally designed and developed for Sun computers in 1984 by Stephen A. Uhler, then at Bellcore.
>MGR featured overlapped, asynchronous windows and an applications interface that was both machine and network independent.
>Each MGR window had support for both character terminal operations as well as basic graphics operations. It was controlled by mousing pop-up menus, by keyboard interaction, and by escape sequences written on pseudo-terminals by client software.
>The system was presented at the USENIX Fourth Computer Graphics Workshop in 1987 as "MGR - a Window System for UNIX".[1] The entire MGR source code was posted to the comp.sources.unix Usenet newsgroup, Volume 17, Issue 1, in January 1989.[2]
MGR was the largest posting to ever appear in comp.sources.unix:
https://groups.google.com/forum/#!topic/comp.sources.unix/GG...
Also Chris Torek, Mark Weiser and others developed "Maryland Windows" at the University of Maryland Computer Science Department, based on the Gosling Emacs screen redisplay code and terminal drivers. It was very good over slow modems because it used Emacs's intelligent redisplay algorithm aka "Ultra-hot screen management package" -- the one with the skull and crossbones.
https://www.donhopkins.com/home/code/display.c.txt
Maryland Windows source code:
http://cd.textfiles.com/sourcecode/unix_c/languags/c/mw.tar
https://groups.google.com/forum/#!msg/net.emacs/yXfZGeHJrNY/...
Of course now lots of people just use emacs with shell buffers as a windowing system, inside of something like screen or tmux.
There is an X window manager written entirely in elisp for GNU Emacs, EXWM, that was started in 2015:
https://github.com/ch11ng/exwm
I have been using it exclusively on my machines for the past three years. By far the best computing environment I have used.
In 2018 I stumbled on XWEM, an X window manager in elisp for XEmacs that was developed from 2003 to 2004:
http://www.nongnu.org/xwem/
Oh wait. That IS what we have today! Never mind.
https://en.wikipedia.org/wiki/DSSSL
"Sometime in or before 1994, Opera Software began drafting a "DSSSL Lite" specification for the consideration of the World Wide Web Consortium"
https://www.drdobbs.com/a-triumph-of-simplicity-james-clark-...
>A Triumph of Simplicity: James Clark on Markup Languages and XML
>By Eugene Eric Kim, July 01, 2001
>If you peek under the hood of high-profile open-source projects such as Mozilla, Apache, Perl, and Python, you'll find a little program called "expat" handling the XML parsing. If you've ever used the man command on your GNU/Linux distribution, then you've also used groff, the GNU version of the UNIX text formatting application, troff. If you've ever done any work with SGML, from generating documentation from DocBook to building your own SGML applications, you've undoubtedly come across sgmls, SP, and Jade.
>Whether you've heard of him or not (and mostly likely, you haven't), James Clark (below right) has made your life easier. In addition to authoring these and other widely used open-source tools (see http://www.jclark.com/ for a complete list), Clark served as the technical lead of the original W3C XML Working Group and as the editor of the XSLT and XPath recommendations. He recently founded Thai Open Source Software Center ( http://www.thaiopensource.com/ ). His latest project is TREX, an XML schema language. Clark sat down with Eugene Eric Kim to discuss markup languages, the standardization process, and the importance of simplicity.
https://news.ycombinator.com/item?id=16227249
>The mighty programmer James Clark wrote the de-facto reference SGML parser and DSSSL implementation, was technical lead of the XML working group, and also helped design and implement XSLT and XPath (not to mention expat, Trex / RELAX NG, etc)! It was totally flexible and incredibly powerful, but massively complicated, and you had to know scheme, which blew a lot of people's minds. But the major factor that killed SGML and DSSSL was the emergence of HTML, XML and XSLT, which were orders of magnitude simpler.
>James Clark: http://www.jclark.com/ https://en.wikipedia.org/wiki/James_Clark_(programmer)
>There's a wonderful DDJ interview with James Clark called "A Triumph of Simplicity: James Clark on Markup Languages and XML" where he explains how a standard has failed if everyone just uses the reference implementation, because the point of a standard is to be crisp and simple enough that many different implementations can interoperate perfectly.
>A Triumph of Simplicity: James Clark on Markup Languages and XML: http://www.drdobbs.com/a-triumph-of-simplicity-james-clark-o...
>I think it's safe to say that SGML and DSSSL fell short of that sought-after simplicity, and XML and XSLT were the answer to that.
>"The standard has to be sufficiently simple that it makes sense to have multiple implementations." -James Clark
https://news.ycombinator.com/item?id=20384206
>He's not that famous outside of hard core geek circles, but I am a huge fan of James Clark (not the SGI guy, but he's awesome too for different reasons), ...
Just think what could have been!
NeXT did that in 1988: https://en.wikipedia.org/wiki/Display_PostScript
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.
What if Sun had open sourced NeWS in the early 90s? Could NCSA or Netscape have used an open source NeWS to build a web browser that renders HTML using NeWS on X11 or Windows? With no need for JavaScript or CSS, just Postscript?
Don Hopkins? Is it plausible that we’ve had 25 years of JavaScript hell because Sun management didn’t open source NeWS? Or were there insurmountable technical obstacles as well?
https://en.wikipedia.org/wiki/LaserWriter#Hardware
>The LaserWriter used the same Canon CX printing engine as the HP LaserJet, and as a consequence early LaserWriters and LaserJets shared the same toner cartridges and paper trays. PostScript is a complete programming language that has to be run in a suitable interpreter and then sent to a software rasterizer program, all inside the printer. To support this, the LaserWriter featured a Motorola 68000 CPU running at 12 MHz, 512 kB of workspace RAM, and a 1 MB frame buffer.
>At introduction, the LaserWriter had the most processing power in Apple's product line—more than the 8 MHz Macintosh. As a result, the LaserWriter was also one of Apple's most expensive offerings. For implementation purposes, the LaserWriter employed a small number of medium-scale-integration Monolithic Memories PALs, and no custom LSI, whereas the LaserJet employed a large number small-scale-integration Texas Instruments 74-Series gates, and one custom LSI. The LaserWriter was, thereby, in the same form factor (for its RIP), able to provide much greater function, and, indeed, much greater performance, all within the very same LBP-CX form factor, although the external packaging was, for marketing purposes, somewhat different.
James Gosling fought very hard for NeWS, but in the end failed to convince Sun to do the right thing. He was optimistic when he talked me into going to Sun to work on NeWS after I'd already given up on it by 1990, saying that Sun had turned over a new leaf, and was soon going to announce their commitment to NeWS:
But in the end Sun redefined the meaning of the word "free" by announcing that OpenWindows source code was "Free for $1000": it cost $1000 for the tape media, and nobody was allowed to put it on an FTP server.Here is a link to my flamey-poo on that sensitive topic, followed by the official announcement to which I was reacting. I'll include some choice excerpts, and a couple more links on the topic.
https://www.donhopkins.com/home/archive/NeWS/flame.txt
>I have been following the messages on the network in the aftermath of the OWPS "free for $1000" disaster... The big problem was not the $1000. It was the word "free".
>In short: If you were a slave, what how would you feel if your master announced you could go "free", but he really meant he was selling you down the river for a media cost of only $1000?
>[...] For years, we (customers, software developers, and employees) have been asking Sun to make Open Windows available for free, in such a way that it could be distributed on the X11R4 tape or through other public channels, but that has not happened yet. Our biggest concern is not that we don't have to pay money!! The most important thing is that we can make changes to the source code, and g...
I still wish anything had the features of NeWS. I wish people could currently be able to feel freedom, power, expressiveness of such environments, where you could change the look and behavior of anything on your screen with a couple of lines typed in a REPL.
Even though the browser has been creeping every day towards it, it seems impossible to escape the constriction of it's haphazard evolution. Browsers have all the hard parts of a NeWS server already worked out inside them (but in C/C++ code), but even if you could magically transform it, it seems it would still be horribly constrained by many other layers of cruft.
After reading your "flamey-poo" I'm wondering how much other non-technical, meddlesome corporate baggage would have come along for a ride even if someone somehow could have convinced them to make "free" === "free".
If it was more than none, I have a hard time seeing how a strong enough "View Source" philosophy could have sprouted from it no matter how strong the tech was/is. From what I understand the web started with that philosophy, and it only partially made it out of the battle with copy/paste intact.
The fact that you were apparently already burned out once before this flame tells me that there was a lot of such baggage. Am I in the ball park here?
The hype and corporate bullshit that surrounded Java is a good example of what that corporate baggage would have been like if it had been deployed for NeWS's benefit instead of Java's.
If Sun had put as much energy into promoting and supporting NeWS as they did with Java, we would probably live in a very different world today.
Sun turned a corner when they abandoned their Berkeley hippie BSD roots and got into bed with AT&T / SVR4 / Solaris, and that changed a lot of stuff for the worse, making it a lot harder to do things like give away the source code to X11/NeWS. A lot of people from different companies who used to be Sun's enemies, and who had extremely different philosophies and antithetical approaches to "open software", joined Sun and started influencing and managing its policies and projects. A disastrous example was the Distributed Objects Everywhere project and CORBA fiasco, which was originally the crazy idea of a bunch of people from HP and DEC, Sun's former nemesis's, who then came to Sun and started pushing it into everything, to the detriment of NeWS and other older projects at Sun. Some of the problematic people and armchair architectural astronauts that Sun imported and put in charge of DOE/CORBA, like Steve MacKay and Michael Powell, were worthless corporate bullshitters whose main goals were to establish and maintain a hegemony, and they kept their grandiose plans in their head and never wrote anything down or made any hard decisions or came up with anything concrete, because they didn't want to be pinned down to committing to something, when they were actually in way over their heads. The whole point of the incredibly complex software they finally developed was interoperability with other company's compatible software, but in reality none of it actually worked together. It only talked to itself. SLOWLY.
Since DOE was intended to run everywhere and talk to everything but actually didn't, they should have called DOPE for Distributed Objects Practically Everywhere.
DOPE was a complete failure at its stated mission, and it had ridiculously costly overhead and complexity. When they finally delivered something years behind schedule and lacking crucial promised features, it actually required TWO CDROMs to install. (You'd think they could have distributed a distributed network object system over the network, instead of via CDROM, but nooooo: it was just too big to download.) And in the end, nobody actually used "DOE" or "NEO" for anything consequential. They wasted a spectacular amount of time, energy, money, careers, and good will on that crap.
https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere
https://www.javaworld.com/article/2077168/distributed-object...
And then when Java finally came along, the same meddlesome corporate baggage handlers and armchair architectural astronauts went into overdrive to evangelize and promote the Java Juggernaut. And even more of them flocked in droves to Sun to jump on the Java bandwagon. If it was bad after the invasion of System V / AT&T / HP / DEC minions, things got much worse once the Java zombies started arriving in teaming brain-eating hoards to get their part of the action in response to all the hype. The original Java team was brilliant, and there were some extremely excellent people working on it, but they were totally outnumbered by the dead weight of all the hangers-on who didn't want to work hard to make a struggling company great, but just wanted an easy job at a secure company that was already great...
Here's a handy guide to when to use open source:
Open source is a business tool, not necessarily an end (though it can be an end too).Not in Display PostScript, perhaps, but NeXT definitely had OOP pervasively; where do you think the modern Apple use of Objective-C came from?
That's why it was such a natural progression for Apple to switch from Display PostScript to Cocoa, which was the moral equivalent of PDF, which is just PostScript without the Turing-complete programming language part.
Incidentally, the nascent web looked horribly primitive when you already had fairly rich networked hypermedia and missed the significance of the web architecture.
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.
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)
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 toolk...
Swings and roundabouts
(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
Owen Densmore's discussion of John Warnock's "Linguistic Motherboard" idea for PostScript:
https://donhopkins.com/home/archive/NeWS/linguistic-motherbo...
======================================================================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:
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 fi...https://donhopkins.com/home/images/X11NeWSPorscheHitsSunSoft...
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
>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....
>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.
(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/ ) might finally start to reduce the churn and nail things down.)
( https://en.wikipedia.org/wiki/Delphi_%28IDE%29 )