Thursday, May 28, 2009

Beware Of Mumpsimus

In first year of university, I took a class that used the wonderful book Becoming A Master Student. The book had many stories that have stayed with me over the years.

One is the story of mumpsimus. You can read more at the link, but the gist is that a monk used a Latin word, mumpsimus, for decades before discovering it was bogus. Upon the revelation, the monk replied that he didn't care: he had been using it for 40 years and so it would it remain.

In my freshman year, I was an uncomfortable chemistry major. Little did I know that I would be writing about that story many years, later vis-a-vis computer science. (The story itself may go back centuries!)

I mentioned mumpsimus in the comments of the last post. I had speculated on using protected methods over private methods. The feedback was unified in its rejection of the idea, yet I mused that I would probably continue my style. Ouch. That is mumpsimus indeed: after seeking opinions, I launched a heroic denial of the responses and continued on my merry way. Nice.

Another example is the defeat of mumpsimus. Years ago, in C++, I would define class members like so:

class Person {
int m_id;
string m_name;
int m_age;

When I turned to Java, I held on to that style -- for about 1 day. When I saw what IDEs could do for automatically generating getters and setters, it became obvious that the prefix had to go. Thankfully, logic carried the day over mumpsimus.

The Upshot

The point here is that we have a name for a particular mindset, and a reminder that it is important to re-evaluate ideas with an honest understanding of our biases.

Wednesday, May 27, 2009

Java Methods: protected is the new private?

In code reviews (including my code), when I see a Java method marked as private, I ask if there are any unit tests for it.

Since tests are written in other files in parallel packages, the answer, of course, is no.

I've recently realized that I've obtained the following habit: my methods are either public or protected. I have no use for default or private. I don't like default because I feel compelled to write a comment saying that it is package-level access; I don't like private because of the lack of testing options.

Before you start hammering in comments, here are some thoughts:

  • This is not for a formal API to another team or other 3rd party. In that case, I would be more careful and rigid. You may argue there is no distinction, in which case: commence hammering.
  • I realize that protected is not default and that it is leaking encapsulation somewhat. I can cheerily say that I don't care. I like scanning a file and seeing either public or protected.
  • I'm not trumpeting that I write more unit-tests than others on my team. Just because a method is protected doesn't mean that I've written the tests!
What do you think? Has your style changed over the years, with respect to access modifiers on methods?

Wednesday, May 13, 2009

The Case for Clojure


At NFJS shows, a common question is "I only have time to learn one new language on the JVM: which should I pick?".

The easy answer is true: it doesn't matter. Just pick one already!

However, I think people can reasonably ask for more information.

Even though my personal favourite is Groovy, I fancy that, like a good law professor, I could argue a decent case for any of them.

In this post, I'll write a bit on Clojure. To be honest, the title is deceiving: I don't know Clojure, and this isn't a full-blown legal case. I'm really inviting you to some resources (see below).

However, I know enough to see the benefit. This is an earnest post.

Mark Volkmann is giving a Clojure talk on Thursday at the St Louis JUG. Quoting from his intro, Clojure is a dynamically-typed, functional programming language that runs on the JVM.

From past talks, and from Mark's intro, here are some reasons I think Clojure is worthy of your consideration:

Let's Lisp Again, Like We Did Last Semester

If you liked Lisp back in university, welcome back: Clojure has a Lisp-like syntax and style. Both the syntax and functional programming seems new again, in part thanks to Stuart Halloway's book.

Here, 'new' means a shot-in-the-arm to the FP community and a welcoming online scene. Let's face it: it can be lonely when studying older languages.

Got Lisp?

If you don't know Lisp or functional programming, adding Clojure to your repetoire is almost like right-brain thinking. It is profoundly different from Java, C#, and other imperative languages. This is important in order to truly grow. To borrow from natural languages: it's cool if you know French and Spanish, but it's cooler if you know French and Chinese (or Spanish and Chinese).

Bonus: though not unique to FP, Clojure can execute data as code. This is powerful, and quite underrated, IMHO. This goes all the way back to grand-daddy Lisp, so you'll be learning from one of the undisputed giants. What's more both Lisp and Clojure have a minimal, consistent syntax. Though it is, er, mind-expanding at first, many people become true fans of the philosophy.

Software Transactional Memory

Concurrency is the new memory management. Memory management was a beast until garbage collection evolved, over decades, to be a shining sword.

Now, on the JVM, we've tamed the memory beast and wrestle with concurrency. Consider books like this: JCiP is an outstanding book, but it is a tough go, in part because the developer must coordinate lock-level tools. Or, worse, a team of people must coordinate lock-level tools.

What if we had something really different -- a pseudo-intelligent agent like a garbage collector, except aimed at concurrency? That's what Clojure offers: a unique alternative that might (and that's all we can say: might) slay the beast of our time.

The Upshot

Come on out to the JUG on Thursday, or if you aren't in St Louis, check out Mark's excellent article on Clojure. It is quite thorough, and has received kudos from the Clojure community.

Mandatory Listening: Michael Nygard on SE-Radio

Ted Neward has told us to buy Michael Nygard's Release It.

I have told you to listen to Software Engineering Radio.

Perhaps you haven't listened. Perhaps you've been busy, or perhaps you reject advice from respected IT leaders (and me) on principle.

Well, now there are no excuses: check out SE-Radio episode 134 with Michael Nygard. You may not refute an implicit double recommendation!

Believe me, you won't regret it. Then read the book and check out his talks on the NFJS tour.

Tuesday, May 5, 2009

Language Shootout At Lambda Lounge

Gmail has been recommending "vending machines" ads to me for some weeks now.

Here's why: the Lambda Lounge has issued the Vending Machine exercise as a way to showcase the idioms of different languages (and there has been good discussions on the mailing list, hence the Google ads).

If you are in St Louis, drop by on Thursday night (details here), to see some live demos! There are a wide variety of languages on display.

For best results, take a shot with a language of your choice. Though somewhat behind, I've been working on a Groovy version.

Stay tuned to the website (or the mailing list) to find resources to examples.