The surface language was basically Scheme, with some special forms removed and others added or renamed. The type system was basically a simplified Common Lisp Object System; all values were instances of CLOS classes.
The compiler, runtime, and development environment were built on Macintosh Common Lisp. Ralph inherited MCL's design and aesthetics.
Like Common Lisp, it was designed for writing software by interacting with it and modifying it as it ran. That's the essential point.
The project I worked on, bauhaus, was running basically all the time we worked on it. We worked on it by interrogating and hot-modifying the running system, in the time-honored tradition of old-fashioned Lisp and Smalltalk systems.
Later Dylan was not like that. It evolved into just another batch-compiled application language. You edit some files. You batch-compile them. You run the resulting artifact for testing. Rinse and repeat.
That's how OpenDylan is today. That's why it lost me.
It's also what's wrong with some newer Lisps, from my point of view. They aren't designed for building programs by modifying them from inside while they run. They don't know how to handle existing data in the presence of redefined types. They don't provide interactive debuggers and inspectors that can be used to rummage through the memory of the running program, edit it while it runs, and conitnue execution.
Common Lisp provides these features, and has done for decades. Ralph provided them. Smalltalk does, too. If all the Common Lisp implementations in the world suddenly evaporated, I could get along fine with Smalltalk, after a brief period of adjustment. It's probably purely an accident of history that I'm a Lisper rather than a Smalltalker, anyway.
But Dylan doesn't have those essential features anymore, and nothing that lacks them is likely to win me over--not OpenDylan, not Julia, not Clojure or Haskell, or F#. I like all of those languages, but not nearly as much as I like my livecoding.
Later, Slava went to Apple to work on Swift, which turned out to be another mediocrity, lacking any sort of originality / vision and having a firm expiration date. There used to be a time when programming languages focused primarily on end-user empowerment and paradigm-centered computing was the norm (e.g. Seymour Papert's groundbreaking research in constructionism and incremental learning / development). There is precious little left of that now.
I don't know whether the others you mention are or not.
A reasonable litmus test is: define some data structure and make a bunch of instances of it. Now redefine the data structure. What happens to the existing instances? Does the runtime automatically notice that the structure definition has changed and offer you a way to update the existing instance to comply with the new definitions?
Another is to write a function that intentionally contains a call to some other nonexistent function, then call it. What happens when you hit the undefined function? Are you offered an interactive session that you can use to grovel around in the dynamic environment of the suspended function call? Can you see all the parameters and locals on the stack? Can you edit their values? Redefine types and pending functions? Can you supply the missing function definition, resume the suspended function call, and reasonably expect it to return a value as if the function in question had been defined all along?
If the answers are yes, then the language runtime is interactive "in the bones", in the sense I mean. If not, then not so much.
8th I have actually looked at and it's both _not_ particularly interactive (certainly nowhere near as interactive as Factor) and has a very strange license [1] to boot which makes it a total nop for me. It has been criticized before [2].
What is wrong with 8th's license? It is basically a Forth, so extremely interactive...mostly just messing with a stack...not sure about metaprogramming. I think a production license costs you $200 as a one time fee and you have to pay no royalties or anything for apps (better than many tools out there). Upgrading to a later version comes at a discount too. Most of the runtime is proprietary/closed-source if that is what you were saying (def understandable if you had a problem with that). Also, being a 1-developer project, progress is rapid, but I'd be worried about what happens if the maintainer wins the lottery.
Any language with a REPL can be described as "interactive" but that's not what having a strong focus on interactive development means. As Mikel Evins wrote, it's really about the entirety of a language being geared around interactive development.
I can't blame you for parsing it the other way; it's a more likely spelling. You can blame my eccentric father for the odd spelling of my first name, but he inherited the surname fair and square.
It's pronounced exactly the same way as "Michael Evans."
It's been a while, thanks for making it happen!
I 100% agree that it seems like you can't unwind the stack the same way you can in Common Lisp or Smalltalk though.
Later, as Dylan evolved away from its roots, it made sense to resurrect the old code name to distinguish the Lisp that we used to write a Newton OS from the later non-Lisp that it gradually evolved into.
People did know about it, though. One of the links in a sibling comment is to turbolent's little Lisp that compiles to Javascript, named Ralph in homage to the language I used every day back in the early nineties.
We used to keep known good images to work from. Generally a pristine release image, and a reference image with current project code preloaded, and then one or more working images with programmer-specific or task-specific code loaded. I used to save a working image at the end of the day and launch it again the next morning. MCL would remember my state right down to the positions and contents of my windows, so it was a quick and easy way to drop right back into the state of mind I was in at the end of the previous day.
For source code, we used revision control, exactly as you'd expect. In the Ralph days it was Apple's Projector. Nowadays most folks use git.
It's not super convenient to use revision control for dumped images because they're moderately large binaries. Source-control systems are mostly not great with those. So I keep reference images around, treating them like any other valuable binary asset--the difference being that rebuilding them from scratch is pretty fast and easy with today's fast machines.
My standard operating procedure is to start with a single scratch file that constructs a sketch of my naive idea of the data I'm going to be working with, load it, and start poking it to find out where I'm wrong.
As I begin to know what I'm doing, exploratory expressions turn into definitions of functions and data structures. I refactor them out into proper source files and add references to them into a system loader (like everybody else, I use ASDF for that).
Occasionally I might screw up the dynamic state by doing something dumb. Then I kill the session and restart it. The Lisps I use are generally back up and ready for me to continue in less than a second.
When I've made enough progress to want to build a release that I can distribute to testers, I write a builder file. The exact details of that depend on which Lisp I'm using; Lispworks, SBCL, and CCL each have their own idiosyncratic ways of going about it, but a simple build is generally something like a half dozen lines, and a complex one probably isn't much more than a page or so.
The builder file evolves along with the rest of the project.
The same general process applies to unit and integration tests. In fact, I'm pretty much always testing--testing my thoughts and testing what I just wrote is probably the majority of my activity most days. All I have to do to create formal unit and integration tests is make a testing scaffold and then harvest expressions from my scratch files and test comments to flesh it out.
When I release, I tag a commit in the source repo. I might also make a reference image to keep around locally, in case I want to test something against it or hand it to a collaborator.
I work in files a lot, which is typical of Lispers. Smalltalkers are a little more oriented to living in the image. For the most part, files are a serialization format that you use to exchange code and other resources with other sites. Locally, everything lives in your image. Modern Smalltalk systems have their own built-in interfaces to revision control, either to git or, in Squeak or Pharo, to a Smalltalk-specific revision-control system called Monticello.
This book describes an early version of Dylan that was very close to Ralph:
https://www.amazon.com/Dylan-Object-Oriented-Dynamic-Language/dp/B000KGC0HA
It used to be possible to find a copy of the book online, but I didn't turn up anything with a quick search.
I think Bauhaus sources still exist somewhere, but I don't know how you'd get them. I asked Apple about releasing them some years ago and they ignored the question.
A few years later I asked whether they were still in Apple's software library, and the person I asked--who, I would have thought, should know about it--didn't seem to have any idea what I was talking about. Maybe they ditched the software library.
Once upon a time there were videos of some of the demos that various folks did of pre-release Newton features. Maybe some of those still exist somewhere; I don't know.
Here's the link again for reference in context:
http://lispm.de/docs/prefix-dylan/book.annotated/
I should have known Rainer would have it.
Even better: he's also archived the design notes:
Ralph used prefix notation, dylan infix notation. Here you can find an implementation of ralph:(2)
From (2): Ralph is a Lisp-1 dialect that compiles to JavaScript. It is heavily inspired by an early version of Dylan (also known as "Prefix Dylan"), as described in Dylan – An object-oriented dynamic language.
Also (3) is about a Lisp to Dylan translator. There is also norvig lisp to dylan translator cited in (3).
(1) https://en.wikipedia.org/wiki/History_of_the_Dylan_programmi...
(2) https://github.com/turbolent/ralph
(3) https://tim.pritlove.org/2003/11/10/converting-lisp-to-dylan...
Ralph was named for Ralph Ellison, author of a different, later book Invisible Man, about being a black man in America.
Off topic, but many years ago I had lunch with Larry Tesler (John Koza was also there) and Larry knew of my CL book from the 1980s and pitched me to rewrite it in Dylan. That might have changed my career trajectory.
I liked and admired Larry. I considered him a friend. Once I sat with Steve Jobs in my office at NeXT and argued about Larry's virtues. I took the pro-Larry position.
Your lunch was probably around the time I was working on that Lisp OS at Apple. That was Larry's idea, too.
If you don't hear from me, it's not because I don't want to talk with you; it's because I'm forgetful (one reason I like email better than synchronous calls. Inboxes remember things that I forget.)
Knowledge Graph Navigator sort of intersects with some of my running interests--particularly knowledge representation and frame stores.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
To be expected, I suppose. It really was my favorite working language ever.
https://www.youtube.com/watch?v=HOuZyOKa91o
The video was made by a Ruby programmer, rather than an experience Smalltalker, so it's more a newbie showing you cool things he's discovered, rather than an expert showing the power of the system.
On the other hand, there's this one:
https://www.youtube.com/watch?v=o4-YnLpLgtk
That one is an expert, Kalman Reti, showing some of what it's like to work with a Symbolics Lisp Machine. (It's not a real Lisp machine; they're all at least thirty years old now; this is an emulator running the old Symbolics OS on Linux).
Go to YouTube and search for Rainer Joswig and you'll find a few video demos of Lisp Machines and MCL and so forth.
Finally, here are a few images from about eighteen years ago, also from Rainer. They show various views of the Macintosh Common Lisp and SK8 environments. It's not an experienced user showing you around, but at least you can get some idea what the environments looked like:
I'd probably use SBCL or CCL for everything, if Lispwork' CAPI or something equivalent worked on them. I do use them when I don't need to build a GUI that I can easily port among platforms.
When I wrote a WYSIWIG text editor years ago, I did it with CCL because it was for my own use, and I didn't need it to run on platforms other than macOS. If I wrote a new version of it, I'd try to find a way to make it work across Windows and Linux, as well. (I can't use Lispworks for that because it's violates their license restrictions on distributing something that can be used as a Lisp development environment.)
I use other languages when I'm paid to, or when I want to do something that is a lot easier to do in another language. For example, I recently wrote a prototype of a web-based collaborative editor and publishing platform for shared documents. I chose Couchbase for storage, because it solves the sync problem reasonably well, and I used Clojure and Clojurescript with React and Reframe, because it worked well with the Couchbase Java SDK.
I've been paid to build prototypes, apps, tools, and system software with Lisp, Icon, ML, C, C++, Objective-C, Java, Python, Swift, Prolog, Haskell, Scheme, and other things. If I had a modern version of Ralph, I'd most likely use that. Failing that, Common Lisp is what I like best.
Common Lisp is generally the first thing I think of for any new work I undertake. There are exceptions, but usually my first choice is Common Lisp. It has been for a little over thirty years.
I've often worked in other languages--usually because someone wants to pay me to do so. I usually pick Common Lisp, though, when the choice of tools is up to me, unless some specific requirement dictates otherwise.
The objections you list might be an issue to some extent, but not much of one. Certainly not enough to discourage me from using Common Lisp in a pretty wide variety of projects. I've used it for native desktop apps, for web apps, for system programming, for text editors, for interpreters and compilers. When I worked on an experimental OS for Apple, the compiler and runtime system I used were built in Common Lisp.
I'll use something else when someone pays me enough to do it. I'll use something else because it's clearly the best fit for some specific set of requirements. I'll use it when there isn't a suitable Common Lisp implementation for what I want to do. I'll even use something else just because I want to get to know it better.
I've taken various detours along the way into learning and using various other languages. I like several of them quite a bit. I just don't like them as much as Common Lisp.
The pleasure I take in my work is a significant factor in my productivity. Choosing tools that offer me less joy is a cost I prefer not to bear without good reason. That cost often exceeds the advantage I might realize from using some other language. Not always; but often.
There was once a language I liked even better than Common Lisp. Apple initially called it 'Ralph'. It evolved into Dylan, which, in its present form, I don't like as much as Common Lisp. If I or someone else invested the considerable time and effort needed to write a modern version of Ralph, then I might choose it over Common Lisp.
For now, though, I'll stick with the old favorite. It continues to deliver the goods.