Hacker News Reader

Comment by azrazalea | Hacker News Reader

Nope, it has new problems that are (IMO) worse.

I have dabbled in Common Lisp over the years and am quite comfortable with it. I know nothing about Clojure. What are the problems with Clojure? I am just curious. Thanks!

Usually, people tend to see the following problems:

* no native support, hosted language (js java)

* unreadable (java) tracebacks

* no tail call optimization

These are not my problems with Clojure, but then things I often read. I am interested in Common Lisp because of the native support.

I prefer loop/recur to TCO. You know exactly when you are, and are not, in tail position (which can be a bit obscure) and the compiler won't let you recur from non-tail.

loop/recur handles only a tiny part of TCO.

TCO means all calls in tail position are optimised, not just the self-recursive ones.

Personally I find loop/recur ugly. It's a partial hack around the lack of TCO.

Though I prefer looping statements like Common Lisp's ITERATE, whose design I like a lot...

https://common-lisp.net/project/iterate/doc/index.html

To add to what @macco said: No reader macros. Apparently this extraordinarily powerful tool violates a religious principle with the inventor Rich Hickey.

If it was powerful enough to warrant use, someone would hack it onto tools.reader. It's obvious where it would go. For some reason, nobody has bothered with this. Likely because the reader already has programmable data (via tagged literals) and anything beyond that results maintaining your own special reader.

I haven't yet encountered somewhere that I'd have used reader macros for that wasn't better solved by using data literals or tagged literals. There might be some random place where I need syntax beyond clojure's data literals, but I'm far more likely to use a combination of data literals + tags. If absolutely required (it hasn't been yet in 5 years of daily production usage), I could simulate custom grammar using clj-antlr and a macro. If, for some unknown reason, I needed a custom non-sexp grammar embedded in my lisp that I wanted to serialize exactly and then read back in the same syntax (probably because I hate myself and/or my team), I could hack it tools.reader.

tldr; you have reader macros if you want them. Nobody wants them who uses Clojure day to day. If they did want them, they could trivially extend tools.reader themselves.

Virtually nothing requires reader macros. That doesn't mean they aren't useful.

Personally if I wanted reader macros in clojure I wouldn't bother implementing them because it wouldn't be worth the pain to me. However, if clojure had them I/libraries would likely make good use of them.

It has a reader as a library. It's entirely possible for you to change its lookup map to a defmethod and go to town altering s-expressions for arbitrary syntax if you wish. You're not hacking a new reader here, you'd refactoring something that probably should have been a generic method to begin with into one. Nobody has bothered with this because it's not useful to anyone, as far as I can tell. People who want non-data syntax write it with clj-antlr/instaparse (which are very easy to use) and use a macro when they want to interleave it into their code. These universally end up with a data-based AST that is readable and printable.

In addition to the other problems described, Clojure just breaks the value of Lisp's syntax. Common Lisp does have its irregularities but code littered with Java imports and square brackets might as well just use C formatting and be done with it.

The primary value, to me of Lisp syntax is that code is represented as data structure literals which can be manipulated as easily as any other data structure prior to execution. Clojure has that; it just comes with literals for a few more data structures and uses two of them, vectors and maps in the syntax of built-in forms.

Why would arguments in Lisp (= "list processor") form a vector?

Is it so that the syntax of vectors can be used? Then it has technical consequences.

Is it because of technical issues (arguments are vectors internally) and thus it can be exposed in the syntax, too?

Or both?

I think the motivation for making the sequence of arguments in function/macro definitions vectors instead of lists was primarily syntactic - to make them look different from the body. They're definitely vectors internally though.

How do square brackets break the syntax? Aren't they just syntactic sugar for (vector ...), exactly the same as ' is syntactic sugar for (quote ...)?

And imports, obviously, are just special forms. It's not like Lisp doesn't have others. It's still an S-expression, so why is it problematic?

If you know Common Lisp reasonably, you'll probably have some insight into Clojure, e.g. Leiningen is a system definition facility; seq is an extension of sequences; and multimethods are generics much like methods. I'd say Clojure stands on the shoulders of giants.

There are some Lispy things that Clojure does out of the box that are more Lispy than than Common Lisp does out of the box, e.g. lists and other seq's as functions in the function position of an x-expression. There are things Clojure will not do such as reader macros. Clojure's syntax is a bit different, but generally reads cleaner in the same way one might say a font reads cleaner. YMMV.

> lists and other seq's as functions in the function position of an x-expression.

Makes code more difficult to read. I consider this a language design error. I had that on the Lisp Machine 30 years ago (example callable arrays, ... - maybe even Maclisp in the 70s had it), few people used it and it did not make it into Common Lisp.

Common Lisp was designed such that for the programmer and for the compiler the first element of a Lisp form is easily recognisable as a function: it has to be a symbol naming a function or an actual lambda expression.

Pays back it code maintenance over time...

> but generally reads cleaner in the same way one might say a font reads cleaner.

I think it reads cleaner in the way PERL code is read cleaner.

Personally, I find code easier or harder to read in the same ways I find prose easier or harder to read -- it depends on the author's ability to tell a story and the story the author is trying to tell and my interest in hearing the telling.

Seq's as functions are sometimes more readable to me for the same reasons code that uses reader macros may be more readable to me (even though reader macros may do away with normal s-expression syntax entirely). But again, mileage varies.

Arrays are functions, by definition. They relate inputs to outputs.

That does not mean I want them in a programming language to be functions.

I guess I just don't see a disadvantage. An array is a pure function, no side effects, so it should always be safe to treat it as one.

One disadvantage: you can't inline the code for such a vector reference, unless the compiler knows at compile time that this is a vector reference.

But this is true for anything that's in the callee position, right? Either it can be determined (possibly via static flow analysis) that it's a particular function, in which case it is inlined; or else it is an unknown function, in which case it won't be. It would seem that statically verifying that something is a vector reference isn't really harder than doing the same for a function, all else being equal.

if a Common Lisp compiler sees a call to cl:aref then it can inline it, without using static flow analysis or similar...

I was under the impression that CL compilers already had to do a lot of fairly complicated static analysis to achieve acceptable performance, because of dynamic typing.

Depends. Since the developer can use low-level functions and provide type declarations, a compiler can generate usefully fast code without too much work. More advanced compilers need less declarations, since they do some amount of type inference. One of the costs: the compiler then usually is quite a bit slower.

Reply on news.ycombinator.com