4 ms·

When Ralph was new, it was essentially a hybrid of Common Lisp and Scheme. It was very much a Lisp--not just technically, or in matters of surface syntax, but d

When Ralph was new, it was essentially a hybrid of Common Lisp and Scheme. It was very much a Lisp--not just technically, or in matters of surface syntax, but down in its bones. 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.

metroholografix 6y ago
Strongly agree with that viewpoint and the central paradigm it describes, it's what's made my 15 year investment into Lisp more than worth it. It's also what makes every newly emergent language not measure up to Lisp: None of them focus on interactive development. In fact, the only one I'm aware of that (partly) did that was Slava Pestov's Factor but ultimately, it was more a proof-of-concept than anything that could be considered practical and is now languishing. 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.
- gnufx 6y ago
  I don't remember ever hearing of Ralph when Dylan appeared, though that was long ago. Was it talked about externally?
  - mikelevins 6y ago
    The name "Ralph" wasn't really secret anymore once Dylan went public, but there also wasn't any particular reason to talk about it. The name of the language was Dylan at that point. 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.
- 7thaccount 6y ago
  Hmmmm...PharoSmalltalk, 8th (same rough family as Factor), Mathematica, Dyalog APL, J, K...lots of tools that are fully interactive in their bones.
  - metroholografix 6y ago
    I wouldn't characterize Pharo/Mathematica/Dyalog APL as newly emergent, they've been around for a long time. I can't say anything about J and K since I've never used them but my superficial impression is that they are focused on a specific niche, not as general purpose as most Lisps. They've also been around for a long time. 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]. [1] https://8th-dev.com/com-license.html https://8th-dev.com/com-license.html [2] https://news.ycombinator.com/item?id=15672361 https://news.ycombinator.com/item?id=15672361
    - 7thaccount 6y ago
      New is pretty relative, but yeah they've definitely been around for a while. I'd say the array languages (APL/J/K) can be used in far more areas than most people think, but I understand your point and am on the fence myself. 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.
Ingon 6y ago
Probably discussed before, and I’m happy to read about it if you have pointers to it, but how does livecoding work with multiple ppl/source control? Is there a persistent textual format where all changes to the image are stored? How about releases?
- mikelevins 6y ago
  Old-fashioned Lisp and Smalltalk systems (and some old Scheme systems) can save the live memory image to a file. You can load that file at launch time to reproduce the dynamic state of the system at the time the image was saved. You can share saved dynamic state between colleagues that way. Pretty handy, especially when you want someone to be able to debug a hard-to-reproduce bug that just showed p on your screen. 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.
nahuel0x 6y ago
hi Mikel, do you know if there is some Ralph and Bauhaus info/docs/sources out there? Or they are completely lost in time?
- mikelevins 6y ago
  They're not completely gone, but they're hard to find. 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 wasn't exactly the same. Ralph had some extensions that weren't part of the language described in the book. For example, it had a class for representing blocks of memory allocated outside the Dylan heap (that is, "foreign" memory). 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.
  - mikelevins 6y ago
    I just noticed that a sibling comment has a link to Rainer Joswig's archive of the Dylan book (Dylan, an Object Oriented Dynamic Language, the book I referred to above). Here's the link again for reference in context: http://lispm.de/docs/prefix-dylan/book.annotated/ 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: http://lispm.de/docs/prefix-dylan/design-notes/ http://lispm.de/docs/prefix-dylan/design-notes/

metroholografix 6y ago

Strongly agree with that viewpoint and the central paradigm it describes, it's what's made my 15 year investment into Lisp more than worth it. It's also what makes every newly emergent language not measure up to Lisp: None of them focus on interactive development. In fact, the only one I'm aware of that (partly) did that was Slava Pestov's Factor but ultimately, it was more a proof-of-concept than anything that could be considered practical and is now languishing. 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.

gnufx 6y ago
I don't remember ever hearing of Ralph when Dylan appeared, though that was long ago. Was it talked about externally?
- mikelevins 6y ago
  The name "Ralph" wasn't really secret anymore once Dylan went public, but there also wasn't any particular reason to talk about it. The name of the language was Dylan at that point. 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.
7thaccount 6y ago
Hmmmm...PharoSmalltalk, 8th (same rough family as Factor), Mathematica, Dyalog APL, J, K...lots of tools that are fully interactive in their bones.
- metroholografix 6y ago
  I wouldn't characterize Pharo/Mathematica/Dyalog APL as newly emergent, they've been around for a long time. I can't say anything about J and K since I've never used them but my superficial impression is that they are focused on a specific niche, not as general purpose as most Lisps. They've also been around for a long time. 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]. [1] https://8th-dev.com/com-license.html https://8th-dev.com/com-license.html [2] https://news.ycombinator.com/item?id=15672361 https://news.ycombinator.com/item?id=15672361
  - 7thaccount 6y ago
    New is pretty relative, but yeah they've definitely been around for a while. I'd say the array languages (APL/J/K) can be used in far more areas than most people think, but I understand your point and am on the fence myself. 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.

Ingon 6y ago

Probably discussed before, and I’m happy to read about it if you have pointers to it, but how does livecoding work with multiple ppl/source control? Is there a persistent textual format where all changes to the image are stored? How about releases?

mikelevins 6y ago
Old-fashioned Lisp and Smalltalk systems (and some old Scheme systems) can save the live memory image to a file. You can load that file at launch time to reproduce the dynamic state of the system at the time the image was saved. You can share saved dynamic state between colleagues that way. Pretty handy, especially when you want someone to be able to debug a hard-to-reproduce bug that just showed p on your screen. 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.

nahuel0x 6y ago

hi Mikel, do you know if there is some Ralph and Bauhaus info/docs/sources out there? Or they are completely lost in time?

mikelevins 6y ago
They're not completely gone, but they're hard to find. 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 wasn't exactly the same. Ralph had some extensions that weren't part of the language described in the book. For example, it had a class for representing blocks of memory allocated outside the Dylan heap (that is, "foreign" memory). 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.
- mikelevins 6y ago
  I just noticed that a sibling comment has a link to Rainer Joswig's archive of the Dylan book (Dylan, an Object Oriented Dynamic Language, the book I referred to above). Here's the link again for reference in context: http://lispm.de/docs/prefix-dylan/book.annotated/ 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: http://lispm.de/docs/prefix-dylan/design-notes/ http://lispm.de/docs/prefix-dylan/design-notes/