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

Learning Clojure: comparing with Java streams

blog.frankel.ch

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Learning Clojure: comparing with Java streams

#21

Post by Sharlin »

cgrand-net wrote: post #14
Sharlin wrote: post #7

The equivalent of `flatMap` is not `flatten`. Semantically `flatMap` is equivalent to `(comp flatten map)` – hence the name! – but Clojure does offer it as a single function named `mapcat` (”map and catenate”).

Flatten is a steam-roller and should be used wisely: it recursively flatten a sequential collection. Most of the time this is not what you want. Most of the rest of the time when you think that’s what you want it’s a code smell telling you that the shape of your items has gone out of control. And there’s the rare occurrence where you can really use it.

Oops, indeed. Didn’t realize that Clojure flatten is recursive.

Re: Learning Clojure: comparing with Java streams

#22

Post by Sharlin »

jetrink wrote: post #13
Sharlin wrote: post #7

The equivalent of `flatMap` is not `flatten`. Semantically `flatMap` is equivalent to `(comp flatten map)` – hence the name! – but Clojure does offer it as a single function named `mapcat` (”map and catenate”).

> Semantically `flatMap` is equivalent to `(comp flatten map)` With the caveat that `flatten` is recursive and can handle a mix of collections and non-collections, while `mapcat` is non-recursive and every value returned by the mapcatted function must be a collection or nil. (Identity returns its argument.) (flatten [1 [2 3] [[4 5 6]]]) > [1 2 3 4 5 6] (mapcat identity [1 [2 3] [[4 5 6]]]) > IllegalArgumentException…

Thanks, I wasn’t aware that flatten is recursive.

Re: Learning Clojure: comparing with Java streams

#24

Post by didibus »

grzm wrote: post #16
didibus wrote: post #15

Earlier quoted context omitted.

Actually, Clojure does not have reader macros, because it was thought to be the biggest cause of the lisp curse.

Nit: Clojure does not have user-defined reader macros. There are quite a few built-in reader macros, including #? added for reader conditionals.

Fair enough, though definitly a nitpick :p

Re: Learning Clojure: comparing with Java streams

#25

Post by zmmmmm »

Out of curiosity, can anybody comment whether the Clojure versions of these are "lazy" in the sense that if you only take the first element from the result, does the the stream process all the results or just the first? eg:

    (first (map #(extract-name %) justice-league))
Does it map all the elements or only the first? This is actually the key aspect of streams, and more important in many ways than whatever syntax sugar is available to invoke the operations.

Re: Learning Clojure: comparing with Java streams

#26

Post by jimbokun »

zmmmmm wrote: post #25

Out of curiosity, can anybody comment whether the Clojure versions of these are "lazy" in the sense that if you only take the first element from the result, does the the stream process all the results or just the first? eg: (first (map #(extract-name %) justice-league)) Does it map all the elements or only the first? This is actually the key aspect of streams, and more important in many ways than whatever syntax suga…

In Clojure, all of these are lazy by default.

Re: Learning Clojure: comparing with Java streams

#27

Post by serpix »

virmundi wrote: post #12
outworlder wrote: post #11

Earlier quoted context omitted.

Doesn't Clojure have reader macros? The whole point of lisps is that you can extend them.

When I worked with Clojure the community seemed to treat macros as a nuclear option. Only use them when absolutely necessary. For some, this translated to “you can’t hug your children with nuclear arms”. If the community hasn’t changed, perhaps macros out of favor.

This still stands, macros are a really high level abstraction and do not compose. Almost always a function is enough. But if it saves a good chunk of repetition on something complex then go for it.

A good example of code with macro overkill is compojure-api. There is just so many clever macros that you need to read the original source code with a microscope to know what the code expands to.

Re: Learning Clojure: comparing with Java streams

#28

Post by lispm »

didibus wrote: post #15
outworlder wrote: post #11

Earlier quoted context omitted.

Doesn't Clojure have reader macros? The whole point of lisps is that you can extend them.

Actually, Clojure does not have reader macros, because it was thought to be the biggest cause of the lisp curse.

Then I'm surprised that it allows the user to define functions and macros.

Re: Learning Clojure: comparing with Java streams

#29

Post by keymone »

ppppppaul wrote: post #8
outworlder wrote: post #4

> and Clojure’s syntax is pretty limited Erm, what? I am confused by the use of the word 'limited' in this context.

lisps can be thought of languages that avoid syntax. the code you write is more like a high level AST.

Yeah, and since you can represent using an AST any syntactic construct in other languages, it makes lisp the opposite of limited in terms of syntax.

Re: Learning Clojure: comparing with Java streams

#30

Post by keymone »

nfrankel wrote: post #9
outworlder wrote: post #4

> and Clojure’s syntax is pretty limited Erm, what? I am confused by the use of the word 'limited' in this context.

I confirm: the syntax is limited. There are only a few keywords and langage constructs. The power is in the number of functions made available, or the ones you create for yourself.

Maybe it’s a problem with translation? “Limited” comes with negative connotation, as in “you can’t do as much as the other, non-limited guy”. Maybe you wanted to say “minimal” instead? s-expression based syntax is as powerful as it gets, as it allows to concisely represent any AST.
Post reply on HN