interesting article with a hint of relevance
Sukant Hajra
American reviewing some prognostications from the 60's [1]. It's a pretty fast
read, and I enjoyed it.
What's prompting me to post to this list is a very interesting quote:
Unfortunately, Strachey did not use any higher-order functions to structure
the program, relying only on recursion. This is the equivalent of relying
only on GOTO statements, not loops, and it means that he ends up with
auxiliary functions whose name reflects their role in control flow (such as
PCP or PartialCapturePositionList) rather than an independent purpose (such
as MakeMove). Readers have to uncover the control flow by
reverse-engineering the recursive calls.
I think you guys were using higher-order functions. You should have been
forced to with applications of "map". But I think you guys have a whole
arsenal of other higher-order functions to lean on beyond what you guys were
doing. And in retrospect (and pulling from Norvig's comment above), I think
you'll find that doing so might untwist some of your mutual recursion
hoop-jumping.
I'll publish my Scala work as soon as I have a moment to clean it up a little
more. It's a bit unfair to compare my Scala code to your Clojure code because
I've been looking at Scala for about two years, but you all have /just/ dived
into Clojure with only hints of working with a Lisp in the past. But here's a
few helpful things to think about moving forward.
1) Dig deep into macros. They're hugely important for any Lisp. Know when
to use them and when not to. This is not something I've mastered
personally, but something that I hope to. Paul Graham, whose written great
things about Lisps has a nice free book that gets to a lot of the finer
points about Lisps called "On Lisp" [2].
2) Learn about Clojure's multimethods [3] and protocols [4]. I don't know
them that well, but they are analogs of implicits in Scala (no great link,
sorry) and type classes in Haskell [5]. These are extremely important
abstractions to know about to have highly modular code, which I think is
something important for the coding group to pursue. Occasionally people
will refer to Philip Wadler's "Expression Problem" [6] which is designed to
expose the problems simple languages have with modularity. Multimethods,
protocols, implicits, and type classes are all solutions that can be
applied towards this problem with varying degrees of success.
Finally, if you're looking for a great text to go through to learn a Lisp (and
a host of programming topics), Structure and Interpretation of Computer
Programs (SICP) is highly recommended and freely available [7].
-Sukant
[1] http://blogs.scientificamerican.com/at-scientific-american/2011/08/23/systems-analysis-look-back-1966-scientific-american-article
[2] http://www.paulgraham.com/onlisp.html
[3] http://clojure.org/multimethods
[4] http://clojure.org/protocols
[5] http://www.haskell.org/haskellwiki/OOP_vs_type_classes
[6] http://www.daimi.au.dk/~madst/tool/papers/expression.txt
[7] http://mitpress.mit.edu/sicp/full-text/book/book.html