My company bought me a Xerox 1108 Lisp Machine running Interlisp D in 1982. I write a commercial product for that environment that we sold for $5K, and it was a lot of fun. I run the latest Medley releases occasionally just for nostalgia. For present day hacking enjoyment I go with SBCL Common Lisp+Emacs, or Racket, or Python when I need the ecosystem.
Xerox really did a great job creating their Lisp Machines, a joy to develop on.
I often fantasize about a world where lisp or smalltalk machines took off instead of the Windows/Linux we have now. I know things weren't perfect, but it just seems like such a cool system and that we've evolved in a much less powerful direction.
In 2000, I worked for a company that had been acquired by IBM. When I discovered that I had access to things like VisualAge, APL, OS/2 I had a blast downloading and exploring these.
You're right; there was a pretty good vision for the future within IBM back then. It just didn't catch on.
When I worked at Kaleida (a joint venture of IBM and Apple), I had the wonderful opportunity to play around with Sk8, which was amazing! It was kind of like Dyland and ScriptX, in that it was an object oriented dialect of Lisp/Scheme with a traditional infix expression syntax. But it also had wonderful graphics and multimedia support, and cool weird shaped windows, and you could point at and explore and edit anything on the screen, a lot like HyperCard.
>SK8 (pronounced "skate") was a multimedia authoring environment developed in Apple's Advanced Technology Group from 1988 until 1997. It was described as "HyperCard on steroids",[1] combining a version of HyperCard's HyperTalk programming language with a modern object-oriented application platform. The project's goal was to allow creative designers to create complex, stand-alone applications. The main components of SK8 included the object system, the programming language, the graphics and components libraries, and the Project Builder, an integrated development environment.
SK8 (pronounced "skate") is a multimedia authoring environment developed in Apple's Research Laboratories. Since 1990, SK8 has been a testbed for advanced research into authoring tools and their use, as well as a tool to prototype new ideas and products. The goal of SK8 has been to enable productivity gains for software developers by reducing implementation time, facilitating rapid prototyping, supporting cross platform development and providing output to multiple runtime environments including Java. SK8 can be used to create rich media tools and titles simply and quickly. It features a fully dynamic prototype-based object system, an English-like scripting language, a general containment- and renderer-based graphic system, and a full-featured development interface. SK8 was developed using Digitool's Macintosh Common Lisp.
mikelevins on Dec 20, 2019 | parent | context | favorite | on: Interface Builder's Alternative Lisp Timeline (201...
Dylan (originally called Ralph) was basically Scheme plus a subset of CLOS. It also had some features meant to make it easier to generate small, fast artifacts--for example, it had a module system, and separately-compiled libraries, and a concept of "sealing" by which you could promise the compiler that certain things in the library would not change at runtime, so that certain kinds of optimizations could safely be performed.
Lisp and Smalltalk were indeed used by a bunch of people at Apple at that time, mostly in the Advanced Technology Group. In fact, the reason Dylan existed was that ATG was looking for a Lisp-like or Smalltalk-like language they could use for prototyping. There was a perception that anything produced by ATG would probably have to be rewritten from scratch in C, and that created a barrier to adoption. ATG wanted to be able to produce artifacts that the rest of the company would be comfortable shipping in products, without giving up the advantages of Lisp and Smalltalk. Dylan was designed to those requirements.
It was designed by Apple Cambridge, which was populated by programmers from Coral Software. Coral had created Coral Common Lisp, which later became Macintosh Common Lisp, and, still later, evolved into Clozure Common Lisp. Coral Lisp was very small for a Common Lisp implementation and fast. It had great support for the Mac Toolbox, all of which undoubtedly influenced Apple's decision to buy Coral.
Newton used the new language to write the initial OS for its novel mobile computer platform, but John Scully told them to knock it off and rewrite it in C++. There's all sorts of gossipy stuff about that sequence of events, but I don't know enough facts to tell those stories. The switch to C++ wasn't because Dylan software couldn't run in 640K, though; it ran fine. I had it running on Newton hardware every day for a couple of years.
Alan Kay was around Apple then, and seemed to be interested in pretty much everything.
Larry Tesler was in charge of the Newton group when I joined. After Scully told Larry to make the Newton team rewrite their OS in C++, Larry asked me and a couple of other Lisp hackers to "see what we could do" with Dylan on the Newton. We wrote an OS. It worked pretty well, but Apple was always going to ship the C++ OS that Scully ordered.
Larry joined our team as a programmer for the first six weeks. I found him great to work with. He had a six-week sabbatical coming when Scully ordered the rewrite, so Larry took his sabbatical with us, writing code for our experimental Lisp OS.
Apple built a bunch of other interesting stuff in Lisp, including SK8. SK8 was a radical application builder that has been described as "HyperCard on Steroids". It was much more flexible and powerful than either HyperCard or Interface Builder, but Apple never figured out what to do with it. Heck, Apple couldn't figure out what to do with HyperCard, either.
Powershell is great, but it'd really benefit from a GUI DSL for building UIs and charting data (dotnet is a lot of effort), increased speed (it's pretty slow) and libraries like pandas for data analysis and something like the GNU scientific library available. If those things were all built-in to Powershell/Windows, we'd have something pretty cool and unique, which is the ability to quickly and easily build little apps that don't require installs or anything like that. Just copy your script over for your buddy.
As is the theme in this thread, there's just so much I'd expect Windows to do that it simply can't do. Powershell is basically designed for Devops and not just normal business users unfortunately. It could be so much more.
I feel the exact same way. I’m grateful for modern computers and what they can do, but I think the substrates of Lisp and Smalltalk machines make building flexible component-based software easier than the Linux, Windows, and Web ecosystems we have today. If I had the spare time, I’d work on a modern-day OS inspired by the Lisp and Smalltalk environments of old.
If I had the time and the money, I’d like to pick up where Xerox PARC left off when they stopped working on Smalltalk, Cedar, Mesa, and similar projects. I’m also very fascinated by Apple projects of the 1990s such as SK8, Dylan, and the original proposal for a Lisp-based Newton. During the “interregnum” years at Apple many people with interesting ideas on system design and usability worked at Apple, such as Don Norman and Larry Tesler. I’m grateful for Steve Jobs’ return and for NeXT-based macOS, but unfortunately as time passed by, the Smalltalk, Lisp, and even NeXT influences at Apple faded away. It would be cool if somebody continued this vision. I’d do it in a heartbeat if I had the time and the financial resources.
You might want to check out Urbit: urbit.org. The whitepaper[1] is a bit outdated but in section 12 "Inadequate summary of related work" you can see some of its influences:
"Many historical OSes and interpreters have approached the SSI[2] ideal,
but fail on persistence, determinism, or both. In the OS department,
the classic single-level store is the IBM AS/400 [18]. NewtonOS [19]
was a shipping product with language-level persistence. Many image oriented interpreters (e.g., Lisps [20] and Smalltalks) are also SSI-ish,
but usually not transactional or deterministic. And of course, many
databases are transactional and deterministic, but their lifecycle function is not a general-purpose interpreter."
Urbit is mostly marketing fluff for extracting money from investors and potential users. It is based on a for-profit commodity and ecosystem (their stars and ships and planets and all that stuff) that you have to buy into to use it. You cannot just "run your own urbit".
Sadly, Urbit is forever tarred by one of its contributors. I'm not saying it's not worth investigating. It is. But why put your energies in a software project which already has a cultural strike against it? It's sort of like maintaining RieserFS: technically interesting but upsetting the social nature of programming humans.
Well. Rieser tried to keep his professional and criminal lives separate. RieserFS wasn't an expression of his revolutionary worldview.
And I was going to point out that Java survived Patrick McNaughton, FOSS survived ESR, etc.
From the whitepaper, Urbit looks bitchin. I love its audacity. In that way, reminds me of Linda (tuplespaces), Xanadu, Jef Raskin's Humane Interfaces (Canon Cat), and others.
Alas. It appears Urbit and its creator's worldview are inseparable.
I'll wait for the reboot. Or maybe just glean some of its ideas.
That's a good way to put it. I don't want an OS in the common way of thinking of one. I want something a lot closer to the Xerox Alto, but maybe more with a command oriented language.
Did you program the Alto? It didn’t really have an OS — each app took over, like on a PC or Apple II.
You might be thinking of the Alto’s descendants, the D-Machines, like the Dandilion (Star) or the research machines the Dolphin and the ECL Dorado. Those machines ran complete environments on the bare iron (Smaltalk, Interlisp-D, and Cedar/Mesa) but those environments included full O/Ses.
The Smalltalk environment did initially run on the Alto, but Interlisp never did — too demanding.
>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.
DonHopkins 11 months ago | parent | context | favorite | on: Ten influential programming languages (2020)
You know what's a lot like Ada in a good way is Mesa, which evolved into Ceder, from Xerox PARC. I know people who really loved programming in it. They'd call it "Industrial Strength Pascal". It was a successful experiment in code reuse. A strongly typed language with strong separation between interfaces and implementations, which encouraged creating robust, hardened code.
>Mesa and Cedar had a major influence on the design of other important languages, such as Modula-2 and Java, and was an important vehicle for the development and dissemination of the fundamentals of GUIs, networked environments, and the other advances Xerox contributed to the field of computer science.
Demonstration of the Xerox PARC Cedar integrated environment (2019) [video] (youtube.com)
Mark Weiser and others at Xerox PARC's ported the Cedar environment to Unix, which resulted in the development of the still-widely-used Boehm–Demers–Weiser conservative garbage collection.
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.
>Similarly, we treat any data inside the objects as potential pointers, to be followed if they, in turn, point to valid data objects. A similar approach, but restricted to procedure frames, was used in the Xerox Cedar programming environment [19].
[19] Rovner, Paul, ‘‘On Adding Garbage Collection and Runtime Types to a Strongly-Typed, Statically Checked, Concurrent Language’’, Report CSL-84-7, Xerox Palo Alto Research Center.
My guess is that the BDW garbage collector had its roots in PCR (pun intended, in fact this entire message was just an elaborate setup ;), but I don't know for sure the exact relationship between Cedar's garbage collector, PCR's garbage collector (which is specifically for Cedar code), and the Boehm–Demers–Weiser garbage collector (which is for general C code). Does anybody know how they influenced each other, shared code, or are otherwise related? Maybe there's a circular dependency!
This says “developed after the Star“ but imho the Dandelion (marketed as the star) was too slow for this environment and you needed one of the bigger machines (Dolphin or Dorado). Actually it’s kind of amazing to realize that two years later youncould get a small Mac for about a fifth the price that sat on your desk (not rolled next to it on casters) and was much more responsive. Did less, but what it did it did well, and was all that most people needed.
In addition to the Smalltalk and Mesa environments mentioned in the post, there was the Interlisp-D environment too, which got much more use outside thanks to being used outside PARC.
pjmlp on Sept 13, 2020 | parent | next [–]
The Computer History Museum organized a session with Eric Bier, and several other folks demoing the Mesa/Cedar environment.
The only modern environments that seem to have kept alive several of these ideas are Windows/.NET/COM, the ones designed by Apple/NeXT and to certain extent Android (although with a messed up execution).
Even Linux could grasp many of these ideas, if D-BUS would be properly taken advantage of and settled on a specific development experience.
Somehow it looks like we are still missing so much from Xerox PARC ideas.
----
The Cedar Programming Environment: A Midterm Report and Examination
Describes Portable Common Runtime (PCR), and the PostScript and Interpress decomposers implemented in Cedar, and includes many other interesting document about Cedar.
- good ideas too early don't grow, but they reemerge as genes for subsequent generations (closure, pattern matching, immutability etc are all back in fashion)
- there's a paradoxical idea of great pioneering ideas that die before becoming mainstream on their own but need future lesser vessels to shine anonymously. somehow the past was better but couldn't be.. how many other nice things were partially lost ?
At an emotional level I get this and can sympathize. But at a rational level... what would be shortcomings of a Lisp programming environment or Smalltalk image, versus Win/Mac/*nix?
Perhaps I had better specify: apart from software ecosystem support.
Beckman Instruments got our Xerox 1108 in 1983 (and an 1186 a couple of years later). We developed Expert System commercial products in Interlisp-D but ported them to run on the PC (DOS) using the Gold Hill Common Lisp.
That was a wonderful environment to develop on. So, I'm now working on the Medley Interlisp Project!
SpinPro™ designs optimal ultracentrifugation procedures (for biology research)
(Beckman manufactures and sells ultracentrifuge instruments.)
SpinPro had issues with marketing, with few customers.
PepPro™ designs chemical procedures to synthesize custom peptides (small proteins).
PepPro was essentially completed when Beckman Instruments dropped their entire Peptide Synthesis product line. (The PepPro user manual was in final review.)
I ported Charlie Forgy’s OPS5 to InterLisp-D and added a nice UI and a few utilities.
Most of my development work however was doing demos for specific potential clients. It was easy enough to put something tailored together, then a senior person would bring potential clients into my office and I would mostly talk with them while showing them their demo. So, not much practical. That was 40 years ago.
Xerox really did a great job creating their Lisp Machines, a joy to develop on.