Hacker News Reader

Comment by javajosh | Hacker News Reader

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

View on HN

It's 2013, and the top comment on a story about Lisp (on HN, a site written in Lisp) is complaining about syntax? Seriously, how much time did you actually spend learning/using Lisp before giving up because it had a "massive indentation problem"?

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/

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

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.

Not upset, just tired of ignorant programmers who get off on complaining, and inventing solutions to imaginary problems (bad syntax? ooh, clever visualization!) rather than actually writing code. By the way, you didn't answer the question -- how much Lisp code have you written, "javajosh"?

Could you lay off the personal attacks?

"Lisp looks strange not so much because it has a strange syntax as because it has no syntax; you express programs directly in the parse trees that get built behind the scenes when other languages are parsed, and these trees are made of lists, which are Lisp data structures"

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

Most clear clojure code doesn't look parenthetical at all really. Usually my code ends up looking like a few let declarations and then a single line of execution - and I'm only a beginner!

4clojure.com is a good resource to see how experienced clojure programmers can turn what would 50 lines of imperative code into a handful of keywords. The self-similarity is a non-issue. Saying it is a negative is like saying Mozart used "too many notes" in his music.

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

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.

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-three-as-str 1)
    "3.5"

Sure, I could've just done this as a deeply-nested structure:

    > ((fn [n] (str (+ 3 (#(/ % 2.0) (* n n))))) 1)
    "3.5"

... but it's harder to read, debug, and reason about. You wouldn't do that in a non-functional language either! I suppose the tolerance for deep nesting is different for different programmers.

[1] https://github.com/dpritchett/cloball/blob/62300d31666ab1261...

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

Yep, that's what the link in my original post was hoping to demonstrate. I find rolling up a few lets one after the other more natural in some other situations.

Although I'm second-guessing my let example now. Lets are great for assigning names to your building blocks, but I don't really like using them to obscure my processing flow as above. Perhaps this would be a better compromise:

    (defn example [n]
      (let [square #(* % %)
            halve  #(/ % 2.0)
            add3   #(+ % 3)]
        (-> n square halve add3 str)))
    
    > (example 1)
    "3.5"

If the function name or docstring is descriptive enough, I'd just go for

    (defn square-halve-add3-to-string [n] 
      (-> n 
        (#(* % %)) 
        (/ 2.0) 
        (+ 3) 
        str))

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

Reply on news.ycombinator.com