Critique of Lazy Sequences in Clojure • Hacker News Board

Re: Critique of Lazy Sequences in Clojure

#31

Post by hxegon » Mon, Aug 07, 2023, 1:47 PM UTC

invertisment wrote: post #8

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.

You won't start anything. I dare you. Haha. You can't learn Clojure and you know it.

I hope you find something better to do with your day than putting people down.

Re: Critique of Lazy Sequences in Clojure

#32

Post by actuallyalys » Mon, Aug 07, 2023, 1:55 PM UTC

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.

I’m personally a fan of Clojure, in part due to how practical it is. Some of that practicality comes at the expense of simplicity, however.

I wonder if a Scheme dialect would be a better fit for you? They tend to be smaller and might let you focus on semantics more.

Full disclosure: I haven’t spent nearly as much time with any of the Scheme/Scheme-inspired dialects as I have with Clojure. I’m basing this off of their design philosophy and others’ observations.

Re: Critique of Lazy Sequences in Clojure

#33

Post by hxegon » Mon, Aug 07, 2023, 1:57 PM UTC

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.

Clojure's lazy sequences by default are wonderful ergonomically, but it provides many ways to use strict evaluation if you want to. They aren't really a hassle either. I've been doing Clojure for the last few years and have a few grievances, but overall it's the most coherent, well thought out language I've used and I can't recommend it enough.

There is the issue of startup time with the JVM, but you can also do AOT compilation now so that really isn't a problem. Here are some other cool projects to look at if you're interested:

Malli: https://github.com/metosin/malli

Babashka: https://github.com/babashka/babashka

Clerk: https://github.com/nextjournal/clerk

Re: Critique of Lazy Sequences in Clojure

#34

Post by vbezhenar » Mon, Aug 07, 2023, 2:01 PM UTC

memefrog wrote: post #15

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.

It's not really Rust's compiler that 'optimises lazy sequences'. It's LLVM, which notices that the code emitted happens to be able to be optimised down, if you run it for a really, really long time with some very strong optimisations. GHC would be a better example, I think. It performs stream fusion. This means it can turn 'map f (map g xs)' into 'map (f . g) xs', and of course it gets more complex than that, but tha…

> GHC would be a better example, I think. It performs stream fusion. This means it can turn 'map f (map g xs)' into 'map (f . g) xs', and of course it gets more complex than that, but that's the basics. It directly optimises lists (which, this being Haskell, are lazy sequences).

Is it for built-in map or it would work in a general way for, say, `myMap f (myMap g xs)` ?

Re: Critique of Lazy Sequences in Clojure

#35

Post by geokon » Mon, Aug 07, 2023, 2:10 PM UTC

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.

This is sort of true, but it doesn't scale well. You quickly end up having a very verbose `ns` declaration at the top of every file as you try to extend your Clojure

To cut down on the noise, you can coalesce all your extensions into one `ns` but it's not technically feasible with `core` and needs to be done with another library:

https://clojureverse.org/t/how-do-you-write-library-wrappers...

Re: Critique of Lazy Sequences in Clojure

#36

Post by ndr » Mon, Aug 07, 2023, 2:16 PM UTC

> The good parts of laziness: Avoiding unnecessary work

Actually be very careful with side effects. Some functions like `map` and `for` take things in chunks, typically in steps of 32 as most underlying structures are in log-32 leaves.

```

  (let [printing-range (map (fn [i] (print "debug: " i) i) (range))
        first-10 (take 10 printing-range)]
   first-10)
  debug: 0
  debug: 1
  debug: 2
  debug: 3
  debug: 4
  debug: 5
  debug: 6
  debug: 7
  debug: 8
  debug: 9
  debug: 10
  debug: 11
  debug: 12
  debug: 13
  debug: 14
  debug: 15
  debug: 16
  debug: 17
  debug: 18
  debug: 19
  debug: 20
  debug: 21
  debug: 22
  debug: 23
  debug: 24
  debug: 25
  debug: 26
  debug: 27
  debug: 28
  debug: 29
  debug: 30
  debug: 31
  (0 1 2 3 4 5 6 7 8 9)

```

Re: Critique of Lazy Sequences in Clojure

#37

Post by munchler » Mon, Aug 07, 2023, 3:14 PM UTC

F# is similar in that it supports lazy sequences but is mostly eager otherwise, and often handles errors using exceptions. One does have to be careful, but the benefits far outweigh the risks in my experience.

Re: Critique of Lazy Sequences in Clojure

#38

Post by [deleted] » Mon, Aug 07, 2023, 3:34 PM UTC

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.

[deleted]

Re: Critique of Lazy Sequences in Clojure

#39

Post by whalesalad » Mon, Aug 07, 2023, 4:09 PM UTC

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.

I wouldn’t let this article put you off. HN is often full of really negative takes like this that bear far less significance than they might suggest.

Clojure is a fantastic language, and probably the best lisp you could start out with due to the fact that you have the entire Java ecosystem at your fingertips.

Re: Critique of Lazy Sequences in Clojure

#40

Post by waffletower » Mon, Aug 07, 2023, 4:17 PM UTC

I think the main issue with lazy sequences is understanding and controlling their scope. Transducers, particularly when utilized within an `into` scope, can encapsulate laziness very neatly. Indeed, transducers utilize lazy sequences internally, and the OP shows their clear performance advantage. I think the article would be more effective if it shifted tone to "Clojure laziness best practices" rather than damning the idea wholesale. There be dragons for sure.