Is Lisp just too hard? | Hacker News Reader

Is Lisp just too hard?

reprog.wordpress.com

15 pointsMikeTaylor17 comments

"And it gets way, way worse once you start writing actual programs as opposed to mere arithmetic expressions."

I deal with the issue of arithmetic expressions the same way i deal with any other lisp code, i indent properly:

  (+ (* 1.2 
        (- 2 
           1/3)) 
     -8.7)

now just read it from the deepest level outwards.

Yeah, I agree, it's just about as easy to compute Lisp arithmetic as infix arithmetic.

The problem, for me, is that it's not as easy to understand, read, or write. By this, I mean that most of the time that I'm reading an arithmetical expression, I don't really care what it means. I am only reading it because it's easier to just read it than to look for where it ends and continue. It's fluff. Not being as comfortable with prefix, and probably never being as comfortable with infix, it's not as friendly to the eyes.

When I need to understand it, I'm basically converting to infix-- I think in infix, not prefix. The parentheses in the infix expression are mental and implicit, and I think my mental notation is more than adequate. Prefix form gets in the way here.

And obviously, it's more of a pain to write fully parenthesized arithmetic than not.

Yes, devinj, that's it exactly. Lisp notation does win in the cases where you want to sum (or multiply) a bunch of numbers in a single shot, as in (+ 42 53 12 999); but otherwise, the requirement of full bracketing, and the removal of operands from their operators, and the need to COUNT parentheses to see what goes with what, make the notation clumsy. Sorry, Lispers, it's true.

(+ (* (- (/ 45 99) (* (+ 1 4) 3)) (* 4 (- 5 3))))

Which operator operates on the result of the 4*(5-3) sub-expression? You have to stop and THINK about that -- you can't just SEE the answer.

But as pavelludiq points out, you don't ever write math in Lisp like that. I'd write it:

    (+
      (* (- (/ 45 99)
            (* 3 (+ 1 4)))
         (* 4 (- 5 3))))

Or perhaps add in even more indentation. In any case, now if you asked me what operates on the result of (* 4 (- 5 3)), I could tell you immediately that it's *.

That said, I do agree that infix notation for mathematics can often be clearer and more concise. If I found myself doing a lot of arithmetic, I might be tempted to write a macro to allow me to write in infix.

Even if you do, mathematics in LISP is not looking pretty, or "normal" in the beginning for the newcomer.

However, as you start using LISP more and more frequently, the expression you gave could be evaluated within your head at sight. It's just to know where to start looking for a opening/closing paren.

Paul Graham is often saying that the value of Lisp is in large part due to its being so concise. If we have to throw away four lines every time we have a moderately complex arithmetic expression, we're losing quality.

... none of which is to say that Lisp Is Bad (which is certainly not the point I was trying to make in the original article) -- just that the good points are to some degree balanced by some bad ones, and Lisp evangelists don't ultimately help their cause by pretending that even the bad bits are good.

There is nothing stopping you from writing gigantic one-liners in lisp, thats not the same as conciseness. Anyway, my point was that arithmetic doesn't mater that much, if you like the lisp notation, thats fine, if you hate it, you can at least manage it with proper indentation. Its a minuscule annoyance for me.

if that is really a huge problem for you, then you can use Infix readmacros for arithmetic expressions.

Something like this:

  http://www.cliki.net/infix

For me, the point worth arguing is not whether infix vs prefix arithmetic is hard, but that "actual programs" get harder. They don't: Math, logical operations, and variable assignment are the hardest to switch over to thinking Lisply, because those are the operations normally represented as binary operators in other languages[1]. Lisp and other languages share the same prefix notation for standard function calls. When you start moving into "actual" programs from toy examples, functions become a bigger chunk of the program, and the lack of infix operators becomes a smaller deal.

I wonder if intro-to-lisp books should shy away from arithmetic in the first few chapters to avoid this stumbling block. It seems odd to introduce the nature of lisp syntax by focusing on its weakest point. Shuffling lists of symbols around gives an introduction to the syntax and the more fundamental data types, and makes for an easier segue into macros.

[1] Variable assignment is the easiest to overcome, because you simply doesn't use variable assignment as much in Lisp, and in this sense the aversion is a good thing as working to avoid it helps produce more idiomatic code. Logical operators are also easier to overcome because in practice it's not common to have thorny expressions with high nesting levels like you can in arithmetic.

I wonder if it would be worthwhile to have a MATH special form in common lisp that that allows for special evaluation in its body, like how the LOOP form parses its arguments.

I find that logical expressions are easier to parse.

   (OR (AND ...)
       (AND ...)
       ...)

is cleaner (and shorter) than the corresponding one-liner in Python.

Eli responds to him nicely:

http://reprog.wordpress.com/2010/04/14/the-long-overdue-seri...

Lisp is not too hard. What I found missing are the standard library, standard threading, standard database interface, etc.

Interesting that those things are missing from C as well, but nobody seems to mention that...

(Common Lisp has mature FFI and wrappers around things like DBI and graphics libraries. Clojure gives you the JVM libraries for your sins, and I dare you to seriously argue that the JVM has no libraries to its name.)

alexandria, bordeaux-threads, cl-sql.

Really.

Nope.

Nope is too hard?

sorry, was being a bit facetious, but I don't think Lisp is too hard. Takes a bit getting used to, but once you do I don't feel its any harder than C, certainly.

Reply on news.ycombinator.com