Hacker News Reader

    FunCall1( FunCall2( FunCall3(arg1, arg2, arg3)))

vs

   (FunCall1 (FunCall2 (FunCall3 arg1 arg2 arg3)))

Yes those useless parentheses certainly clutter up the code. Look at how much longer the lispy line is compared to the less lispy line. Why it's got a whole -3 more characters!

And the end of the line with all the parentheses. So much uglier to see three parens at the end of the lisp line than the non-lispy line.

Truly a monstrous imposition, that lisp syntax.

And when you look at any lisp code base, look at how they don't indent their code at all. So unlike other languages. Here's literally the first project I could find looking for "lisp source code": https://github.com/adamtornhill/LispForTheWeb/blob/master/we...

Which can be rewritten as:

    (-> (FunCall3 arg1 arg2 arg3)
        Funcall2
        Funcall1)

in Clojure. https://clojuredocs.org/clojure.core/-%3E

So, you're telling me that users of a language known for syntactic abstraction came up with a way to more conveniently express a common pattern of code?

Well color me flabbergasted.

Woah, what's up with all the bile?

The tone of this and my original post are the same. Sarcasm doesn't play well in text. Apologies.

To be fair, both the imperative and the lisp version of that are probably not optimal. In most imperative (OO) languages the first one could hopefully be

    Fun3().Fun2().Fun1()

or even

    thing3.thing2.thing1

If some thing is a property of the other

Concrete example from your linke: a projection and sort (I believe it is). I think that the tail of this expression with 5 parentheses makes this very hard to read (Admittedly it's a matter of experience of course):

    (docs (iter (db.sort *game-collection*  :all 
                                            :field "votes"
                                            :asc nil)))))

Questions I find hard to answer for the above line is: how many args does "iter" have? Is 5 trailing parentheses the right number?

Here is some half-functional half-imperative strawman syntax: for comparison:

   x = some_collection
          .select(c -> c.documents)
          .sort(d -> d["votes"], direction: ascending);

I find that a lot easier to balance, and know how many arguments the projection has compared to the sort.

> Questions I find hard to answer for the above line is: how many args does "iter" have?

It's obvious to me in a millisecond glance that docs and iter are called with one argument.

For one thing, the snippet does not contain a single instance of a ) parenthesis being followed by a ( parenthesis. Also, none of the ) parentheses have any material between them. It's just (sym (sym (sym stuff ...))).

Only three trailing parens are required to close (docs; the other two are for something else.

If iter had additional arguments, it might be written like this:

    (docs (iter (db.sort *game-collection*  :all 
                                            :field "votes"
                                            :asc nil)
                (another-iter-arg)))

It is still obvious that docs has one arg, iter has two and that the :all :field material is under db.sort.

https://news.ycombinator.com/item?id=9229339

Ah, the arg-count-from-indentation makes sense with the concrete example, thanks.

That said: if the code is neither correctly indented or has the parens correctly balanced - then one is in a pickle. It's easy to balance parens on correctly indented code, and it's trivial to indent correctly balanced code.

> That said: if the code is neither correctly indented or has the parens correctly balanced - then one is in a pickle.

But you can format the code automatically, and check if all is good by looking at the shape of your code (indentation). If the amount is the same but you put elements in a strange location, like:

    (defun bar ()
      (let ((a (foo)) (print (list a)))))

Simply pretty-printing it with PPRINT will do:

    (DEFUN BAR ()
      (LET ((A (FOO)) (PRINT (LIST A)))
        ))

(C-c RET, aka. slime-expand-1-inplace, will work too).

Indentation and parenthesis introduce a level of error checking by redundancy: the tools works on structured expressions, you look at indentation. Here above you can see that the body of the LET is empty, while there is a bogus binding in it.

The above example is in practice quite rare. Most errors are easily spotted with paren highlighting. I use paredit, which makes structural editing easy (but which is not too rigid and allows me to make unstructured changes too). You generally don't have unbalanced parenthesis, and if you don't spot the bad syntax with indentation, the compiler has a chance to complain, too.

> I think that the tail of this expression with 5 parentheses makes this very hard to read

> how many args does "iter" have?

Forget about parentheses and look at indentation. You need properly indented code, but that comes easily with a good editor:

    (foo (bar ...
              ...
              ...)
         ...
         (baz (+ x y)))

Both foo and bar takes 3 arguments, baz only one.

Likewise, "iter" has only one argument, because there is only one subtree at the indentation level where its arguments are expected to appear. If I try to add arguments inside the set of closing parentheses, emacs actually color them in red to signal that this is not easily readable.

http://dept-info.labri.u-bordeaux.fr/~idurand/enseignement/P...

> Fun3().Fun2().Fun1()

Hope you like Null Pointer Exceptions. (And poorly named methods.)

Neither the function names or whether a type systems has null or not depends on the paradigm (functional/OO/imperative/procedural/whatever).

I prefer type systems without null if given the choice, but for composition there isn't much different between result|error and result|null (If the null/error case is actually handled. Unless you use C you can usually handle it with something that resembles modads or is at least a pattern matching shorthand

C#

   var managerStreet = employee.Manager?.Address?.Street;

Which is very similar looking to how Rust (Which has no null) propagates errors:

   foo()?.bar()?.baz()?

Afaik using `?` for `Option` is part of the `Carrier` trait which is unstable and only in nightly Rust for the time being.

In practice you end up with less parens than in most languages to express the same thing though. Also, the parens are largely what allows for structural editing: https://cursive-ide.com/userguide/paredit.html

When I work with Clojure, I'm able to think in terms of blocks of logic as opposed to lines of code. This is extremely powerful.

The JVM is certainly not a limitation for many applications out there. Conversely, since Clojure has recur, the only time lack of TCO comes into play is when you're trying to do mutual recursion. I haven't run into a single case where I needed that in 6 years working with the language professionally.

However, Clojure is not really tied to the JVM. It runs on both Node.js and CLR. I'm actually currently working on a Node based micro-framework for Clojure: https://github.com/macchiato-framework/macchiato-core

> However no one has yet figured out how to represent Lisp code in good a way that doesn't require a large number of parentheses, often stacked together in groups of three or four.

Ah, not so! In some ancient Lisp dialects decades ago, there existed an invention known as the "super bracket". Namely the closing square bracket ] would simultaneously close any number of outstanding open parentheses up to the nearest opening [. For instance [foo (bar (1 2 3] could be written instead of (foo (bar (1 2 3))). It's not really such a great idea so it didn't catch on.

Looks like it was none other than InterLisp which had this, mentioned in P. Gabriel's and G. Steele's Evolution of Lisp paper:

https://www.dreamsongs.com/Files/HOPL2-Uncut.pdf P. 18.

Thanks, at least it seems to indicate that someone other than me had an issue with telling N parens from N-1 parens in a row.

I think this is a pretty common syntax problem, it's for example why I prefer xml to json for human editable data despite the extra verbosity - each ending is explicitly labeled.

The Foo(Bar(Baz))) calling style is of course equally broken.

> However no one has yet figured out how to represent Lisp code in good a way that doesn't require a large number of parentheses, often stacked together in groups of three or four.

Parinfer solved this problem for me: https://shaunlebron.github.io/parinfer/

> compilers like them

Editors too.

Although macros can make life difficult for clever editors that want to introspect code.

This is mitigated by the fact that Clojure doesn't expose reader macros to the user.

Don't macros actually help both compiler writers and end users here? Macros are expanded at macro-expansion time, which is a stage before code gets evaluated. Macro-expansion is akin to source code pre-processing in other languages. Therefore all necessary context for fully expanding a macro in Lisp is maximally a source file and minimally a single macro form within some shared compilation environment. Clever editors (like Emacs extensions commonly used by Scheme, Common Lisp, and Clojure programmers) make ample use of this functionality to provide all sorts of code introspection and other smart editing functionality.

Syntax level macros (like C) are unhygienic and basically dangerous, while proper (ast-transforming rather than syntax transforming) hygienic macros are ok for both tools and humans. Macros got a bad reputation just because there were poorly implemented for C.

SLIME is your friend. Stepwise forward and backward macro expansion and contraction. It's a thing of beauty.

I find -> and its brethren helps quite a lot.