Hacker News Reader

Comment by ZenoArrow | Hacker News Reader

In the Parinfer introduction, 'C Style indentation' is mentioned.

What I can't understand is why 'C Style indentation' isn't the default convention, at least in modern user-friendly Lisps. One of the biggest problems people have with Lisp is the readability of grouped parentheses, but the C Style indentation example shows you can write Lisp without them.

I get that it's nice when programs fit in less lines of code, but isn't readability more important than line count?

View on HN

C brace style has nothing to do with readability. Indentation alone shows the block structure just fine; Python proves this.

The purpose of C brace style is to make editing easier in primitive editors that don't do delimiter matching. In such an editor, selecting where, in a long string of closing delimiters, to insert a new element requires counting the delimiters, which is tedious and error-prone. With delimiter matching, the editor does the work for you, so splitting delimiters across lines is completely unnecessary.

Visual Studio's had delimiter matching for years, and will auto-indent based on levels of depth, will add the trailing delimiter, even with adding new elements, etc. C brace style with autoformatting comes in really handy when editing functions on the fly, because it becomes obvious what block you're working on, with no need to look at one parenthesis among many.

Eh, yes and no. Python at least has `elif` statements.

When execution control depends on the order of nested arguments, I find "c" style to really enhance the following contrived example, even with rainbow parens:

  (if true 
    (whatever this is an (example
       that is (kind of hard)
         (-> to 
           (read %))))
     (this is an ELSE but hard to figure out))

Your example arbitrarily indents and new-lines. If that's what's on the table, then nothing is really going to help you.

    if (x 
    > 100) { console
      .log('hello') } else 
    { console.log
    ('world')}

When it comes to if/else and if you indent with some sanity, then lisp is like Python: if the 'else' branch is too hard to spot or if you forget the context by the time you reach the 'else', then your 'if' branch is simply too many lines long. Or you should flip the condition so that the short branch comes first.

Meanwhile, I can't even write your lisp example as-is in any of the editors I tried it in.

Lisp, has cond which is analagous to Python's elif

Also you have your indentation wrong; (this is an ELSE but hard to figur eout) should be one column to the left, which makes it significantly more readable.

It's hard if you indent wrong.

Also: http://imgur.com/FnXXOXJ

Tell me the above picture is something people have problems understanding the structure of.

C style is profoundly less readable for someone who has taken to time to familiarize themselves with Lisp.

Even when you can't use a Lisp-friendly editor?

Really, all you need are highlighted matching parens, I can't think of a single programmer's editor that doesnt' do that.

Do you get that when you're reading through online tutorials?

https://github.com/orthecreedence/highlight-lisp provides paren matching on mouse hover, I find it annoying but I can see how it can be useful to some.

You don't really need it when reading tutorials either. Rainbow, simple matching, or manually counting parens is very much helpful when you're editing code, not so much when you're reading, at least if the code follows standard formatting idioms. You really get used to it: http://www.loper-os.org/wp-content/parphobia.png I would even argue you don't even absolutely need matching despite its helpfulness since Lisp was done and is done on many primitive editors without such features including pen and paper. As a first order approximation, you have just as many parens (braces, brackets) as a C-like language, the opening one is just on the other side, and C too can be done just fine with primitive editors.

Reply on news.ycombinator.com