joe.bowbeer at gmail.com
Mon Feb 18 15:54:14 PST 2013
I'm not seeing a good reason not to keep the 3-arg form.
I like it for pedagogical reasons. The string-compare is not really a
practical example, after all, so I'm not bothered that it uses boxed(). I
think there are potential practical uses for the 3-arg form, and its
inclusion gives us something to point at when asked by viewers of Guy's
talks or users of Clojure.
This is not a classic case of YAGNI. The "are going to" case has already
The argument that, well, it doesn't work so nicely in Java, will need some
more explaining before I buy it.
On Mon, Feb 18, 2013 at 3:46 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> See earlier posting on "reducing reduce." Two reasons:
> - People find it confusing -- they want to know why they have to specify
> two functions that "do the same thing." (Because they are thinking
> sequentially.) And that confusion then infects all the reduce forms.
> - The cases where it has an advantage over either map+reduce or collect
> seem to be somewhat limited. And, due to lots of accidental complexity
> reasons, often involve a fair amount of object creation overhead, which
> starts to eat into the potential performance advantage.
> So through the combination of "few people will use it, but it confuses
> everyone", it seems a reasonable candidate for pruning.
> On 2/18/2013 6:34 PM, Joe Bowbeer wrote:
>> Maybe I'm confused.
>> Why are you now trying to eliminate it?
>> On Mon, Feb 18, 2013 at 3:20 PM, Brian Goetz <brian.goetz at oracle.com
>> <mailto:brian.goetz at oracle.com**>> wrote:
>> 2. Why don't we have a parallel fold (map+combine) like Rich
>> added to Clojure?
>> I'm confused -- the 3-arg reduce was directly inspired by Rich's
>> Reducers work?
More information about the lambda-libs-spec-observers