Clojure User's Group @ Google NYC [Feb, 2011]

This post was sitting in my drafts bin for a while but I decided to finish it off and post it today. My apologies if it is a bit dated and not up on current Clojure syntax.

I was at Clojure User's Group, NYC back in 2011...

And Stuart Halloway flashed this code on the screen:

(describe String (named "last"))

He complained that while it appears simple, it is in fact not simple and showed this code instead (which does the same job).

(->>
   (reflect java.lang.String)
   :members
   (filters
        #(.startWith (str (:name %)) "last"))
   (print-table)
)

He then claimed the new code was simpler. I had to admit I just didn't see it. How is the second listing simpler? The idea is to describe in table format some data right? "describe" seems pretty simple to me.

Over beer that night Stuart illuminated my foggy understanding. The second listing is simpler because it introduces fewer new constructs to the language. It is also simpler because the components are smaller, looser in coupling, and can be re-used later without some special facility or dependency on printable output. The key to reuse being that "print-table" now does tablular output on any incoming data as opposed to hiding that nugget of function deep inside the "describe" machinery.

We went on to discuss the issues with ORM and how mapping data adds a layer of accidental complexity. Being a good disciple of the Java/Groovy camp I believe in hiding complexity behind clever facades like Domain Specific Languages, Frameworks, and API. This is in stark contrast to a good disciple of Lisp's view of the world.

What makes Clojure interesting is the deliberate collision between these two world views. I normally would not be forced to dredge up my decade old exposure to Lisp and place it directly in front of what I've learned from Java the last decade. The Clojure folks force us to do that and you can blame this momentary encounter with Stuart for my talk on Functional Programming in Java and for the thought experiment that is lambda-cache which is an attempt to do caching (via ehCache) using a lambda construct in Plain Old Java Objects.

What is interesting is as we explore Functional Programming on the JVM and as project lambda matures we are going to finally explore how best to reconcile these differing views of simple. That is because simple is anything but simple. In it's purest form simple is really an analogy for beauty when it comes to computer science or mathematics. The value of beauty is debatable. How to achieve beauty is at least in part subjective. 

What is most surprising is that there are objective measures of beauty in many fields. For example humans find adherence to the golden ratio in proportion to be beautiful. There may in fact be a measure of beauty that can be performed mechanically. Similarly, is there a measure for beauty when it comes to computing? Ostensibly simple is the opposite of complex and computational complexity theory is still a dark murky thing. Do we need to shine some light into the corners of complexity theory before we can measure simplicity?

Surprized by how little I use multithreading...

Back in 2000 I was working on multithreaded applications. Since I was working in Posix environments in C I used the Pthreads library. I learned to use Pthreads from both C/C++ and Perl contexts but I had trouble with managing Pthreads and in 2000 I perceived that Java's threading would be easier to use.

For an honest and unbiased comparison of Pthreads and Java threads based on the state of things (at that time) you can look at this paper by Wim H. Hesselink which manages to cover in 8 pages most of the differences. It was these differences between C/C++ and Java that made me interested in shifting from Posix to Java development.

As it turns out, now that I work primarily in Java (something that took me the better part of a decade to orchestrate), I rarely make practical use of multithreading in Java. For the most part you don't need it when you work in an application server. In the cases I typically encounter if you structure your Java application properly it doesn't need explicit multithreading.

Notice, I said explicit. In Java Application Server environments we have tools like messaging queues and timers. Using these Application Server tools properly implicitly produces the same effects as you would get by setting up your own threads and these techniques tend to create fewer bugs since you aren't forced to write thread management code that is easy to make mistakes with.

So, what I'm looking for now are examples of problems that using JMS, asynchronous request processing, or Quartz timers won't provide a clean solution. Why do I need to use multithreading explicitly in today's managed Application Server world? What am I missing?

And once I'm developing multithreaded code... how do I test it?

I've gotten responses from some prominent developers out there already and I hope that we can collaborate and share from the experience. I am excited at the chance to learn from some of the people that I consider to be great thinkers in our community. Either way I know I'll learn something. In the end that's what I'm really after.

Dominant Groovy

Steven Devijver has an interesting post over at java.dzone.com titled Groovy will replace the Java language as dominant language

While I'd love to agree with Steven, I'm afraid I don't. Now... I think Groovy has the potential to be very very popular on the JVM and I think it is a wonderful way to work. Python didn't replace C. From Steven's own article:

Groovy is the dream child of James Strachan, extravagant open-source developer and visionary. While waiting for a delayed flight he was playing with Python and found it such a cool language that he decided the JVM needed to have a language like this too.

No matter what programming language popularity chart you like to stare at and hit reload on in the middle of the night the top two languages today are Java and C not C++ but good old C. That means that even when some programmers could choose from Python, Perl, PHP, Ruby, Haskel, or a whole bevy of languages the still choose C. So I think we'll see the same on the JVM. Many programmers will have the chance to adopt other tools other than Java but the majority will probably choose to stay with Java.

This is a bit of a warning to Sun. C hasn't had new features in a while. Maybe Java shouldn't get new features so fast either? Creating new languages to support new features seems like a really good move to me.

I really like Groovy a lot and I sincerely hope Groovy makes it into the top 10 programming languages in the world in the next few years but I don't think Groovy will supplant Java in the near term. I can see a time when nearly all Java testing is done in Groovy and much web development. But, even when Grails gets "serious" they use Java.

I also don't buy the analogy of "Java is assembly to Groovy" argument. I think Groovy is to Java as Python is to C. This is a big deal on the JVM since scripting on the JVM has been very hard to do. I remember a long time ago there was talk of porting Perl to the JVM and that never really materialized. There is serious work today on Ruby for the JVM and that work seems to have legs.

The idea for multi-language VM is a very good idea. I also think it's counter productive to speculate on who will trump who for popularity. So far I've only seen this cause problems for people and create unnecessary friction. Soon there will be a very big swelling of Groovy support in niches where performance is trumped by developer productivity but where performance still holds sway over productivity and code output Java still reigns.