6 ms·
It's good because it offers the opportunity to simplify and rationalize the type system and associated protocols without losing features. In the early 1990s I
by mikelevins 8y ago
It's good because it offers the opportunity to simplify and rationalize the type system and associated protocols without losing features.
In the early 1990s I worked on an experimental Newton OS written in Dylan. At that time, Dylan was still called "Ralph," and it was basically an implementation of Scheme in which all datatypes were CLOS classes. It was "CLOS all the way down."
Ralph offered substantially the same affordances and conveniences as Common Lisp, but with a simpler and more coherent set of APIs. Ralph was easier to learn and remember, and easier to extend.
To illustrate why, consider finite maps. The idea of a finite map is a convenient abstraction with a well-defined API. Common Lisp offers a couple of convenient ways to represent finite maps, and it's easy to build new representations of them, but there's no generic API for finite maps. Instead, each representation has its own distinct API that has nothing particularly to do with anything else.
By contrast, Ralph had a single well-defined API that worked with any representation of finite maps, whether built-in or user defined.
The upshot is a library of datatypes that is just as rich as Common Lisp's, but with a simpler and more coherent set of APIs, and an easy standard way to extend them with user-defined types that also support the same APIs.
There are signs in the Common Lisp standard that people were already thinking in that direction when the standard was defined. See the sequence functions, for example. Ralph, designed by Common Lisp and Smalltalk implementors, carried that thinking to its logical conclusion, and the result was something like a tidier Common Lisp.
Twenty-eight years later, Ralph is still my favorite of all the languages I've used for serious work. Its development system, Leibniz, remains my favorite development system. My favorite current tools are Common Lisp systems, but that's because I can't have Ralph and Leibniz anymore.
- mindcrime 8y agoMy favorite current tools are Common Lisp systems, but that's because I can't have Ralph and Leibniz anymore. You said below that you don't find modern day Dylan to be as valuable. I don't know much about Dylan, either the pre-1992 version or the newer version(s), but I'm curious if you would elaborate on why the older Dylan was so much superior to modern Dylan in your view?
- mikelevins 8y agoBecause modern Dylan is not an old-fashioned Lisp. I prefer working the old-fashioned Lisp way. I start my Lisp and tell it, an expression at a time, how to be the app I want. Modern Dylan doesn't work like that. It's much more a batch-compiled affair, where you write a lot of definitions and compile them all at once to yield an artifact. Modern Dylan does not have a Lisp-style repl that you can use to gradually build up your app interactively, teaching the runtime new tricks, and incrementally querying it to examine what you've built--as I did when working on the Dylan Newton. For a while, Bruce Michener and I discussed what it would take to restore that kind of support to OpenDylan, but in the end I concluded it was an impractical amount of work.
- mindcrime 8y agoGotcha. I've never really used OpenDylan, but I've had it on my "list of things to learn one day" for a while, so just curious about your take on that. I didn't realize that old Dylan had a lisp style REPL and that new Dylan doesn't.
- Immortalin 8y agoWhat's your opinion on Julia given its Dylan heritage?
- mikelevins 8y agoJulia is almost good enough for me to use, but not quite. I'd prefer an s-expression syntax, but that's not a deal killer for me. I like some other languages that don't have s-expression syntaxes, though I miss the easy text manipulation that s-expressions support. I would want a convenient way to deliver a self-contained executable. If there's a simple way to do that with Julia, I don't know about it. I look for it periodically, but haven't found it. If it's there and I've simply overlooked it, then I might actually start using it regularly. I have a few other nits, but they're just nits. On the whole, I think Julia's pretty nice.
- fasquoika 8y ago>I would want a convenient way to deliver a self-contained executable. It's a bit rough around the edges, but it does exist: https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl
- mikelevins 8y agoExcellent; thank you! I'll take a look.
- mikelevins 8y agoOne thing I forgot to mention is that I don't know whether Julia handles dynamic redefinitions gracefully. What I mean is, for example, if I evaluate a new definition of an existing class, what happens to all the existing instances of that class? In Common Lisp, the old instances are now instances of the new class, and there is a runtime facility, defined in the language standard, for updating existing instances to ensure that they conform to the new definition. If a language lacks facilities like that, then it's hard to work the way I prefer to work. I guess I sort of expect that Julia will not have graceful support for redefinitions, because, generally speaking, the only people who even think of that feature are people who are intimately familiar with old-fashioned Lisp and Smalltalk systems, and they're sort of thin on the ground. But maybe I'll be pleasantly surprised.
- deleted 8y ago[deleted]