Hacker News Reader

Comment by pjmlp | Hacker News Reader

Usually people that complain, don't spend time counting the amount of times () [] {} appear on their beloved programming languages.

   print(args) => (print args)

   if (cond) { exp1} else {exp2 } => (if (cond) (exp1) (exp2))
   
   array[index] => (index array)

And so on. On average there is probably the same amount, but visually it kind of appears to be more.

View on HN

I think it's not just the number of special symbols, syntax matter. When the eye see array[index], the brain can make some assumptions - 'array' is some sort of, well, array or something else indexable, and index is most probably some simple type. With (array index) one must pause and think is array a function? array? something else? Is index another some simple type? Or another function? Something else entirely?

I know that at the end there's no distinction (lisp syntax is AST, and every other source code ends up as AST), and the idea that someone would accept syntax restrictions as a good thing is probably strange to the true lisper, but people care about the syntax. By eliminating syntax and forcing the programmer to write AST directly lisp gave enormous power to the user, but at the end not enough programmers were willing to give up on comfort to acquire all that power.

Haha, yes. The number of times I've looked at javascript with something like this:

  	})
      })
    });

...trailing almost every function definition is equally absurd. At least with Lisp I only have to deal with one delimiter type and just count the number instead of the })})}); mess of javascript and some other languages.

Although I do have to say I think Python got it right in trying to do away with as much of it as feasible.

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

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

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

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

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

This is absolutely true. Worse, those brackets each define a different modal state. Even more worse, some languages ran out of brackets for all the purposes they wanted brackets for, so they invented their own - is there anything less thought-out than the double underscores in python? No, there is not.

In general, the reliance of syntax on random punctuation instead of meaningful symbols (a'la APL) or clear, human-parsable text is maddening - LISP and its derivatives do it far less than other modern languages, but still too much for my taste.

I'd also prefer clearly spelled-out syntax in this age of autocomplete rather than a jumble of weird abbreviations while I'm wishing for unicorns, and languages with code editors that do a good job of visually representing the flow of code rather than rely on punctuation, white-space or some unholy combination.

Programming seems kinda primitive compared to other aspects of computer-enabled content creation at times.

I think in terms of adoption it might be much more important than it is made out to be. A lot of potential new users are people who have many other choices and very little free time. If the language is such that they cannot immediately recognise a fundamental pattern like a function call then they are going to stop reading. Even if they keep reading for a couple of days and still find it hard to relax and read fluently then by that time they are probably going to give up because they simply don't have the time. So s-expressions are what gives the language part of its power and lisp should not change but don't be surprised if it has less users because 80% of the usual first time users of a language get discarded at the start. It is very hard to make it back up from there.

I think the reason people find it hard to adjust to the new pattern is that they have been trained all their lives to recognise the pattern where the name of something is distinct and outside of the thing itself. In mathematics obviously people have been used to expressing functions using f(x) since an early age (10?). But physically also. Think of these things:

- The name of a shop or a village tends to be on a sign on the outside.

- The name of a book is on the cover.

- The title of a folder is on the outside.

- The name of an OS file etc.

Naming things is very important. Its the basis of a lot of communication, understanding and abstraction and people are used to the name of something being fundamentally distinct and outside of the thing itself.

Reply on news.ycombinator.com