Live data from Hacker News

Symbolics Lisp Machine Museum

smbx.org

111–120 of 136 posts

Re: Symbolics Lisp Machine Museum

#111

Earlier quoted context omitted.

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

All is representations. Some are closer to the data they are representing than others. I am aware that text is a representation. It is a also a data structure: A data structure which we are better able to manipulate directly with our human senses, and a data structure which tools like DEdit still render to.

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

First off, pleasantness of an interaction is a matter of personal opinion. If you like DEdit, great: I'm not stopping you. But I don't enjoy DEdit and its like. That's my prerogative.

Secondly, I'm not working "only with raw text." Paredit &co let me manipulate the sexpr data structure more directly (or less directly, depending on how you look at it). Geiser and SLIME let me evaluate and manipulate the code as code. But at the end of the day, I'm also operating on text, so I have all of the textual data tools as well, and because Paredit is actually operating on text, it can be used outside of the context of Lisp: As Perlis said, "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."

Re: Symbolics Lisp Machine Museum

#112
post #104

Earlier quoted context omitted.

...You should probably tell people if you cite yourself.

What's your problem exactly?

It's not a problem, really, I just think it's a good idea to tell people if you're citing your own pages, in general. It's by no means awful to do so, but it's better to let people know, so they don't think that your claim is corroborated by an external source when it isn't.

If you think I have a problem with you, or something, I don't. So don't worry about it.

Re: Symbolics Lisp Machine Museum

#113
post #87
post #81

Earlier quoted context omitted.

There was Dylan

The early versions of that were used for the Lisp OS - actually more than one. As usual, the IDE was implemented in Common Lisp.

Honestly, from the look of it, I'd like earlier versions of Dylan better than the language we ended up with. I never really liked the non-sexpr syntax. But that's just me.

The IDE was really written in CL? Huh. I'd have thought that they would have gone the self-hosting route.

Re: Symbolics Lisp Machine Museum

#114

Earlier quoted context omitted.

Jobs' Apple would never allow such a product. A user programmable machine for which people could release software without paying Apple a cut? Zero chance of that getting off the ground, for the same reason that Hypercard had to die. http://www.loper-os.org/?p=568

If we limit our perspective to the duration of Jobs's lifetime, the Apple I, II, III, and the entire Macintosh line never required a tithe to Apple for releasing software. (You can argue about the cost of developer tools / the developer program for the Mac, but you'd be wrong, since (a) those were never profitable for Apple and (b) people could and did use third party development tools.) HyperCard development flounde…

"Obsolete" is overstating it. You could do a lot with HyperCard. People did.

Apple management started talking about cutting it pretty much immediately. It didn't directly generate any revenue--Apple gave it away for free. It didn't fit into any familiar product category. It wasn't on anybody's list of must-have features. Basically, Apple management didn't understand what it was or why it existed.

Apple's programmers and other makers were an entirely different matter. They used it for all sorts of things. So did third-party developers. So did people who discovered how to make software through working with HyperCard. Projects sprouted in Apple that either extended HyperCard or implemented new software in the same spirit with expanded capabilities--but all those projects had the same problem as HyperCard: management didn't see what they were supposed to be for. Furthermore, the other projects didn't benefit from Apple management's promise to Bill Atkinson that HyperCard would be given away to Apple customers.

HyperCard's days were numbered from the beginning; that much is true. But to call it "obsolete" from the beginning misunderstands a lot.

Re: Symbolics Lisp Machine Museum

#115
post #104

Earlier quoted context omitted.

What's your problem exactly?

It's not a problem, really, I just think it's a good idea to tell people if you're citing your own pages, in general. It's by no means awful to do so, but it's better to let people know, so they don't think that your claim is corroborated by an external source when it isn't. If you think I have a problem with you, or something, I don't. So don't worry about it.

The source is well-known and long-time Lisper Mikel Evins who worked for Apple in various projects and also in these projects where Lisp-based operating systems were developed. Mikel has multiple times mentioning and describing this work. You even find it here on Hackernews, where he is a user. Just google for it. I see that he is even participating in this thread now.

Re: Symbolics Lisp Machine Museum

#116
post #87

Earlier quoted context omitted.

The early versions of that were used for the Lisp OS - actually more than one. As usual, the IDE was implemented in Common Lisp.

Honestly, from the look of it, I'd like earlier versions of Dylan better than the language we ended up with. I never really liked the non-sexpr syntax. But that's just me. The IDE was really written in CL? Huh. I'd have thought that they would have gone the self-hosting route.

> But that's just me.

No, it's not just you. Most Lisper thought that way. But the target weren't Lisp developers, it were C++/Apple Pascal developers. Basically similar purposes which Java was designed for: general 'mainstream' application/OS developers from mobile systems upwards. Management did not think that an s-expression-based syntax would be a success with developers used to use Pascal, C and C++.

> The IDE was really written in CL? Huh. I'd have thought that they would have gone the self-hosting route.

The new language was emerging and targeting the new hardware platforms.

You can think of it that it was similar with the Playstation games from Naughty Dog - for example Crash Bandicoot. The platform for the software was the Game Object Oriented Lisp on Playstation and the development environment were desktop computers running and IDE based on Allegro Common Lisp.

The dev environment were Macs. The developers were often Lisper and Apple bought the technology and the people. Even the later product version development environment 'Newton Toolkit' was originally developed in Common Lisp.

There were stranger things then. I once saw a version of Microsoft Word for Macintosh on a developer CD, written in Common Lisp. It was a relatively sophisticated User Interface mockup. It looked like the real MS Word for Mac, but lacked much of the functionality. But when you looked at the application file on the bit level, you could see that it was a Macintosh Common Lisp runtime/image. It was written by or for Microsoft. Long ago.

Re: Symbolics Lisp Machine Museum

#117

Earlier quoted context omitted.

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.

The designers argued that a million-line software (the OS + basic applications) was easier to debug/develop without having TCO everywhere. It makes stack traces useless, unless one thinks of clever ways to keep tail calls recorded, which makes it complex/tricky. The basic machine architecture is a stack machine with compact and nice instructions. Stack traces were useful then. The compiler also was not very sophisticated when it comes to optimizations.

Re: Symbolics Lisp Machine Museum

#118
post #80
post #40

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

BTW while pretty much every Interlisp-D user used D-edit, I was never comfortable with it because it required use of the mouse. By the time I started using Interlisp I had about six or seven years of Emacs wired into my fingers and didn't like being slowed down by taking my fingers off the keyboard. There was an emacsy interface made by Kelly ??? in the office next to me which I extended into a real Emacs clone (with…

That's probably what I would have done. But I'm a snot-nosed 15 year old kid.

Re: Symbolics Lisp Machine Museum

#119
post #116

Earlier quoted context omitted.

Honestly, from the look of it, I'd like earlier versions of Dylan better than the language we ended up with. I never really liked the non-sexpr syntax. But that's just me. The IDE was really written in CL? Huh. I'd have thought that they would have gone the self-hosting route.

> But that's just me. No, it's not just you. Most Lisper thought that way. But the target weren't Lisp developers, it were C++/Apple Pascal developers. Basically similar purposes which Java was designed for: general 'mainstream' application/OS developers from mobile systems upwards. Management did not think that an s-expression-based syntax would be a success with developers used to use Pascal, C and C++. > The IDE w…

I guess that makes sense. Kind of like how Infocom was compiling their software on a VAX, and distributing it to the micros.

But it's weird to think about how much Lisp/Smalltalk related stuff came out of Apple in the 80s and 90s. I can't imagine them doing that stuff now.

Re: Symbolics Lisp Machine Museum

#120
post #115

Earlier quoted context omitted.

It's not a problem, really, I just think it's a good idea to tell people if you're citing your own pages, in general. It's by no means awful to do so, but it's better to let people know, so they don't think that your claim is corroborated by an external source when it isn't. If you think I have a problem with you, or something, I don't. So don't worry about it.

The source is well-known and long-time Lisper Mikel Evins who worked for Apple in various projects and also in these projects where Lisp-based operating systems were developed. Mikel has multiple times mentioning and describing this work. You even find it here on Hackernews, where he is a user. Just google for it. I see that he is even participating in this thread now.

Fair enough. That does make sense, I guess.

Sorry for giving you grief over... everything, but I can't say I entirely regret it. I learned a lot that I wouldn't have otherwise, which is why I use HN in the first place.

Post reply on HN