Mastermind in Clojure and Java

Have you heard of mastermind? It’s a logic game in which one player repeatedly tries determine the secret code that another player set at the beginning. With each guess, the player is given information on how many correct pegs his guess contains, and how many are in the correct position. For more details on the rules, check the wikipedia article.

I built a Clojure implementation of Mastermind as a learning project. (Code and details of functionality at github.) My primary goals were to gain familiarity with the language, and to see what the functional programming paradigm feels like when working on a project that is larger than one big function. After I finished, I re-implemented (almost) all of the features in Java for a comparison. (Code also available at github.) Interested in the results? read on.

Hoping to leave class-oriented programming

Sometimes you need to pass around a function. In Java, since “Everything Is An Object”, you make a class, and define the function as a method in that class. Of course, you need a separate source files for this, since you want this class to be public.

Before long, you find that in a different situation, you want to pass a different function, so you make an interface, another class, and make both classes extend the interface. Now the two functions that would have logically fit in some already existing file have generated three source files.

Does it have to be this way? It’s a lesser known fact that in Python, everything is an object. A function is an object, a class is an object, a module is an object. But somehow, a commitment to everything being an object didn’t lead Guido to conclude that everything should have it’s own class file. Somehow “Everything Is An Object” doesn’t imply (in Python or Ruby) that functions must be defined in classes.

I’ve been using Spring with Java, and that is certainly preferable to me than Java without Spring, for medium or large projects. But it strikes me that much of what Spring helps me manage is the simple fact that I need many functions available in situations where I don’t want to instantiate an object first. When I use Spring to inject a singleton object, often what I really want is a handful of related, stateless functions. I would guess that about well over half of the classes in my projects are essentially one of two things: glorified namespaces or data types without behavior.

More to the point, as I build complex applications, I fear that building them in Java significantly adds to the complexity. I fear that I’m building in a way that requires some acclimation to a handful of patterns and a framework that ultimately shift the complexity of the problem to a different sort of complexity. It seems that this is the best that the Java world allows: familiar patterns of complexity.

So what’s a Java developer to do? Where to go from here?

Next steps for Java development

So you wanted to learn Java. Naturally, you did the hello world thing, then you learned about flow control. You became accustomed to the type system, declarations, initialization, and you learned about scoping issues. Then you learned about polymorphism, inheritance, and you’ve learned how to write object oriented Java code. You’re familiar with the collections API, and you are accustomed to using generics for type safety.

Of course, you want to get paid for programming in Java eventually, and the little console apps you have been building don’t exactly look production quality. Moreover, when you look at the job postings, you see a hodgepodge of terms that don’t mean anything to you, such as Struts, Spring, Hibernate, J2EE, Tomcat, WebSphere, Ant, Maven, etc. What to do?

Book review: Effective Java by Joshua Bloch

If you write Java as part of you job, you need to read this book. If you are learning Java, and hope to write Java as part of a future job, you need to read this book. So for many developers, the question of whether you should read this book is answered very quickly. The most important questions that remain are when to read Effective Java, and why to read Effective Java.

This is not a book to read to learn Java, Bloch assumes throughout that you have a familiarity with the language. It is also not a book to help you take the next steps after learning core Java, such as learning popular APIs such as JDBC, Java EE, or Swing. Effective Java is unlikely to equip you to accomplish any programmatic goal in Java that you were unable to code before reading it.

If you are overly pragmatic, it may seem that this book meets no real need. But if you have learned several languages, the purpose of this book, and the importance of books like this, is obvious.

Should you get certified? Should anyone?

Technology certification exams have a bad reputation. You don’t have to go far to find someone deriding the idea that a multiple choice test could be useful in distinguishing programming skill. Some say that they are a waste of time and a marketing scam. Others even claim that they distinguish you in the wrong way, and that any certifications that you have earned should be removed from your resume, as they will actually hurt your chances of getting the job you want.

I disagree, and think that there is a place for certifications, but there is some confusion about what you can and cannot get out of them, and when they may be beneficial to your career.

Book Review: Clean Code by Robert Martin

I read Clean Code by Robert Martin (Uncle Bob), and it was well worth it. In about 400 pages, Uncle Bob gives real motivation for writing clean code, explains, in careful detail what clean code means for all of the regular parts of a typical system, and then applies the principals discussed on several substantial chunks of real-life code.

Martin begins with motivation to strive to write clean code. That may seem unnecessary, but it serves several good purposes, even for those that were willing to buy a book entitled “Clean Code.” First of all, in Martin’s engaging style , you become excited about the possibility of writing better code. More importantly, in my view, is that rather than appealing to prideful notions of craftsmanship or art, he makes it clear that clean code is about useful, maintainable, flexible software. That it is about reducing the cost of software, and preventing, reducing, and fighting the software rot and decay that often surrounds us.

Why my code is rarely Groovy

I’ve spent over half a year using Groovy as my primary language, and it was a very good experience.  The flexibility of Groovy is a joy to anyone coming from the rigid Kingdom of Nouns, and the Grails web framework is excellent, far preferable to the various combinations of Struts/Spring/Hibernate (and others) that I had used with Java. And for a Java developer, the benefits of using the familiar, rock-solid Java infrastructure — libraries, web application servers, and the JVM itself — are significant.

I often found myself wondering why Groovy doesn’t get more interest among Java developers. After all, everyone needs a scripting language for small tasks, why not use one that you practically know already? And just because your production code is Java doesn’t mean you can’t test with Groovy.

But then a funny thing happened.

Hello, world!

public class Hello {
    public static void main(String[] args) {
        System.out.println("Hello, world!");
    }
}

I executed that program about 30 months ago. For me, it was a moment of optimism, now that Java was installed and working, I could focus on learning how to program. For my wife, it was depressing. Seeing the plain white text on the black console window highlighted how much I had yet to learn.