5 ms·

The Hidden Origins of Lisp (2015)

64 points by abrax3141 4y ago

roenxi 4y ago
While Lisp had to have some path from then to now, it is interesting to ask how important the mathematical foundations really are. Lisp is really a celebration of the humble function - everything bar nothing is some variant of (function arg arg arg). While the mathematicians were the first people to isolate that it seems quite likely it would have been naturally discovered from the engineering branch of programming when someone started trying to push the bounds of a macro system and realised that all the syntax was getting the way. I suspect Lisp has incredible longevity because it is nearly impossible to simplify down from functions. The approach also seems to breed a certain level of flexibility that other languages struggle to match - I have seen software that does a better job of editing text than Emacs, but I have not seen software more capable of taking on any challenge. Even Excel doesn't have quite the same level plumbing-exposed openness that can be achieved with a raw stack of functions. But I think alien civilisations would also invent Common Lisp, although they might use square brackets or somesuch.
- tasuki 4y ago
  > But I think alien civilisations would also invent Common Lisp Not Scheme? Common Lisp seems a more arbitrary to me...
  - bmitc 4y ago
    Scheme is so nice. Common Lisp is much more of an amalgamation of ideas.
- agumonkey 4y ago
  many languages had functions but not functions over functions (algol had downward but not upward), there's a level of genericity in lisp that I believe came from the math side of things because they dealt with ideas rather than machine architecture
- mark_l_watson 4y ago
  Sorry for being a little off topic: I think that Lisp languages are long lived because of how the code looks visually. Because of needing to use deep learning in most things I do, I need to use Python more often than I would like. It makes me happy looking at Lisp code in my editor, not so much Python code.
  - wslh 4y ago
    Really curious: what is nice about looking at Lisp code [aesthetically] in your editor? I find the multiple parenthesis weird in large codebases. I am not a Lisp developer, just limited knowledge playing and interacting with AutoLISP [1], Racket (love what I see in the REPL there), and really appreciate the idea of seeing things in function terms. [1] https://en.wikipedia.org/wiki/AutoLISP https://en.wikipedia.org/wiki/AutoLISP
    - medo-bear 4y ago
      not op but for me structured editing is one of the biggest pluses when it comes to editing lisp code. here is a good example of what i mean [0]. btw autolisp standard formating is kind of an anti-example of good lisp formating. in emacs lots of excellent tools exist to make parantheses an extremely helpful feature [1] [0] https://m.youtube.com/watch?v=D6h5dFyyUX0 https://m.youtube.com/watch?v=D6h5dFyyUX0 [1] http://www.loper-os.org/wp-content/parphobia.png http://www.loper-os.org/wp-content/parphobia.png
      - 0x445442 4y ago
        What I don’t like about the LISP syntax is not the parens but the inside out nature of a lot of LISP code. It’s the same reason I don’t care for NodeJS code. However, a lot of the imperative Common Lisp code I’ve seen is not nearly as jarring.
        kazinator 4y ago
        Lisp must be read outside->in to understand what it is saying. Given (foo (a) (b c)), if you don't know what foo is and just start reading (b c), which is inside, hoping that later you can work out what is foo, you could be going down a blind alley. foo could be a macro or special operator which entirely controls what (b c) means, and so if you have no idea what foo is, it follows that your guess about what (b c) means could be completely wrong. To understand what is calculated in Lisp, given that you understand what the syntax means, the evaluation is inside->out (that is, if the syntax is an ordinary expression made of nested function calls, and not something with a custom evaluation order). That's no different from math. In any languages that have math-like nested expressions with bracketing, you have inside-out evaluation. The alternative are catenative languages and such, which have never been mainstream. There are assembly languages which go line by line. Imperative languages with statements and expressions tend to have small expressions where evaluation is followed inside-out; the rest of the control flow is just top down, with some forward and backward skips. Lisp has all of the above in it. Lisp can be assembly language. For instance, in this source file from Clozure Common Lisp: https://github.com/Clozure/ccl/blob/master/level-0/ARM/arm-hash.lisp https://github.com/Clozure/ccl/blob/master/level-0/ARM/arm-h... (defarmlapfunction fast-mod-3 ((number arg_x) (divisor arg_y) (recip arg_z)) (mov imm0 (:lsr number (:$ arm::fixnumshift))) (smull imm2 imm1 imm0 recip) (mul imm0 imm1 divisor) (sub number number imm0) (sub number number divisor) (mov imm0 (:asr number (:$ (1- arm::nbits-in-word)))) (and divisor divisor imm0) (add arg_z number divisor) (bx lr)) It's just ARM code, ending in a "bx lr" and everything. The Lisp can be anything requires a jump in intellectual maturity and mental flexibility. You have to approach everything you might see in an unfamiliar Lisp project with an open mind, prepared for anything. Now that's true in any large system --- but not in a way where it is rolled into one unifying syntax. If a non-Lisp project has ARM assembly in it, it might just be conventional syntax. So you are hit on the head with a hammer: "this is obviously not the Foo language; it looks totally different". Suppose you are some newbie and don't know what ARM assembly language is; you still know that the files are something special and different. If you're a newbie not knowing what ARM assembly is and see that in Lisp code, you just think that it's just more indecipherable Lisp weirdness. You just barely learned car and cdr and now you have (bx lr) and smull. Man, Lisp is weird!
- Jtsummers 4y ago
  > The approach also seems to breed a certain level of flexibility that other languages struggle to match - I have seen software that does a better job of editing text than Emacs, but I have not seen software more capable of taking on any challenge. I think the author would agree with you. In the last post of the series (https://blog.lfe.io/excerpts/2015/03/27/1101-the-hidden-origins-of-lisp-future/ https://blog.lfe.io/excerpts/2015/03/27/1101-the-hidden-orig...): > And here the answer arrives, not as some astounding epiphany, but again in humble simplicity: Lisp's fun and its beauty rest not only in its syntactic elegance but in its power of expression. This is specifically important for the adventurer: if you want to create something new, explore some new programmatic territory, you need tools at your fingertips which will allow you to do so flexibly and quickly, with as little overhead as possible. Otherwise the moment of inspiration can be to quickly lost, the creative process swallowed in a mire too heavy with infrastructure and process. Sadly it looks like their effort to translate SICP to LFE stalled out a long time ago.
- abrax3141 4y ago
  This is going to sound slightly insane, but for me, having used lisp for almost as old as lisp is (okay, a decade less, but what’s a decade among old friends?), what I find is that I can simply think the computation I want, and essentially type it in exactly as I think it, close the parens and it simply works. Now, of course not all the functions that I thought, or the particular way that I expressed things already existed in which case you have a problem. But for Lisp the problem is just a subgoal and you simply define the functions you want recursing through the think-aloud process. Or if the form of expression doesn’t exist then a macro quickly handles that. (I literally did this very thing this morning, solving a 538 Riddler puzzle. I just sort of thought the method, typed it in, had to write one function I had thought but didn’t exist, and it just worked. It’s like smooth coffee!)
  - abrax3141 4y ago
    Ps. It doesn’t hurt that it has a built-in gdb.
  - kaveh808 4y ago
    Have developed in Lisp on and off since the early 80's, mostly 3D graphics, and have recently returned to it with a vengeance. Lisp is the only language I have used where I didn't feel as if the language was fighting me. Smooth indeed.
    - agumonkey 4y ago
      you were in the CGI industry ? I remember how advanced nichimen mirai (lisp based) was compared to most 3d animation packages, and seeing how easy it is to manipulate complex data and infer new ideas i'm not surprised it led to nicer software compared to c/cpp based ones.
      - kaveh808 4y ago
        It had interesting features due to being based on Lisp. Primarily its integration into Genera and its extensibility. But it never caught on in a significant way. I have been sort of following in its footsteps (at least philosophically) with my latest 3D project in CL.

64 points by abrax3141 4y ago

While Lisp had to have some path from then to now, it is interesting to ask how important the mathematical foundations really are. Lisp is really a celebration of the humble function - everything bar nothing is some variant of (function arg arg arg). While the mathematicians were the first people to isolate that it seems quite likely it would have been naturally discovered from the engineering branch of programming when someone started trying to push the bounds of a macro system and realised that all the syntax was getting the way. I suspect Lisp has incredible longevity because it is nearly impossible to simplify down from functions. The approach also seems to breed a certain level of flexibility that other languages struggle to match - I have seen software that does a better job of editing text than Emacs, but I have not seen software more capable of taking on any challenge. Even Excel doesn't have quite the same level plumbing-exposed openness that can be achieved with a raw stack of functions. But I think alien civilisations would also invent Common Lisp, although they might use square brackets or somesuch.

tasuki 4y ago
> But I think alien civilisations would also invent Common Lisp Not Scheme? Common Lisp seems a more arbitrary to me...
- bmitc 4y ago
  Scheme is so nice. Common Lisp is much more of an amalgamation of ideas.
agumonkey 4y ago
many languages had functions but not functions over functions (algol had downward but not upward), there's a level of genericity in lisp that I believe came from the math side of things because they dealt with ideas rather than machine architecture
mark_l_watson 4y ago
Sorry for being a little off topic: I think that Lisp languages are long lived because of how the code looks visually. Because of needing to use deep learning in most things I do, I need to use Python more often than I would like. It makes me happy looking at Lisp code in my editor, not so much Python code.
- wslh 4y ago
  Really curious: what is nice about looking at Lisp code [aesthetically] in your editor? I find the multiple parenthesis weird in large codebases. I am not a Lisp developer, just limited knowledge playing and interacting with AutoLISP [1], Racket (love what I see in the REPL there), and really appreciate the idea of seeing things in function terms. [1] https://en.wikipedia.org/wiki/AutoLISP https://en.wikipedia.org/wiki/AutoLISP
  - medo-bear 4y ago
    not op but for me structured editing is one of the biggest pluses when it comes to editing lisp code. here is a good example of what i mean [0]. btw autolisp standard formating is kind of an anti-example of good lisp formating. in emacs lots of excellent tools exist to make parantheses an extremely helpful feature [1] [0] https://m.youtube.com/watch?v=D6h5dFyyUX0 https://m.youtube.com/watch?v=D6h5dFyyUX0 [1] http://www.loper-os.org/wp-content/parphobia.png http://www.loper-os.org/wp-content/parphobia.png
    - 0x445442 4y ago
      What I don’t like about the LISP syntax is not the parens but the inside out nature of a lot of LISP code. It’s the same reason I don’t care for NodeJS code. However, a lot of the imperative Common Lisp code I’ve seen is not nearly as jarring.
      - kazinator 4y ago
        Lisp must be read outside->in to understand what it is saying. Given (foo (a) (b c)), if you don't know what foo is and just start reading (b c), which is inside, hoping that later you can work out what is foo, you could be going down a blind alley. foo could be a macro or special operator which entirely controls what (b c) means, and so if you have no idea what foo is, it follows that your guess about what (b c) means could be completely wrong. To understand what is calculated in Lisp, given that you understand what the syntax means, the evaluation is inside->out (that is, if the syntax is an ordinary expression made of nested function calls, and not something with a custom evaluation order). That's no different from math. In any languages that have math-like nested expressions with bracketing, you have inside-out evaluation. The alternative are catenative languages and such, which have never been mainstream. There are assembly languages which go line by line. Imperative languages with statements and expressions tend to have small expressions where evaluation is followed inside-out; the rest of the control flow is just top down, with some forward and backward skips. Lisp has all of the above in it. Lisp can be assembly language. For instance, in this source file from Clozure Common Lisp: https://github.com/Clozure/ccl/blob/master/level-0/ARM/arm-hash.lisp https://github.com/Clozure/ccl/blob/master/level-0/ARM/arm-h... (defarmlapfunction fast-mod-3 ((number arg_x) (divisor arg_y) (recip arg_z)) (mov imm0 (:lsr number (:$ arm::fixnumshift))) (smull imm2 imm1 imm0 recip) (mul imm0 imm1 divisor) (sub number number imm0) (sub number number divisor) (mov imm0 (:asr number (:$ (1- arm::nbits-in-word)))) (and divisor divisor imm0) (add arg_z number divisor) (bx lr)) It's just ARM code, ending in a "bx lr" and everything. The Lisp can be anything requires a jump in intellectual maturity and mental flexibility. You have to approach everything you might see in an unfamiliar Lisp project with an open mind, prepared for anything. Now that's true in any large system --- but not in a way where it is rolled into one unifying syntax. If a non-Lisp project has ARM assembly in it, it might just be conventional syntax. So you are hit on the head with a hammer: "this is obviously not the Foo language; it looks totally different". Suppose you are some newbie and don't know what ARM assembly language is; you still know that the files are something special and different. If you're a newbie not knowing what ARM assembly is and see that in Lisp code, you just think that it's just more indecipherable Lisp weirdness. You just barely learned car and cdr and now you have (bx lr) and smull. Man, Lisp is weird!
Jtsummers 4y ago
> The approach also seems to breed a certain level of flexibility that other languages struggle to match - I have seen software that does a better job of editing text than Emacs, but I have not seen software more capable of taking on any challenge. I think the author would agree with you. In the last post of the series (https://blog.lfe.io/excerpts/2015/03/27/1101-the-hidden-origins-of-lisp-future/ https://blog.lfe.io/excerpts/2015/03/27/1101-the-hidden-orig...): > And here the answer arrives, not as some astounding epiphany, but again in humble simplicity: Lisp's fun and its beauty rest not only in its syntactic elegance but in its power of expression. This is specifically important for the adventurer: if you want to create something new, explore some new programmatic territory, you need tools at your fingertips which will allow you to do so flexibly and quickly, with as little overhead as possible. Otherwise the moment of inspiration can be to quickly lost, the creative process swallowed in a mire too heavy with infrastructure and process. Sadly it looks like their effort to translate SICP to LFE stalled out a long time ago.
abrax3141 4y ago
This is going to sound slightly insane, but for me, having used lisp for almost as old as lisp is (okay, a decade less, but what’s a decade among old friends?), what I find is that I can simply think the computation I want, and essentially type it in exactly as I think it, close the parens and it simply works. Now, of course not all the functions that I thought, or the particular way that I expressed things already existed in which case you have a problem. But for Lisp the problem is just a subgoal and you simply define the functions you want recursing through the think-aloud process. Or if the form of expression doesn’t exist then a macro quickly handles that. (I literally did this very thing this morning, solving a 538 Riddler puzzle. I just sort of thought the method, typed it in, had to write one function I had thought but didn’t exist, and it just worked. It’s like smooth coffee!)
- abrax3141 4y ago
  Ps. It doesn’t hurt that it has a built-in gdb.
- kaveh808 4y ago
  Have developed in Lisp on and off since the early 80's, mostly 3D graphics, and have recently returned to it with a vengeance. Lisp is the only language I have used where I didn't feel as if the language was fighting me. Smooth indeed.
  - agumonkey 4y ago
    you were in the CGI industry ? I remember how advanced nichimen mirai (lisp based) was compared to most 3d animation packages, and seeing how easy it is to manipulate complex data and infer new ideas i'm not surprised it led to nicer software compared to c/cpp based ones.
    - kaveh808 4y ago
      It had interesting features due to being based on Lisp. Primarily its integration into Genera and its extensibility. But it never caught on in a significant way. I have been sort of following in its footsteps (at least philosophically) with my latest 3D project in CL.