The Hidden Origins of Lisp (2015) | Hacker News Reader

The Hidden Origins of Lisp (2015)

blog.lfe.io

64 pointsabrax314120 comments

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.

> But I think alien civilisations would also invent Common Lisp

Not Scheme? Common Lisp seems a more arbitrary to me...

Scheme is so nice. Common Lisp is much more of an amalgamation of ideas.

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

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.

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

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

[1] http://www.loper-os.org/wp-content/parphobia.png

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.

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

Fair question! I have been coding in Lisp languages since the 1970s, and in Common Lisp since 1982. I am used to the syntax. I think it is beautiful.

what context did you use lisps in in the 70s ?

A big part of the aesthetics is that the specific glyphs for parentheses are curved in a way that suggests enclosure.

Suppose we replace ( with ^ and ) with $. The visual aesthetics is ruined. Or suppose we swap them: ) means ( and vice versa. Ditto.

Let's try it:

  (let ((s nil))
    (dotimes (i 16)
      (setq s (rbt-insert (1+ i) s)))
    (pp s))

^ is opening, $ is closing:

  ^let ^^s nil$$
    ^dotimes ^i 16$
      ^setq s ^rbt-insert ^1+ i$ s$$$
    ^pp s$$

) is opening, ( is closing:

  )let ))s nil((
    )dotimes )i 16(
      )setq s )rbt-insert )1+ i( s(((
    )pp s((

the reversal is slightly better than using random glyphs, because we can pretend that ) ( is suggesting closure in a different way. I don't think I could get used to this no matter how much time I put into it.

I can't escape the conclusion that the shape of the glyphs is important. The parens, being shaped the way they are, are making the code readable.

Wow. That’s really interesting. I wonder to what extent this is because we use them for natural writing (like this)? Also, note that the various boxer-derivatives use complete enclosure. But that just looks busy and rigid. The parens have both enclosure and fluidity.

I saw that you tried Julia for deep learning but decided against it. Why is that? I've recently started with it seeking higher productivity/spending less time piping between non-compatible python libraries.

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

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!)

Ps. It doesn’t hurt that it has a built-in gdb.

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.

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.

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.

Reply on news.ycombinator.com