Review: Coursera's "Functional Programming Principles in Scala" by Martin Odersky

I just completed this class as part of my introduction to Scala. For those of you that aren't familiar with Coursera, it is one of a growing number of organizations that provide free online education, taught by professors from well-known universities. These organizations are part of a revolution in education, one that might just change the way we think about post-secondary education. At present, they provide an excellent way to sharpen one's skills.

This was my first Coursera class, and I was impressed by its basic mechanics: the class website, lectures, and assignments. I'm not certain how much of this is attributable to the Coursera team, and how much to Martin Odersky's grad students. I expect the automated grading tools to be the latter, but the general website to be shared between classes. Unfortunately, it appears that you can't look at a class' content without signing up, so I'll have to wait for my next class to make a comparison.

If you're thinking of taking an online class, I caution you not to underestimate the time commitment. This class was advertised as 5-7 hours a week, which doesn't seem like much until you try to fit it into your schedule. I gave over a couple evenings a week for lectures, along with several hours for assignments (usually before work, but occasionally on weekends). Since I got my undergraduate degree in a part-time program, taking two classes a semester in addition a full-time job as a software developer, I didn't think I'd have trouble with the workload. I don't think my lifestyle has changed much in the intervening dozen years, but it was tough to fit this class in.

On to the class. It was seven weeks long, with a couple of hours of lectures each week and a total of six programming assignments (some spanning more than a week). Lectures were broken into segments of 10-30 minutes, focusing on a single topic. However, they weren't simply videos: each lecture had one or more “quizzes” embedded within it, requiring viewer interaction and occasional typing. As a result, you'll need access to the Internet; they aren't something that you can complete on a plane.*

Assignments are packaged as ZIP files containing skeleton source code and an Eclipse project configuration. They can also be built using the sbt build tool, and you need to use this tool to submit them. The source code provides stub methods for the expected implementation and a few minimal unit tests; you are expected to add more tests while completing the assignment. When you submit an assignment, an automated grading tool runs a battery of unit tests and a style check (don't use short-circuit returns!). If you fail any of the unit tests, you'll see the test output but not the test itself; sometimes it's a challenge to figure out what the grader is trying to test.

If you've watched the MIT 6.001 lectures by Abelson and Sussman (aka the SICP lectures), you'll find the Odersky lectures very similar, at least at the beginning (to the point of using many of the same examples). Another point of similarity is that the lectures do not focus on the language itself. For Scheme, that's not so bad: the language is simple. For Scala, you'll want to have an introductory book by your side (for example, Odersky's own Programming in Scala). You'll also want to keep the Scala Standard Library documentation open.

My chief complaint with the course is that it occasionally focused on functional programming to the detriment of good programming, particularly in the assignments. For example, the assignment on Huffman coding used classes as mere data containers, moving all of the logic into standalone functions. Within the context of the assignment — pattern matching — this approach makes sense. However, in the real world I would want to see this implemented with runtime polymorphism: pattern matching in this example is just a glorified switch.**

That said, I highly recommend this class. If you haven't worked with a functional language in the past, you'll find the ideas new and (hopefully) interesting. Even if you have used a functional language, you might find something new: for me, the assignment on “functional sets” (implementing the Set abstraction in pure code) was particularly interesting. And if you're using Scala professionally, I think it's worthwhile to see how the creator of the language approaches problems.

I'll finish with an unexpected insight: Java's generics implementation — and in particular, that parameterized collections don't behave like arrays — was 100% intentional. I'm not sure if you'll be able to watch this lecture, but if you do, you'll see (about 7 minutes in) Odersky explain how Java arrays are bad because they don't allow the compiler to catch certain type errors (the same material is also covered in Programming in Scala). After seeing this, I dug up the JSR-14 spec, and saw that yes, Odersky was one of the people responsible.

---

* Actually, it may be possible to watch on a plane; a quick session with Firebug indicates that the videos are straightforward HTML5. I haven't looked at the code behind them, so it's possible that the quizzes are implemented in JavaScript.

** My concern is that the assignments distribute logic rather than encapsulate it. A more egregious example, but one less open to explication, is in a later assignment: defining a simple type alias to represent a list of pairs. What the simple alias does not convey, however, is that the list must remain sorted. An object-oriented approach would maintain this invariant in the class; consumers would never see/create an unsorted list. The functional approach, by comparison, requires every function that transforms the list to maintain the invariant.

Book Review: Coders at Work / Founders at Work

I just finished reading Coders at Work. I received it as an early Christmas present, and while I've read several other books in the interim, getting to the end was a struggle. This is in sharp contrast to its companion volume, Founders at Work, which I bought last summer and read over the course of a week.

Both books consist of interviews with more-or-less well-known people. In Founders, these range from Steve Wozniak, talking about early days at Apple, to James Hong, who found himself dealing with the viral growth of Hot or Not. In Coders, the interviews range from Simon Peyton Jones (the creator of Haskell) to Donald Knuth (who should need to introduction). All of whom have fascinating histories.

So why did I like one book and not the other? At first I thought it was because I was more familiar with the programmers' stories, particularly those who entered the field at the same time I did. In comparison, the founders' stories were new to me: the challenges of dealing with a viral website, the hunt to find funding. Those stories seemed particularly relevant to me at the time, given that I had just left my full-time job with the thought of founding a software business.

But as I plowed through Coders, I realized that the difference was in the interviewers, not the interviewed. Jessica Livingston, the author of Founders, seemed to let her interviewees go wherever they wished: Woz, for example, took three pages to describe how he got the Apple floppy drive to work. Peter Seibel, by comparison, seemed to have a set list of questions, and forced each interviewee to respond to those questions. At one point I thought of turning “literate programming” into a drinking game, but realized I would be too drunk to ever finish the book.

This approach not only made the interviews unfocused, it made them long. If you put the two books side by side, they appear to be the same size. That's misleading: Founders is 466 pages, while Coders is 617. More important, the former has 33 interviews, the latter only 15. It's easy to read 15 pages in a sitting, but you have to plan for 40+ — or put the book down halfway through and try to regain context when you pick it up.

Bottom line: if you want to learn about the history of our industry, both books are a good choice. If you want to enjoy the process of learning, stick with Founders.

Book Review: Essential JavaFx

I recently received a copy of Essential JavaFx as book give-away at my local Java Users Group meeting. The JUG receives such books directly from publishers, with the expectation that JUG members will write reviews. My review of this book follows; I suspect that Dave won't be sending it back to the publisher.

---

My bookshelf holds a dog-eared copy of The UNIX C Shell Field Guide, written by Gail and Paul Anderson in 1986. To me, it represents the perfect mix of tutorial and reference, presenting an enormous amount of technical detail in a careful progression. Unfortunately, I can't say the same for their book Essential JavaFx: the material is disjointed, skimming the surface of many topics in seemingly random order, without truly examining any of them.

This book begins, as nearly all programming books do, with a simple “Hello, World” example. This part is, in fact, a little too simplistic: it walks the reader through specific screens and buttons of the NetBeans IDE. The actual program appears only as a screen-shot, without explanation of its structure. For a book that is targeted to an audience with “some previous programming experience,” this is disappointing: I want to see the program, not the IDE.

Chapter 2 attempts to remedy that initial surface treatment, by presenting a relatively complex example application. And it starts well, with a description of the way that a JavaFx application is built around a “scene graph,” and the admonishment to “think like a designer [...] visualize the structure of your application.” But then, it dives into variable definitions and control constructs, without so much as mentioning how they fit into the scene graph. And from there, the same chapter touches on accessing Java classes, visual effects, lazy expression evaluation (not identified as such), and animations &mash; a few paragraphs or pages for each, without explanation as to how they might fit together in an application.

Chapter 3 is a whirlwind treatment of the core JavaFx language. And there is a lot to this language: it is far closer to Scala than to Java, with influences from Python. Indeed, I could envision an entire book exploring the effective use of these core language features, perhaps even ignoring the GUI.

The subsequent chapters are much the same: quick hits without real content. Chapter 6, “Anatomy of a JavaFx Application,” is the closest that we get to a step-by-step tutorial, yet even here the Andersons forget their early advice: rather than starting with the application structure, they immediately create component subclasses, and only later assemble them into a scene graph.

In the end, I put the book down and turned to my IDE and “experiential learning.”

---

So, not so great a review of the book. But the language looks fascinating, and I plan to spend time working with it over the next few weeks. My first impression is that it might in fact be “the next big language” for the JVM: it seems to be a nice combination of strong typing, declarative configuration, and functional/object execution. I'm wondering if, like Java before it, JavaFx might be introduced to the world as a GUI language, yet end up as a language for server-centric applications.

Book Review: Dreaming in Code

Dreaming in Code has been out for a few years now, and it's received glowing reviews, some of which are linked from its website. This is not one of those reviews: I ended up returning the book to the library after getting barely halfway through. I found it boring, so much so that I preferred reading about the history of paint.

DiC is often compared to Tracy Kidder's Soul of a New Machine. The latter book came out while I was in high school, and I consider it one of the influences that led me into the computer industry. Superficially, the two books are very similar: they're both histories of a high-tech project, written for a non-technical audience. Both chronicle the successes and failures of the project, both profile the people involved. And yet, SoaNM just does it better. Before writing this post, I opened my copy to a random page for insight … and read to the end of the chapter. Nearly thirty years after it was written, and with the knowledge that I've gained in that time, it still held my interest. Why? And why didn't DiC?

The answer, I think, starts in the prologue. Rosenberg writes of his own experiences programming. Kidder takes us onto a sailboat, running before a storm, and introduces us to Tom West. Every book needs a protagonist, and Tom is ours: we learn of his character, and the events of the prologue are a foreshadowing of the rest of the book. Turn to any page, and Tom West is nearby. Rosenberg, by comparison, lacks a protagonist: Mitch Kapor is a visionary on the fringes, and there are a succession of project managers and programmers who never really step up to the role. Perhaps that's why the project failed, but it doesn't make for good reading.

Not only does DiC not have a protagonist, it doesn't have a crisis. The team in SoaNM is working against a deadline, against internal competition, and against their own limitations. A conventional plotline, but it works, and it moves the book forward. By comparison, the team in DiC drifts around, throws out ideas to see if they stick, and then drifts away. I'm sure there was pain and angst in the Chandler offices, but that never makes its way to the page.

Or perhaps it does, but is diluted by the mass of explanatory material that Rosenberg injects into the book. And here we come back to a difference obvious from the prologues: Rosenberg is a part of the computer industry, even if his job has been to write about it. Kidder is a journalism professor, who likely had never used a computer before this book. Both need to present technical material in their books, and in rereading, I'm amazed at just how dense the technology is in SoaNM. But the difference is telling: Rosenberg looks at the material with an insider's eye, while Kidder is an outsider who has to learn before writing. And in so doing, he distills the content, giving enough detail for the novice, but not so much that the knowledgeable reader is bored.

After three weeks with Dreaming in Code, I gave up. The book was due back to the library, and I didn't have a lot of interest in continuing to read it. Based on what I've read about the project elsewhere, that seems appropriate.