Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Symbolics Lisp Machine Museum

smbx.org

Post reply on HN
Print view View original

101–110 of 136 posts

Re: Symbolics Lisp Machine Museum

#101

Post by rjsw »

pjmlp wrote: post #90
shakna wrote: post #66

Earlier quoted context omitted.

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 Pyth…

It pops up every now and then in Java Language Summit presentations, usually in comparison with .NET, which does support it. So who knows, maybe some day the JVM finally gets it.

Well the .NET CLR was designed by a lisper.

Re: Symbolics Lisp Machine Museum

#102

Post by qwertyuiop924 »

ScottBurson wrote: post #71
shakna wrote: 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.

Ironically, the Lisp Machines didn't have TCO either.

One of their great failings. I'm a Scheme user, so I feel a bit weird without TCO.

Re: Symbolics Lisp Machine Museum

#103

Post by qwertyuiop924 »

pjmlp wrote: post #99
qwertyuiop924 wrote: post #94

Earlier quoted context omitted.

I realize, I just can't stand the ecosystem. Everything is super verbose, frustratingly overcomplicated, and full of XML. Yuck.

It is a consequence of being an enterprise language. I imagine you never had the pleasure of doing enterprise distributed computing projects via CORBA, DCOM, SUN-RPC, DCE in C, C++, Visual Basic and Smalltalk. Guess where those enterprise architects moved on. EDIT: Should have mentioned Delphi and Objective-C as well.

I didn't, it sounds unpleasant, I can guess, and I don't like it, which is why I'm not a fan of Java.

Re: Symbolics Lisp Machine Museum

#105

Post by crististm »

qwertyuiop924 wrote: post #95
crististm wrote: post #89

Earlier quoted context omitted.

Text is not "raw data structure" and you may want to think twice that by manipulating text you touch the "data". From the sidelines, your approach is "all I have are nails and all I need is the biggest hammer you can get me".

Text is a raw data structure, it's just not the one that's used behind the scenes: Everything is a datastructure. And actually I do touch the data by manipulating text. >From the sidelines, your approach is "all I have are nails and all I need is the biggest hammer you can get me". From my perspective, my approach is "that development environment sounds really unpleasant, and while I can appreciare the elegance, I'm…

When your editor's cursor hovers over "transistor T1" do you in fact touch the transistor on the board over your desk, the transistor in the schematic diagram, or only the text that happens to be "1T rotsisnart" spelled backwards (with no underlying meaning that is)?

Data representation is not the data. It's just this: "re" presenting. And when this representation is disconnected from the source by means of showing only the raw text and not allowing access to the source you get what you describe as "unpleasant".

You may find it enjoyable to work only with raw text but you're missing out on working with what that text is supposed to represent.

Re: Symbolics Lisp Machine Museum

#106

Post by jacquesm »

gumby wrote: post #33
noahm wrote: post #15

I 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…

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

That's called 'Agile' nowadays...

Re: Symbolics Lisp Machine Museum

#107

Post by anthk »

gumby wrote: post #33
noahm wrote: post #15

I 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…

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…

Emacs + Geiser + Scheme =)

Re: Symbolics Lisp Machine Museum

#108

Post by JBiserkov »

metaobject wrote: post #70
smnplk wrote: post #64

Earlier quoted context omitted.

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.

The closest thing to a native Clojure is Pixie[1]. As the authors note, it's a "Clojure inspired lisp", not a "Clojure Dialect".

>Pixie implements its own virtual machine. It does not run on the JVM, CLR or Python VM. It implements its own bytecode, has its own GC and JIT. And it's small. Currently the interpreter, JIT, GC, and stdlib clock in at about 10.3MB once compiled down to an executable.

[1] https://github.com/pixie-lang/pixie

Re: Symbolics Lisp Machine Museum

#109

Post by jmorrison »

I have an old MacIvory (Symbolics board set housed in a Mac II) which doesn't want to boot anymore. IIRC Googling indicated that the Mac IIs are like cars - they won't turn over if the motherboard battery is dead. I changed the battery - no joy. Anybody have any recommendations, whether for a repair place (New England, USA) or further DIY things to try?

Re: Symbolics Lisp Machine Museum

#110

Post by bbctol »

protomyth wrote: post #18

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

I'm distantly related to the original founder, and have been told this confusing version of the story: Symbolics was bought out buy a different company that then renamed themselves Symbolics, though none of the people remained and the new company just pulled government contract money for "maintenance." Eventually, the IP was owned by a single person named Andrew Topping, who was known to the rest of the world pretty much only by name; no one knows his history. Then he died. Now nobody has any clue who owns the IP, where any useful documentation is, etc...
Post reply on HN