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

61–70 of 92 posts

Re: The Roots of Lisp (2001)

#61

Post by Turing_Machine »

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…

> Not so with functional.

Sure you can, if you have an editor and REPL worth their salt. Select af(param)and evaluate it. There's what you're calling "a". Select bf(af(param) and evaluate it. There's what you're calling "b". How one carries out "select and evaluate" varies depending on the language, REPL, and editor in use, but there's almost always (always, in my experience) an easy way to do it.

Bonus: if it's a pure functional language (no side-effects) you can do it as many times as you like without messing anything up, and you didn't have to invent any otherwise-useless variables.

Re: The Roots of Lisp (2001)

#62

Post by [deleted] »

coldtea wrote: post #11
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.

"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…

[deleted]

Re: The Roots of Lisp (2001)

#63

Post by lokedhs »

tabtab wrote: post #58
iLemming wrote: post #51

Earlier quoted context omitted.

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

This may be a meme, but it's also very true (like all good comedy). It's truly represents how you start to look at Lisp code after a while:

https://www.thejach.com/imgs/lisp_parens.png

Re: The Roots of Lisp (2001)

#64

Post by iLemming »

tabtab wrote: post #58
iLemming wrote: post #51

Earlier quoted context omitted.

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

> they are not obvious to newbies

Modern Lisps like Racket and Clojure are not that difficult to pick up. I think Clojure might be easier to learn than Python or Javascript. I'm serious.

Look, I understand the sentiment because I was on the same side relatively not too long ago. I never had a formal introduction into a Lisp. I thought Lisp is a dying language, something like Fortran, COBOL, or Pascal. On a whim, out of the blue, I tried learning it. I don't remember exactly why. I was bored or something. I started reading a book on Clojure. Then I found a conference that supposed to happen in a week. It was the first Clojure/Remote conf. I thought: "Well, it's remote. It's cheap. Let me try it out. What do I have to lose?" That conference has changed my life. Quite literally. I was fascinated by seeing awesome things people building. After the conf, I sat in my chair, staring into the void of my blank screen for several minutes. The next day, I went to the office and told them that I'm leaving. Without writing a single program in a language I did not know, I decided to find a job with a tech stack focused on Clojure.

There are lots of misconceptions circling Lisp. People look at Lisp code, and it just doesn't look "sexy" to them. And they immediately dismiss it, claiming it is hard to read. That's not true.

They say - it's dynamically typed mess. Without ever knowing that Clojure has a type system called Spec, which can do things, most other type systems cannot. There's a ton of research happening around type systems in Racket. "Little Typer" book teaches dependent types using a Lisp.

They say Lisp codebases don't scale - that's not true at all. The truth is - programming in Lisp makes people so productive, you don't need large teams to maintain a massive amount of work. And there are companies with large Lisp ecosystems, one example: NuBank in Brazil has over 400 engineers, and their primary language is Clojure.

People say Lisp is not popular. Sure, Clojure's popularity might look dwarfed in comparison with massively popular Python, Javascript, C++, Java, etc. However, Clojure, compared to other "esoteric" languages, is quite popular - today, it has more books, podcasts, conferences, and meetups. More than languages like Haskell, OCaml, Rust, Elm, Purescript, ReasonML, F#.

Learning Clojure has opened a world of possibilities for me personally. My only regret that I haven't gotten into Lisps earlier. Please, don't negatively take my advice. My intentions are sincere. I wish someone would've convinced me to try Lisp early in my career. Please, do sometimes try to get your head out of your shell and give it a try. I promise, if you give Lisp an honest and heartfelt try, you will find something unique. Even if you end up not using it, you will never regret learning it.

Re: The Roots of Lisp (2001)

#65

Post by iLemming »

tabtab wrote: post #59
iLemming wrote: post #50

Earlier quoted context omitted.

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

I've started using Clojure a few years ago as my primary language of choice. I switched multiple jobs since then. I never had a problem with finding one. I worked once for a big fin-tech company. We never said that knowing Clojure was a requirement, but we admitted that the preference would be given to people at least interested in Clojure. And you know what? It helped us to build an incredibly strong team. Even though not everyone used Clojure. Some teams used languages like Ruby, Go, and Javascript.

If I were given a choice to either hire five Javascript/Python/Go programmers and pay them each 100K/Y or hire only three Lispers and pay them each 200K/Y, I would go for the latter. ROI, in that case, would be much, much higher.

And Clojure is a very, very practical tool. Just watch Rich Hickey talks, you will see that the pragmatism of the language is paramount for everyone who uses it.

Re: The Roots of Lisp (2001)

#66

Post by iLemming »

tabtab wrote: post #60
iLemming wrote: post #46

Earlier quoted context omitted.

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 G…

Of course, it's subjective. Do you think everyone is born with an innate ability to read Javascript?

I don't know anything about music, but I feel this debate is like guitar tabs vs. standard music notation. I've heard, for example, that Paul McCartney doesn't know how to read music notation. "Yesterday" is still a masterpiece, though. Now imagine if Paul all his life advocated young musicians against musical notation, because "It's hard to learn to read it. And it's overrated."

The truth is - Lisp is fundamental and absolutely essential for anyone who chose a lifetime career in computer science. And it's not going anywhere, anytime soon. So please stop whining about it and at least get yourself familiar with it or stop calling yourself "a pro."

[Apologies for dramatization, the last part is not aimed at you personally. it's a general message for everyone.]

Re: The Roots of Lisp (2001)

#67

Post by iLemming »

jammygit wrote: post #36

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?

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.

Re: The Roots of Lisp (2001)

#68

Post by lispm »

iLemming wrote: post #64
tabtab wrote: post #58

Earlier quoted context omitted.

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.

> they are not obvious to newbies Modern Lisps like Racket and Clojure are not that difficult to pick up. I think Clojure might be easier to learn than Python or Javascript. I'm serious. Look, I understand the sentiment because I was on the same side relatively not too long ago. I never had a formal introduction into a Lisp. I thought Lisp is a dying language, something like Fortran, COBOL, or Pascal. On a whim, out…

You should stop oversellling things. Spec is not a type system.

Re: The Roots of Lisp (2001)

#69

Post by iLemming »

lispm wrote: post #68
iLemming wrote: post #64

Earlier quoted context omitted.

> they are not obvious to newbies Modern Lisps like Racket and Clojure are not that difficult to pick up. I think Clojure might be easier to learn than Python or Javascript. I'm serious. Look, I understand the sentiment because I was on the same side relatively not too long ago. I never had a formal introduction into a Lisp. I thought Lisp is a dying language, something like Fortran, COBOL, or Pascal. On a whim, out…

You should stop oversellling things. Spec is not a type system.

Just because you can't do a rigorous static analysis (which to certain degree is possible, check out Spectrum) it doesn't mean that Spec is not a type system.

Re: The Roots of Lisp (2001)

#70

Post by SamReidHughes »

jammygit wrote: post #36

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

Post reply on HN