Owen Densmore (who implemented the PostScript "object.ps" Smalltalk-like object oriented programming system for NeWS, and worked at Apple on the LaserWriter and PostScript printing system), and David Rosenthal (who developed NeWS with James Gosling, and one of the original employees of NVIDIA), patented a way to implement Smalltalk's (and NeWS's) object oriented programming system in the shell:
Method for apparatus for implementing a class hierarchy of objects in a hierarchical file system
Abstract
A method and apparatus for implementing a class hierarchy of objects in a hierarchical file system is disclosed, which does not require the support of additional file attributes by the hierarchical file system, and has particular application to object oriented programming in window-based computer systems. The class hierarchy comprises a root class, a plurality of classes and a plurality of class instances. The root class is implemented with a hierarchy of root class directory and root class files. Each class is implemented with a hierarchy of class directories and class files comprising the class methods, and the initial values of the class instance variables. Each class instance is implemented with a hierarchy of class instance directory and class instance files comprising the class instance variables. Each hierarchy of directories and files also comprises a path file. The content of these path files are logically related to each other, based on their class' relationships. By controlling the invocation of class methods, using these path files, inheritance is achieved. By accessing the class instance variables through the class methods, data abstraction is also achieved. Additionally, the method and apparatus also supports the pseudo class instance/class "Self" and " Super" when invoking another class method by a class method.
"PostScript is a linguistic 'mother board', which has 'slots' for several 'cards'. The first card we built was a graphics card. We're considering other cards..."
— John Warnock (Adobe), as recounted by Owen Densmore to Don Hopkins
This document traces how the "linguistic motherboard" concept evolved from PostScript through NeWS to MOOLLM's CARD.yml — a 40-year thread connecting printers to LLMs.
[...]
Owen Densmore's Object-Oriented PostScript (1986)
At Sun, Owen invented the OOP system that made NeWS truly powerful. He realized that PostScript's dictionary stack could implement Smalltalk-style classes:
Push a class dictionary onto the stack
Method lookup walks the stack (multiple inheritance)
Instance dictionaries hold per-object state
See: "Object Oriented Programming in NeWS" (Owen Densmore, 1986)
Tom Stambaugh helped Owen see how to adapt Smalltalk patterns:
"Owen and I discussed his 'crazy' idea at a poolside table at the now-demolished Hyatt Palo Alto, on El Camino. I told him that it made sense to me, we scribbled furiously on napkins, and I helped him see how he might adopt some learnings from Smalltalk."
Filesystem as Object Hierarchy (1993)
Owen Densmore and David S. H. Rosenthal (both NeWS authors) patented a method to implement object-oriented class hierarchies directly in a hierarchical file system:
US Patent 5187786A: "Method and apparatus for implementing a class hierarchy of objects in a hierarchical file system"
Directories as class and instance containers
Path files coordinate inheritance and method lookup
Shell path as dictionary stack (!)
No new file attributes required
This formalized the NeWS/Smalltalk OOP patterns into filesystem semantics — shell scripts with OOP inheritance.
The insight: Directories are objects. Files are interfaces. The filesystem IS the object graph.
The deeper insight: Every directory is an agent. Every file is an agent. Every YAML section can be an agent. Agents all the way down. See `ARCHITECTURE.md` → "The Universal Foundation".
>He worked with James Gosling on Andrew at CMU and NeWS at Sun, and on X10 as well as X11 and ICCCM, and he implemented the original X10 compatibility layer that was in NeWS 1.0, before X11 was a "thing".
>Only the diehards want to develop applications using basic window system facilities. The preferred approach is a higher-level “toolkit” of user interface components, such as menus and scroll bars. Experience with current toolkits shows the need for an object-oriented interface to these components. NeWS, the Network/extensible Window System, allows user interface components to be programmed in PostScript. Fortunately, object-oriented interfaces are natural in PostScript, and they have been used to create a toolkit with some novel properties. Among these are the use of concurrent processing and run-time inheritance of component methods. “Postscript is the future of words on paper.” Arthur C. Clarke
>One of the great things about NeWS was that it was programmed in PostScript. We had figured out how to make PostScript object-oriented, homomorphic to SmallTalk. We organized objects in the window system in a class hierarchy with inheritance. This, for example, allowed Don Hopkins to implement pie menus for NeWS in such a way that any user could replace the traditional rectangular menus with pie menus. This was such fun that Owen Densmore and I used the same technique to implement object-oriented programming for the Unix shell.
Tom Stambaugh described how Smalltalk inspired Owen Densmore's PostScript object oriented system in NeWS.
A point he didn't mention is that PostScript is directly descendent from Interpress, which was developed at Xerox PARC and reincarnated as PostScript at Adobe by Chuck Geschke and John Warnock:
It seems to me that Forth is to stacks what LispLanguage is to lists. Forth demonstrated the advantages of a stack-centric paradigm in which each pushed or popped item could be evaluated as an expression or a primitive. Postscript reflects the application of that paradigm to the world of typography, 2-d graphics, and page layout. My own recollection is that Postscript's primary contribution was the use of splines to describe character glyphs, allowing them to be effectively rendered at virtually any resolution desired. If anything, Postscript owes more to TexLanguage and DonaldKnuth than to Forth. I view the stack-based language paradigm as a convenient afterthought rather than a central organizing principle.
I also think we should note the contribution that OwenDensmore, at Sun, made in demonstrating how to use Postscript dictionaries to create a dynamically-bound object-oriented runtime environment. This was the fundamental premise of the Sun window server that ultimately became the NetworkExtensibleWindowSystem. Owen and I discussed his "crazy" idea at a poolside table at the now-demolished Hyatt Palo Alto, on El Camino. I told him that it made sense to me, we scribbled furiously on napkins, and I helped him see how he might adopt some learnings from Smalltalk. It was one of those afternoons that could only have happened at that time in that place in that culture. -- TomStambaugh
Primary Source: Brian Reid's 1985 "laser-lovers" Post
This document preserves the definitive first-person account of PostScript's origins, written by Brian Reid on March 2, 1985 — just 11 months after Adobe shipped its first PostScript manual.
I used to leave a file called README in my public ftp directory that just said:
README: no such file or directory
One glorious day somebody finally sent me email complaining that they could not read the README file. I advised them to use "emacs README" instead of using cat. I was sorely disappointed they never sent me back a thank you note for correctly suggesting that emacs was the solution to their problem. It was my finest moment in passive aggressive emacs evangelism.
>If you've ever asked the question: How do they make Crystal Pepsi clear? Here is your answer. The method is surprisingly simple and uses a technique to make a microemulsion where the droplet size of the flavour oil is around 1 micron. This method comes directly from Pepsi, via a patent they filed in 1989, providing a detailed method for producing oil-in-water microemulsions for beverages. The patent specifically discusses clear colas and methods for producing the same.
>This video is an introduction to creating microemulsions and provides a process for doing it at home with simple equipment and easily available ingredients.
Sure, worse may be better, but how do you know your code is worse unless you actually review it? You might accidentally let some good code slip into production, then your product isn't as better as it could be.
DonHopkins on Jan 16, 2020 | parent | context | favorite | on: Reverse engineering course
Will Wright defined the "Simulator Effect" as how game players imagine a simulation is vastly more detailed, deep, rich, and complex than it actually is: a magical misunderstanding that you shouldn’t talk them out of. He designs games to run on two computers at once: the electronic one on the player’s desk, running his shallow tame simulation, and the biological one in the player’s head, running their deep wild imagination.
"Reverse Over-Engineering" is a desirable outcome of the Simulator Effect: what game players (and game developers trying to clone the game) do when they use their imagination to extrapolate how a game works, and totally overestimate how much work and modeling the simulator is actually doing, because they filled in the gaps with their imagination and preconceptions and assumptions, instead of realizing how many simplifications and shortcuts and illusions it actually used.
>There's a name for what Wright calls "the simulator effect" in the video: apophenia. There's a good GDC video on YouTube where Tynan Sylvester (the creator of RimWorld) talks about using this effect in game design.
>Apophenia (/æpoʊˈfiːniə/) is the tendency to mistakenly perceive connections and meaning between unrelated things. The term (German: Apophänie) was coined by psychiatrist Klaus Conrad in his 1958 publication on the beginning stages of schizophrenia. He defined it as "unmotivated seeing of connections [accompanied by] a specific feeling of abnormal meaningfulness". He described the early stages of delusional thought as self-referential, over-interpretations of actual sensory perceptions, as opposed to hallucinations.
RimWorld: Contrarian, Ridiculous, and Impossible Game Design Methods
>Tip 5: On world building. As you know by now, Will's approach to creating games is all about building a coherent and compelling player experience. His games are comprised of layered systems that engage players creatively, and lead to personalized, some times unexpected outcomes. In these types of games, players will often assume that the underlying system is smarter than it actually is. This happens because there's a strong mental model in place, guiding the game design, and enhancing the player's ability to imagine a coherent context that explains all the myriad details and dynamics happening within that game experience.
>Now let's apply this to your project: What mental model are you building, and what story are you causing to unfold between your player's ears? And how does the feature set in your game or product support that story? Once you start approaching your product design that way, you'll be set up to get your customers to buy into the microworld that you're building, and start to imagine that it's richer and more detailed than it actually is.
It's almost impossible to get root beer syrup or extract in the Netherlands, but I found the solution (ha ha) in Darcy O'Neil's "Art of Drink" videos. He wrote a book about soda fountain history, "Fix the Pumps: The History of the American Soda Fountain" (which malfist recommended in the sibling comment), and he gets into the science and history and culture behind drink flavoring.
First of all you need to make quality carbonated water (de-aerate water by boiling it, carbonate it when ice cold, use heavy cold glasses, don't use ice):
Carbonating Water: The 2 Most Important Things To Do
>Making root beer is really quite simple and anyone can do it in about 20 minutes. The core flavour is wintergreen oil and then there are additional complementary flavours that give the root beer its character.
He has several videos about formulating cola and many other flavors too:
>Cocaine, or at least the aroma compounds in coca-leaf is an important flavour component of Coca-Cola today and possibly other colas, historically. So the question you might ask is "what does cocaine smell like?" And here is the answer. If you've ever thought about making your own version of Coca-Cola and thought something was missing, this might be that piece to the puzzle.
You use the same stuff they train drug sniffing dogs with (methyl benzoate and methyl cinnamate). Also there's another ingredient, truxilic acid, that's extremely hard to get, and is much more expensive ($300/gram) than real cocaine.
The bit about dogs just gives me nightmares. I picture a few puffs of the dust from that dispersing in my kitchen during that experiment, and then every item then in the vicinity becoming a beacon for drug dogs for the rest of my life :D
The Stepan company in New Jersey is the only entity legally allowed to import coca leaves (aside from the DEA, ICE, the FBI and a few others that buy and sell all the time) and extract the illegal methyl benzoyl ecgonine (C17H21NO4) leaving the flavor compounds. Query whether they would sell the de-cocainized product to a soft drink hobbyist.
Friends in Colombia report that Sek Cola sold there has the ecgonine ingredient. Not sure how close the recipe replicates the original Atlanta beverage.
I often carbonate my tap water and drink it straight, and have never thought the taste was any different from commercial seltzers. Then again, my tap water is just as good as or better than commercial bottled water, likely because it is mostly from mountain spring and snow melt, that travels down rocky high-flow streams.
There's a Nile Red video where Nigel carbonated water with carbon from diamonds, and when he tasted it, he complained that it tasted like his local tap water, which wasn't very good.
A modern computer makes billions of calculations per second. The calculations have a "forward direction". For example, if the result of x + y is 4, you cannot "compute backwards" and find out what x and y are equal to.
But calculations can be reversible. For instance one could say that x is 3, and then have enough information to run the calculation backwards. This is particularly interesting because physics dictates that computers based on reversible calculations use less energy than ones based on non-reversible calculations.
Lecturer: Postdoc Holger Bock Axelsen from the Department of Computer Science, University of Copenhagen
reply