I agree with Chouser that an uncluttered library is a great virtue. I
too have been turned off by CL in part because of the enormous number
of subtly distinct built-in functions. I'm partial to Scheme, though,
so maybe I'm best viewed as a fanatic on this point. :-)
That said, it does seem pleasantly Clojure-ish to have functions named
x-when, like "map-when". This is pretty self-explanatory, so I'd be
happy having these sorts of functions, especially when they do replace
complex chaining of other functions.
But I'm not afraid of using reduce, map, and apply to prepare values
to use as arguments to built-ins. And I'm not afraid to encapsulate
this into my own functions when I need to. I'm OK with building up a
bit of a language for whatever problem I'm tackling. (There's the
schemaniac in me again.) There's a golden mean between complexity and
clarity. At first glance, Jason's suggestions seem close to that mean
to me, and I really like what he's done.
Thanks for the good work, Jason!
Michael
On Jan 13, 5:42 pm, Chouser <chou...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
