Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Roots of Lisp (2001)

paulgraham.com

Post reply on HN
Print view View original

51–60 of 92 posts

Re: The Roots of Lisp (2001)

#51

Post by iLemming »

tabtab wrote: post #37
coldtea wrote: post #11

Earlier quoted context omitted.

"Some good concepts"? It was the first language to add "if/else" constructs, GC, closures, first class functions, reference semantics, and recursion. It took between 5 to 40 years before these became available in mainstream languages (conditionals like if/else were adopted early, GC not so much, closures took even more). Add to that macros and the flexibility of runtime evaluation / code creation, which most mainstre…

As far as "Lisp lacks visual clues", after many heated debates on this, I've concluded that the ugliness and rigidness of "production" languages enforces certain visual and syntactic standards that makes reading others' code easier. Indentation of Lisp won't "solve" this because production languages also can be indented. It's not a difference maker. Parameter lists are wrapped in parenthesis and separated with commas…

> In a debugger and/or Write statements I can readily examine intermediate values "a" and "b". Not so with functional.

You clearly have no idea. Lisp has a REPL. True REPL. No, it's not a thing where you type something into it and it blurts out something in return like in most other languages. And it's better than so much praised Jupyter notebooks.

Lisp REPL is connected to your editor, and from your editor or IDE you can not only examine and evaluate any expression and sub-expression, you can do it on the fly, it gives you immediate feedback. You don't even need to think about a debugger (which Lisps do have too). You can try things while writing them.

Imagine a landscape artist that changes the entire landscape in real-time with every stroke of his brush. That's how it feels to be programming in a Lisp.

Re: The Roots of Lisp (2001)

#52

Post by lispm »

jecel wrote: post #19
coldtea wrote: post #11

Earlier quoted context omitted.

"Some good concepts"? It was the first language to add "if/else" constructs, GC, closures, first class functions, reference semantics, and recursion. It took between 5 to 40 years before these became available in mainstream languages (conditionals like if/else were adopted early, GC not so much, closures took even more). Add to that macros and the flexibility of runtime evaluation / code creation, which most mainstre…

One small detail - though COND and IF/ELSE are very closely related, they aren't quite the same thing. Early Smalltalk also started out with COND (a right arrow which made code look like modern switch/case) and later evolved to #ifTrue:ifFalse: which is still postfix, so feels backwards compared to other languages. Lisp and Scheme got more conventional if/else eventually.

> COND and IF/ELSE are very closely related

In earlier Lisp COND was the primitive and IF was a macro expanding into COND. In newer Lisp it's IF which is the primitive and COND which is the macro.

Re: The Roots of Lisp (2001)

#53

Post by lispm »

tabtab wrote: post #37
coldtea wrote: post #11

Earlier quoted context omitted.

"Some good concepts"? It was the first language to add "if/else" constructs, GC, closures, first class functions, reference semantics, and recursion. It took between 5 to 40 years before these became available in mainstream languages (conditionals like if/else were adopted early, GC not so much, closures took even more). Add to that macros and the flexibility of runtime evaluation / code creation, which most mainstre…

As far as "Lisp lacks visual clues", after many heated debates on this, I've concluded that the ugliness and rigidness of "production" languages enforces certain visual and syntactic standards that makes reading others' code easier. Indentation of Lisp won't "solve" this because production languages also can be indented. It's not a difference maker. Parameter lists are wrapped in parenthesis and separated with commas…

> Lisp won't do this because it's then harder to blur/merge/change the distinction between code and data, which is the very power of Lisp.

Though it has tried a bunch of times.

> Some people have a certain kind of eye and/or brain that allows them to read Lisp quickly

Could be that or that one just needs a bit of practice - as it is the case with many thing: riding a bike, driving a car, learning a foreign language, mastering a new dance, ...

> 60 odd years without catching on in the mainstream is evidence of this

That you observe two things does not mean that they are necessarily in a causal relation.

> I also personally find them difficult to debug

One just introduces variables like in your imperative example:

  (let* ((a (af param))
         (b (bf a))
         (c (cf b)))
    c)
Now you'd see the variables and their bindings in a debugger.

Re: The Roots of Lisp (2001)

#54

Post by tromp »

nikofeyn wrote: post #47
tromp wrote: post #8

> In 1960, John McCarthy published a remarkable paper in which he did for programming something like what Euclid did for geometry. One could argue that Church's (1930s) lambda calculus, which underlies LISP, is a closer analogue to Euclid's distillation of the essence of Geometry. With the minimal addition of pure binary IO, the lambda calculus is easily transformed into an untyped programming language [1]. On the ot…

i don't think it's accurate to say lambda calculus underlies lisp, is it? certainly lambda calculus was used to define functions in lisp, as seen in the original lisp paper (or the most famous one). http://jmc.stanford.edu/articles/recursive.html lambda calculus was a tool, but it seems godel and turing's work on computing machines and recursive functions were more fundamental to the original lisp.

Maybe "underlies" is a little strong, and I should have said "inspired"...

Re: The Roots of Lisp (2001)

#55

Post by lispm »

armitron wrote: post #41
tabtab wrote: post #37

Earlier quoted context omitted.

As far as "Lisp lacks visual clues", after many heated debates on this, I've concluded that the ugliness and rigidness of "production" languages enforces certain visual and syntactic standards that makes reading others' code easier. Indentation of Lisp won't "solve" this because production languages also can be indented. It's not a difference maker. Parameter lists are wrapped in parenthesis and separated with commas…

You know your brain adapts so you can read something easier/faster the more you are exposed to it. For me, Lisp code couldn't be easier/faster to read and comprehend. I'm convinced most of the people making jokes about parentheses or Lisp code being hard to read are superficially dismissing it without putting in even a minimal effort of working with it. Things that don't immediately click are discarded. Individual cu…

I think that the syntax has some hurdles, but it's not the parentheses: It's to mentally understand when lists and symbols are data and when they are code. That's a problem not found in other programming languages and at the same time it is an interesting feature. Lisp is not alone to have such hurdles - another example would be Haskell which is also more difficult to learn than the average programming language (lazy evaluation, type system, monads, ...).

Often Lisp had been used as a teaching language for computer science concepts (recursion, evaluation models, algorithms, etc.) and thus it was associated by students with novel concepts they struggle with and not with solving practical problems. A typical example is the SICP book. It's great, but mostly CS and mathematics oriented -> the result is that the feedback is mixed.

Re: The Roots of Lisp (2001)

#56

Post by wostusername »

LandR wrote: post #22
jecel wrote: post #19

Earlier quoted context omitted.

One small detail - though COND and IF/ELSE are very closely related, they aren't quite the same thing. Early Smalltalk also started out with COND (a right arrow which made code look like modern switch/case) and later evolved to #ifTrue:ifFalse: which is still postfix, so feels backwards compared to other languages. Lisp and Scheme got more conventional if/else eventually.

Something I discovered about Clojure's cond recently. It usually looks likethis: (cond ( a b) (println "a > b") :else (println "a = b")) I thought the :else had to be :else, but it only needs to be truthy, so it can be anything that isn't false or nil (which makes sense as you want it to always execute that form if no others match). So this is just the same: (cond ( a b) (println "a > b") :hotdog (println "a = b")) P…

In Haskell you usually use `otherwise` for the last guard clause, like so:

     f x | x
It took me a while to realize that `otherwise` isn't a keyword or bit of syntax. It's just a variable bound to True: https://hackage.haskell.org/package/base-4.12.0.0/docs/src/G...

Re: The Roots of Lisp (2001)

#57

Post by tabtab »

lispm wrote: post #53
tabtab wrote: post #37

Earlier quoted context omitted.

As far as "Lisp lacks visual clues", after many heated debates on this, I've concluded that the ugliness and rigidness of "production" languages enforces certain visual and syntactic standards that makes reading others' code easier. Indentation of Lisp won't "solve" this because production languages also can be indented. It's not a difference maker. Parameter lists are wrapped in parenthesis and separated with commas…

> Lisp won't do this because it's then harder to blur/merge/change the distinction between code and data, which is the very power of Lisp. Though it has tried a bunch of times. > Some people have a certain kind of eye and/or brain that allows them to read Lisp quickly Could be that or that one just needs a bit of practice - as it is the case with many thing: riding a bike, driving a car, learning a foreign language,…

Re: Though [separating in Lisp] has tried a bunch of times.

I haven't seen it done well. The attempts kind of end up with the worse of both worlds.

Re: Could be that or that one just needs a bit of practice

But the key is how much, and how long does it vary per individual. There is no solid research that I know of, so it's just opinion and anecdotes either way.

I tried to get used to it and read it fast, but it just felt progress was really slow. Most Algol-derived languages use punctuation and symbols that seem to make them stand out better than words alone. I'm not quite sure how to describe it, but standardizing the meaning of "funny symbols" help my particular eyes work faster. My head parses words too slow, and I have been reading words since kindergarten. Similar discussions:

https://wiki.c2.com/?LispLacksVisualCues

https://wiki.c2.com/?ChallengeSixLispVersionDiscussion

One can make that claim about any tool I should note, even COBOL. Some seasoned COBOLer's can crank out and read COBOL code really quick, I'd note. The top COBOLer can probably out-code an average Lisper I'd bet.

Re: That you observe two things does not mean that they are necessarily in a causal relation.

True, but per lack of formal studies per above, speculative observations are all any of us have. It should be a curiosity why after 60 years it never caught on mainstream. Almost nothing else in IT has had that many shots at it.

Re: One just introduces variables like in your imperative example:

Yes, but the Algol-derived languages (like C, Python, etc.) do that "style" in an easier-to-read and more consistent way, at least in my opinion.

Side note: why am I getting a rotten score? What did I do bad? I don't want bad scores. I'm just expressing my opinion openly. I don't feel I deserve punishment.

Re: The Roots of Lisp (2001)

#58

Post by tabtab »

iLemming wrote: post #51
tabtab wrote: post #37

Earlier quoted context omitted.

As far as "Lisp lacks visual clues", after many heated debates on this, I've concluded that the ugliness and rigidness of "production" languages enforces certain visual and syntactic standards that makes reading others' code easier. Indentation of Lisp won't "solve" this because production languages also can be indented. It's not a difference maker. Parameter lists are wrapped in parenthesis and separated with commas…

> In a debugger and/or Write statements I can readily examine intermediate values "a" and "b". Not so with functional. You clearly have no idea. Lisp has a REPL. True REPL. No, it's not a thing where you type something into it and it blurts out something in return like in most other languages. And it's better than so much praised Jupyter notebooks. Lisp REPL is connected to your editor, and from your editor or IDE yo…

Usually real-world code has a lot of context and references such that stand-alone expression evaluation is often of limited value. Maybe there are tricks of the trade to solve this, but they are not obvious to newbies.

It sounds like one has to throw away years of "imperative habits" and just do everything different: reading, debugging, structuring, etc. For us non-Sheldons, it's hard to overhaul our head in a month.

Re: The Roots of Lisp (2001)

#59

Post by tabtab »

iLemming wrote: post #50
terminaljunkid wrote: post #9

IMO Lisp is just overrated, it lacks visual clues, reads right to left with horrible nesting etc.. Sure it has some good concepts. But fanboys on internet make it seem like some God tier thing.

> But fanboys on internet make it seem like some God tier thing Lisp is based on math and logic. And if there's a God, he probably speaks Math. So, maybe those fanboys onto something here. But, seriously, once you learn a bit of Lisp, you realize that Lisp has influenced every single modern programming language. Essentially, no matter what PL you are programming in - we are all programming in a Lisp. Sometimes your l…

I personally admire Lisp conceptually. It's a work of art. It's the practical use as tool in a team environment that you cannot carefully control hiring is where I have skepticism.

Re: The Roots of Lisp (2001)

#60

Post by tabtab »

iLemming wrote: post #46
terminaljunkid wrote: post #9

IMO Lisp is just overrated, it lacks visual clues, reads right to left with horrible nesting etc.. Sure it has some good concepts. But fanboys on internet make it seem like some God tier thing.

No, Lisp does not lack visual clues. But yes, very often people complain about Lisp readability. And that stems from the lack of familiarity, most people are familiar with the infix notation, but not prefix, used in Lisp. But I have seen many times, people who pick up Lisp (Clojure, Racket, etc.) as their first programming language - they do just fine, a matter of fact - they later find code written in other language…

Re: It takes time, for some it's hours, for others - weeks, but eventually you will stop seeing parentheses, and instead, you will see structure, consistency, and meaning. And Lisp becomes more readable than any other language you've used before.

I'd like to see a university test this theory. I suspect it's subjective and varies greatly per individual, but testing on say 100 random subjects could better resolve the Great Lisp Dispute.

Post reply on HN