Symbolics Lisp Machine Museum

Re:Symbolics Lisp Machine Museum by qwertyuiop924 on Thursday October 13, 2016 @07:48PM (#12705153)

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-purpose tool.

[ Parent | on HN ]

Re:Symbolics Lisp Machine Museum by lispm on Thursday October 13, 2016 @08:09PM (#12705271)

It feels very different.

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

   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.

[ Parent | on HN ]

Re:Symbolics Lisp Machine Museum by qwertyuiop924 on Thursday October 13, 2016 @08:37PM (#12705383)

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.

[ Parent | on HN ]

Re:Symbolics Lisp Machine Museum by lispm on Thursday October 13, 2016 @09:18PM (#12705547)

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

[ Parent | on HN ]

Re:Symbolics Lisp Machine Museum by qwertyuiop924 on Thursday October 13, 2016 @10:04PM (#12705695)

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.

[ Parent | on HN ]

Re:Symbolics Lisp Machine Museum by crististm on Friday October 14, 2016 @04:18AM (#12706742)

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

[ Parent | on HN ]

Re:Symbolics Lisp Machine Museum by qwertyuiop924 on Friday October 14, 2016 @06:53AM (#12707251)

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 having trouble finding the relative upshot."

[ Parent | on HN ]

Re:Symbolics Lisp Machine Museum by crististm on Friday October 14, 2016 @07:34AM (#12707408)

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.

[ Parent | on HN ]

Re:Symbolics Lisp Machine Museum by qwertyuiop924 on Friday October 14, 2016 @12:51PM (#12709352)

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

[ Parent | on HN ]