Hacker News Reader

> I don't see anything profound here

[borderline trolling, but...] In general, the syntax doesn't matter much. Most programming language discussions focus on the syntax, but in the long term and in larger applications that's not the important part.

From my personal opinion, based on using Clojure for about ten years, and maintaining a SaaS business based on it for the last four: what really matters are many little features taken together. The sequence abstractions and functions, great data structures and their interop, defined serialization for data structures, core.async, transducers, spec — each of those can be picked apart as "nothing profound" by itself. And yet together they form a tool which removes most friction from programming and lets me focus on the problem domain.

I've programmed Lisp code for several years and personally I do find Lisp code harder to read, especially when doing arithmetic.

The direct benefit of Lisp syntax is that everything is consistent. Arithmetic operators have the same syntax as regular functions. Because all Lisp code has a consistent structure, that makes it easy to do some really neat things. For example, it isn't hard to write a program that takes Lisp code as input and processes it in some way.

This is the reason why you see so many people write a toy Lisp interpreter. It's really easy to write code to evaluate Lisp code because all Lisp code has an identical structure.

As a Lisp programmer, this benefit emerges in the form of macros. Macros run at compile time, take some Lisp code as input, and spit out new Lisp code as output. The new lisp code is then substituted for the old one.You can think of macros as a very small user-defined compiler. These let you build all sorts of language constructs that you couldn't build in other programming languages. For example, you can add pattern matching to a Lisp with macros. The macro would take a list of patterns and corresponding expressions as input and spit out some code that checks for the patterns and runs the corresponding expressions if the pattern matches.

> These let you build all sorts of language constructs that you couldn't build in other programming languages.

Many languages (e.g. Rust[0]) let you write procedural macros, even if their grammar is much more complex than that of a Lisp.

Is there some technical advantage to Lisp macros over macro processors in other languages (ignoring string-based ones like the CPP), or do all the benefits lie in the massively improved ergonomics of writing macros?

(Note that Rust also has simpler hygienic macros, but they're not expressive enough for many things.)

[0]: https://doc.rust-lang.org/reference/procedural-macros.html

You've pretty much covered it; lisps are better at macros than any language with complicated syntax.

Most of the flow control in a lisp (for, while, if, etc, etc) can be implemented with macros. It isn't often a program needs a new form of flow control but when you need it it is there as an option and a lisp will do it better than the competition. If Rust can do threading macros then it probably has enough of the power that it isn't missing out. Still going to be a bit cumbersome.

Lisps give you the option that flow control can be implemented in a library. None of the old-school popular languages manage that.

I've been playing around with Clojure, having a lot of fun, and enjoying the community around the language. I love it, I absolutely love it, and I will come around to saying some glowing things about it at the end of this comment.

But first...

When I saw Bob Martin writing about it, it was a bit of a, "Damn.. Spaceballs!" moment. And the post itself didn't exactly light me on fire. So I don't know if this is the greatest introduction to the language.

And to be honest, the syntax is hard to read. It imposes more structure on everything you do: certain kinds of operations require more nesting, more context. Nothing just sits on the page with a standard layout and structure: it's always governed by these parantheses that are running around all willy nilly. And that's just harder to read.

BUT. There is one huge, huge, huge, huge win from it:

Every single thing in the language works the same way. Everything! It's all just expressions.

That might seem like no big deal. But as a programmer, it means that if I don't understand why a piece of my program isn't working, all I have to do is put my cursor right after the expression I want to understand and type C-c C-e to evaluate that subexpression.

So if

  (defn f [x] (+ (* 3 x) 1))

...isn't working as I expect, I don't have to run (f 5). I can bind x to 5 and evaluate (* 3 x). And the same applies to any larger program I write.

There are other things that I love about Clojure, but this has certainly been a breath of fresh air coming from other languages that have more ceremony. It is liberating to be able to isolate and assess a portion of code without having to refactor it into a standalone method. I can move much faster, and have a lot more fun.

It's all about reducing the feedback loop. Expression based, late binding languages with interactive environments can't be topped.

It's not supposed to be profound. It's just a tiny tutorial/taster. He has more to say (fwiw) on the why here: http://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.h...

Quite agree on your syntax comments. The morphology of the syntax itself (as opposed to its consistency, homoiconicity, etc) is uninteresting. Who even notices syntax after a while using a programming language? I think I could edit any of the languages I know in any of a number of surface representations - syntax as-is, some kind of graphical AS tree, graphical nested bubbles, etc etc.

I honestly think the syntax fetish is just because people want to write something (we all like the sound of our own voices/keyboards), and if they don't know anything about a language, emoting on surface syntax is about all they've got.

Woah strawman. There's no fetishization going on here, it's a micro-tutorial.

It's the opposite of profound - and decidedly so.

You're focusing on something called syntax and legibility, not this article -- which is why you see no diff. between the two expressions.

Of course on a superficial level the difference is nominal.

Why the first one is more powerful than the second goes much deeper. The first expression is both a function definition and a first-class list. The latter is pure syntax.

The consequences of this go deep - but if you're looking for something profound at the surface of things then carry on shaving your yaks.

I think you've missed the point; this is a blog post by Uncle Bob.

Everything he says is profound, right?

(No, it's not, but to be fair the parent comment also about people assuming just because someone famous says something, it is necessarily also profound).

Also, unrelated...

> but if you're looking for something profound at the surface of things then carry on shaving your yaks.

Doesn't 'yak shaving' refer to the same thing as 'going down a rabbit hole', 'pulling a piece of yarn', etc?

Ie. Looking at something that looks simple and then finding it much deeper and more complicated than you expected?

Isn't that... exactly what you're talking about with the syntax?

Like, you're literally telling the parent to keep pulling at the syntax comparisons, like oh hey, bet you'll find nothing interesting here... then literally also telling them that it is a rabbit hole when you look at how functions are lists?

That makes absolutely no sense to me when you use it in that context.

I wouldn't give much importance to his Clojure articles, they are all shallow and superficial. My only conclusion is that he writes them primarily for marketing purposes.

I'd extend this to all his writings.

The profound insight is that your example demonstrates almost all of Clojure's syntax.

That in and of itself isn't particularly useful or meaningful. There are languages with even less syntax than Clojure, but that doesn't necessarily make them more practical or ergonomic.

Exactly. Clojure's syntax is as simple as pragmatically possible, but not simpler.

…and yet, still more visually noisy than the same function written in Haskell.

Not that it actually matters, of course.

And yet anything more substantial than a single-line function clearly demonstrates the breadth of syntax required in Haskell comparatively, e.g. https://gist.github.com/honza/5897359

Those two snippets are not equivalent. If you were trying to make an argument in good faith, you would have read the code properly and seen that for yourself, and/or read the comments below the snippets which point this out and link to a further explanation.

> Not that it actually matters, of course.

It matters if you care about consistency. After learning the simplicity of lisp, all other use of special symbols for infix syntax strikes me as arbitrary and fiddly. Arbitrary choices should be left to library (function and macro) developers, I appreciate that the core language is simple, extensible, and consistent.

I find ML languages easier to read than Lisps, but that’s an unpopular opinion.

I do too, but Clojure people get awfully touchy when you criticise their church.

I don't think it's that it's "criticism of the church" that people get touchy about. It's just that people tend to focus on the syntax in isolation and not acknowledge the tradeoffs that are involved with different syntaxes.

A lot of lispers are used to people complaining about the parens and syntax but not acknowledging the consistency, the macros, the language-design-as-a-library, the structural editing, and the easy repl integration story that you get in return. And those are the features that lispers are really excited about, and it's frustrating when people don't acknowledge that you give up all of those benefits when you choose algol-like syntax.

Now, I'm not saying that you're one of those people who doesn't understand that, but if you've met lispers who "get touchy" about it that's probably why.

And then those same Lispers will whole sale write off procedural Algol like languages as being "lesser", despite everything that that has been accomplished with languages like C.