Thought Spearmints

What's the deal with functional languages, Part 1: Scheme

What with all the hubbub about Erlang, I've started diving into functional programming languages. Back in school, I learned a bit of Scheme as part of a mostly-Pascal-based second-semester CS course -- just before Scheme became the language with which the introductory CS concepts were introduced to first-year CS students at my university. To get back into the swing of things, I cracked open my copies of Springer and Friedman's Scheme and the Art of Programming, and The Scheme Programming Language, 3rd ed., and downloaded the excellent PLT Scheme environment. Currently I'm working my way through the exercises in the Springer/Friedman book -- fairly elementary, but I figured I'd start from square one.

Initial observations:

• I don't find the parentheses nearly as odious as I thought I would. Modern Scheme environments make matching the parens a snap, and the syntax coloring highlights the important stuff -- namely, the stuff within the parens!
• I really appreciate the language's small core -- the fact that many everyday constructs (e.g. let) can be defined in terms of even more primitive constructs (lambda).
• Cool to be able to leverage tail recursion and express certain constructs recursively while retaining the smaller memory footprint of the equivalent iterative expression.
• Continuations are first-class concepts in Scheme. These still make my head spin, need to read/experiment further...
• I can understand why the cool Lisp kids are all, "What's the big deal about closures/map/reduce/etc., they've been here all along!"

More as interesting things arise.

Interfaces : Constants :: Abstract classes : ...

...static methods?

It's common practice in Java projects to use an interface as a dumping ground for related constants. Back in the pre-1.5 days, developers did this in order that client classes could implement the interface and gain unqualified access to the fields. Nowadays, of course, you can just static-import the constants you need to use. In addition, the fact that fields on interfaces are implicitly static and final made declaring the constants less verbose.

Effective Java discourages this practice on published interfaces, for good reasons. Even if the interfaces aren't published, you might discourage the practice on the premise that an interface is intended to prescribe behaviors that implementers promise to honor -- not to hold a bunch of constants. My thought is that if your team agrees that constants can be placed into interfaces, those interfaces consist of constants only, and the interfaces aren't to be implemented, such use is okay. You could even cook up Checkstyle or PMD rules to enforce the practice.

For utility classes, I'd cultivated the habit of making their constructors package-private or protected, having them raise UnsupportedOperationException, and writing a test to demonstrate the results of attempting such an instantiation. See this entry for more on that. Recently, a colleague suggested that instead of writing all that boilerplate for a utility class, why not make utility classes abstract instead? That way we're guaranteed uninstantiability; plus, we don't have to make the constructor less private than we want just so we can write a test to demonstrate the instantiation behavior (or turn off code coverage for such a constructor). Initially I balked at the suggestion, because in my mind abstract connoted an invitation to subclass, when utility classes typically aren't extended. I almost wanted to be able to declare such a class both abstract and final. Really, I wanted C#'s static classes.

In the end, I supported the notion of declaring utility classes abstract. I'd like to write a Checkstyle rule that ensures that when a class consists solely of static members, it is declared abstract.

Interesting how I came around on this one.