4 ms·

I don't see anything profound here, except perhaps that the language will gladly accept the user's blatant type error and just explode at runtime. For the most

I don't see anything profound here, except perhaps that the language will gladly accept the user's blatant type error and just explode at runtime. For the most part this article is fetishising over basic syntax. Surely the compelling parts of Clojure go somewhat deeper than basic syntax. And if this is another tired discussion about legibility of syntax between languages, I have to wonder why people are still so fascinated by this? Between the following two representations of the same function… (defn f [x] (+ (* 3 x) 1)) …and… f x = 3 * x + 1 …I see very little difference in legibility. Sure, one is visually noisier (and incidentally, the noisier, less clean(!!!) notation is Robert C. Martin's favourite) but if you can afford to navel-gaze this much on syntax I'd question why you don't have anything more important to do. Of course I recognise that I must also not have much better to do since I read the article and I'm now commenting on it. It's just weird to me that one would fetishise syntax, and then describe a language sporting a less visually-noisy syntax as "The Dark Path". Edit: Apparently I need to state for the record that I spent a few years writing Clojure professionally. I'm not unfamiliar — I just haven't drowned in kool-aid.

deleted 7y ago
[deleted]
Scarbutt 7y ago
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.
- tincholio 7y ago
  I'd extend this to all his writings.
malisper 7y ago
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.
- hope-striker 7y ago
  > 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 https://doc.rust-lang.org/reference/procedural-macros.html
  - roenxi 7y ago
    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.
wellpast 7y ago
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.
- wokwokwok 7y ago
  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.
billjings 7y ago
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.
- TurboHaskal 7y ago
  It's all about reducing the feedback loop. Expression based, late binding languages with interactive environments can't be topped.
crispinb 7y ago
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.html 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.
2019-nCoV 7y ago
The profound insight is that your example demonstrates almost all of Clojure's syntax.
- yakshaving_jgt 7y ago
  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.
  - 2019-nCoV 7y ago
    Exactly. Clojure's syntax is as simple as pragmatically possible, but not simpler.
    - yakshaving_jgt 7y ago
      …and yet, still more visually noisy than the same function written in Haskell. Not that it actually matters, of course.
      - 2019-nCoV 7y ago
        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 https://gist.github.com/honza/5897359
        yakshaving_jgt 7y ago
        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.
      - sooheon 7y ago
        > 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.
jwr 7y ago
> 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.
SaxonRobber 7y ago
I find ML languages easier to read than Lisps, but that’s an unpopular opinion.
- yakshaving_jgt 7y ago
  I do too, but Clojure people get awfully touchy when you criticise their church.
  - robto 7y ago
    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.
    - SaxonRobber 7y ago
      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.

deleted 7y ago

[deleted]

Scarbutt 7y ago

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.

tincholio 7y ago
I'd extend this to all his writings.

malisper 7y ago

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.

hope-striker 7y ago
> 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 https://doc.rust-lang.org/reference/procedural-macros.html
- roenxi 7y ago
  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.

wellpast 7y ago

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.

wokwokwok 7y ago
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.

billjings 7y ago

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.

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

crispinb 7y ago

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.html 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.

2019-nCoV 7y ago

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

yakshaving_jgt 7y ago
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.
- 2019-nCoV 7y ago
  Exactly. Clojure's syntax is as simple as pragmatically possible, but not simpler.
  - yakshaving_jgt 7y ago
    …and yet, still more visually noisy than the same function written in Haskell. Not that it actually matters, of course.
    - 2019-nCoV 7y ago
      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 https://gist.github.com/honza/5897359
      - yakshaving_jgt 7y ago
        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.
    - sooheon 7y ago
      > 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.

jwr 7y ago

> 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.

SaxonRobber 7y ago

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

yakshaving_jgt 7y ago
I do too, but Clojure people get awfully touchy when you criticise their church.
- robto 7y ago
  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.
  - SaxonRobber 7y ago
    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.