Earlier quoted context omitted.
True 'nuff. I prefer Scheme to CL. The tooling isn't as developed, but Chicken and Guile are both plenty usable, and Scheme is less crufty than CL.
Chicken + some plugins they provide are almost more than enough for most people! Great project.
Symbolics Lisp Machine Museum
41–50 of 136 posts
Re: Symbolics Lisp Machine Museum
#42Symbolics made some really cool tech. I just wish everybody would stop complaining about it. Yes, it was amazing. Yes, nothing modern can ever compare, not even Emacs, an environment arising from the same culture. Yes, we who experienced The Glory of the Lispm must eternally genuflect before it, condescending to anybody who didn't. Instead, go look at what Symbolics did (or try: it's quite hard to get the emulator ru…
There's no reason it can't come back. It requires a massive amount of programming work and possibly new hardware but it's definitely possible and people are already working towards it. It's actually quite possible to build upon it and even surpass it.
Re: Symbolics Lisp Machine Museum
#43Earlier quoted context omitted.
>Obviously not. ...And what makes you say that? I was actually aware, in any case. >A Lisp system is not text-based. >Lisp is based on data. Code is data and data can be code. >Using an editor to work with text is only half of the story. A good Lisp IDE lets me more or less directly interact with the data. I'm aware of that, but text is a fairly convenient representation of Lisp data. In fact, I'm unsure what you mea…
> I'm aware of that, but text is a fairly convenient representation of Lisp data. Some Lisp data does not have a textual representation, it might have a graphical representation or the textual representation may not be very helpful (Lisp data being a graph might be better displayed as a 2d or even 3d graph, than as a textual representation). The Symbolics UI of the REPL/Listener would allow you to interact with the 2…
In any case, I don't really want my editor editing sexps. The moment my editor is working with sexps rather than characters, it's no longer a general-purpose tool.
Re: Symbolics Lisp Machine Museum
#44Symbolics made some really cool tech. I just wish everybody would stop complaining about it. Yes, it was amazing. Yes, nothing modern can ever compare, not even Emacs, an environment arising from the same culture. Yes, we who experienced The Glory of the Lispm must eternally genuflect before it, condescending to anybody who didn't. Instead, go look at what Symbolics did (or try: it's quite hard to get the emulator ru…
> That system lost, and it's never coming back There's no reason it can't come back. It requires a massive amount of programming work and possibly new hardware but it's definitely possible and people are already working towards it. It's actually quite possible to build upon it and even surpass it.
...Unless, of course, one of the popular embedded or mobile systems companies (Apple, etc.) Suddenly rewrote everything in lisp, and forced all 3rd-party devs to do the same, creating a massive market only reachable by Lisp programmers.
What a wonderful dream.
Re: Symbolics Lisp Machine Museum
#45Earlier quoted context omitted.
> I'm aware of that, but text is a fairly convenient representation of Lisp data. Some Lisp data does not have a textual representation, it might have a graphical representation or the textual representation may not be very helpful (Lisp data being a graph might be better displayed as a 2d or even 3d graph, than as a textual representation). The Symbolics UI of the REPL/Listener would allow you to interact with the 2…
Thanks for the information. It is legitimately interesting. But while it is a neat idea, the difference seems to be largely inside-baseball. Sure, we're dealing with text, but we can still inspect our code quite well, and we can do much of the same sort of stuff. In any case, I don't really want my editor editing sexps. The moment my editor is working with sexps rather than characters, it's no longer a general-purpos…
Imagine the editor and the runtime work on the same data:
EDIT data EVAL
In GNU Emacs it looks like this: Emacs EDIT -> text -> Emacs SAVE FILE
SBCL LOAD FILE -> SBCL READ -> SBCL EXECUTE
or Emacs EDIT -> text -> Emacs TRANSFER to SBCL
-> SBCL READ > SBCL EXECUTE ->
SBCL generate TEXT -> SBCL TRANSFER to Emacs
-> Emacs DISPLAY -> text
With presentations it looks for the user that the Emacs side knows the data for the text.That's a lot of indirection, a lot of conversions, different runtimes, etc.
S-Edit feels like working with clay. A text editor feels like working with instruments, manipulating something which then manipulates the clay and you are watching the result through goggles.
Re: Symbolics Lisp Machine Museum
#46Earlier quoted context omitted.
> That system lost, and it's never coming back There's no reason it can't come back. It requires a massive amount of programming work and possibly new hardware but it's definitely possible and people are already working towards it. It's actually quite possible to build upon it and even surpass it.
People are working on new Lisp-based systems (which is awesome!) But Symbolics systems will never come back, and it's unlikely that any of these systems will gain traction in a world where Unix dominates. ...Unless, of course, one of the popular embedded or mobile systems companies (Apple, etc.) Suddenly rewrote everything in lisp, and forced all 3rd-party devs to do the same, creating a massive market only reachable…
Re: Symbolics Lisp Machine Museum
#47Earlier quoted context omitted.
We can do more than that. If everybody followed the trend, then Lisp would be dead, and we'd all just write Java. shivers
Thankfully Rich Hickey & co wrote Clojure so we can program on a modern Lisp in the Java Virtual Machine and in the browser! (ClojureScript) (even the .NET CLR is supported) [1] http://clojure.org [2] http://clojurescript.org
Scheme kind of gets you thinking in a way that works iteratively, but gets expressed recursively. Its easy to read, and can make for some great optimisation without being premature.
The JVM does not really support this style of programming - despite LISP's syntax leading towards it.
Re: Symbolics Lisp Machine Museum
#48I used to work with a number of LISP machine believers at the MIT AI Lab/CSAIL. They all had more modern computers for day to day tasks, but used the lispm for most of their programming. This wasn't that long ago (I left in 2010), and I suspect that those machines will remain in active use for as long as people can keep them running. They all believed that the loss of the lisp machine was a serious loss to society an…
Re: Symbolics Lisp Machine Museum
#49Earlier quoted context omitted.
If it is functional(and maybe if not), you can potentially get a decent amount of money from selling that.
Or you could donate it to the computer history museum.
Re: Symbolics Lisp Machine Museum
#50Earlier quoted context omitted.
Thankfully Rich Hickey & co wrote Clojure so we can program on a modern Lisp in the Java Virtual Machine and in the browser! (ClojureScript) (even the .NET CLR is supported) [1] http://clojure.org [2] http://clojurescript.org
Though it kind of sucks that Tail Call Elimination is such a difficult task on the JVM. Scheme kind of gets you thinking in a way that works iteratively, but gets expressed recursively. Its easy to read, and can make for some great optimisation without being premature. The JVM does not really support this style of programming - despite LISP's syntax leading towards it.