Clean Scala?

In recent posts, I've reviewed "Programming in Scala" and "Clean Code". These two books have very different goals, but reading them concurrently got me thinking about how the relationship between a programming language and its users (i.e. software developers) changes over time, and the implications that has on code quality.

Programming in Scala and Clean Code are both products of their respective languages' life cycle. After several years in incubation, Scala is just starting to make its way into production applications and generate some buzz. Right now, experienced Scala developers are probably outnumbered by curious newbies by a factor of ten or more. The timing of "Programming in Scala" could not be better - an excellent introductory book is exactly what the nascent Scala community needs to bring more developers into the fold.

In contrast, there's absolutely no need for another introductory Java book. Since the mid-90's, literally dozens have been published, and some are now in their seventh or eighth edition. There's no shortage of Java developers, just a shortage of developers who can code Java well. Hence the need for books like "Clean Code", which advise developers on how to deal with poorly-written Java code, and discourage them from writing any bad code of their own.

Reading these two books concurrently had me wondering if some years' hence, there will be a need for a "Clean Scala" book. I certainly hope not. The creators of Scala took advantage of many "lessons learned" from Java (and other languages, presumably) to craft a better language. One of their goals was to allow developers to write concise code that more clearly expresses their intentions. I think Scala has achieved that goal, but making expressive code easy is not the same thing as making it mandatory.

The elegant code examples in "Programming in Scala" make it hard to imagine that anyone could ever write crufty code in Scala. However, I've learned - the hard way - not to underestimate a developer's ability to warp and misuse a language in ways its creators could have never imagined.

At this early stage, it's not clear to me what the most notorious abuses of Scala will be, nor how much frustration they will cause the developers who have to clean up the mess. Will future Scala masters still exhort novices to use expressive variable and function names, to avoid repeating themselves, to follow the Law of Demeter? Will the beauty of Scala make these truths self-evident? Or will Scala introduce its own unique set of anti-patterns? My hopes are for the best, but I guess we won't know for a few years.

Review: Clean Code

"Clean Code"by Robert C. Martin is not a conventional programming book. It's not about a new language, framework, methodology or tool. It's about how to be a better developer.

As such, it has much in common with books likeCode Complete,Effective Java,The Pragmatic Programmer,Refactoring, andImplementation Patterns, all of which fall into a genre I've dubbed "self-help books for software developers". I'm not being dismissive here: after all, systems can be just as dysfunctional as families. As developers, we can benefit from some good advice on how to cope.

Much of the advice that "Uncle Bob" dispenses will be familiar to readers of those other books. (Indeed, "Clean Code" references "Refactoring", "Implementation Patterns" and "The Pragmatic Programmer" quite extensively.) I find this redundancy comforting rather than disappointing. After all, if all these books disagreed about what the best software development practices were, how would you know which advice to follow?

(However, there is a certain irony in having read about the DRY principle - "Don't Repeat Yourself" - in three different books.)

Despite the commonalities with its predecessors, "Clean Code" is more than just a rehashing of old advice. The unique aspect of "Clean Code" is the section near the end of the book where "Uncle Bob" uses the principles laid out in the preceding 12 chapters to refactor samples real-world code drawn from the JUnit testing framework, the JCommon library, and his own work.

It was fascinating to see perfectly functional code iteratively refactored into "clean code" much better suited for reuse and further extension. Other books have explained this principle and demonstrated it on small pieces of example code, but only in "Clean Code" have I seen it applied to widely-used open-source code.

If you've ever wanted to refactor some dysfunctional code but not known where to start, or doubted that the end result would justify the effort, you should read Martin's book; it will give you the hope and confidence to give it a try.

Enabling Java 1.6 for Mac OS X

OK, I might be the last Java developer using a Mac to realize this, but apparently Mac OS X 1.5 (Tiger) uses J2SE 5.0 by default, even though Java SE 6 has been available for nearly two years.

I figured this out today while reading Google's instructions on how to create Java applications for App Engine. (Side note: Woot!) The section regarding compatibility with different versions of Java contained this curious sentence:

For developers that don't have easy access to Java 6 (such as developers using Mac OS X), the App Engine SDK is compatible with Java 5.

That was a head-scratcher. I know that Apple's support for Java usually lags Sun's releases for Windows/Solaris/Linux by a few months, but Java 6 was released over two years ago. Surely Apple has caught up by now, right? To the Terminal window!

Hank:~ mtye$ java -version
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-284)
Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing)

Huh. That can't be right, can it? No, a little poking around on Apple's site reveals that Java SE 6 was pushed out to users with Java for Mac OS X 10.5 Update 1, back in May 2008. So where's my Java 6?

I found a crucial clue here. Apparently, in the /Applications/Utilities/Java directory, there's a Java Preferences application that can be used to determine which Java version is used by default. I fired it up and got this:

Oh, there's Java 6! Right behind the 32-bit version of Java 5, for some reason. Let's fix that with a little drag & drop:


Let's check again:

Hank:~ mtye$ java -version
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)


Ah, that's much better. I feel so 2007 now!

Why "Code Shark"?

Well, it's certainly not because I think of myself as a relentless apex predator, prowling the seas of software development. Rather, I'm alluding to the fact that certain species of shark (specifically, obligate ram ventilators) have to keep swimming in order to survive. Lacking the ability to breathe in the conventional piscine manner, these sharks maintain a steady flow of oxygenated water over their gills by swimming forward with their mouths open. If they were ever to stop, they would suffocate and eventually die.

I've been coding for a living for almost two decades, and in that time, I've learned that a career in software development has something in common with those sharks: if forward motion stops, it suffocates and dies. "Forward motion", in this case, means the acquisition of new skills: new languages, new tools, new methodologies, and even new ways of thinking.

If you keep up to date, a wider variety of interesting projects are available to you. If you fall behind, you get stuck maintaining crufty legacy code. (Or worse, you get a Dilbert Principle promotion and become one of those managers who has no clue what his/her underlings actually do.)

Many years ago, I had a career near-death experience: I unwittingly drifted into a dead-end job maintaining an obsolete system. When I decided it was time to move on, I was stymied because I possessed none of the skills my employer required for new development projects. Looking for jobs at other companies was equally fruitless; the only opportunities open to me involved maintaining the same kind of obsolete system!

Escaping from this trap required a complete career reboot: I quit my job, learned a new language and paradigm (Java and OOP), and persevered until I found an employer who was more concerned with my potential than my experience (or lack thereof). I was relieved to get my career moving forward again, but it was very costly in both time and money - it would have been far better to never get stuck in the first place.

In the years since, I have made a concerted effort to fill in the gaps in my skill set, so as never to become obsolete again. It's a daunting challenge; the software development ocean is so vast that keeping up to date is nearly a full-time job in itself. So far, the investment has paid off: each of my jobs has been more rewarding - intellectually and financially - than the last.

In this ongoing process of reading, learning, and acquiring new software development skills, I've occasionally made discoveries that might be helpful to others who are on a similar journey. I've belatedly set up this blog to share these ideas with a wider audience. I hope you find them useful, or at least entertaining.

Keep swimming!