The Roots of Lisp (2001)

http://www.paulgraham.com/rootsoflisp.html

by afurrysolver • 7 years ago

124 90 7 years ago

coder1001• 7 years ago

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!

fouc• 7 years ago

Yet some of the most successful business people seem to be good at tech. I heard that half of the CEOs of the top 500 fortune companies have a STEM degree.

Hendrikto• 7 years ago

My guess: STEM degrees require and foster critical thinking, logic, and abstraction skills, which are all very conducive to being a good business person.

allenu• 7 years ago

There might be some survivorship bias in there if STEM fields are more successful than others, naturally leading to more STEM leaders, or more opportunities for leaders to form.

coldtea3• 7 years ago

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

tabtab18• 7 years ago

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.

Nokinside• 7 years ago

I'm electronics and embedded software developer, but I took a pause from that and founded a small web business startup with few guys two years before PG founded Viaweb. The product was very similar to PG 's Viaweb. Viaweb was more general and consumer market oriented. We had narrow focus with b2b trough our connections.

It's hard to describe how easy it was to make money in the late 90's with even little technical skill and tiniest amount of business understanding. We were making money hand over fist knowing next to nothing.

PG sold his company for $50 million, we sold ours for $5 million after we took the mountain of cash out of it (another $5 million). After reading how PG did it, I think his genius was paying $16,000 a month for a PR firm. He understood the value of PR, we didn't. http://www.paulgraham.com/submarine.html

His essays, HackerNews and Y combinator are expression of this understanding. He has created expanding self-reinforcing network of affordable PR and connections for startups. That's the real scarcity in the startup scene. Being accepted into a batch is valuable. Instead of hiring PR firm, PR firm accepts you and stamps you with the Y Combinator brand.

psychoslave• 7 years ago

Does PR stands for Purchase Request here?

tabtab18• 7 years ago

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.

LanceH• 7 years ago

It's not very common for anyone to be good at business. But for some reason when people are good at tech, suddenly that becomes the reason they are bad at business.

bsaul• 7 years ago

Recently had a conversation on how functional programming and declarative programming were somewhat linked, and how i observed that languages that started to go down the functional road slowly tried to add more and more capabilities for DSLs, and then slowly moved toward becoming a lisp. But that was just my feeling.

is this theorized somewhere ? Or am i just dreaming ?

try_again• 7 years ago

A well-known quote is that whoever doesn't understand Lisp is doomed to reinvent it: http://lambda-the-ultimate.org/node/2352

deepaksurti• 7 years ago

Greenspun tenth rule may come into play here [1]

[1] https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

dgb23• 7 years ago

Anecdotal experience:

(dynamic) functional programming enables very 'easy' succinct abstractions through combing out concretions and composing functions out of a general tool-set. Think code-reuse in the small.

With some discipline you naturally end up with a very data-oriented codebase, where the specificity of your application/library ends up in your data-structures.

Now these data-structures are really just plain data, without specific behavior attached to them, so they embody the (maybe almost) declarative part of your program/system. The next step would be to polish them to make them more human readable.

An additional feature of Lisps is their homoiconicity and macros. These come into play when plain data-structures are not the right fit anymore. Typically you want to handle some user/client defined behavior. You can now transform the syntax of the language itself to clean up your API to reduce boilerplate and increase readability.

In a sense you have now programmed your own DSL.

tromp2• 7 years ago

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 other hand, full blown and richly typed pure functional programming languages like Haskell remain semantically faithful to their lambda calculus underpinnings.

[1] https://tromp.github.io/cl/Binary_lambda_calculus.html

lisper• 7 years ago

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.

nikofeyn• 7 years ago

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.

curious_yogurt• 7 years ago

The claim seems accurate to me, at least for Scheme: that is, lambda calculus does underlie Scheme.

Lambda calculus, as articulated in Church's 1935 paper, gives us a way to understand computability. But if we look specifically at Operation II in the paper (p. 347), what we have is the lambda function in Scheme. Given that every function in Scheme (including special forms) is equivalent to some lambda function, it seems that in virtue of Operation II we can say that lambda calculus underlies Scheme.

Whether we can push this further to say that lambda calculus underlies McCarthy's initial conception of LISP, or some arbitrary version of Common Lisp, I do not know for certain. But if all these versions treat lambda functions the same way as Scheme does (in relevant respects), then the claim holds for Lisp generally.

[1]: Church. An Unsolvable Problem of Elementary Number Theory. _American Journal of Mathematics_, Vol. 58, No. 2. (Apr., 1936), pp. 345-363.

tromp2• 7 years ago

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

terminaljunkid• 7 years ago

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.

coldtea3• 7 years ago

"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 mainstream languages still lack.

And of course, Lisp's rules remain (and will always be) the most succinct way to define a full blown programming language with meta-programming facilities to boot -- as opposed to a mere Turing machine like thing or assembler.

IMO Lisp is just overrated, it lacks visual clues, reads right to left with horrible nesting etc..

This doesn't make any sense...

The nesting is the same as in almost any language.

"reads right to left" - huh?

You know that Lisp code can be indented right?

lkschubert82• 7 years ago

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 suffer from the right->left reading.

jecel• 7 years ago

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.

LandR2• 7 years ago

Nesting can be sorted via macros, e.g. closures threading macros

    (defn unique [str]
       (->> (str/split str #"\s+")
            (map #(Integer/parseInt %))
            (partition-by even?)
            (take-while #(not= (count %) 1))
            (first)
            (count)
            (inc)))

  (unique "2 4 6 8 7 10 12")
   => 5

Joker_vD• 7 years ago

It was the first language to add "if/else" constructs, GC, closures, first class functions, reference semantics, and recursion.

"Lisp is still #1 for key algorithmic techniques, such as recursion and condescension."

tabtab18• 7 years ago

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.

iLemming11• 7 years ago

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 languages harder to read.

Unlike other languages, Lisp sometimes is difficult to read by just looking at it. Staring at Lisp code, examining its "static" properties without prior training indeed may pose a challenge. But there is a way to learn how to parse Lisp code mentally. And the best way of learning that is by editing it.

First, you need to find an IDE that supports structural editing of symbolic expressions (or s-exps). Basically, it would help if you learned a few operations:

slurp, barf, transpose, raise, kill s-exp, yank s-exp

Depending on the IDE you use, they may be called differently, and there may be more, these are the basic ones.

Once you learn those basic operations, you are now ready to untangle "unreadable" Lisp. The trick is to change the code while you read it.

Similar to how Tony Stark looks at the hologram of a model and moves his hands outward, forcing the hologram to expand, then he picks one of the parts, studies it, maybe completely removes it. He then would move his hands in a closing motion, and hologram would "assemble." That's how you work with Lisp.

So, for example, you read a function, if necessary, extract things, pick an expression, evaluate it, etc. Once you gain a good understanding of what the function does, you can undo all the changes, or if you think you have improved it - do save.

In other languages, when the structure of the code is settled, it's more challenging to pick it apart, move things in and out. You are forced to read the code "top to bottom." But in Lisp, code is a living, breathing thing. You basically feel like performing a surgery - you can tweak things, try them, and see instantaneous feedback in the REPL.

In other languages, code is "dead," until you save it, (re)compile it and execute it. And REPL in those languages is "crippled" and not a fully-fledged "true" REPL like in Lisp. Being able to pick any [sub]expression and evaluate it, without any kind of prior ceremony is truly liberating and empowering.

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.

tabtab18• 7 years ago

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.

iLemming11• 7 years ago

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 language of choice adheres to core principles of Lisp, sometimes that connection is loose. Nevertheless, there's plenty of Lisp in every modern programming language. So, no. Lisp is not overrated.

tabtab18• 7 years ago

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.

TruffleLabs• 7 years ago

McCarthy wasn’t just interested in making Lisp for AI, he was thinking about the possible applications AI, with Lisp as a platform to get to more advanced states of understanding. An example of this is in his paper “Computer Control of a Machine for Exploring Mars." Stanford Artificial Intelligence Project, Memo N. 14, June 15, 1964, Author: McCarthy, John, 1927-2011; Stanford University Library collections.

https://stacks.stanford.edu/file/druid:qh147kq8662/SC1041_SA...

yters• 7 years ago

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?

abhiyerra• 7 years ago

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

tabtab18• 7 years ago

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

https://xkcd.com/224/

ctkrohn• 7 years ago

Funny to see this after all these years. I read this paper just before starting college in 2003 and it inspired me to spend most of the summer writing a rudimentary Lisp interpreter in rudimentary C++. That was my first piece of my code that actually worked, and was more than a dozen or so lines. Good memories.

jammygit• 7 years ago

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?

armitron2• 7 years ago

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.

lerax• 7 years ago

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

tosh• 7 years ago

another angle:

while Clojure is a Lisp with its own distinct flavor it gives you …

* a large community of practitioners and professionals (great for asking questions, finding collaborators, …)

* easy access to libraries in the js/jvm/.net ecosystems

* a style that relies more on data and transformations of data (illuminating simplicity)

in any case: it is worth digging deeper, one thing that kept me away was not knowing where to start (analysis paralysis). in hindsight picking any Lisp would have been great (instead of postponing).

Find a thread and start pulling :)

Rich Hickey’s talks were a great entry point for me https://github.com/tallesl/Rich-Hickey-fanclub

e.g. https://www.youtube.com/watch?v=rI8tNMsozo0 (the “Simplicity Matters” keynote at Rails Conf 2012)

edit: Land of Lisp is a great book as well

iLemming11• 7 years ago

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

Yet, somehow out of all Lisp dialects, Clojure today remains the most pragmatic choice. Clojurescript is arguably the best alt-js choice, where Elm, Reason and Purescript for various reasons still can't reach its level of the simplicity and practicality.

Clojure has immutability by default, which alone has number of great benefits. It is FP focused. It can be learned à la carte, which greatly simplifies process of learning.

Clojure community is one of the friendliest and most diverse communities of developers.

In comparison, Common Lisp today (sadly) becoming like Latin of programming languages. It is cool to learn it and know it, but in many circles the practicality of that knowledge remains somewhat questionable.

pmoriarty• 7 years ago

I'd personally avoid SICP unless you have an interest in writing programming languages or solving math problems. I personally found it really boring, and couldn't get through it.

My own personal taste also leans towards Scheme (especially Chicken Scheme), so that's what I'd recommend. To me it feels more elegant, more modern, and of lighter weight than Common Lisp. I'm also kind of allergic to the JVM and Clojure's non-lispy innovations in syntax, so I'd personally avoid it too.

That said, I myself started with Common Lisp and then moved on to Scheme and then Emacs Lisp (which is a decent choice of Lisp to learn, in that, despite some shortcomings, it puts the entire Emacs ecosystem at your fingertips). Once I'd learned Common Lisp, I found learning the rest to be quite easy.

iLemming11• 7 years ago

SICP is not about Lisp, Scheme was chosen because of its simplicity, but the book is not about Scheme. If you always wanted to go through the book, maybe also take a look at "How to design programs." It's a bit like a SICP, but it's written in a different style, you may prefer that one instead.

- If you want something practical - do try Clojure. Don't listen to JVM haters and Lisp "purists". JVM is a pretty robust piece of tech and Clojure is a proper Lisp dialect. Besides, Clojurescript is a lot of fun.

- If you like Lua, and want to make simple, fun games try Fennel. If you're into math and enjoy playing with fractals and such, do try Racket.

- If you are serious about Lisp, sooner or later you may want to learn Common Lisp. Especially if you already using Emacs and want to improve your emacs-lisp skills.

SamReidHughes• 7 years ago

Clojure is a better language, and a better Lisp, and a better tool for making software, but not "really" a Lisp. If you want to learn about Lisp, I think you should zero in on Scheme, Common Lisp, and Emacs Lisp. But this of course depends on what you want.

The cons cell thing is a big deal. Cons cells are a stupid language construct. But that's baked into the identity of what Lisp is.

blackrock• 7 years ago

I get that Lisp is popular because of its meta-programming abilities, ie its macro system. And the reasoning was that you didn’t have to wait for the language writers to implement the feature you wanted, since you could implement it yourself as a macro.

But this presented other problems, namely that you might end up coding your libraries on an island, and no one else could understand your code. This is probably why Lisp is mostly more powerful when there is only one or a few programmers working on the code base.

But with the increase in other programming languages, and the massive amounts of other libraries out there, then is this macro system really all that necessary anymore?

slifin2• 7 years ago

Clojure is a lisp that runs on top of Java, JavaScript and a couple of others and has access to all of those libraries via npm and maven

Having more libraries than most languages doesn't nullify the use of macros, macros are usually discouraged in application code because they don't compose well, don't make a macro if a function will do

However having macros meant that when go popularised CSP concurrency at the language level it meant we didn't need to change the language (for all variants of Clojure) it just meant we could make a library with macros to do CSP concurrency and it works on the browser on the server etc

Completely opt in, well documented as a library and we didn't weigh down the language with this feature, if or when the next big concurrency thing comes along we won't be looking to deprecate go channels from the language

Macros are incredibly powerful and you probably won't need them often but for those small cases of scratching a particular itch they're a get out of jail free card

The Roots of Lisp (2001)

Related Stories