Live data from Hacker News

On Lisp

paulgraham.com

51–60 of 107 posts

Re: On Lisp

#51

Great book, but not if you are just starting out with Lisp. For that, see PG's other book: http://www.amazon.com/ANSI-Common-LISP-Paul-Graham/dp/013370... Also make sure you check the errata for On Lisp, there are a few examples that you will really need the errata for.

Actually a much better place to start is Practical Common Lisp:

http://gigamonkeys.com/book/

Or if you are now to programming in general:

http://www.cs.cmu.edu/~dst/LispBook/

Re: On Lisp

#52
post #46

Has anyone every tried to visualize lisp with a treemap? Maybe that would take care of the massive indentation problem that makes lisp so hard to read (for me).

What do you mean by indentation problem? In practice, everyone just uses emacs to indent, no problem.

Oh, I was just thinking that it would be nice to visualize lisp in a more two-dimensional way, something like this:

http://bl.ocks.org/mbostock/4063582

I'm not really a lisp coder at all (a bit of clojure experience), but the relentless self-similarity of lisp languages is both a strength and a weakness, IMHO. But it's regular syntax would make it a good candidate for a treemap. Just sayin'.

Re: On Lisp

#53
post #50
post #47

Earlier quoted context omitted.

Surely expressing personal issues with Lisp's syntax is valid, especially if a possible solution is offered. If you see at least some of the larger codebases written in Lisp, it is natural to be overwhelmed by the level of indentation, which will cause the code to wrap under many editor setups.

I've heard people complain about parentheses, but indentation isn't usually the issue. I challenge you: I looked at your personal website, and you seem to claim experience in Java and C. Show me a large codebase in Lisp and a large codebase in Java or C where the Lisp codebase is dramatically less readable than the Java or C codebase due to indentation.

You seem very upset. Calm down. I just had an idea that it might be fun to represent lisp code in a treemap. Or rather a zoomable treemap like this:

  http://bost.ocks.org/mike/treemap/

Re: On Lisp

#55
post #48

Earlier quoted context omitted.

You could have a look at the software below Hacker News. It's written in the Arc Lisp dialect (which itself is implemented on top of the Racket Lisp dialect). Apart from Racket, Clojure is also a nice Lisp to get started with. It runs on the JVM. I'd advice against learning Common Lisp as your first Lisp these days, even though Common Lisp is what On Lisp is about.

I'd advise exactly the opposite. While clojure and racket are excellent languages, they are very different from one another and CL. Telling someone to learn python or ruby if they ask about learning lua isn't a good advice, is it?

Oh, if your goal is to learn one of the Lisps, then don't spend any time on Common Lisp. It's old and ugly.

Similar, if someone asked about a modern scripting language, I'd send them away from Perl in favour of Python or Ruby.

If they goal was explicitly Perl (or Common Lisp) that would be a different thing, though.

Re: On Lisp

#56
post #30
post #16

Lisp is a dangerous language that shouldn't be taught or used these days. There are plenty of superior programming techniques. Mathematical programming - linear programming, finite domain constraint programming, constraint logic programming, logic programming, relational programming Static functional programming - ml, haskell A good modern introduction to programming is Concepts, Techniques, and Models of Computer Pr…

What kind of argument is this. > constraint logic programming, logic programming The book you comment on actually implments a logic programming system. Both common lisp and clojure have implmentations of high performance logic systems. > Static functional programming Both Clojure and Common Lisp have type systems that can do most things ml and haskell can do. Its arguable that some of this (in the CL) are even more p…

> Both Clojure and Common Lisp have type systems that can do most things ml and haskell can do.

Except they let you do MORE, which is often bad. For example, in Haskell STM you have a static guarantee that you don't have mutation or IO inside of a transaction. How are you going to guarantee that with Clojure STM?

Re: On Lisp

#57
post #48

Any advice or link for someone new to Lisp like me? Also, is there any good open source project using Lisp that I can fork/download and tinker with? I'm still having problem wrapping my head around Lisp. Even implementing some simple algorithms in Lisp took some time for me. I think this is due to the fact that I learned to program in C. Nowadays I work mainly with python/ruby/javascript, but I got the feeling that I…

You could have a look at the software below Hacker News. It's written in the Arc Lisp dialect (which itself is implemented on top of the Racket Lisp dialect). Apart from Racket, Clojure is also a nice Lisp to get started with. It runs on the JVM. I'd advice against learning Common Lisp as your first Lisp these days, even though Common Lisp is what On Lisp is about.

Any particular reason against Common Lisp?

Re: On Lisp

#58
post #28
post #27

What percentage of the techniques in this book are also applicable to Clojure programming? I don't know a lot about how the two macro systems differ.

A lot of it. Clojure has a Common Lisp like macro system. There are some slight changes where clojure tried to make things a little simple, and the syntax is a lot diffrent. I think there are people on the internet who have implmented most of the example in clojure.

No reader macros, though.

Re: On Lisp

#59
post #56
post #30

Earlier quoted context omitted.

What kind of argument is this. > constraint logic programming, logic programming The book you comment on actually implments a logic programming system. Both common lisp and clojure have implmentations of high performance logic systems. > Static functional programming Both Clojure and Common Lisp have type systems that can do most things ml and haskell can do. Its arguable that some of this (in the CL) are even more p…

> Both Clojure and Common Lisp have type systems that can do most things ml and haskell can do. Except they let you do MORE, which is often bad. For example, in Haskell STM you have a static guarantee that you don't have mutation or IO inside of a transaction. How are you going to guarantee that with Clojure STM?

That is absolutly possible with a static type system.

Re: On Lisp

#60
post #38
post #30

Earlier quoted context omitted.

What kind of argument is this. > constraint logic programming, logic programming The book you comment on actually implments a logic programming system. Both common lisp and clojure have implmentations of high performance logic systems. > Static functional programming Both Clojure and Common Lisp have type systems that can do most things ml and haskell can do. Its arguable that some of this (in the CL) are even more p…

> Both Clojure and Common Lisp have type systems that can do most things ml and haskell can do. I don't know about that, Haskell has quite a few very non-trivial extensions in it's type system that I have yet to see replicated outside of research languages. ( Rank-N Types, GADTs, Kind polymorphism, etc).

See things, like this http://en.wikipedia.org/wiki/Qi_%28programming_language%29 or https://github.com/clojure/core.typed
Post reply on HN