Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My guess is that most people that don't like the indentation have never used it. It is notably more readable when looking at someone else's code, and makes wonderful use of whitespace.

Now if only there were some formatting standard to get rid of some of that parens in Lisp without loss of power.



Funny thing... the other day I tried converting some Lisp to Python as a demonstration, and discovered that the number of parens you get to remove depends largely on the programming style you're using. Mostly, they just get shifted around or replaced with brackets (or braces), and you have to add a lot of commas.

If you scan over http://norvig.com/python-lisp.html, you'll see a lot of opportunities to remove parens; but in fact many of those are not semantically identical.

In python, a block does not return a value.

    if a:f(x);else:g(y)
If you wanted it to return a value, you'd have to rewrite 'if' as a function and say something like:

     myif(a, [(f, x)], [(g, y)])
If you wanted to evolve python towards Lisp without having to add parens, I'd make it so indented blocks are actually expressions and automatically return a value to the defining block.

(Of course, the normal python way is to use "return" statements or side-effects, rather than writing an ad-hoc version of the lisp 'if')


Python 2.5 now lets you do:

 x = f(x) if a else g(y)
f() and g() aren't evaluated till they're needed.


That syntax looks like it's intended to communicate that f(x) is the normal result, and g(y) is exceptional. I wouldn't want to use it unless that's what I intended to communicate. It also looks like you would need to put parens around the "if" expression if you were to use it within a more complex expression, e.g

 2 + (f(x) if a else g(y)) + 3


And before Python 2.5, people usually used this idiom:

    x = a and f(x) or g(y)
If you know the idiom, I think this is more readable (conditional is on the left), though it has the drawback of using completely nonsensical keywords.


Another drawback I just noticed is that if f(x) returns false, you'll get g(y) even if a is true.


I don't think the keywords are nonsensical.

   (or (and a (f x))
       (g y))


Thanks, I didn't know that. That makes parenthesis optional unless you need to break precedence rules.


There are plenty of ways to represent a Lisp parse tree without using parens. The only thing is, by the time you know Lisp well enough to implement one, you've begun to like the parens.


Totally true. Plus you can have editors "present" the lisp tree however you like to see it (ie "whitespace" or parens !). Although I practice, I don't know if anyone really writes code without the parens (for the reason you say).


I use it every day and still don't like it - I miss Lisp.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: