4 ms·

I just moved a medium sized codebase from clojure transducers to JS, and after having used clojure for 7+ years, and done so professionally, I don't wanna go ba

by j-pb 6y ago

I just moved a medium sized codebase from clojure transducers to JS, and after having used clojure for 7+ years, and done so professionally, I don't wanna go back, ever. The JS solution is shorter, faster, and easier to understand. I'm thankfull for the insights into reality and programming clojure has provided, but highly optimised clojure is neither idiomatic nor pretty, you end up with eductions everywhere. Combine that with reaaaallllyy bad debuggability with all those nested inside out transducer calls (the stack traces have also gotten worse over the years, I don't know why, and a splintered ecosystem (lein, boot, clj-tools)) I'd pick rust and deno/js any day for a greenfield project over clojure. sadly.

nbardy 6y ago
Debugging performance problems is the reason I stopped using `cljs`. Those stack traces are so painful.
kostadin 6y ago
I have limited exposure to Clojure transducers but I spend most of my time writing JS/TS and I've found thi.ng/transducers[0] a pleasure to work with and super elegant for constructing data processing workflows. [0] https://github.com/thi-ng/umbrella/tree/develop/packages/transducers https://github.com/thi-ng/umbrella/tree/develop/packages/tra...
ithrow 6y ago
That's a very common scenario for Clojure users to go through and it's one of the reason it has so many abandoned/unfinished libraries (although 7 years was a lot). After they have gather all the insights they can from Clojure and its ecosystem (which is a worthy endeavor IMO), they go back to their big ecosystem mainstream programming language because of all the benefits you get from it even if that programming language is worse. It also doesn't help Clojure the fact that JS 2020 is way better than JS in 2010 and that you can easily bring all your Clojure insights/concepts to JS.
- dcolkitt 6y ago
  > After they have gather all the insights they can from Clojure and its ecosystem (which is a worthy endeavor IMO) Just out of curiosity, what do you mean by this? I've never used Clojure, but have done a fair bit of hacking in other Lisp dialects. Do you (or anyone with an opinion) think there's some insight benefit to Clojure specifically vis-a-vis Racket/Scheme/etc?
  - ithrow 6y ago
    Production implementations of persistent data structures in an industrial VM plus abstractions for state management, polymorphism, concurrency, the sequence abstraction, etc... It just gives more things for day-to-day programming. While Scheme gives you good foundations, you have to build a lot stuff yourself, it's too primitive (haven't follow Scheme since R5RS). But it's really mostly about the literal data structures and leveraging them anywhere you can to represent information, it's maps everywhere. Data oriented solutions is the common term use in the community. This answer by one the Clojure maintainers sums it up better than me: https://news.ycombinator.com/item?id=25377022 https://news.ycombinator.com/item?id=25377022 Racket extends Scheme with useful stuff too for everyday programming but Clojure's immutable data structures with its big library of functions for manipulating them in a nice abstract generic way, with the fact that in runs in the JVM gives it a big edge for "real world" programming IMO. You do need strong knowledge of Java and the JVM for critical services. Almost all your knowledge of Racket and Scheme will transfer and be valuable for Clojure, so you already know most of it and have a big head start if you plan to learn it.
  - divs1210 6y ago
    Some of the top reasons for me: * immutability with persistent data structures * csp with core.async * encourages designing a data-driven functional core with an imperative shell * powerful REPL (better than python / scheme / racket, worse than SBCL) * multi-platform (backend / browser / mobile through react native) * easy and comprehensive testing because of several factors: functional nature, dynamic binding of vars, generative testing, etc.
- reader_mode 6y ago
beders 6y ago
> reaaaallllyy bad debuggability Odd, I can just step through my code with Cursive if I need to.
- harperlee 6y ago
  How is the experience with transducers? I did not try it but I fear that you'd first see the transducer being constructed into a heap of anonymous functions and clojure implementation details, and then afterwards you can step into how that gets executed in each element of the stream. I have had unpleasant experiences with clojure debugging... so I feel what your parent post is saying.
  - raspasov 6y ago
    Perhaps it's just a different way of doing the same thing, but I never feel the need to reach for a debugger in the presence of the REPL and tools like Timbre. Just wrap what you want to see in (timbre/spy ...) and you're good to go.
    - j-pb 6y ago
      Please stop moving the goalpost. "Debugging clj / cljs is hardpartly due to transducers" -> "I can step though my code with cursive" -> "how does cursive handle transducers?" -> "you don't need a debugger"
      - nightwolf 6y ago
        The person who mentioned using the Cursive debugger is different than the person who mentioned using the REPL.
        tiagoespinha 6y ago
        It's not about the person, but the idea.
divs1210 6y ago
Yup, it's like the leadership is actively hostile towards community building. * Prismatic Schema, immensely popular, was "replaced" by spec, which is not yet complete and still in the research phase * leiningen (one of the best language tooling out there) was "replaced" by Clojure CLI that can't do half of what leiningen can * transducers (a brilliant concept) are not easy (as in close at hand) because the code is quite different to normal lazy-sequence based code (I wrote a library [1] to address this) I still prefer Clojure for all my side projects, but it is very clear that the community is tiny and fragmented. [1] https://github.com/divs1210/streamer https://github.com/divs1210/streamer
- harperlee 6y ago
  Schema and spec do not target the same functionality. In general I agree that it would be best if a small community does not spread itself too thin, but on the other hand, can't Hickey, Miller et al work on what they are interested in? They have published rationales for why those "splintering" works are of interest and they make sense. It seems incongruent to happily use a tool that was born out of an opinionated design, and then complain when the authors keeps pushing their opinionated PL design.

by j-pb 6y ago

nbardy 6y ago

Debugging performance problems is the reason I stopped using `cljs`. Those stack traces are so painful.

kostadin 6y ago

I have limited exposure to Clojure transducers but I spend most of my time writing JS/TS and I've found thi.ng/transducers[0] a pleasure to work with and super elegant for constructing data processing workflows. [0] https://github.com/thi-ng/umbrella/tree/develop/packages/transducers https://github.com/thi-ng/umbrella/tree/develop/packages/tra...

ithrow 6y ago

That's a very common scenario for Clojure users to go through and it's one of the reason it has so many abandoned/unfinished libraries (although 7 years was a lot). After they have gather all the insights they can from Clojure and its ecosystem (which is a worthy endeavor IMO), they go back to their big ecosystem mainstream programming language because of all the benefits you get from it even if that programming language is worse. It also doesn't help Clojure the fact that JS 2020 is way better than JS in 2010 and that you can easily bring all your Clojure insights/concepts to JS.

dcolkitt 6y ago
> After they have gather all the insights they can from Clojure and its ecosystem (which is a worthy endeavor IMO) Just out of curiosity, what do you mean by this? I've never used Clojure, but have done a fair bit of hacking in other Lisp dialects. Do you (or anyone with an opinion) think there's some insight benefit to Clojure specifically vis-a-vis Racket/Scheme/etc?
- ithrow 6y ago
  Production implementations of persistent data structures in an industrial VM plus abstractions for state management, polymorphism, concurrency, the sequence abstraction, etc... It just gives more things for day-to-day programming. While Scheme gives you good foundations, you have to build a lot stuff yourself, it's too primitive (haven't follow Scheme since R5RS). But it's really mostly about the literal data structures and leveraging them anywhere you can to represent information, it's maps everywhere. Data oriented solutions is the common term use in the community. This answer by one the Clojure maintainers sums it up better than me: https://news.ycombinator.com/item?id=25377022 https://news.ycombinator.com/item?id=25377022 Racket extends Scheme with useful stuff too for everyday programming but Clojure's immutable data structures with its big library of functions for manipulating them in a nice abstract generic way, with the fact that in runs in the JVM gives it a big edge for "real world" programming IMO. You do need strong knowledge of Java and the JVM for critical services. Almost all your knowledge of Racket and Scheme will transfer and be valuable for Clojure, so you already know most of it and have a big head start if you plan to learn it.
- divs1210 6y ago
  Some of the top reasons for me: * immutability with persistent data structures * csp with core.async * encourages designing a data-driven functional core with an imperative shell * powerful REPL (better than python / scheme / racket, worse than SBCL) * multi-platform (backend / browser / mobile through react native) * easy and comprehensive testing because of several factors: functional nature, dynamic binding of vars, generative testing, etc.
reader_mode 6y ago

beders 6y ago

> reaaaallllyy bad debuggability Odd, I can just step through my code with Cursive if I need to.

harperlee 6y ago
How is the experience with transducers? I did not try it but I fear that you'd first see the transducer being constructed into a heap of anonymous functions and clojure implementation details, and then afterwards you can step into how that gets executed in each element of the stream. I have had unpleasant experiences with clojure debugging... so I feel what your parent post is saying.
- raspasov 6y ago
  Perhaps it's just a different way of doing the same thing, but I never feel the need to reach for a debugger in the presence of the REPL and tools like Timbre. Just wrap what you want to see in (timbre/spy ...) and you're good to go.
  - j-pb 6y ago
    Please stop moving the goalpost. "Debugging clj / cljs is hardpartly due to transducers" -> "I can step though my code with cursive" -> "how does cursive handle transducers?" -> "you don't need a debugger"
    - nightwolf 6y ago
      The person who mentioned using the Cursive debugger is different than the person who mentioned using the REPL.
      - tiagoespinha 6y ago
        It's not about the person, but the idea.

divs1210 6y ago

Yup, it's like the leadership is actively hostile towards community building. * Prismatic Schema, immensely popular, was "replaced" by spec, which is not yet complete and still in the research phase * leiningen (one of the best language tooling out there) was "replaced" by Clojure CLI that can't do half of what leiningen can * transducers (a brilliant concept) are not easy (as in close at hand) because the code is quite different to normal lazy-sequence based code (I wrote a library [1] to address this) I still prefer Clojure for all my side projects, but it is very clear that the community is tiny and fragmented. [1] https://github.com/divs1210/streamer https://github.com/divs1210/streamer

harperlee 6y ago
Schema and spec do not target the same functionality. In general I agree that it would be best if a small community does not spread itself too thin, but on the other hand, can't Hickey, Miller et al work on what they are interested in? They have published rationales for why those "splintering" works are of interest and they make sense. It seems incongruent to happily use a tool that was born out of an opinionated design, and then complain when the authors keeps pushing their opinionated PL design.