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

31–40 of 46 posts

Re: Learning Clojure: comparing with Java streams

#31

Post by roenxi »

Not a lot of comments here for the number of upvotes, but the trend of the comments strikes me as lopsidedly negative and I'd like to throw in something positive to the mix - Clojure needs more people publishing beginner friendly code even if it isn't using some specific function that does the same thing with less typing. So, y'know, I'm really glad we've got people out there who are documenting how they manage to get things to work under the new and generally unfamiliar paradigm of "practically functional". Especially since Clojure's Achilles heel is the combined double-whammy of its incoherent error messages and the learning curve for a beginner trying to pick up how to do common tasks in a world with 'no variables'.

We have a programmer with >15 years experience, who is learning a new language and in the process producing code that is neat, functional (in the sense of no bugs) and not unreasonably verbose. Clojure is a language that is dense with clever ideas, it takes a lot longer than a few months to get good at using them if they are new. The terse comments throwing out improvements or making corrections seem a little harsh, I'd hoped to see people talking more about concepts than naming functions.

Re: Learning Clojure: comparing with Java streams

#32

Post by TeMPOraL »

Sharlin wrote: post #22
jetrink wrote: post #13

Earlier quoted context omitted.

> 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.

That's sort of implied by the name. A non-recursive flatten wouldn't really flatten much, and would be called join, or concatenate.

Re: Learning Clojure: comparing with Java streams

#33

Post by TeMPOraL »

keymone wrote: post #30
nfrankel wrote: post #9

Earlier quoted context omitted.

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.

When talking about Lisp syntax, what you almost always want to say is "lisp has $most-positive-word-in-context syntax". So it's "limited" for some, "simple" for others, but the overall point is the same - no cruft and unnecessary sugar, and uniformity allows for easy programmatic transformations of code.

Re: Learning Clojure: comparing with Java streams

#34

Post by vlaaad »

roenxi wrote: post #31

Not a lot of comments here for the number of upvotes, but the trend of the comments strikes me as lopsidedly negative and I'd like to throw in something positive to the mix - Clojure needs more people publishing beginner friendly code even if it isn't using some specific function that does the same thing with less typing. So, y'know, I'm really glad we've got people out there who are documenting how they manage to ge…

Didn't mean to sound harsh, it's just I already replied to author with words of encouragement in the reddit thread (https://www.reddit.com/r/Clojure/comments/9u4p5m/learning_cl...) and didn't want to repeat all that comment here, so I decided instead to show briefly to other readers what can be improved.

Re: Learning Clojure: comparing with Java streams

#35

Post by Sharlin »

TeMPOraL wrote: post #32
Sharlin wrote: post #22

Earlier quoted context omitted.

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

That's sort of implied by the name. A non-recursive flatten wouldn't really flatten much, and would be called join, or concatenate.

The flatten functions I know from statically typed languages (eg. Rust, Scala) only flatten one level. So flatMap is actually more or less equivalent to (flatten . map).

Re: Learning Clojure: comparing with Java streams

#36

Post by TeMPOraL »

Sharlin wrote: post #35
TeMPOraL wrote: post #32

Earlier quoted context omitted.

That's sort of implied by the name. A non-recursive flatten wouldn't really flatten much, and would be called join, or concatenate.

The flatten functions I know from statically typed languages (eg. Rust, Scala) only flatten one level. So flatMap is actually more or less equivalent to (flatten . map).

Interesting. My experience is the opposite - in dynamically typed languages like Erlang, Clojure or Common Lisp, flatten is understood to flatten lists, and flatmap is something else entirely - from what I gather, it's Scala that made the weird choice of naming a concatenation function `flatten`, thus creating `flatMap`[0], and then people started borrowing the name.

From this I provisionally conclude that "flatten" being non-recursive is an artifact of Scala confusing things; not an unusual thing in my experience with this language, but this time it seems to have gotten out of hand, instead of being contained within Scala ecosystem.

--

[0] - Even Haskell calls this `concatMap`, see [1].

[1] - https://stackoverflow.com/questions/49843262/where-does-the-...

Re: Learning Clojure: comparing with Java streams

#38

Post by phyrex »

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…

Yes, map returns a lazy sequence. Lazy sequences get realized in batches of 32, so calling `first` would realize the 32 first values and then return the first one of that.

Re: Learning Clojure: comparing with Java streams

#39

Post by didibus »

lispm wrote: post #28
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.

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

I think most schemes also don't have reader macros. How often do you actually use them in CL?

I feel reader macros have the problem that it modifies/extend the foundational syntax. And that can become overloaded really quickly. Normal macros can change evaluation semantics, but not the fundamental syntax. Which makes it easier to navigate and understand in general. Also, reader macros are pretty hard to write in comparison.

Racket has a nice take on them though. Making them more like all new programming grammars, and defining your dialect per file. Even there though, most alternate syntax is for research or fun mostly.

Re: Learning Clojure: comparing with Java streams

#40

Post by lispm »

didibus wrote: post #39
lispm wrote: post #28

Earlier quoted context omitted.

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

I think most schemes also don't have reader macros. How often do you actually use them in CL? I feel reader macros have the problem that it modifies/extend the foundational syntax. And that can become overloaded really quickly. Normal macros can change evaluation semantics, but not the fundamental syntax. Which makes it easier to navigate and understand in general. Also, reader macros are pretty hard to write in comp…

> I think most schemes also don't have reader macros.

Scheme even has a fixed syntax in the RnRS reports. Lisp does not have that.

> Also, reader macros are pretty hard to write in comparison.

Not really. One just reads things from a stream and returns an s-expression.

> I feel reader macros have the problem that it modifies/extend the foundational syntax

That's a feature.

The main purpose of user-written reader macros is to extend S-expressions to support literal syntax of new user-defined data types.

There is nothing scary about it at all.

> Racket has a nice take on them though. Making them more like all new programming grammars, and defining your dialect per file

My Lisp Machine had that already in the 80s. It supported different language syntax - from various Lisp variants to Pascal, C and other languages.

> Even there though, most alternate syntax is for research or fun mostly.

On my Lisp Machine it was actually useful.

Post reply on HN