5 ms·

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 s

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.

ramenbytes 3y ago
You're not alone. When someone asks "What OS do you prefer, Windows, Linux, or Mac?" my answer is: "none". Anyhow, back to dreaming. Someday maybe...
- 7thaccount 3y ago
  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.
  - gumby 3y ago
    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.
    - DonHopkins 3y ago
      Rumors of my Death, LLMification, and Enshittification are greatly exaggerated, Gumby! PS: about you comment below: The Novix NC4016 was FORTH coming. https://en.wikichip.org/wiki/novix/nc4016 https://en.wikichip.org/wiki/novix/nc4016 DonHopkins on Jan 20, 2022 | parent | context | favorite | on: Xerox PARC Mesa Programming Language 5.0 (1979) [p... Previous HN discussion about that video: https://news.ycombinator.com/item?id=22375449 https://news.ycombinator.com/item?id=22375449 Eric Bier Demonstrates Cedar: https://www.youtube.com/watch?v=z_dt7NG38V4 https://www.youtube.com/watch?v=z_dt7NG38V4 >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. [...] https://news.ycombinator.com/item?id=34056973 https://news.ycombinator.com/item?id=34056973 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. https://en.wikipedia.org/wiki/Mesa_(programming_language) https://en.wikipedia.org/wiki/Mesa_(programming_language) >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) https://news.ycombinator.com/item?id=22375449 https://news.ycombinator.com/item?id=22375449 Computer History Museum: Eric Bier Demonstrates Cedar https://www.youtube.com/watch?v=z_dt7NG38V4 https://www.youtube.com/watch?v=z_dt7NG38V4 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. https://news.ycombinator.com/item?id=22378457 https://news.ycombinator.com/item?id=22378457 I believe that stuff is the port of Cedar to the Sun. Xerox PARC developed "Portable Common Runtime", which was basically the Cedar operating system runtime, on top of SunOS (1987 era SunOS, not Solaris, so no shared libraries or threads, which PCR had to provide). He demonstrates compiling a "Hello World" Cedar shell command, and (magically behind the scenes) dynamically linking it into the running shell and invoking it. Experiences Creating a Portable Cedar. Russ Atkinson, Alan Demers, Carl Hauser, Christian Jacobi, Peter Kessler, and Mark Weiser. CSL-89-8 June 1989 [P89-00DD6] http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-8_Experiences_Creating_a_Portable_Cedar.pdf http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-8... >Abstract: Cedar is the name for both a language and an environment in use in the Computer Science Laboratory at Xerox PARC since 1980. The Cedar language is a superset of Mesa, the major additions being garbage collection and runtime types. Neither the language nor the environment was originally intended to be portable, and for many years ran only on D-machines at PARC and a few other locations in Xerox. We recently re-implemented the language to make it portable across many different architectures. Our strategy was, first, to use machine dependent C code as an intermediate language, second, to create a language-independent layer known as the Portable Common Runtime, and third, to write a relatively large amount of Cedar-specific runtime code in a subset of Cedar itself. By treating C as an intermediate code we are able to achieve reasonably fast compilation, very good eventual machine code, and all with relatively small programmer effort. Because Cedar is a much richer language than C, there were numerous issues to resolve in performing an efficient translation and in providing reasonable debugging. These strategies will be of use to many other porters of high-level languages who may wish to use C as an assembler language without giving up either ease of debugging or high performance. We present a brief description of the Cedar language, our portability strategy for the compiler and runtime, our manner of making connections to other languages and the Unix operating system, and some measures of the performance of our "Portable Cedar". PCR implemented threads in user space as virtual lightweight processes on SunOS by running several heavy weight Unix processes memory mapping the same main memory. And it also supported garbage collection. Mark Weiser worked on both PCR and the Boehm–Demers–Weiser garbage collector. https://en.wikipedia.org/wiki/Boehm_garbage_collector https://en.wikipedia.org/wiki/Boehm_garbage_collector This is the 1988 "Garbage Collection in an Uncooperative Environment" paper by Hans-Juergen Boehm and Mark Weiser: https://hboehm.info/spe_gc_paper/preprint.pdf https://hboehm.info/spe_gc_paper/preprint.pdf >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. http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-84-7_On_Adding_Garbage_Collection_and_Runtime_Types_to_a_Strongly-Typed_Statically-Checked_Concurrent_Language.pdf http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-84-7... 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! https://news.ycombinator.com/item?id=24450970 https://news.ycombinator.com/item?id=24450970 Xerox Cedar “Viewers Window Package” (2018) (toastytech.com) http://toastytech.com/guis/cedar.html http://toastytech.com/guis/cedar.html gumby on Sept 13, 2020 | next [–] 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. https://youtu.be/z_dt7NG38V4 https://youtu.be/z_dt7NG38V4 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 http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-83-11_The_Cedar_Programming_Environment_A_Midterm_Report_and_Examination.pdf http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-83-1... C - Cedar/Mesa Interoperability http://www.bitsavers.org/pdf/xerox/parc/cedar/C_-_Cedar_Mesa_Interoperability_Aug1992.pdf http://www.bitsavers.org/pdf/xerox/parc/cedar/C_-_Cedar_Mesa... Describes Portable Common Runtime (PCR), and the PostScript and Interpress decomposers implemented in Cedar, and includes many other interesting document about Cedar.
- deleted 3y ago
  [deleted]
linguae 3y ago
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.
- yosoyubik 3y ago
  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." - [1] https://media.urbit.org/whitepaper.pdf https://media.urbit.org/whitepaper.pdf - [2] "Solid-State Interpreter"
  - retrocryptid 3y ago
    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.
pjmlp 3y ago
We almost had it in OS/2, I guess many aren't aware that Smalltalk was kind of ".NET for OS/2" during its heyday. Hence why it is a first party on SOM (OS/2 COM version), and SOM does support metaclasses. But then OS/2 went as we all know, and with IBM's backing of Java, Visual Age products turned into Eclipse. http://www.edm2.com/index.php/VisualAge_Smalltalk http://www.edm2.com/index.php/VisualAge_Smalltalk https://en.wikipedia.org/wiki/IBM_System_Object_Model https://en.wikipedia.org/wiki/IBM_System_Object_Model
- dharmatech 3y ago
  Always a pleasure to see your comments in hn threads, pjmlp. Happy Thanksgiving.
  - pjmlp 3y ago
    Thanks, likewise.
- dharmatech 3y ago
  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.
  - DonHopkins 3y ago
    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. Q: What do you get when you cross Apple and IBM? A: IBM! https://en.wikipedia.org/wiki/SK8_(programming_language) https://en.wikipedia.org/wiki/SK8_(programming_language) >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. [...] The SK8 Multimedia Authoring Environment: https://sk8.dreamhosters.com/sk8site/sk8.html https://sk8.dreamhosters.com/sk8site/sk8.html What is SK8? 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. [...] Sk8 Users Guide: https://macintoshgarden.org/sites/macintoshgarden.org/files/manuals/SK8_0.9_User_Guide.pdf https://macintoshgarden.org/sites/macintoshgarden.org/files/... https://news.ycombinator.com/item?id=21846706 https://news.ycombinator.com/item?id=21846706 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.
uticus 3y ago
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. (I see one great thread talking about downsides of image-based(as in, Smalltalk image) on related @ https://news.ycombinator.com/item?id=34300806#34302095 https://news.ycombinator.com/item?id=34300806#34302095)
agumonkey 3y ago
two things come to mind: - 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 ?

ramenbytes 3y ago

You're not alone. When someone asks "What OS do you prefer, Windows, Linux, or Mac?" my answer is: "none". Anyhow, back to dreaming. Someday maybe...

7thaccount 3y ago
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.
- gumby 3y ago
  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.
  - DonHopkins 3y ago
    Rumors of my Death, LLMification, and Enshittification are greatly exaggerated, Gumby! PS: about you comment below: The Novix NC4016 was FORTH coming. https://en.wikichip.org/wiki/novix/nc4016 https://en.wikichip.org/wiki/novix/nc4016 DonHopkins on Jan 20, 2022 | parent | context | favorite | on: Xerox PARC Mesa Programming Language 5.0 (1979) [p... Previous HN discussion about that video: https://news.ycombinator.com/item?id=22375449 https://news.ycombinator.com/item?id=22375449 Eric Bier Demonstrates Cedar: https://www.youtube.com/watch?v=z_dt7NG38V4 https://www.youtube.com/watch?v=z_dt7NG38V4 >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. [...] https://news.ycombinator.com/item?id=34056973 https://news.ycombinator.com/item?id=34056973 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. https://en.wikipedia.org/wiki/Mesa_(programming_language) https://en.wikipedia.org/wiki/Mesa_(programming_language) >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) https://news.ycombinator.com/item?id=22375449 https://news.ycombinator.com/item?id=22375449 Computer History Museum: Eric Bier Demonstrates Cedar https://www.youtube.com/watch?v=z_dt7NG38V4 https://www.youtube.com/watch?v=z_dt7NG38V4 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. https://news.ycombinator.com/item?id=22378457 https://news.ycombinator.com/item?id=22378457 I believe that stuff is the port of Cedar to the Sun. Xerox PARC developed "Portable Common Runtime", which was basically the Cedar operating system runtime, on top of SunOS (1987 era SunOS, not Solaris, so no shared libraries or threads, which PCR had to provide). He demonstrates compiling a "Hello World" Cedar shell command, and (magically behind the scenes) dynamically linking it into the running shell and invoking it. Experiences Creating a Portable Cedar. Russ Atkinson, Alan Demers, Carl Hauser, Christian Jacobi, Peter Kessler, and Mark Weiser. CSL-89-8 June 1989 [P89-00DD6] http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-8_Experiences_Creating_a_Portable_Cedar.pdf http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-8... >Abstract: Cedar is the name for both a language and an environment in use in the Computer Science Laboratory at Xerox PARC since 1980. The Cedar language is a superset of Mesa, the major additions being garbage collection and runtime types. Neither the language nor the environment was originally intended to be portable, and for many years ran only on D-machines at PARC and a few other locations in Xerox. We recently re-implemented the language to make it portable across many different architectures. Our strategy was, first, to use machine dependent C code as an intermediate language, second, to create a language-independent layer known as the Portable Common Runtime, and third, to write a relatively large amount of Cedar-specific runtime code in a subset of Cedar itself. By treating C as an intermediate code we are able to achieve reasonably fast compilation, very good eventual machine code, and all with relatively small programmer effort. Because Cedar is a much richer language than C, there were numerous issues to resolve in performing an efficient translation and in providing reasonable debugging. These strategies will be of use to many other porters of high-level languages who may wish to use C as an assembler language without giving up either ease of debugging or high performance. We present a brief description of the Cedar language, our portability strategy for the compiler and runtime, our manner of making connections to other languages and the Unix operating system, and some measures of the performance of our "Portable Cedar". PCR implemented threads in user space as virtual lightweight processes on SunOS by running several heavy weight Unix processes memory mapping the same main memory. And it also supported garbage collection. Mark Weiser worked on both PCR and the Boehm–Demers–Weiser garbage collector. https://en.wikipedia.org/wiki/Boehm_garbage_collector https://en.wikipedia.org/wiki/Boehm_garbage_collector This is the 1988 "Garbage Collection in an Uncooperative Environment" paper by Hans-Juergen Boehm and Mark Weiser: https://hboehm.info/spe_gc_paper/preprint.pdf https://hboehm.info/spe_gc_paper/preprint.pdf >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. http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-84-7_On_Adding_Garbage_Collection_and_Runtime_Types_to_a_Strongly-Typed_Statically-Checked_Concurrent_Language.pdf http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-84-7... 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! https://news.ycombinator.com/item?id=24450970 https://news.ycombinator.com/item?id=24450970 Xerox Cedar “Viewers Window Package” (2018) (toastytech.com) http://toastytech.com/guis/cedar.html http://toastytech.com/guis/cedar.html gumby on Sept 13, 2020 | next [–] 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. https://youtu.be/z_dt7NG38V4 https://youtu.be/z_dt7NG38V4 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 http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-83-11_The_Cedar_Programming_Environment_A_Midterm_Report_and_Examination.pdf http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-83-1... C - Cedar/Mesa Interoperability http://www.bitsavers.org/pdf/xerox/parc/cedar/C_-_Cedar_Mesa_Interoperability_Aug1992.pdf http://www.bitsavers.org/pdf/xerox/parc/cedar/C_-_Cedar_Mesa... Describes Portable Common Runtime (PCR), and the PostScript and Interpress decomposers implemented in Cedar, and includes many other interesting document about Cedar.
deleted 3y ago
[deleted]

linguae 3y ago

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.

yosoyubik 3y ago
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." - [1] https://media.urbit.org/whitepaper.pdf https://media.urbit.org/whitepaper.pdf - [2] "Solid-State Interpreter"
- retrocryptid 3y ago
  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.

pjmlp 3y ago

We almost had it in OS/2, I guess many aren't aware that Smalltalk was kind of ".NET for OS/2" during its heyday. Hence why it is a first party on SOM (OS/2 COM version), and SOM does support metaclasses. But then OS/2 went as we all know, and with IBM's backing of Java, Visual Age products turned into Eclipse. http://www.edm2.com/index.php/VisualAge_Smalltalk http://www.edm2.com/index.php/VisualAge_Smalltalk https://en.wikipedia.org/wiki/IBM_System_Object_Model https://en.wikipedia.org/wiki/IBM_System_Object_Model

dharmatech 3y ago
Always a pleasure to see your comments in hn threads, pjmlp. Happy Thanksgiving.
- pjmlp 3y ago
  Thanks, likewise.
dharmatech 3y ago
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.
- DonHopkins 3y ago
  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. Q: What do you get when you cross Apple and IBM? A: IBM! https://en.wikipedia.org/wiki/SK8_(programming_language) https://en.wikipedia.org/wiki/SK8_(programming_language) >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. [...] The SK8 Multimedia Authoring Environment: https://sk8.dreamhosters.com/sk8site/sk8.html https://sk8.dreamhosters.com/sk8site/sk8.html What is SK8? 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. [...] Sk8 Users Guide: https://macintoshgarden.org/sites/macintoshgarden.org/files/manuals/SK8_0.9_User_Guide.pdf https://macintoshgarden.org/sites/macintoshgarden.org/files/... https://news.ycombinator.com/item?id=21846706 https://news.ycombinator.com/item?id=21846706 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.

uticus 3y ago

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. (I see one great thread talking about downsides of image-based(as in, Smalltalk image) on related @ https://news.ycombinator.com/item?id=34300806#34302095 https://news.ycombinator.com/item?id=34300806#34302095)

agumonkey 3y ago

two things come to mind: - 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 ?