12 ms·

History of Lisp Editing

157 points by lemming 9y ago

timonoko 9y ago
Teletype Lisp editor was really amazing experience. I got the idea I could do something similar to natural languages. Especially Finnish Language, which contains very long words, and the end of those words do not necessarily need to be printed out to aid comprehension. So chapters and paragraphs and sentences would be like S-expressions in Interlisp Editor, only first few words showing and first few letters printed out in worlds. Unfortunately this grand idea never came real, because they did not give me extra teletype time in 1974.
white-flame 9y ago
I'd like to find out how people tolerate ()[]{};,. in their programming, in far greater quantities and in more complex interspersal than Lisp's parens. )]];));}}};
- moxious 9y ago
  I think it's about visual parsing. They may be greater in number in C derived languages but it's not idiomatic or considered clean by anyone to write it as you did, where it's typical to see things like )))))) in lisp. If there were multiple markers stacked up in a C based language they'd be visually distinguished from one another ];} and you'd at least have a chance. Look, we can get used to anything so clearly the lisp way can work. But it seems pretty straightforward to me why people think it's visually confusing and why lisp gets made fun of. Simplicity in syntax is great but lisp really overdid it. If you invented a human language that could get by with only 12 letters, I wouldn't give you kudos for that because of the general principle that simplicity is good...
  - agumonkey 9y ago
    I understand and appreciate syntactic classification. But it's a false thing. It makes you care about syntax more than semantics.
  - DonaldFisk 9y ago
    There have been at least three attempts to change the syntax of Lisp, so that it looks more like Algol: Lisp 2, CGOL, and Dylan. None of these gained much traction. Lisp programmers prefer the parentheses. When you autoindent, the indentation of the code makes its underlying structure (AST) clear without having to count either parentheses in Lisp or braces in C. By the 1970s, autoindenting editors (EMACS) and structure editors had been developed for Lisp. In the C/Unix world, until recently, indentation and parenthesis/brace counting had to be done by hand. Among C programmers (but not, to their credit, Java programmers) there are still arguments about code layout, a problem solved decades ago for Lisp.
    - kazinator 9y ago
      > In the C/Unix world, until recently, indentation and parenthesis/brace counting had to be done by hand. Nope! The vi editor has a :set lisp mode, and a % command to jump to matching parens. I think that was already in vi in the 1980's. FWIW, % is described in POSIX; Lisp mode isn't.
      - DonaldFisk 9y ago
        Ta. I just tried it. If it's all the same with you I think I'll stick with Emacs. :-) What I was trying to say is that these things are easier to do by hand in C than in Lisp, but more difficult to do algorithmically, and this discouraged people developing syntax-aware editors, and encouraged the plethora of competing C styles. In the Lisp world, the difficulty of doing these by hand resulted in earlier syntax aware editors and the consensus on style.
        kazinator 9y ago
        In Lisp style, there is a "local maximum" (global?). Deviations from the style are obvious losers. In C, there are many choices, which are all viable. int main(void) { FILE *f = fopen("commands", "r"); if (f) { char line[512]; while (fgets(line, sizeof line, f)) { ... } fclose(f); return 0; } else { printf("failed to open file\n"); exit(EXIT_FAILURE); } }
  - flavio81 9y ago
    The thing is, if you actually set yourself out to create an application in Lisp, and you do learn the language and the tools made for programming in that language, not only you will have no problem with parentheses... ... but you also will find that most of your code is highly readable! Lisp code (or at least Common Lisp code) can be highly readable. I never need to count parenthesis to understand code. The indentation itself makes the structure obvious. And if there is any doubt, the editor (say, Emacs) will tell me where each expression ends. > "But it seems pretty straightforward to me why people think it's visually confusing and why lisp gets made fun of." "Appearances" are not the same as "reality".
- munificent 9y ago
  You know, I think it's a fine argument to say, "Yes, Lisp has a lot of parentheses but we like how it looks." I don't think it makes sense to say, "No, other languages have more punctuation characters than Lisp." The latter is an objective statement that can be actually tested. I went to Rosetta Code and grabbed the implementations of Conway's Game of Life in Racket, Ruby, Python, and Java. For each one, I manually removed comments and string literals. Then I wrote a little script. It looks at each character in the file and groups them into categories: bracket: ()[]{} whitespace: space\t\r\n text: a-zA-Z01-9_ punctuation: =,;<>-'!|?:#/*%+. Then I looked at each file to see what fraction of non-whitespace characters are brackets or punctuation (including brackets). Here's the results: bracket punctuation life.java 13.25% 27.52% life.py 13.27% 21.95% life.rb 9.56% 23.73% life.scm 22.29% 28.30% The Racket implementation has roughly twice as many bracketing characters as the other languages, and more of all kinds of punctuation than any of them. It may be that the languages and example programs I chose aren't representative, but I'd be surprised if another corpus was significantly different. Most languages have multiple levels of precedence. The entire point of that is to allow eliding explicit bracketing characters for commonly nested subexpressions. You may dislike that feature, which is reasonable. But I don't think you can argue that it doesn't exist and doesn't accomplish what it intends to do. Consider: var isCloser = x1 * x1 + y1 * y1 < x2 * x2 + y2 * y2 // 0 brackets (define is-closer (< (+ (* x1 x1) (* y1 y1)) (+ (* x2 x2) (* y2 y2)))) ; 16 brackets
  - yorwba 9y ago
    I think most of the non-bracket "punctuation" in Racket is caused by the kebab-case identifiers and to a lesser degree by ? and ! in function names. So in fact "Other languages have more punctuation characters than Lisp." is not an objective statement at all, since it relies on the definition of punctuation, which is subjective or at least language-specific.
    - munificent 9y ago
      Good point. I updated my little script to (roughly) take each language's identifier rules into account. Now "?" is considered an identifier character in Ruby and "-", "!", and "?" are punctuation in Racket. It gets a little fuzzy, of course because ">" works like punctuation in "(> 1 2)" but less so in "(number->string 123)". bracket punctuation life.java 13.25% 27.52% life.py 13.27% 21.95% life.rb 9.56% 23.29% life.scm 22.29% 24.81% This gets Racket down to having similar levels of punctuation but note that, of course, brackets are still significantly more common than other languages.
escherize 9y ago
I incorporated parinfer into my reagent live coding environment here[1], and it's been working pretty well. I have also used Atom with Parinfer to teach a nontechnical designer the basics of clojure. Enough to build templates using hiccup for her resume, and personal website. I don't think smartparens or paredit would be anywhere near as easy for her to pick up. If you're used to indentation being meaningful as some langs do, you should probably try out clojure/script with parinfer. [1]: http://escherize.com/cljsfiddle http://escherize.com/cljsfiddle
- hellofunk 9y ago
  Would be nice to see some examples on that page about how to actually use parinfer commands. Or maybe you have that explained on a different page? edit: I see, the point of parinfer is to not use commands or hot keys. I'm going to play with your site and if the slurp/barf behavior is any better than paredit.
torrent-of-ions 9y ago
I started to use paredit early in my Lisp career and never looked back. I tried smartparens but found it annoying (I find it much harder to change my tools these days). Parinfer looks very clever, but I'm not afraid of "hotkeys" (I use emacs) and I don't want to do manual indentation. Is there any benefit over paredit for me?
- lgas 9y ago
  I'm a paredit user too and I tried but couldn't make the switch to parinfer. I think there's just too much muscle memory I'm fighting against. But I've heard that parinfer was much easier to pick up from two separate people that were just learning Clojure, for whatever that's worth.
- agumonkey 9y ago
  I too stucked with paredit, it's a very beneficial sweet spot. Parinfer adds lots of sugar, sometimes very helpful (switching layout, automatic ones). I'll give it a spin but I'm not sure I'll drop paredit (maybe because of loyalty)
- Myrmornis 9y ago
  I also use paredit. I haven't learned many of the advanced operations or keyboard shortcuts, it does the right thing intuitively just by using open/close paren and forward/backward/kill line/kill word etc. EDIT: I don't mean that to sound critical of parinfer development. Developing the software on top of a formal relationship between indentation and parens sounds like a very interesting and laudable approach. What I'd love to see is work on producing relaxed modes inheriting from paredit for use in non-lisps such as python.I use a very slightly modified paredit for python and have done every day for years. It gets it 95% right. https://github.com/dandavison/paredit-c https://github.com/dandavison/paredit-c
kgwgk 9y ago
> I'd like to find out how people tolerated parens back in the golden days of Lisp. Why is it so unimaginable that people can just live with all those parentheses? The only parenthesis-related fragment in my .emacs is the following: (keyboard-translate ?\( ?\[) (keyboard-translate ?\[ ?\() (keyboard-translate ?\) ?\]) (keyboard-translate ?\] ?\)) I guess all the listed approaches may make things easier once you get used to them, but I'm sure I'm not the only one writing parentheses one by one.
- pjmlp 9y ago
  Apparently moving from puts("Hello") to (puts "Hello") Or for example if (i < x) { puts ("low"); } else { puts ("high"); } to (if (< i x) (puts "low") (puts "high") ) Is very complex.
  - mpweiher 9y ago
    Yeah, actually it is. That despite the examples being seemingly somewhat contrived and the comparison also not so good. Prefix notation is hard, at least for people whose native language is S-V-O, and not V-S-O. So i < x reads naturally: "i is smaller than x". On the other hand: < i x reads unnaturally: "is smaller than i x". It's not a huge deal individually, but it does add up. And of course the extra level of parens is necessary(?) in LISP. "if" is interesting, because it seems to do fine in prefix notation, and puts() is also a bit weird because its subject is missing/implied: stdout puts:"hello". But in general I find it more surprising that prefix-y notation is as acceptable as it is for most function calls, despite the fact that, when offered, infix notation is considered more "natural" or even more "built-in", than that applying it to even more situations is considered difficult.
    - jesse_m 9y ago
      I like to read my code in plain english too but I tend to change how I make a sentence from code when dealing with prefix notation. Like instead of "is smaller than i x", I read that as "compare i and x". Of course that doesn't hold for all cases. I just find I have to change my thinking a bit when dealing with Lisp and OCaml and C, making the way I read my code change too.
Grue3 9y ago
I don't use paredit or similar extensions to code Lisp. Just bare Emacs (with SLIME, of course) is enough. The closing parens that I didn't type are distracting. If there's so much parentheses in your code that you're tired of closing them, maybe it needs a refactoring?
- triclops200 9y ago
  > tired of closing them This comment misses the point entirely. The point isn't to mitigate having to type them, it's to help keep structural preservation. All of these structural editors also do so much more than just close the parens. They allow you to edit the code as the tree it is as well as navigate it as such. Without the parens actually being there, you couldn't do that in a determininistic way, thus the auto-closing of parens is more of a side effect than anything else.
  - yvdriess 9y ago
    Indeed. Or to simplify: - At no point during the editing process do you have an invalid s-expression. - You manipulate the code datastructure, not the code text.
  - lispm 9y ago
    The feature to navigate/manipulate s-expressions is available in most Lisp text-based editors. That's not a special feature.
  - breck 9y ago
    You actually don't need parentheses--you can use whitespace. You give up the ability to add N arbitrary trees/nodes to one line, but in return you get beautiful, geometric code that's easier to reason about at scale.
    - deleted 9y ago
      [deleted]
    - ohyes 9y ago
      I do this too. ctrl-meta-q is really all I need... Sometimes i'll do rainbow parens if i'm feeling festive.
anon1253 9y ago
Very interesting! paredit + agressive-indent made my life so much easier. Now I don't have to worry about parens OR indentation. Unless you work with people who have different preferences of course, but for my own stuff I generally stopped trying to fight agressive-indent (at least it's consistent).
MarkMMullin 9y ago
kb-emacs should be on that list too, I would think
linkmotif 9y ago
Hah, fun: > Debating Maclisp vs Interlisp (i.e. storing code as text vs structure) This really puts "tabs vs. spaces" to shame.
- AceJohnny2 9y ago
  I found this the most interesting. For one thing reminding me of Erik Naggum's existence, insight, and causticity[1], and for another exploring what seems to be a promising but dead branch of programming. As we continue wishing we had "better ways to write programs", constantly re-exploring visual programming (Scratch and its spinoffs), it's interesting to me that the ALGOL-children (C and the like) have completely lost this way of developing programs. What is there to learn, both from the technology itself and from how we forget? [1] https://en.wikiquote.org/wiki/Erik_Naggum https://en.wikiquote.org/wiki/Erik_Naggum
cat199 9y ago
no expert at all; was before my time - But probably worth spending some time with ITS, TOPS-10, and TOPS-20 & digging around with TECO and its descendants which came to be emacs, and probably checking into 4.2/4.3BSD as well.. The former group is pretty much the platform for early LISP (when lisp was still in caps :b ), and the latter, well, alot of good stuff happened here.. plus built in franz lisp and the lisp mode for (real) vi ..
deleted 9y ago
[deleted]
gumby 9y ago
D-Edit was already around when I got to PARC in late 1983. The first thing I worked on was an Emacs in Interlisp-D. I think ITS Emacs (written in TECO) had paren matching before the CADR Lisp machines (what you call Zmacs, but it was EINE originally). The first Emacs written in Lisp was Multics Emacs (written by Bernie Greenberg) and it had paren matching when I used it but that was 81/82 timeframe. What do you call paren matching by the way? Emacs always had structure navigation (c-m-F/B and c-m-U etc) in which case that support went back into the 1970s. (BTW the first Emacs-like editor for the lispms was EINE (Eine Is Not Emacs); it was replaced by ZWEI (Zwei Was Eine Initially). Look at a German dictionary if that is not funny. IIRC Zmacs was a renaming by Symbolics as part of their efforts to move beyond the AI lab implementation (While LMI/TI continued to sync back to the AI lab sources).
- ScottBurson 9y ago
  Hi Gumby! You're missing a close paren at the end there :-) ETA: are you sure about the timeline? I thought Multics Emacs was something of a reaction to EINE/ZWEI -- I seem to recall that Bernie didn't like the fact that all the editing primitives required an explicit point argument; he made point implicit, a design decision that was copied in Gosling Emacs. Well, that's my recollection anyway.
- rjsw 9y ago
  There are emulators for the MIT, LMI and TI machines that can be used to get a feel for ZWEI or to generate screenshots.
- lispm 9y ago
  EINE was the first Emacs written in Lisp. Actually Lisp Machine Lisp by the then young Dan Weinreb at the age of 17. Dan passed away way too early a few years ago. https://en.wikipedia.org/wiki/Daniel_Weinreb https://en.wikipedia.org/wiki/Daniel_Weinreb
- gumby 9y ago
  lispm, ScottBurson: yes I think I have eine/multics Emacs backwards...it was a long time ago!

157 points by lemming 9y ago

Teletype Lisp editor was really amazing experience. I got the idea I could do something similar to natural languages. Especially Finnish Language, which contains very long words, and the end of those words do not necessarily need to be printed out to aid comprehension. So chapters and paragraphs and sentences would be like S-expressions in Interlisp Editor, only first few words showing and first few letters printed out in worlds. Unfortunately this grand idea never came real, because they did not give me extra teletype time in 1974.

white-flame 9y ago

I'd like to find out how people tolerate ()[]{};,. in their programming, in far greater quantities and in more complex interspersal than Lisp's parens. )]];));}}};

moxious 9y ago
I think it's about visual parsing. They may be greater in number in C derived languages but it's not idiomatic or considered clean by anyone to write it as you did, where it's typical to see things like )))))) in lisp. If there were multiple markers stacked up in a C based language they'd be visually distinguished from one another ];} and you'd at least have a chance. Look, we can get used to anything so clearly the lisp way can work. But it seems pretty straightforward to me why people think it's visually confusing and why lisp gets made fun of. Simplicity in syntax is great but lisp really overdid it. If you invented a human language that could get by with only 12 letters, I wouldn't give you kudos for that because of the general principle that simplicity is good...
- agumonkey 9y ago
  I understand and appreciate syntactic classification. But it's a false thing. It makes you care about syntax more than semantics.
- DonaldFisk 9y ago
  There have been at least three attempts to change the syntax of Lisp, so that it looks more like Algol: Lisp 2, CGOL, and Dylan. None of these gained much traction. Lisp programmers prefer the parentheses. When you autoindent, the indentation of the code makes its underlying structure (AST) clear without having to count either parentheses in Lisp or braces in C. By the 1970s, autoindenting editors (EMACS) and structure editors had been developed for Lisp. In the C/Unix world, until recently, indentation and parenthesis/brace counting had to be done by hand. Among C programmers (but not, to their credit, Java programmers) there are still arguments about code layout, a problem solved decades ago for Lisp.
  - kazinator 9y ago
    > In the C/Unix world, until recently, indentation and parenthesis/brace counting had to be done by hand. Nope! The vi editor has a :set lisp mode, and a % command to jump to matching parens. I think that was already in vi in the 1980's. FWIW, % is described in POSIX; Lisp mode isn't.
    - DonaldFisk 9y ago
      Ta. I just tried it. If it's all the same with you I think I'll stick with Emacs. :-) What I was trying to say is that these things are easier to do by hand in C than in Lisp, but more difficult to do algorithmically, and this discouraged people developing syntax-aware editors, and encouraged the plethora of competing C styles. In the Lisp world, the difficulty of doing these by hand resulted in earlier syntax aware editors and the consensus on style.
      - kazinator 9y ago
        In Lisp style, there is a "local maximum" (global?). Deviations from the style are obvious losers. In C, there are many choices, which are all viable. int main(void) { FILE *f = fopen("commands", "r"); if (f) { char line[512]; while (fgets(line, sizeof line, f)) { ... } fclose(f); return 0; } else { printf("failed to open file\n"); exit(EXIT_FAILURE); } }
- flavio81 9y ago
  The thing is, if you actually set yourself out to create an application in Lisp, and you do learn the language and the tools made for programming in that language, not only you will have no problem with parentheses... ... but you also will find that most of your code is highly readable! Lisp code (or at least Common Lisp code) can be highly readable. I never need to count parenthesis to understand code. The indentation itself makes the structure obvious. And if there is any doubt, the editor (say, Emacs) will tell me where each expression ends. > "But it seems pretty straightforward to me why people think it's visually confusing and why lisp gets made fun of." "Appearances" are not the same as "reality".
munificent 9y ago
You know, I think it's a fine argument to say, "Yes, Lisp has a lot of parentheses but we like how it looks." I don't think it makes sense to say, "No, other languages have more punctuation characters than Lisp." The latter is an objective statement that can be actually tested. I went to Rosetta Code and grabbed the implementations of Conway's Game of Life in Racket, Ruby, Python, and Java. For each one, I manually removed comments and string literals. Then I wrote a little script. It looks at each character in the file and groups them into categories: bracket: ()[]{} whitespace: space\t\r\n text: a-zA-Z01-9_ punctuation: =,;<>-'!|?:#/*%+. Then I looked at each file to see what fraction of non-whitespace characters are brackets or punctuation (including brackets). Here's the results: bracket punctuation life.java 13.25% 27.52% life.py 13.27% 21.95% life.rb 9.56% 23.73% life.scm 22.29% 28.30% The Racket implementation has roughly twice as many bracketing characters as the other languages, and more of all kinds of punctuation than any of them. It may be that the languages and example programs I chose aren't representative, but I'd be surprised if another corpus was significantly different. Most languages have multiple levels of precedence. The entire point of that is to allow eliding explicit bracketing characters for commonly nested subexpressions. You may dislike that feature, which is reasonable. But I don't think you can argue that it doesn't exist and doesn't accomplish what it intends to do. Consider: var isCloser = x1 * x1 + y1 * y1 < x2 * x2 + y2 * y2 // 0 brackets (define is-closer (< (+ (* x1 x1) (* y1 y1)) (+ (* x2 x2) (* y2 y2)))) ; 16 brackets
- yorwba 9y ago
  I think most of the non-bracket "punctuation" in Racket is caused by the kebab-case identifiers and to a lesser degree by ? and ! in function names. So in fact "Other languages have more punctuation characters than Lisp." is not an objective statement at all, since it relies on the definition of punctuation, which is subjective or at least language-specific.
  - munificent 9y ago
    Good point. I updated my little script to (roughly) take each language's identifier rules into account. Now "?" is considered an identifier character in Ruby and "-", "!", and "?" are punctuation in Racket. It gets a little fuzzy, of course because ">" works like punctuation in "(> 1 2)" but less so in "(number->string 123)". bracket punctuation life.java 13.25% 27.52% life.py 13.27% 21.95% life.rb 9.56% 23.29% life.scm 22.29% 24.81% This gets Racket down to having similar levels of punctuation but note that, of course, brackets are still significantly more common than other languages.

escherize 9y ago

I incorporated parinfer into my reagent live coding environment here[1], and it's been working pretty well. I have also used Atom with Parinfer to teach a nontechnical designer the basics of clojure. Enough to build templates using hiccup for her resume, and personal website. I don't think smartparens or paredit would be anywhere near as easy for her to pick up. If you're used to indentation being meaningful as some langs do, you should probably try out clojure/script with parinfer. [1]: http://escherize.com/cljsfiddle http://escherize.com/cljsfiddle

hellofunk 9y ago
Would be nice to see some examples on that page about how to actually use parinfer commands. Or maybe you have that explained on a different page? edit: I see, the point of parinfer is to not use commands or hot keys. I'm going to play with your site and if the slurp/barf behavior is any better than paredit.

torrent-of-ions 9y ago

I started to use paredit early in my Lisp career and never looked back. I tried smartparens but found it annoying (I find it much harder to change my tools these days). Parinfer looks very clever, but I'm not afraid of "hotkeys" (I use emacs) and I don't want to do manual indentation. Is there any benefit over paredit for me?

lgas 9y ago
I'm a paredit user too and I tried but couldn't make the switch to parinfer. I think there's just too much muscle memory I'm fighting against. But I've heard that parinfer was much easier to pick up from two separate people that were just learning Clojure, for whatever that's worth.
agumonkey 9y ago
I too stucked with paredit, it's a very beneficial sweet spot. Parinfer adds lots of sugar, sometimes very helpful (switching layout, automatic ones). I'll give it a spin but I'm not sure I'll drop paredit (maybe because of loyalty)
Myrmornis 9y ago
I also use paredit. I haven't learned many of the advanced operations or keyboard shortcuts, it does the right thing intuitively just by using open/close paren and forward/backward/kill line/kill word etc. EDIT: I don't mean that to sound critical of parinfer development. Developing the software on top of a formal relationship between indentation and parens sounds like a very interesting and laudable approach. What I'd love to see is work on producing relaxed modes inheriting from paredit for use in non-lisps such as python.I use a very slightly modified paredit for python and have done every day for years. It gets it 95% right. https://github.com/dandavison/paredit-c https://github.com/dandavison/paredit-c

kgwgk 9y ago

> I'd like to find out how people tolerated parens back in the golden days of Lisp. Why is it so unimaginable that people can just live with all those parentheses? The only parenthesis-related fragment in my .emacs is the following: (keyboard-translate ?\( ?\[) (keyboard-translate ?\[ ?\() (keyboard-translate ?\) ?\]) (keyboard-translate ?\] ?\)) I guess all the listed approaches may make things easier once you get used to them, but I'm sure I'm not the only one writing parentheses one by one.

pjmlp 9y ago
Apparently moving from puts("Hello") to (puts "Hello") Or for example if (i < x) { puts ("low"); } else { puts ("high"); } to (if (< i x) (puts "low") (puts "high") ) Is very complex.
- mpweiher 9y ago
  Yeah, actually it is. That despite the examples being seemingly somewhat contrived and the comparison also not so good. Prefix notation is hard, at least for people whose native language is S-V-O, and not V-S-O. So i < x reads naturally: "i is smaller than x". On the other hand: < i x reads unnaturally: "is smaller than i x". It's not a huge deal individually, but it does add up. And of course the extra level of parens is necessary(?) in LISP. "if" is interesting, because it seems to do fine in prefix notation, and puts() is also a bit weird because its subject is missing/implied: stdout puts:"hello". But in general I find it more surprising that prefix-y notation is as acceptable as it is for most function calls, despite the fact that, when offered, infix notation is considered more "natural" or even more "built-in", than that applying it to even more situations is considered difficult.
  - jesse_m 9y ago
    I like to read my code in plain english too but I tend to change how I make a sentence from code when dealing with prefix notation. Like instead of "is smaller than i x", I read that as "compare i and x". Of course that doesn't hold for all cases. I just find I have to change my thinking a bit when dealing with Lisp and OCaml and C, making the way I read my code change too.

Grue3 9y ago

I don't use paredit or similar extensions to code Lisp. Just bare Emacs (with SLIME, of course) is enough. The closing parens that I didn't type are distracting. If there's so much parentheses in your code that you're tired of closing them, maybe it needs a refactoring?

triclops200 9y ago
> tired of closing them This comment misses the point entirely. The point isn't to mitigate having to type them, it's to help keep structural preservation. All of these structural editors also do so much more than just close the parens. They allow you to edit the code as the tree it is as well as navigate it as such. Without the parens actually being there, you couldn't do that in a determininistic way, thus the auto-closing of parens is more of a side effect than anything else.
- yvdriess 9y ago
  Indeed. Or to simplify: - At no point during the editing process do you have an invalid s-expression. - You manipulate the code datastructure, not the code text.
- lispm 9y ago
  The feature to navigate/manipulate s-expressions is available in most Lisp text-based editors. That's not a special feature.
- breck 9y ago
  You actually don't need parentheses--you can use whitespace. You give up the ability to add N arbitrary trees/nodes to one line, but in return you get beautiful, geometric code that's easier to reason about at scale.
  - deleted 9y ago
    [deleted]
  - ohyes 9y ago
    I do this too. ctrl-meta-q is really all I need... Sometimes i'll do rainbow parens if i'm feeling festive.

anon1253 9y ago

Very interesting! paredit + agressive-indent made my life so much easier. Now I don't have to worry about parens OR indentation. Unless you work with people who have different preferences of course, but for my own stuff I generally stopped trying to fight agressive-indent (at least it's consistent).

MarkMMullin 9y ago

kb-emacs should be on that list too, I would think

linkmotif 9y ago

Hah, fun: > Debating Maclisp vs Interlisp (i.e. storing code as text vs structure) This really puts "tabs vs. spaces" to shame.

AceJohnny2 9y ago
I found this the most interesting. For one thing reminding me of Erik Naggum's existence, insight, and causticity[1], and for another exploring what seems to be a promising but dead branch of programming. As we continue wishing we had "better ways to write programs", constantly re-exploring visual programming (Scratch and its spinoffs), it's interesting to me that the ALGOL-children (C and the like) have completely lost this way of developing programs. What is there to learn, both from the technology itself and from how we forget? [1] https://en.wikiquote.org/wiki/Erik_Naggum https://en.wikiquote.org/wiki/Erik_Naggum

cat199 9y ago

no expert at all; was before my time - But probably worth spending some time with ITS, TOPS-10, and TOPS-20 & digging around with TECO and its descendants which came to be emacs, and probably checking into 4.2/4.3BSD as well.. The former group is pretty much the platform for early LISP (when lisp was still in caps :b ), and the latter, well, alot of good stuff happened here.. plus built in franz lisp and the lisp mode for (real) vi ..

deleted 9y ago

[deleted]

gumby 9y ago

D-Edit was already around when I got to PARC in late 1983. The first thing I worked on was an Emacs in Interlisp-D. I think ITS Emacs (written in TECO) had paren matching before the CADR Lisp machines (what you call Zmacs, but it was EINE originally). The first Emacs written in Lisp was Multics Emacs (written by Bernie Greenberg) and it had paren matching when I used it but that was 81/82 timeframe. What do you call paren matching by the way? Emacs always had structure navigation (c-m-F/B and c-m-U etc) in which case that support went back into the 1970s. (BTW the first Emacs-like editor for the lispms was EINE (Eine Is Not Emacs); it was replaced by ZWEI (Zwei Was Eine Initially). Look at a German dictionary if that is not funny. IIRC Zmacs was a renaming by Symbolics as part of their efforts to move beyond the AI lab implementation (While LMI/TI continued to sync back to the AI lab sources).

ScottBurson 9y ago
Hi Gumby! You're missing a close paren at the end there :-) ETA: are you sure about the timeline? I thought Multics Emacs was something of a reaction to EINE/ZWEI -- I seem to recall that Bernie didn't like the fact that all the editing primitives required an explicit point argument; he made point implicit, a design decision that was copied in Gosling Emacs. Well, that's my recollection anyway.
rjsw 9y ago
There are emulators for the MIT, LMI and TI machines that can be used to get a feel for ZWEI or to generate screenshots.
lispm 9y ago
EINE was the first Emacs written in Lisp. Actually Lisp Machine Lisp by the then young Dan Weinreb at the age of 17. Dan passed away way too early a few years ago. https://en.wikipedia.org/wiki/Daniel_Weinreb https://en.wikipedia.org/wiki/Daniel_Weinreb
gumby 9y ago
lispm, ScottBurson: yes I think I have eine/multics Emacs backwards...it was a long time ago!