Style and substance

David Pollak's efforts to develop a web framework that doesn't suck has clearly established him as one of the elite few laying claim to both substance and style. So, i've been looking forward to his book, Beginning Scala, and i was grateful to get a chance to look at the early drafts. In some sense i'm the worst person to review a book like this because -- despite the fact that i'm a perpetual beginner -- i'm a total curmudgeon. This is likely to show through in my comments on his book.

So... let me begin by saying that i think it pretty much nails communication with his target audience: Joe, the programmer. Joe is more likely than not going to need an easy going style and clear, reasonably concise examples and a pretty much standard set of how to's. David's got that down. So, if you're Joe, and you know who you are, get Beginning Scala -- cause Scala's the new Java and it's really only a matter of time before you're going to need to know how to program in it. Ok, that's out of the way. Now, let's move on.

Unfortunately, i'm not Joe the programmer. i'm looking for something that's a little bit more. Whatever that is. Ok, i've got one or two clues about what that is, for me. First off, having a single end-to-end application that provides context, relevance and sufficient complexity is, in my book, the way to go about this kind of communication. By construction, it demonstrates to a practitioner in the field why they care; but it does something more than that. When the application complexity is just right then it demonstrates that you can decompose hard problems in to simpler ones. That's the beauty of Scala because that's the beauty of a compositional approach like functional programming, and Scala is a functional language.

If you've chosen your application and your decomposition well, then you can also introduce concepts in a logical order -- even if you have to revisit various implementation choices along the way. Guess what, most application programmers are constantly in the business of learning new technology or design and development idioms on the job. It's part of what we do. So, going back and reimplementing various bits and pieces of a largish application is actually pretty common place -- especially if there is a pay-off like improved performance or new feature sets enabled by better refactoring. The real pay-off in the communication event, however, is when you put it all back together after you've decomposed it. That's where you can see that the approach really does bring some order to the chaos.

Now, hmmm... what would be an application of sufficient complexity that would be relevant to today's programmer? Oh wait! i know, how about a web framework? Seriously, this was how Mr Pollak taught himself Scala in particular and the functional and actor idioms, more generally, by rubbing them up against the very real world problem of programming the web. David knows this domain like the back of his hand. It would have been the perfect vehicle to walk through some of the design rationale in Lift -- from the perspective of someone who bootstrapped his own understanding of Scala from total beginner to pragmatic expert who's opinion is widely sought after.

So, let me give some practical examples. Beginning Scala has the obligatory discussion of parser combinators. Plez. i can haz monadz? Nothing is as maintainable as an EBNF grammar. Look at Haskell, the incubator of parser combinators. Do you write Happy grammars or Alex lexers using parser combinators? No! You write normal grammars and Happy and Alex do their backend with parser combinators. There's a reason for this. EBNF grammars are considerably more compact and readable. And, it makes sense to do the backend with parser combinators for all the reasons that application structuring using monads is good. Further, there are high level tools (like BNF converter) that lift this game considerably. (See my previous blog posts about this wonderful tool.) The reason to talk about parser combinators in the raw, so to speak, is to justify monads and introduce some of the beautiful design patterns available via that abstraction -- in the context of a relevant problem like parsing (cf my curmudgeonly outlook expressed above).

Another example: actors. i would really love to see a discussion by Mr Pollak on his opinion of the issues around state, statelessness, the web and functional versus actor idioms in the relevant context of web applications. This is pretty much the burning issue on most programmer's minds these days, even if their name is Joe or Jo. Oh, and just because her name is Jo, doesn't mean she's not blindingly smart. She's just very focused on getting her customer's app working on time and under budget. So, don't sell her short. She knows what's what, too. In my humble opinion, she'd like to see that issue addressed even -- no especially -- in the context of learning Scala. In other words, both Joe and Jo have also got a substantial take on style, and really don't need publishers profiling them and forcing authors to write books where everybody is wanting a little bit more.

But wait, maybe this is a marketing ploy. Cause i know David knows i'm going to buy his book on Scala to get his take on the ins and outs of the language and he knows i'm going to buy a book he writes on Lift -- if he ever gets around to writing it, and even if there are a dozen books about Lift by the time he publishes. Doh! Now i get it. Very clever.