So I’m starting to learn Clojure, using Stuart Halloway’s book Programming Clojure as a guide. It’s a steep learning curve for me as I’ve only ever done procedural and object-oriented programming, save for a brief dalliance with Scheme in a programming course I took in graduate school.

I get the basic concepts of functional programming (immutable data, functions without side effects, etc.) but am nowhere near the point where this functional mindset comes naturally to me. I still want to break things down into objects, with methods that carry out actions step-by-step.

One of the the things about Clojure that seems to be tripping me up a lot is the syntax surrounding the ns, use and require special forms. For example, one of the first references to use occurs on p. 19 of Programming Clojure, and it looks like this:

A bit later, on p. 38, he reintroduces use, but this time the example looks like this:

Now, I get that in the first example, he’s saying “only use the str-join function from the clojure.contrib.str-utils library,” while in the second example he’s using everything. What I don’t get is the differing syntax, using a quoted vector in the first example, and a quoted list in the second. It sort-of makes me think that this should work too:

but of course it doesn’t, and I get a mostly useless error message in the REPL. Now, if you’re an experienced Lisp, Scheme or Clojure programmer, you probably understand why this last example is wrong and you really don’t understand how I could possibly think that could be right, but I’m just not there yet. But I’m working on it!

Another thing that has hindered my progress a bit is the way that Clojure’s standard library and its API documentation are organized. Take the clojure.core library for example: it contains several hundred functions, and unless you already know the name of the function you’re looking for, tracking down just the right function for what you need is like looking for a needle in a haystack. For example, a little program I was playing with yesterday dealt with a list of maps, like so:

Now what I wanted was to convert this list of maps into a single map, where the names of the relation types were the keys and the values were the relation types themselves; i.e. a result like this:

After looking through the API documentation for clojure.core I decided there wasn’t any function that would perform this kind of transformation directly (or at least not that I could tell). I also determined (I think) that there’s only one function, hash-map, that will produce a map from its inputs; everything else seems to produce a list/sequence. So anyways, I ended up going with this approach:

and it works, but I’m looking at it and wondering, is this the best way to do this? Is there maybe a more efficient approach than first constructing a list of the type names, then interleaving those with the types to produce yet another list, and finally using hash-map to convert it into a map?

Having said all that, the challenge of learning this new (to me) approach to programming is fun, and I anticipate that it’s going to affect how I think about programs that I write in the languages that I already know well, like Ruby and Java. I’m also excited about finally having what feels like a more “practical” Lisp to play with, one that I can use with existing Java libraries that I work with every day.

When Jamis Buck wrote last year about ceasing development on Capistrano, his post really struck a chord with me. If this post reminds you of that one, it’s because I re-read it before sitting down to compose this one. It was the next best thing to having Jamis on hand to give me a pep talk before I had to stand up and say something that I’ve been putting off saying for too long. As a bonus, I could visualize him calmly and quietly making one of those neat little string figures while I tried decide exactly what it was I wanted to say.

It is with mixed feelings that I announce that I’m stepping away from FXRuby development, effective immediately. I will no longer be accepting bug reports, support requests, feature requests, or general emails related to FXRuby. I will continue to follow the mailing list, but I am no longer the maintainer of this project.

When I started developing FXRuby back in late 2000, it was a lot of fun for me. I was still new to Ruby (most of us were, back then) and Ruby was in need of a good GUI toolkit, so working on FXRuby provided me with not only a good way to learn the ins and outs of the language, but also to get really plugged into the community. In recent years, however, working on FXRuby has become a chore. I’m a decade older, at a different place in my life and career, and there are frankly just too many other things that I’d rather be working on at this point. These feelings are compounded by the fact that FOX development has, as best I can tell, stalled out, and without anything new to look forward to on the FOX front there’s little motivation for me to continue working on FXRuby. So it’s time to make a clean break and call it quits.

I would like to take this opportunity to thank everyone who did participate in the FXRuby community over the years. Knowing that you found my work of some value means a lot to me, and I appreciate the encouragement that I received from you along the way. I was never successful at organizing a development team around FXRuby, something which I regret, but a number of people contributed patches or third-party tools and extensions to FXRuby. If I tried to name all of those contributors, I would invariably leave someone off the list by accident, so let me just say: Thanks, you guys; you know who you are. A special thanks as well to those of you who bought the book. And of course, I owe an immense debt of gratitude to Jeroen van der Zijp, without whom there would be no FOX toolkit, and thus no FXRuby.

Someone on the mailing list asked whether FOX and FXRuby are “pretty much dead.” I can’t speak for Jeroen or the FOX project. As for FXRuby, however, that’s up to you. FXRuby is, and always has been, an open source project. If you are interested in hacking on FXRuby, or even taking over maintenance of the project, please feel free to fork the project on GitHub and release updates as you see fit. The Wiki has a lot of information about setting up a development and build environment on Windows, Linux and Mac OS X, and if you have specific questions about the build chain I’ll do my best to help you get set up.

If no one steps forward to maintain FXRuby, that’s fine too. The code has been pretty stable, if not bug-free, for quite awhile now, and it may the case that the code’s “done” anyways. If you feel that way and want to continue using FXRuby, it’s not going anywhere. If on the other hand, you have some fresh new ideas about how to move ahead, go for it! I will be cheering you on from the sidelines.

In closing, thanks again for all of your support over the last ten years. I’m certainly not done with Ruby, and I’m looking forward to exploring other ways in which I can participate in the Ruby community in the future.