Hacker News Reader

Comment by thiht | Hacker News Reader

You took the examples where the number of parentheses is the same. Here is a more honest example:

    if (a && !b) {expr} => (if (and (a) (not b)) (expr))

That's a simple expression and I'm not even sure I managed to match the () correctly

View on HN

I agree it's hard to write lisp without a proper editor. Having seen the light I just can't go back now. The power, ease, and simplicity are not something I've experienced with non lisps.

I don't know much about Lisp, but at ILC 2014 [1] there were about 40 participants. In a show of hands, absolutely all of them used Emacs to write their Lisp. I've never seen Emacs unanimity anywhere else.

http://ilc2014.iro.umontreal.ca/

Incedentally I also use Emacs for editing lisp. (emacs lisp and Clojure.) Learning the hotkeys/concepts behind structural editing of lisp code was life changing metamorphasis, but quite difficult overall. There's been some fantastic work done by the Parinfer [1] team to bring the awesomeness of structural editing of lisp to the masses. The basic idea is that your parenthesis should infer where they belong by way of your indentation.

I installed Parinfer it on my project: CLJSFiddle[2], and it's not what I'm used to and doesn't have everything but for a novice it is highly usable - check it out!

[1] https://shaunlebron.github.io/parinfer/ [2] http://cljsfiddle.com

Your example is also misleading. The `a` and `expr` are written as variables in the left example, but as function calls in the Lisp version. More correctly it would be either

  if (a && !b) { expr } => (if (and a (not b)) expr)

  if (a() && !b) { expr() } => (if (and (a) (not b)) (expr))

Now the amount of parentheses is either 4/6 or 8/10 which is not a very big difference (and caused only by the syntactic sugar for `not`), especially considering that the left example uses `!`, `&&` and two kinds of parentheses (perhaps a `;` as well).

You're absolutely right, I didn't know the difference between "a" and "(a)", sorry.

My point was more about the two extra parentheses for each && or ||. Imagine converting

   if (a && b && c && d || e)

to a LISP.

    if (a && b && c && d || e) {
      doSomething();
    }

becomes

    (if (or (and a b c d) e)
      (doSomething))

It's just a little more explicit because operator associativity and precedence aren't worked out for you. (For better or for worse.)

EDIT: I think you were imagining something like this:

    (if (or (and a (and b (and c (and d)))) e)
      (doSomething))

..which is definitely not the art.

Adding to this, in a real situation those variables are probably not going to be nice single letter variables. With longer names the Lisp syntax with unambiguous structure/order of precedence becomes much nicer.

  (if (or (and foobar
               (some-predicate-p quux)
               (= qwerty 432))
          (a-long-function-call-with-two-args bar ytr))
      ...)

Compared to something like:

  if (foobar &&
      somePredicate(quux) &&
      (qwerty == 432) ||
      aLongFunctionCallWithTwoArgs(bar, ytr)) {
      ...
  }

Don't put parenthesis around "a", this is a function call.

   (when (and a (not b)) 
     expr
     ...
     expr)

Reply on news.ycombinator.com