Comments on abstract-anaconda - Chapter 1

[aidy lewis]

Brian

General

* Could we not explain OO, FP and Clojure test-first using midje?

Specifics

* Liked the introduction, but would be interested in why you chose
Clojure over Scala. What is your opinion on hybrid languages?
* When you talk about some functional languages being 'lazy', you say
'eliminate bookkeeping busywork'. What do you mean by this?
* You suggest using Leiningen when installing Clojure. What has this
over a Linux package manager tool?
* Is personifying the evaluator as a bird necessary? It confuses
things. Lets just get straight to the point.
* I think the the small introduction to immutability could be a
little clearer (trees and branches)
* I get a conflict with this example (should I be using a namespace?):

def double (fn [n] (+ n n)))

java.lang.Exception: Name conflict, can't def double because
namespace: user refers to:#'clojure.core/double

Aidy

[Brian Marick]

On Jun 26, 2012, at 1:58 PM, aidy lewis wrote:
>
> * Could we not explain OO, FP and Clojure test-first using midje?

I haven't found explaining new languages with tests to work. It's an information overload: not only do you have to understand the language, you have to understand this (likely) unfamiliar process.

As the "solutions" files for the exercises grow more complex, I've really wanted to have tests for those functions. I wouldn't explain them in the body of the book, but I'd put enough in the exercise code that the interested reader could learn more.

The problem is that Clojure (really the JVM) doesn't make it convenient to just have plain old ordinary isolated files with tests and code. I *think* you need to make a whole project directory structure, and I really don't want to thrust that in the faces of readers. I will investigate whether that's really true, but not soon.

Do other people miss tests?

> Specifics
>
> * Liked the introduction, but would be interested in why you chose
> Clojure over Scala. What is your opinion on hybrid languages?

There was no interesting reasoning behind that. I know Clojure. I don't know Scala. Clojure would let me get the message across. So I started building a course with the book's title.

I suppose I could say that, given that I made a fuss in the Introduction about how people need to know languages that have very different approaches to problems, it makes sense to choose Clojure as more different from Java than Scala. I'd even guess that's true. But it was not my motivation.

> * When you talk about some functional languages being 'lazy', you say
> 'eliminate bookkeeping busywork'. What do you mean by this?

Laziness frees you from the question of "Have I produced exactly the right number of values needed by the rest of the computation?" You just behave as if you're creating them all, and let the runtime avoid making too many. I'll add a sentence or two about that, but it really requires a chapter's worth of explanation.

> * You suggest using Leiningen when installing Clojure. What has this
> over a Linux package manager tool?

As I'm using it, Leiningen offers two benefits. 1) Once you've downloaded it, it takes care of downloading anything else you need (on demand). 2) It offers a way to start a repl that doesn't smack you in the face with all kinds of Java-isms. Without it, I think I'd have to talk about Java things that (a) are not important to the topic of the book and (b) I don't understand myself, because I've sheltered under the protection of Leiningen.

> * Is personifying the evaluator as a bird necessary? It confuses
> things. Lets just get straight to the point.

Well, it's my style to be somewhat cutesy. I'll back off if other people are annoyed.

More justifiably: when the point is subtle (as are many things about functional programming), "getting straight to it" is overwhelming to some of the people I like to think of as my target audience. Functional programming is notoriously off-putting because (I believe) authors dive into precision and abstraction too fast. I've build my career, really, about not doing that.

My style is to present explanations that privilege being compelling over being entirely truthful. Then, over time, I introduce the qualifications and clarifications that I earlier hoped the reader wouldn't realize were needed. Some people hate that style. So be it.

So: the birds are intended to give something of a concrete flavor to the explanation. (Some people are visual learners.) You couldn't extend the bird metaphor to cover all of computational evaluation, but I think that's OK. (In the chapters I've written since then, I barely mention the metaphor.)

> * I think the the small introduction to immutability could be a
> little clearer (trees and branches)

I'll look at it again. I was actually hoping that I could ignore immutability in these introductory chapters, and spring a surprise later on: "Here's something you probably didn't realize: in all your work up to here, you never changed a data structure or assigned a variable." In a course - very interactive, very centered on the speaker - I can pull that off. In a book, I thought I couldn't. So I introduced it. But I'm reluctant to make a big deal out of it early on.

I'll give some thought to this. [Though it's hard to talk about a negative: "Notice that you never have to do X."]

> * I get a conflict with this example (should I be using a namespace?):
>
> def double (fn [n] (+ n n)))
>
> java.lang.Exception: Name conflict, can't def double because
> namespace: user refers to:#'clojure.core/double

Urk. I should have noticed that. I'll have to pick a different name. Someone else suggested `twice` for a different reason. There are a lot of Clojure functions that it's safest to consider reserved words. (You can work around name clashes, but I'm unconvinced it's worth the bother in most cases.)

-----
Brian Marick, Artisanal Labrador
Now working at http://path11.com
Contract programming in Ruby and Clojure
Occasional consulting on Agile