That's nothing like Symbolics Genera. Genera is amazing in so many ways, even how it does command line completion.
Check out http://en.wikipedia.org/wiki/Genera_(operating_system) for some basic info on what a Lisp Machine was like...
3,597 karma · joined December 11, 2011
Check out http://en.wikipedia.org/wiki/Genera_(operating_system) for some basic info on what a Lisp Machine was like...
I've also written most of a porting guide in our Hacker's Guide as well: http://opendylan.org/documentation/hacker-guide/porting.html
The "HARP" backend outputs native code for x86-linux, x86-freebsd and x86-windows.
The C backend outputs C and works on x86_64-linux, x86_64-freebsd and Mac OS X.
We have an in-progress LLVM backend that will support all of the above platforms and more.
As for ARM/Linux, we have a port in progress for the C backend. In theory, it should work after a cross-compile or using cross-compilation tools, but we haven't quite tried it out yet ourselves (the person doing the port is getting married this weekend and going away for a couple of weeks).
If you would like to help out with Dylan on ARM/Linux, drop by #dylan on FreeNode IRC and I'll work with you. (The hack-a-thon this weekend is a great time for that.)
Otherwise, we plan to have this in the 2013.2 release (whenever that is).
Type names are typically enclosed in '<...>' like '<integer>' (but that's just a convention used everywhere).
The postgres client library and uWSGI bindings are probably doable within a weekend. Feel like dropping by? :)
For me, some of the important things are:
* The language is much smaller and cleaner than Common Lisp (and designed by some of the same people that participated in the CL standardization).
* Because it has a smaller community and installed base at this point in time, it has the freedom to evolve in new directions whereas an existing Lisp is already defined and tied down to what it is (for the most part). (Coroutines would be a nice addition for example.)
* You can produce executables from it and don't have to have a running image.
* The integration of the type system is, for the most part, nice. It is nice to have the ability to have a mix of dynamic and more static typing. (The type system could be better, and that too is an interesting possible future direction.)
* Always using multi-methods and everything being an object and the more powerful dispatch capabilities are quite handy.
* It has a condition system like Common Lisp rather than exceptions.
* The macro system is okay.
* It is nice having multiple return values, #rest parameters and keyword parameters, all cleanly integrated.
* The C-FFI is good.
* Some people like the syntax. I enjoy how readable the code is to me.
* I'm not tied into using the JVM.
Some Lisps have some of the above, some don't. Not everyone might like all of the above, but for me, it is a comfortable fit.
Hopefully we'll be making some good headway on things for our next release (which will include ARM Linux support among other things).
It has a long history behind it going back to the Harlequin Lisp company in the 1990s.
This release brings a modernization of the documentation from old formats and a lot of newly written material:
http://www.ravenbrook.com/project/mps/version/1.111/manual/h...
(For those who are interested in it for open source work, they're happy to talk about the licensing. They've been very generous with us for http://opendylan.org/ for example.)
Clearly, a lot of work has gone into the library side of things, but I'm curious what is special about the language level for technical computing.
I'd have said Common Lisp as well, but some might argue point #1 with respect to that.
It is nice to see others (re-)discovering the joy of full on multiple dispatch though!
Maybe, maybe not. I've had parts of a precise, copying, compacting (commercial grade) garbage collector running under emscripten.
It "crashes" still, but seems viable.
How do you run a Lisp Machine environment today? Or Oberon System 3 or v4 (I never tried anything later)?
It is easy to reinvent and re-sell stuff when everything before is pretty much no longer available.
I've had a few conversations lately with people who worked on some of this stuff. A lot of history is totally gone.
A gating factor here is that much of the time, old software doesn't run, isn't available in source form, the old hardware is long gone and there aren't emulators, etc. We also probably over-glorify some things from the past. :)
Making the Texas Persistent Store build again is a bit of a chore as it is C++ from 1994 and things have changed a good bit. But even things that last had a release in the last decade don't build any longer (like framerd). Much less something like SHRDLU which was written in MacLisp and ran on ITS!
I'd love to see runnable copies of T, EuLisp, Sk8, FramerD and so many other things. It often feels like we lose so much of our history.
Does it harm you in some way?
If it works, it works. If it doesn't, it doesn't. And either way, we've learned something. There's one one approach or set of approaches that are blessed and known to work 100% of the time.
I was more than happy to support it given the fine work that he's done in the past and how easy it has been to get answers from him about CodeMirror.
If this helps him produce more software or release some of what he's already written, then great. I'd rather he do this than get a more traditional job and have the fruits of his labor locked up.
But either way... what's the harm in trying a different approach? What's the harm in (potentially) giving him the opportunity to continue doing what he enjoys and does well?
If you don't want to give him that opportunity, that's fine. But there's little need to cast aspersions, right?
> Many years ago
> (before Objective C had exceptions or blocks or GC or ...)
TOM had the things that I mentioned back in 1998, 1999, maybe earlier.
Objective C has come a long way since then.