7 ms·

I've started learning Clojure about a year ago, couldn't say it was easy (the fault might be with me and not Clojure) Clojure has a lot a faults (just look at

I've started learning Clojure about a year ago, couldn't say it was easy (the fault might be with me and not Clojure) Clojure has a lot a faults (just look at some of the comments here) BUT and it's a BIG BUT for me... Clojure is SUPER FUN :) Over the years(15+), I've been coding in PHP (suck it haters), Go, Rust,Java,Python AngularJS+, Svelte and I can honestly say for me, nothing is more fun that coding in Clojure. It's fun testing a function in "realtime" by just "eval" it on the spot. I don't even code "in the REPL" I just use Calva and eval inline in VSCode Maybe it's cause it's my new toy but it really does bring back the "joy of coding" I've been missing in the other languages. *Learning Clojure became much more easier, once I told myself "It's Maps All The Way Down :D" Sure there are stuff like atoms that make it possible to code around the "immutability" but that is like using a cheat-code to go back to the old ways. Yes there are many times when mutable-data-structures are required, but while learning, don't grab for them as a first solution ! Anywhoo YMMV but once you get over the warts (many there are), much fun and insights awaits :)

kelseyfrog 4y ago
Clojure user here since 2010(my earliest Clojure project on Github), and while I agree with the fun point, the iceberg wart for me at this point is the inelegance of the interface hierarchy and its structure behind the scenes. Clojure's forward-facing interface (a hundred functions that operate on one data structure) ended up breaking down for me at some point and became 10 functions on 10 data structures and those data structures became AFn, APersistentSet, APersistentMap, APersistentVector, IFn, IPersistentSet, IPersistentMap, IPersistentVector, ITransientMap, ITransientVector, IndexedSeq, LazySeq, &c, &c, &c. Maybe I started writing code wrong. Maybe I dived too deep into the internals, Maybe it was something else. But at the end, there wasn't one data structure, there were dozens and dozens each with justifiable differences, but even so, that's not what was advertised. It took a decade to reach that point and perhaps the vast majority of folks never will. The sad part is that I know none of it is up for change without creating a Clojure2, and that highlights the problem. Why should changing the internals need to break backwards compatibility? There is one unspeakable reason: the illusion wasn't complete and they weren't really internals to begin with.
- rawoke083600 4y ago
  Right ! But you still had fun the last decade correct /s ? :P My "real response" to is, I haven't seen this complaint(concern) to this extend that you describe in the wild or in my own life. I've definitely not coded in Clojure long enough to have seen any of that like you have, thus far my experience has been good with 'just' using maps. I do feel my next "step-up" would be to incorporate something like SPEC or Mali to "define/check" the fields/structure of said maps.
- lenkite 4y ago
  Lets say that someone wants to improve on Clojure and make a better functional, immutable LISP! What should they start with ? Some things I miss is type support (for easy refactoring, auto documentation and performance), (small) native compilation, support for mobile platforms and their UI's, first-class web-assembly support, real structs and misc things like performant implementations for `first`, `last` and other clojure functions, light-weight concurrency like Go, data-flow analysis and pipelines, etc. An example of clojure performance issues covered here: https://tech.redplanetlabs.com/2020/09/02/clojure-faster/ https://tech.redplanetlabs.com/2020/09/02/clojure-faster/ All that stuff above should be fixed at the language/stdlib level. But what is your take on what needs fixing ? What would have been your solution for the N data-structures/ M algo problem you mentioned above ?
  - bcrosby95 4y ago
    If you want an easy win, one thing Rich mentioned in a talk is - if he had to do Clojure all over again today - he would put transducers at the 'bottom'. For data transformation this makes the underlying collection type largely immaterial. > real structs I'm not even sure if value types are conducive towards immutable, persistent data structures. I'm certainly excited for project Valhalla but I'm not sure if Clojure, nor any Clojure-like JVM language, written in an idiomatic fashion, would really benefit from it. > light-weight concurrency like Go Project loom is already in preview mode. Lightweight concurrency is nearly here for any JVM language, and once it's fully released I will likely have zero reason to use core.async. > type support Static typing is A Thing you can choose to do, but I doubt you would get many daily Clojure users agreeing that it is "better". I think it's different and better in some circumstances but not necessarily others. It definitely feels trendy these days, sorta like how dynamic typing felt trendy 15 years ago.
dack 4y ago
Yeah I think the hype cycle with Clojure looks like this: Stage 1: Confused by parens/the lispiness. early uncertainty Stage 2: learn the REPL and library functions and fall in love. irrational exuberance Stage 3: build an unmaintainable mess and can't refactor. trough of sorrow Stage 4: figure out how to decouple appropriately and evolve the codebase rather than refactor all the time. live happily ever after!
- rawoke083600 4y ago
  Stage5: All other languages and their syntax now looks ugly and wrong. I'm mean for heavens sake put the parens on the outside ! We are not heathens. Lol only half joking. It really did surprise me how can something I hated some much in the beginning of learning Clojure (all the parens) has now become one of the things I most adore about the language (all the parens)
  - nickpeterson 4y ago
    This is the worldview of all apl developers.
    - agumonkey 4y ago
      Last time I listed my resume I added "prolog or apl please"
  - pjmlp 4y ago
    ML (via Caml Light), Lisp, Smalltalk and Prolog did it for me, each on its own way. Nowadays I am happy to see a bit of them on the languages I actually get to use.
  - yogthos 4y ago
    It's really hard for me to see any justifications for a syntax that's not based around s-expressions. The benefits of being able to trivially transform any code as data and have powerful structural editing facilities outweigh any perceived downsides in my experience. I also find that s-exps act as a visual diagramming tool making your code more scannable because you can visually see the relationships between statements by looking at the nesting.
yogthos 4y ago
I've been working with Clojure for the past decade, and it's still the most enjoyable development experience I've had. Once you experience using an interactive workflow where you can see the results from the code you're writing live, it's really hard to go back.
- agumonkey 4y ago
  I physically suffer when I go back to systems like django, where there's no principled underpinnings, no 'protocol' and only a thin way to interact with the system live. Curse of good languages.
  - yogthos 4y ago
    indeed
- atdt 4y ago
  Can you recommend a good YouTube video that demonstrates this? I'm used to writing code incrementally in Python via the IPython REPL. I've also used Twisted's Manhole to get a REPL inside an already-running Python server process. But I believe you're referring to something substantially richer than that.
  - sokoloff 4y ago
    For me, it's a combination of having a REPL and having a good interactive interface between the editor and the REPL. Typing forms into and evaluating them in the REPL is one thing, but typing them into your editor file and evaluating them from there in the REPL is much more useful. (I can't fairly say one way or the other whether that's possible/common in IPython.) Here's a short one to give a taste of that: https://www.youtube.com/watch?v=rQ802kSaip4 https://www.youtube.com/watch?v=rQ802kSaip4 A good section from another talk specifically about that "don't type at the REPL" point: https://www.youtube.com/watch?v=Qx0-pViyIDU&t=740s https://www.youtube.com/watch?v=Qx0-pViyIDU&t=740s Here's a longer set of related references: https://clojure.org/guides/repl/annex_community_resources https://clojure.org/guides/repl/annex_community_resources
phforms 4y ago
Same here, started using Clojure pretty much exclusively about a year ago and never looked back. It was rough to get to that comfortable state where I am now, having to find out how Clojure CLI tools work, what Java Classpaths are, how to properly set up my editor (Neovim), how to make sense of Clojure internals like “seq” and when to use which collection type (and when not to care), etc. But it has also been a fun and liberating experience, after I went down the static type route for some years. I feel like Clojure just doesn’t get in my way and doesn’t force me to follow a certain style or paradigm; it provides many different choices (“providing more” instead of “taking away”) and treats you like an adult who can make responsible decisions on their own. Although I missed the linguistic art of domain modelling through type definitions, spec gave me some of that back and even provides stuff like generative testing, which is pretty awesome. Of course, it is not meant as a replacement for static typing and has a different philosophy (see Rich Hickeys talks about it), but for me it is the best of both worlds. The dynamic development style is something that I experienced before through learning Lisp/Scheme and it is also one of the thing that I enjoy most about Clojure. Coding “experimental”, building functions from individual pieces that I iteratively design using the REPL as my assistant (which actually means - as parent wrote - communicating with it from the editor itself, which we mostly do), feels so natural and I would miss it now that I am so used to it.
- jjnoakes 4y ago
  > treats you like an adult who can make responsible decisions on their own I have to disagree with this characterization. It also seems a bit patronizing. Having more choice can be good in some cases, and having fewer choices can be good in other cases. One isn't treating you less like an adult than the other.
- KingMob 4y ago
  > doesn’t force me to follow a certain style or paradigm; it provides many different choices (“providing more” instead of “taking away”) and treats you like an adult who can make responsible decisions on their own. This is really not correct. Certain choices Hickey made, prevent you from coding as you like. E.g., Hickey doesn't allow strong reader macros or inheritance in Clojure.

kelseyfrog 4y ago

Clojure user here since 2010(my earliest Clojure project on Github), and while I agree with the fun point, the iceberg wart for me at this point is the inelegance of the interface hierarchy and its structure behind the scenes. Clojure's forward-facing interface (a hundred functions that operate on one data structure) ended up breaking down for me at some point and became 10 functions on 10 data structures and those data structures became AFn, APersistentSet, APersistentMap, APersistentVector, IFn, IPersistentSet, IPersistentMap, IPersistentVector, ITransientMap, ITransientVector, IndexedSeq, LazySeq, &c, &c, &c. Maybe I started writing code wrong. Maybe I dived too deep into the internals, Maybe it was something else. But at the end, there wasn't one data structure, there were dozens and dozens each with justifiable differences, but even so, that's not what was advertised. It took a decade to reach that point and perhaps the vast majority of folks never will. The sad part is that I know none of it is up for change without creating a Clojure2, and that highlights the problem. Why should changing the internals need to break backwards compatibility? There is one unspeakable reason: the illusion wasn't complete and they weren't really internals to begin with.

rawoke083600 4y ago
Right ! But you still had fun the last decade correct /s ? :P My "real response" to is, I haven't seen this complaint(concern) to this extend that you describe in the wild or in my own life. I've definitely not coded in Clojure long enough to have seen any of that like you have, thus far my experience has been good with 'just' using maps. I do feel my next "step-up" would be to incorporate something like SPEC or Mali to "define/check" the fields/structure of said maps.
lenkite 4y ago
Lets say that someone wants to improve on Clojure and make a better functional, immutable LISP! What should they start with ? Some things I miss is type support (for easy refactoring, auto documentation and performance), (small) native compilation, support for mobile platforms and their UI's, first-class web-assembly support, real structs and misc things like performant implementations for `first`, `last` and other clojure functions, light-weight concurrency like Go, data-flow analysis and pipelines, etc. An example of clojure performance issues covered here: https://tech.redplanetlabs.com/2020/09/02/clojure-faster/ https://tech.redplanetlabs.com/2020/09/02/clojure-faster/ All that stuff above should be fixed at the language/stdlib level. But what is your take on what needs fixing ? What would have been your solution for the N data-structures/ M algo problem you mentioned above ?
- bcrosby95 4y ago
  If you want an easy win, one thing Rich mentioned in a talk is - if he had to do Clojure all over again today - he would put transducers at the 'bottom'. For data transformation this makes the underlying collection type largely immaterial. > real structs I'm not even sure if value types are conducive towards immutable, persistent data structures. I'm certainly excited for project Valhalla but I'm not sure if Clojure, nor any Clojure-like JVM language, written in an idiomatic fashion, would really benefit from it. > light-weight concurrency like Go Project loom is already in preview mode. Lightweight concurrency is nearly here for any JVM language, and once it's fully released I will likely have zero reason to use core.async. > type support Static typing is A Thing you can choose to do, but I doubt you would get many daily Clojure users agreeing that it is "better". I think it's different and better in some circumstances but not necessarily others. It definitely feels trendy these days, sorta like how dynamic typing felt trendy 15 years ago.

dack 4y ago

Yeah I think the hype cycle with Clojure looks like this: Stage 1: Confused by parens/the lispiness. early uncertainty Stage 2: learn the REPL and library functions and fall in love. irrational exuberance Stage 3: build an unmaintainable mess and can't refactor. trough of sorrow Stage 4: figure out how to decouple appropriately and evolve the codebase rather than refactor all the time. live happily ever after!

rawoke083600 4y ago
Stage5: All other languages and their syntax now looks ugly and wrong. I'm mean for heavens sake put the parens on the outside ! We are not heathens. Lol only half joking. It really did surprise me how can something I hated some much in the beginning of learning Clojure (all the parens) has now become one of the things I most adore about the language (all the parens)
- nickpeterson 4y ago
  This is the worldview of all apl developers.
  - agumonkey 4y ago
    Last time I listed my resume I added "prolog or apl please"
- pjmlp 4y ago
  ML (via Caml Light), Lisp, Smalltalk and Prolog did it for me, each on its own way. Nowadays I am happy to see a bit of them on the languages I actually get to use.
- yogthos 4y ago
  It's really hard for me to see any justifications for a syntax that's not based around s-expressions. The benefits of being able to trivially transform any code as data and have powerful structural editing facilities outweigh any perceived downsides in my experience. I also find that s-exps act as a visual diagramming tool making your code more scannable because you can visually see the relationships between statements by looking at the nesting.

yogthos 4y ago

I've been working with Clojure for the past decade, and it's still the most enjoyable development experience I've had. Once you experience using an interactive workflow where you can see the results from the code you're writing live, it's really hard to go back.

agumonkey 4y ago
I physically suffer when I go back to systems like django, where there's no principled underpinnings, no 'protocol' and only a thin way to interact with the system live. Curse of good languages.
- yogthos 4y ago
  indeed
atdt 4y ago
Can you recommend a good YouTube video that demonstrates this? I'm used to writing code incrementally in Python via the IPython REPL. I've also used Twisted's Manhole to get a REPL inside an already-running Python server process. But I believe you're referring to something substantially richer than that.
- sokoloff 4y ago
  For me, it's a combination of having a REPL and having a good interactive interface between the editor and the REPL. Typing forms into and evaluating them in the REPL is one thing, but typing them into your editor file and evaluating them from there in the REPL is much more useful. (I can't fairly say one way or the other whether that's possible/common in IPython.) Here's a short one to give a taste of that: https://www.youtube.com/watch?v=rQ802kSaip4 https://www.youtube.com/watch?v=rQ802kSaip4 A good section from another talk specifically about that "don't type at the REPL" point: https://www.youtube.com/watch?v=Qx0-pViyIDU&t=740s https://www.youtube.com/watch?v=Qx0-pViyIDU&t=740s Here's a longer set of related references: https://clojure.org/guides/repl/annex_community_resources https://clojure.org/guides/repl/annex_community_resources

phforms 4y ago

Same here, started using Clojure pretty much exclusively about a year ago and never looked back. It was rough to get to that comfortable state where I am now, having to find out how Clojure CLI tools work, what Java Classpaths are, how to properly set up my editor (Neovim), how to make sense of Clojure internals like “seq” and when to use which collection type (and when not to care), etc. But it has also been a fun and liberating experience, after I went down the static type route for some years. I feel like Clojure just doesn’t get in my way and doesn’t force me to follow a certain style or paradigm; it provides many different choices (“providing more” instead of “taking away”) and treats you like an adult who can make responsible decisions on their own. Although I missed the linguistic art of domain modelling through type definitions, spec gave me some of that back and even provides stuff like generative testing, which is pretty awesome. Of course, it is not meant as a replacement for static typing and has a different philosophy (see Rich Hickeys talks about it), but for me it is the best of both worlds. The dynamic development style is something that I experienced before through learning Lisp/Scheme and it is also one of the thing that I enjoy most about Clojure. Coding “experimental”, building functions from individual pieces that I iteratively design using the REPL as my assistant (which actually means - as parent wrote - communicating with it from the editor itself, which we mostly do), feels so natural and I would miss it now that I am so used to it.

jjnoakes 4y ago
> treats you like an adult who can make responsible decisions on their own I have to disagree with this characterization. It also seems a bit patronizing. Having more choice can be good in some cases, and having fewer choices can be good in other cases. One isn't treating you less like an adult than the other.
KingMob 4y ago
> doesn’t force me to follow a certain style or paradigm; it provides many different choices (“providing more” instead of “taking away”) and treats you like an adult who can make responsible decisions on their own. This is really not correct. Certain choices Hickey made, prevent you from coding as you like. E.g., Hickey doesn't allow strong reader macros or inheritance in Clojure.