Live data from Hacker News

The Roots of Lisp (2001)

paulgraham.com

31–40 of 92 posts

Re: The Roots of Lisp (2001)

#31
post #22
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 traditional Lisp and common Lisp, and similar dialects, the symbol t is customarily used as the catch all last case.

There is an interesting situation is in the case family of constructs which match an input value against keys, in Common Lisp.

Inspired by cond, the t symbol also serves as the fallback in case when the key doesn't match the other cases. So that is to say:

   (case (expr)
     (a ...)
     (b ...)
     (42 ...)
     (t ...))  ;; 
Common Lisp also supports the symbol otherwise in place of t.

But the programmer may also sometimes have the t symbol as a specific key value; or likewise the otherwise symbol. That requirement is handled by putting the key into a list:

   (case (expr)
     (a ...)
     ...
     ((t) ...))  ;; 

Re: The Roots of Lisp (2001)

#32
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…

Cool! You might enjoy this:

http://www.flownet.com/ron/lambda-calculus.html

[EDIT] Heh, I just realized that we corresponded on this back when I wrote it in 2014! Small world.

Re: The Roots of Lisp (2001)

#33

It amazes me how @pg managed to conquer the business side of startups and started YC given his very technical background! To me it is not very common for (very) technical people to be good at both tech and business!

Often times it's a matter of just listening to customers. Even if you don't have a knack for the domain, if you get enough feedback and react to it, you can "organically" fit it well. It's sort of comparable to a genetic algorithm. Of course, having a knack for a domain could mean fewer iterations of rework.

Lisp is ideal for changing on a dime, at least for a small team.

Re: The Roots of Lisp (2001)

#34
post #10

It amazes me how @pg managed to conquer the business side of startups and started YC given his very technical background! To me it is not very common for (very) technical people to be good at both tech and business!

For some counter examples: Bill Joy co-founded SUN - but also wrote ex, vi, the BSD UNIX tcp/ip stack, and other things. Marc Andreessen wrote Mosaic and Netscape - and is a famous VC person now (of Andreessen Horowitz fame). Bill Gates, also very technical (wrote early MS programs, BASIC interpreters etc). Eric Schmidt (ex Google CEO) wrote Lex (the lexer, now more known by its GNU port, flex) and was SUN's first pr…

Early Microsoft tended to clone or buy successful products. They were not really into core R&D, only improvement R&D. They let others be the guinea pigs. Gates was a skilled poker player, which probably helped him be a shrewd business-person. When all was said and done, you would realize he walked away with all your best cards.

Re: The Roots of Lisp (2001)

#35
post #14

Earlier quoted context omitted.

I think they are referring to the nested nature of lisp function calls. (second-fn (first-fn val)) I think that is really just personal preference/what you were taught as opposed to good or bad language design. But it really doesn't matter as one of the big benefits of lisp is it's ability to be metaprogrammed. That same example could be rewritten in clojure as (-> val first-fn second-fn) thanks to macros and doesn't…

> I think they are referring to the nested nature of lisp function calls. (second-fn (first-fn val)) How's this different than: secondFn(firstFn(val)) other than the placement of parenthesis, the two cases read exactly the same, left to right.

I'm on the side of lisp here, but in OOP you'd usually write something like

    val.firstFn().secondFn()

Re: The Roots of Lisp (2001)

#37
post #11

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.

"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, while code blocks are wrapped in curly braces and separated with semi-colons.

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.

Building architectural eyesores is probably not a rational plan for a city, but dammit, those eyesores help you know and remember where you are.

Some people have a certain kind of eye and/or brain that allows them to read Lisp quickly, but this may not be universal. Some say "with enough time you'll get used to it", but the fact Lisp has been around for 60 odd years without catching on in the mainstream is evidence of this. Somebody would be rich by now off its alleged advantages if they were real (beyond a "write-only" startup language).

Functional languages are better at expressing ideas but slower at communicating them to other readers, on average. I also personally find them difficult to debug because they don't have enough "intermediate state" to x-ray for debugging purposes. Here's a conceptual illustration:

      // imperative:
      a = af(param);
      b = bf(a);
      c = cf(b);

      // functional
      c = cf(bf(af(param)));
In a debugger and/or Write statements I can readily examine intermediate values "a" and "b". Not so with functional. SQL presents a similar issue. Its new WITH statements help out, but only partly. Divide-and-conquer works better if you can examine the divisions.

Re: The Roots of Lisp (2001)

#38

Which is the better introduction to Lisp: On Lisp (by pg), SICP, or another text (maybe on Common Lisp)? Or is it better to just go straight to Clojure these days?

On Lisp is an advanced text about Lisp macros, not recommended as an introduction (but highly recommended if you've written Common Lisp).

SICP is great but not really about Lisp.

I recommend Norvig's PAIP [1] or Graham's ANSI Common Lisp [2].

Another book that's often recommended is Practical Common Lisp but I think it's dated and hasn't aged well. It's also nowhere near as mind expanding as PAIP/Graham's books.

[1] https://github.com/norvig/paip-lisp

[2] PDFs can be found on Google

Clojure is not recommended as it is very different to Lisp.

Lisp code needs to be entirely rewritten before it will run on Clojure. That is not true for Common Lisp, Emacs Lisp and even Scheme.

Re: The Roots of Lisp (2001)

#39
post #24

If I look at the operon structure of a genome, and squint a bit, it looks very similar to the LISP structure: (func var0 var1 ... varn) Could it be that the design of LISP is inspired by the structure of the genetic code?

I always thought this as well. In Lisp, data is the program similar to how DNA is data as well as the program.

We are all just mutated Lisp...and mutts.

https://xkcd.com/224/

Re: The Roots of Lisp (2001)

#40

Which is the better introduction to Lisp: On Lisp (by pg), SICP, or another text (maybe on Common Lisp)? Or is it better to just go straight to Clojure these days?

Clojure is always the wrong option to get into the principles of Lisp.

* Clojure utilizes non-standard Lisp syntax like []{}, weird function declaration and differ semantics of some forms (like cond usage, a powerful specie of switch-case of Lisp);

* Clojure don't have cons pairs, neither car and cdr operators. Cons pairs are fundamental Data Structures to build compound data, very well explored in SICP and any LISP text book.

* Clojure has the batteries of Java, so you will own a giant ecosystem to build complex software, but the evil parts of jvm will be inherited too. For the first contact with Lisp, this can be a unnecessary pain in the ass.

I would recommend to start a LISP journey with Land of Lisp or Practical Common Lisp (PCL), both focused in Common Lisp. Land of Lisp has a lot of history about the beginning of Lisp and the author write the book in a fun way, lot of charges and xkcd-like humor. The book has a collection of game projects per chapter, one at time, teaching principles of the language. PCL it's very useful for understanding specific parts of the language, I used as complement when Land of Lisp was not sufficient (loop topic on PCL is very good).

Post reply on HN