Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Critique of Lazy Sequences in Clojure

clojure-goes-fast.com

Post reply on HN
Print view View original

21–30 of 52 posts

Re: Critique of Lazy Sequences in Clojure

#21

Post by roenxi »

psd1 wrote: post #6

I've been circling around lisp for a couple of years. I'm starting in a month, I'll spend several hours a day. I still don't know what language I want to learn. I was drawn to Clojure because it looked like a lisp for getting stuff done. But a few things put me off. This article puts me off more. I want to get the semantics down before I have to think about what's going on under the hood.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses"

Clojure is fun enough that people get to know all the edge cases. And put up with the stack traces.

If you do decide to try it, don't use deps.edn, go straight to Leiningen for build tooling. Even just for playing around in the REPL.

Re: Critique of Lazy Sequences in Clojure

#22

Post by vemv »

jwr wrote: post #13

This article is somewhat puzzling for me. On one hand, the OP clearly knows Clojure very well. The disadvantages of laziness are real and well described. On the other hand, though, this sounds like a theoretical/academic article to me. I've been using Clojure for 15 years now, 8 of those developing and maintaining a large complex SaaS app. I've also used Clojure for data science, working with large datasets. The disa…

I enjoyed the article while I have a very comparable Clojure experience.

There's always new minutiae to learn. Plus I get a handy link that I can just paste next time the topic of laziness comes up in a code review.

I'd just simply point out that there are a few sub-tribes within the Clojure world. Some are very attracted to formalism/correctness, other pride themselves in rejecting them.

Re: Critique of Lazy Sequences in Clojure

#23

Post by kimi »

jwr wrote: post #14
kimi wrote: post #3

Not sure if the "transducer" approach suggested as a workaround makes your life easier or further adds to the mental overhead. See https://www.astrecipes.net/blog/2016/11/24/transducers-how-t... for some example transducers.

Using transducers is really easy and intuitive (with "comp" letting you compose a pipeline of transformations in a readable way). Writing custom transducers, especially stateful transducers is really difficult. But that's not something you'll do often. My 10kLOC complex app has three stateful transducers that I wrote. I think transducers are an under-appreciated aspect of Clojure. They are an extremely valuable and f…

Yes I agree with you that transducers are OK. I think that they miss a bit in ergonomics, not power.

Re: Critique of Lazy Sequences in Clojure

#24

Post by BaculumMeumEst »

geokon wrote: post #16

As I posted on Reddit: It might also be good to mention Injest https://github.com/johnmn3/injest Which makes transducers more ergonomic to use if you are like me and use threading macros everywhere Would be curious to hear how others feel about it

these look great to me. would there be a downside to adding them to core?

Re: Critique of Lazy Sequences in Clojure

#25

Post by dontlaugh »

lenkite wrote: post #10

The main issue is that Clojure compiler doesn't really optimize lazy sequences right ? Most language compilers do this. Rust lazy iterators for example many times exhibit faster performance than for-lops. And clojure also doesn't give an error/warning when lazy sequences aren't finalized.

Rust's lazy iterators don't cache the results, to be iterated over again. It allows the optimiser to inline all calls and end up with a loop that doesn't need bounds checks, which is why they can be faster than C-style loops over arrays.

Re: Critique of Lazy Sequences in Clojure

#26

Post by BaculumMeumEst »

psd1 wrote: post #6

I've been circling around lisp for a couple of years. I'm starting in a month, I'll spend several hours a day. I still don't know what language I want to learn. I was drawn to Clojure because it looked like a lisp for getting stuff done. But a few things put me off. This article puts me off more. I want to get the semantics down before I have to think about what's going on under the hood.

Despite its weak points, Clojure is still an excellent lisp for getting things done. For long running programs that live on the server, and especially for multithreaded/asynchronous workloads, I find it far better to work with than other lisps.

Re: Critique of Lazy Sequences in Clojure

#27

Post by unlogic »

BaculumMeumEst wrote: post #17

It’s too bad that transducers were created long after clojure’s inception. Can you always replace a lazy seq with a transducer? Could the language theoretically be redesigned to replace all default usages of lazy seqs with transducers, even if it were a major breaking change? And have lazy operations be very explicit?

It could certainly be redesigned to have explicit lazy collections/operations and use transducers as the composition glue. It would be a breaking change, so it's never going to happen in Clojure. But if somebody plans to design a language inspired by Clojure, they should certainly take this hint.

Re: Critique of Lazy Sequences in Clojure

#28

Post by unlogic »

BaculumMeumEst wrote: post #24
geokon wrote: post #16

As I posted on Reddit: It might also be good to mention Injest https://github.com/johnmn3/injest Which makes transducers more ergonomic to use if you are like me and use threading macros everywhere Would be curious to hear how others feel about it

these look great to me. would there be a downside to adding them to core?

Clojure authors are quite conservative about adding such opinionated instruments into the language, especially when they come from outside. But fortunately, being a Lisp allows Clojure to add such language modifications with libraries without forcing those modifications upon every user of the language.

Re: Critique of Lazy Sequences in Clojure

#29

Post by BaculumMeumEst »

unlogic wrote: post #28
BaculumMeumEst wrote: post #24

Earlier quoted context omitted.

these look great to me. would there be a downside to adding them to core?

Clojure authors are quite conservative about adding such opinionated instruments into the language, especially when they come from outside. But fortunately, being a Lisp allows Clojure to add such language modifications with libraries without forcing those modifications upon every user of the language.

That’s true, but:

1) they did add threading macros, which are very popular, and these seem to serve a very similar purpose for transducers. You could argue their inclusion would make the language a little more uniform even.

2) There is precedence for doing the same operation with different mechanisms, like map vs mapv, so the change fits in nicely in that sense

3) as the article points out (edit: just realized you are the author, heh, hello!), transducers often have better performance than alternatives. I think it makes sense to highlight them and encourage their usage as much as possible. The more high performance code in the wild, the better. Even just introducing new ergonomics that facilitate their usage will influence that.

Re: Critique of Lazy Sequences in Clojure

#30

Post by BaculumMeumEst »

unlogic wrote: post #27
BaculumMeumEst wrote: post #17

It’s too bad that transducers were created long after clojure’s inception. Can you always replace a lazy seq with a transducer? Could the language theoretically be redesigned to replace all default usages of lazy seqs with transducers, even if it were a major breaking change? And have lazy operations be very explicit?

It could certainly be redesigned to have explicit lazy collections/operations and use transducers as the composition glue. It would be a breaking change, so it's never going to happen in Clojure. But if somebody plans to design a language inspired by Clojure, they should certainly take this hint.

If we ever found ourselves in a position where Clojure’s market share was decreasing YoY, do you think it would ever make sense for Clojure’s maintainers to design a new language that implements this + any other issues that come up on Clojure’s yearly survey (and other lessons learned) that might be more easily addressed by sacrificing backwards compatibility? Or do you do think the community would want them to focus on maintaining Clojure themselves?

I realize the maintainers likely would not even be interested in such a thing, of course, just daydreaming.

Post reply on HN