Live data from Hacker News

Symbolics Lisp Machine Museum

smbx.org

61–70 of 136 posts

Re: Symbolics Lisp Machine Museum

#61
post #55

Earlier quoted context omitted.

I am aware of that indirection, but it never really shows up, or gets in my way. Maybe I'm missing something. Could you link me some information about S-Edit? I can't find anything on it, and it might help me understand what you mean.

http://www.textfiles.com/bitsavers/pdf/xerox/interlisp/31012... Chapter 16 describes DEdit, the display oriented structure editor of Interlisp-D. ALso see for general philosophy of interactive Lisp systems this article from 1978 (!!!): http://www.softwarepreservation.org/projects/interactive_c/b...

Neat. But actually, I find that mechanism quite unpleasant, and one I wouldn't like working with. I'm sure it's quite powerful, but so is Vim, and I never really "got" Vim either. I would, in fact, argue that manipulating text has advantages over direct object manipulation: the first of which is that you can more directly edit text, whereas the DEdit interface is all about executing commands on objects. Secondly, you can apply useful transformations to text which don't necessarily make sense to apply to raw datastructures (search + replace, regexes, other handy transforms). Finally, many of the advantages of manipulating a pure datastructure can be had in text as well: see paredit.

But that's just me. You use your cool lispm tools, I'll resign myself to never acheiving ultimate productivity.

But I was resigned to that already, pretty much.

Re: Symbolics Lisp Machine Museum

#62
post #33

Earlier quoted context omitted.

It was by far the most productive programming environment I have ever used. The level of integration of the editor, debugger, IO system, and interpreted and compiled code is unparalleled. Interestingly it philosophically descended from MACLISP development on a machine (PDP-10) that was designed with Lisp in mind and that had an O/S (ITS) whose "shell" was a debugger, so you could also do pretty tightly coupled develo…

"Programming by successive approximation" is hardly scorn worthy in my mind.

I too am left wondering, what is the alternative?

Re: Symbolics Lisp Machine Museum

#63
post #47

Earlier 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.

recur in clojure is also easy to read in my opinion.

Re: Symbolics Lisp Machine Museum

#64

Earlier 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

Not a super fan of Clojure, but it's a good language. Shame it's still stuck in the Java ecosystem, though.

I believe the whole point was to target the JVM, because of reuse and maturity. And actually it's not stuck just in java ecosystem, clojure got wings years ago. Yoy can find it inside a browser today too :)

Re: Symbolics Lisp Machine Museum

#65

Earlier 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

Not a super fan of Clojure, but it's a good language. Shame it's still stuck in the Java ecosystem, though.

[deleted]

Re: Symbolics Lisp Machine Museum

#66
post #63
post #47

Earlier quoted context omitted.

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.

recur in clojure is also easy to read in my opinion.

True.

However, a named let in Scheme is not a loop. Its still a lambda.

Which means you can have nested lets with TCE, and you can construct them on the fly, depending on what your needs are, usung patterns like currying.

That flexibility just doesn't work on the JVM. You can force it, but it'll be slow and horrible compared to another pattern - and I don't think a LISP should tell me how to do something. That's Python's ideology.

Re: Symbolics Lisp Machine Museum

#68

Earlier quoted context omitted.

Or you could donate it to the computer history museum.

They have a couple, they're on display and in the collection. Better that it would go to someone who would restore the whole thing (not just the exterior) and actually use it.

I donated my MacIvory, hosted in a Macintosh Quadra 650, to the Computer History Museum. If you see one of those there, it might be my old one.

Re: Symbolics Lisp Machine Museum

#69

Who actually owns the Symbolics IP these days? I still wonder if it would be possible to put a 3600 on a chip.

I thought that symbolics was still running in a limited capacity and pulling in money from government contracts. At least that was the case five or six years ago. I know licenses for Genera were being sold as late as 2010 for around 5k. I would be interested to know if this IP changed hands.

Re: Symbolics Lisp Machine Museum

#70
post #64

Earlier quoted context omitted.

Not a super fan of Clojure, but it's a good language. Shame it's still stuck in the Java ecosystem, though.

I believe the whole point was to target the JVM, because of reuse and maturity. And actually it's not stuck just in java ecosystem, clojure got wings years ago. Yoy can find it inside a browser today too :)

I wonder if there ever has been talk of a native Clojure? I guess it may not be very usable without the JVM ecosystem, though. Frankly, I find calling JVM library calls from Clojure to be quite ugly and really stand out in the code (mostly because of the mix of the lower-case-dash-delimited variable and fn nameing convention of Clojure and the mixed-case/camelCase naming style of Java.
Post reply on HN