small medium large xlarge

20 Mar 2013, 22:16
Michael Bevilacqua-Linn (13 posts)

Hey Folks,

Just curious if anyone whose started in on the book has any thoughts or feedback, good, bad or otherwise. There’ll be a few more betas, focused on getting the rest of the content in there and addressing problems with the book.

So if you’ve got comments, let em rip!

Thanks, MBL

27 Mar 2013, 21:38
Tim Carter (1 post)

Hi Michael. I’m enjoying the book. In Chap 2, I’ve just worked through the Java and Clojure implementations. I found the Java example complete and easy to follow. On the Clojure side, I would have liked to see an example GreetingController implementation and then seen how to add that to the request-handlers map: so that the end Clojure app would more closely mirror the Java app, if you see what I mean. Best wishes, Tim

28 Mar 2013, 13:01
Michael Bevilacqua-Linn (13 posts)

Hey Tim,

Yep I see exactly what you mean, thanks! I’ll fix that up, the next beta is already on it’s way, but it should be in the beta after that.


07 Apr 2013, 19:25
Kevin Scaldeferri (1 post)

I have two questions:

1) What’s the best way to report typos in the text?

2) In section 2.3, I have found a few examples of what I would consider non-idiomatic Scala, bordering on errors in some cases. Is the code by any chance available on github or something similar where I could fork and submit a pull-request? Or is there another way you’d prefer to receive suggestions for code changes?

08 Apr 2013, 22:19
Michael Bevilacqua-Linn (13 posts)


Thanks very much, that would be very useful.

The best way to report technical errors is through the errata report page - It’s pretty fancy, you can plug in the technical errors/non idiomatic usages there, and then I check them off as I fix them.

Typos can go in there as well, though, since it hasn’t been copyedited yet there are probably a bunch. Feel free to report them as well, but it may not really be worth your time.

But please do enter the tech errors if you get a chance, I’m aiming to clear out that errata list in the next beta, which should be out in a few weeks.

Thanks, Mike

06 May 2013, 00:38
G. Ralph Kuntz, MD (2 posts)

You might consider making the instance variables on pages 13 and 14 final, since they are only set in the constructors.

06 May 2013, 00:44
G. Ralph Kuntz, MD (2 posts)

On page 18, namesCommaSeperated should be spelled namesCommaSeparated.

15 Nov 2013, 18:30
Cognitive Match (1 post)

Not sure if you’re still taking on comments now that the book is out. I just started it yesterday and this jumped out a bit - in the scala version of TinyWeb in handleRequest() you have this block to define the composed filters:

val composedFilter = filters.reverse.reduceLeft((composed, next) => composed compose next)
val filteredRequest = composedFilter(httpRequest)

That’s a pretty non-trivial piece of code for someone new to scala (I had to open an editor to work out what it was doing) and I think it needs at least a small note to say something like “we’ll look at function composition later”.

Also, since filters is immutable shouldn’t composedFilter be an instance variable rather than re-computed on every request?

(Other than that I’m really enjoying the book. I think it’s a very good idea to concentrate on OO vs FP patterns and so far it seems much more real-world practical than a lot the FP material I’ve read which can be very academic)


19 Feb 2014, 15:33
Ivano Pagano (2 posts)

Hi there

In Pattern 1 - Replacing Functional Interface, I read

In functional languages, functions are higher order: they can be returned from functions and used as arguments to others.

But this is not correct: higher-order functions are those that takes functions as parameters or as return value.

The definition is pretty inconsequential in the book but I think it’s suggesting an incorrect language for those unfamiliar with functional programming.


19 Feb 2014, 15:49
Ivano Pagano (2 posts)

Also in Pattern 5 - Replacing Iterator when using the sequence comprehension in scala to find people by zip code, you suggest using an auxiliary function

def isCloseZip(zipCode: Int) = zipCode == 19123 || zipCode == 19103

while in the clojure example a set is used.

Wouldn’t it be more consistent if the scala example too would use a Set as a function?

val isCloseZip = Set(19123, 19103)
01 Mar 2014, 13:47
Michael Bevilacqua-Linn (13 posts)

Hey thanks Ivano,

Good point on the definition, it should read functions can be used as higher order functions, or something to that effect. Anyhow, something that doesn’t imply every function is automatically a higher order function. Small but important distinction, if there’s another printing I’ll fix it :-)

Ack, good catch on that inconsistency… A lot of the code examples evolved, as I was writing, and there are a few places where I introduces inconsistencies like that.

01 Mar 2014, 13:48
Michael Bevilacqua-Linn (13 posts)

Thanks Cognitive Match!

Good points! If there’s another printing of the book, I’ll have the chance to tweak it :-). We shall see.

Thanks! MBL

18 Jul 2014, 20:38
Thomas Peklak (3 posts)

In the oo/strategy/people_example.clj you make a kind of awkward first-name-valid? function in my opinion. I am really no Clojure expert but I think it should suffice to write:

(defn first-name-valid? [person]
    (:first-name person))

because nil and false are treated as falsy values and all real names should be treated as true. Please feel free to correct me on that point.

You must be logged in to comment