On Tue, Jan 13, 2009 at 4:05 PM, Jason Wolfe <jawo...@berkeley.edu> wrote:
>>
>> It raises a question, though -- how much functionality should a
>> function provide to be worth making everyone who reads the code learn
>> the new vocabulary? I've written each of these inline when I've
>> needed them. Are they better as idioms or functions?
>
> I would say they're better as functions, for several reasons.
>
> First, many of these aren't really "new vocabulary", since you can
> clearly tell what they do from their name and knowledge of the
> existing core functions. If you know map and you know take-when and
> take-while, you already know what map-when and map-while do.
>
> Moreover, I think some of these actually fill in mysterious gaps in
> the language. For and map are essentially two different ways of
> saying the same thing; which to use in a given situation seems to be
> largely a matter of aesthetics (except when there are multiple
> iterates...). Yet, for supports :when and :while, whereas there are
> no map-when and map-while forms. Conversely, we get mapcat but no
> forcat.
Those are good arguments. I guess what I fear is some of the reaction
I've had to reading Common Lisp code. The difference in feeling
between CL and Clojure is important to me because I tried repeatedly
and failed to adopt CL into my toolbox, but Clojure went quite
smoothly.
One of the things I found difficult with CL was the extremely large
number of builtin functions -- a large vocabulary with subtle
differences between nearly synonymous-sounding words. It meant that
at first glance, a particular block of could would look simple -- 5
lines, how hard could it be? But in reading it I would discover I
only new 2 of the 15 functions used. So I'd fight through it, feeling
like I was learning something useful, but the next function would use
15 completely different functions.
Now perhaps I'm just whining, perhaps I needed better reference tools,
perhaps I'm mis-identifying the problem. But it is a real source of
my hesitancy to ask for more built-in functions.
> For instance, I
> find myself needing to use map-map or merge-reduce fairly frequently,
> and the (reduce (fn [m [k v]] (assoc m k (f v))) {} m) type idioms
> they replace are much more difficult to read than calls to the
> utilities IMO.
Yes, that's a mouthful. I'll need to study merge-reduce and map-map a
bit more to see when to use them instead of merge, merge-with, and
into.
--Chouser
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
