Kyle R. Burton on 24 Aug 2007 17:27:44 -0000

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[philly-lambda] Re: Do you keep wishing for the patterns from other languages?

  • From: "Kyle R. Burton" <>
  • To:
  • Subject: [philly-lambda] Re: Do you keep wishing for the patterns from other languages?
  • Date: Fri, 24 Aug 2007 13:27:14 -0400
  • Authentication-results:; spf=pass ( domain of designates as permitted sender); dkim=pass (test mode)
  • Dkim-signature: a=rsa-sha1; c=relaxed/relaxed;; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IAidcUeQgzCyPfrQSVYo8REv2CdOAvCf2j0TPDYpYRLF/c8JC/mFPGg5r6QTiHITMvVe99lDtmRBnohM8PT8KGIDKoD4M4mFJBSBEOML4ALya/L2XdMnipRgSY2u4x5DvaawAqhFhRndFSIqrRNaLiNDqKZjjneDByvXrPsPd4Q=
  • Mailing-list: list; contact
  • Reply-to:
  • Sender:

> That's an interesting statement (to paraphrase): "I like to give names
> to the patterns I use." It gets me wondering about the position some
> take (including me much of the time) that patterns are a way for
> covering up for a language's deficiencies. I don't walk into a house a
> see a sign that says "foyer" in the space with a coat rack and a
> staircase. Just thinking out loud... More food for thought:
> for(elem = list; elem != NULL; elem = elem->next) {
>   /* do something */
> }

> Should a clueful C programmer look at that and see an idiomatic C list
> iterator, or should she see an missing feature in the language?

I do :)  With no name, I have to look more closely at the structure
and what's going on - also it forces the developer to type more,
raising the risk of typos and other bugs :)

In scheme (JScheme) there is an iterate form, which uses
define-method, to allow iteration over lots of stuff (cons based
lists, javas List, Map [over the entries], vectors, etc):

  (iterate (lambda (elt) do-something) iterable-thing ...)

In C, using HOFs or extending the language are uncommon development
practices (there is always the whole embedded sql approach though).

> D'oh! I think my brain skipped over that, because it couldn't make
> sense of the non-standard Scheme.

Which is another problem altogether - when creating new syntactic
constructs is a normal part of the development process in those
languages, it makes it really difficult to know what you're looking at
without knowing all the context that has built up to the
statement/code you're reading.  This is one thing that really scares
non-lispers.  It goes back to the premise that there should be
referential integrity to the code and that what you're reading should
depend as little as possible on what has been done above/before/in
other modules.

> > > (aif (assoc people 'kyle) (cdr it) #f)
> >
> > > But then I realized the COND lets me do assentially the same thing:
> >
> > > (cond ((assoc people 'kyle) =>
> > >         (lambda (it) (cdr it)))
> > >       (else
> > >         #f))
> >
> > I think I get the spirit of what you meant by that cond, but I don't
> > see it as equivalent to the earlier aif :)
> I'm not sure what you mean; is there some error in my translation? In
> the event that there isn't, here's what the first clause of that COND
> means: If the test evaluates to something that isn't false, call the
> lambda with that value.

I don't see how the lambda gets called?  Is that what the '=>' does?
The way I read that is that the first clause in the cond returns a
function, while the second clause returns false.  The function, if
given a cons cell will return the cdr...I am used to seeing code like:

(define (test-assoc people)
  (cond ((assoc 'kyle people)
         (cdr (assoc 'kyle people)))

(write "first test ")
(write (test-assoc '((kyle . value))))

(write "first test ")
(write (test-assoc '((john . value))))


> I don't mean this in a dismissive way, but reading the above
> paragraph, I feel like we're from different planets. I hear the
> language of Java and Eclipse and Ruby and Agile and refactoring and
> unit tests and Martin Fowler, and I instinctively resist it. It's not
> that the ideas are *wrong*, they just seem unworthy of the religious
> zeal that often accompanies them.

Well, the verboseness of some of those languages makes automated
refactoring tools _necessary_.  Yegge's blog post about that was on
the mark:

Thanks for the discussion!


You received this message because you are subscribed to the Google Groups "Philly Lambda" group.
To unsubscribe from this group, send email to
For more options, visit this group at