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

On Lisp

paulgraham.com

Post reply on HN
Print view View original

81–90 of 107 posts

Re: On Lisp

#81

Post by brudgers »

javajosh wrote: post #43

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

Indentation is optional in Lisp and solely exists to make code more readable by expressing the structure of the syntax tree. In contrast some languages, such as Python, require indentation due to attaching syntactic significance to the size of white space.

Because Lisp communities tend to eschew an imperative programming style, sequential operations tend to be composed of nested functions (and therefore indented) in lieu of passing values by mutable variables to blocks of sequential instructions.

Though arguments about programming styles are always going to remain unconvincing because the benefits of one over the other or vice versa are revealed when programmers are actually writing programs, it is objectively the case, that Lisp's indentation idiom can be used to express the sequence of execution for programs written using a functional style in a consistent way.

Re: On Lisp

#82

Post by brazzy »

jdale27 wrote: post #69
javajosh wrote: post #52

Earlier quoted context omitted.

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

I'm not really a lisp coder at all (a bit of clojure experience) In other words, you don't have a clue. Right, thanks for clearing that up.

And thanks to you for providing an example of the arrogance that turns most people away from the lisp community...

Re: On Lisp

#83

Post by brudgers »

chongli wrote: post #41
thurn wrote: 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 fair amount of the examples involve mutation; a practice that Clojure discourages. A lot of the macros are very instructive, however.

Indeed, On Lisp has an excellent discussion of mutation and its use in programs written in a functional style. In discussing destructive functions, Graham describes the ways in which they can be used with reasonable safety - e.g. immediately mutating a list newly created by a mapping function.

The reasons one might do so in Clojure are likely to bear similarity to those provided by Graham - speed and memory - despite the vastly greater resources of today's computers versus those of 1991.

Re: On Lisp

#84

Post by arh68 »

vamega wrote: post #44
nonrecursive wrote: post #2

Instructions for printing it with lulu: http://www.lurklurk.org/onlisp/onlisp.html . I did this about a month ago and the copy I received was great.

Just tried to do this, and found that the cover image size doesn't seem accurate anymore. What did you do for the cover?

Really? I just made the book and ordered it last night and the cover (the 13MB png) looked like it lined up exactly. The first cover-uploader had a 10MB limit but the other worked fine (not the design-your-own, the 1-piece-cover-designer).

Re: On Lisp

#85

Post by niuzeta »

I thought 'oh, is this a new book'?

Then I looked at the date. It seems as though all 'classical' sources on lisp or functional paradigm are either two decades old, or just-out-yesteryear. What happened in between?

Re: On Lisp

#86

Post by arh68 »

javajosh wrote: post #53
jdale27 wrote: post #50

Earlier quoted context omitted.

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/

>it might be fun to represent lisp code in a treemap

Wow, yeah, that's a really interesting idea. Is there just one (good) way to map a codebase? Many?

It seems like a bad idea at first glance, since the map shows, at any level, more things with less context-per-thing when compared to straight text. It seems totally natural to use it for profiling. Refactoring would be a lot more grokable if it could all be visualized at once. But how would it work for scanning/editing & digging through documentation?

Re: On Lisp

#87

Post by arh68 »

heretoo wrote: post #65
javajosh wrote: post #53

Earlier quoted context omitted.

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/

Perhaps like these? http://foldr.org/~michaelw/emacs/

I very much like the mwe-color-box.el example. Is something like that possible for backquoting? The quoting-levels would be much easier to see with nested background shading. I'll have to try it at home.

Re: On Lisp

#88

Post by agumonkey »

dpritchett wrote: post #79
agumonkey wrote: post #73

Earlier quoted context omitted.

How large are these s-exp ? Lisp is unreadable when nested too much (I'm starring at an xml->s-exp dump and I don't even wanna try to read it), but usually lisp code and data tend to be factored into little combinators and separated specific functions. If you can, try to split them.

Here's a link to an example of that coping strategy from some bad Clojure I wrote last night [1]. I sometimes use an accumulation of lets for a similar effect, but only when describing simpler transformations. The lets might look like so (warning- silly example): (defn n-squared-over-two-plus-three-as-str [n] (let [squared (* n n) halved (/ squared 2.0) added (+ halved 3)] (str added))) > (n-squared-over-two-plus-thr…

Thanks for the edition, the code wasn't as obvious. I believe Haskell `where` construct is to write code this way (beside the flipped order).

Re: On Lisp

#90

Post by minikomi »

dpritchett wrote: post #79
agumonkey wrote: post #73

Earlier quoted context omitted.

How large are these s-exp ? Lisp is unreadable when nested too much (I'm starring at an xml->s-exp dump and I don't even wanna try to read it), but usually lisp code and data tend to be factored into little combinators and separated specific functions. If you can, try to split them.

Here's a link to an example of that coping strategy from some bad Clojure I wrote last night [1]. I sometimes use an accumulation of lets for a similar effect, but only when describing simpler transformations. The lets might look like so (warning- silly example): (defn n-squared-over-two-plus-three-as-str [n] (let [squared (* n n) halved (/ squared 2.0) added (+ halved 3)] (str added))) > (n-squared-over-two-plus-thr…

That looks like a good place to use the arrow macro http://clojuredocs.org/clojure_core/clojure.core/-%3E
Post reply on HN