Code and comments

Practical and theoretical aspects of software development

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? It’s time to learn another JVM language. Despite the abundance of JVM languages (Groovy, JRuby, Jython), only Scala and Clojure offer hope of reasonable performance. I was close to investing in Scala. It’s very flexible, far less verbose less verbose than Java, and it’s fast.  It has a much more sophisticated type system than Java, and has great support for concurrency. But I balked at Scala’s complexity. It’s type system is a bit much for the real world, and I worry about the multi-paradigm approach, allowing for object-oriented, proceedural, and functional programming.

If not Scala, then what? The only other option that looks like a potential path forward is Clojure. I’ve toyed with Scheme in the past long enough to get the hang of writing functions that end with a bunch of right-parens, but never long enough to understand what a substantial program would look like. I’m ready to give Clojure a real shot. I plan on spending at least a year with the language, trying to get to a real understanding of Clojure, Lisp, and the functional paradigm.

I’ve resisted the functional programming crowd for a few years. I haven’t been convinced that it is practical in the real world. I spent some time learning Haskell, and it reinforced that notion. I found it extremely enjoyable to write mathematical functions, solving a number of Project Euler problems in Haskell. But when your language requires the concept of a monad in order to do simple IO, then you have taken a wrong turn.

I’m hoping that I’ll find Clojure more pragmatic. In the end, I may find the kingdom of verbs is no better for building large complex systems. But even if I settle on Scala, Groovy, or another mult-paradigm approach in the long term, I expect that I need to immerse myself in the functional world first.


Written by Eric Wilson

October 18, 2012 at 5:13 am

Posted in commentary

Tagged with , , ,

%d bloggers like this: