The Clojure for Beginners workshop at the Oakland Workshop Weekend a couple of weekends ago went well. Everyone who came to the workshop came into it curious about Clojure and they all stayed engaged and curious to the end! They all wanted the slides, and after a few fixes, I’ve uploaded them to my Github project page for the presentation here.
Just FYI, here are the considerations I had when creating the slides, from an instructor perspective:
I’ll be teaching a short workshop at the upcoming Oakland Workshop Weekend that is a beginner’s introduction to Clojure. The Clojure workshop is currently slated for the Saturday, June 22 at 5pm (until 7pm).
Workshop Weekend is a full 2-day long event where you register and can take as many courses as you can attend in those 2 days. Some of the classes for the upcoming June iteration include cheese making, aquaponics, negotation, soldering, and web hosting 101. It’s worth attending, especially if you’ve never been (and even if you’re not attending the Clojure workshop, which rumor has it will be super-awesome, natürlich!).
If you have any questions or suggestions about the Clojure workshop, drop me a line!
Update (6/14/2013): You can get a $10 discount on the registration if you use the code CLOJURE0613.
I use a fair number of libraries for my Clojure project that are not integrated into the Maven ecosystem by Clojars and Leiningen. For as long as I was using Leiningen 1, I was able to get around this using the hack of putting all my local/native libraries in the ‘libs’ directory. Leiningen 2 encourages standardizing on using the user’s local Maven repository, and eschewing the ‘libs’ hack is one part of that process. Not only is jumping on board with Leiningen v2 a good thing, but I needed v2 in order to open SWT windows in a REPL on Mac OS X for the first time ever. So the following are the instructions that I followed to ultimately get my local / native lib jars installed with my local Maven repo for Leiningen 2 to pick up automatically. Let me know if they work for you!
Most programming languages have facilities of some sort to enable the developer to execute commands on the OS’s shell prompt. Maybe it’s just me, but I’ve never been able to have an easy time at managing system processes properly (i.e., representing processes individually through the language’s constructs). Representing multiple processes piped from one to the next properly seemed like a pipe dream (sorry). I think the first painless way of doing this, at least among all the different options that I’ve seen, is in Clojure with the clj-commons-exec project. At the moment, it seems like a hidden gem. A side benefit of the project is that the evolution of the code for piping one process to the next, at least for me, is instructive on the difference between object-oriented and functional paradigms.
Since learning Clojure will most often require a lot of experience in coding in Clojure, a practical consideration for any new learner will be having an effective environment for editing code, testing, deploying, etc. On the Clojure development (developer?) website, there are instructions on getting started with Clojure. I believe that these instructions are intended to be the official help resource for everyone, and people are making good effort to keep it up-to-date and authoritative. My attempt, with this post, is to formalize what I know, and then contribute over to the official documentation whatever others might find a useful addition.
There are many ways to dabble in Clojure. My approach has been to read something, retain some fraction of it, and then repeat this process until those fractions equal a whole. When stepping into functional programming for the first time, especially after OOP, it’s not easy to grasp it right away. Sooner or later, the ideas will stick, right? That means learning in multiple passes, where some deeper level of understanding happens during each pass compared to the last. Kind of like iTunes Essentials with “The Basics”, “Next Steps”, and “Deep Cuts”. So that is what I want to present to you, in an ordering that will minimize your difficulty along the way.
On Wednesday and Thursday, I’ll be volunteering at a Software Carpentry boot camp that’s happening in Berkeley/Oakland. I’m looking forward to it.
Previously, I’ve created an episode of the online lectures for secure shell. I also wrote the initial code for the episode using phylogenetic trees, although it got re-written by Greg. So I was more like just the narrator in that episode, but now I know how triangular matrices can be handled by maps. It’s always nice when you can work alongside smart people and can imbibe some of their knowledge and wisdom.
For a while, now, I’ve been trying to explain to people what makes someone effective — productive and efficient to do programming and/or science research. Until very recently, I was working in a genetics research lab, and I was asked by coworkers about what it takes for someone to be productive. Whether it was in terms of programming productivity or ability to intuit scientifically, I had been on both sides of the non-/productive divide. I distilled the differences to being resourceful and resolved.
Everything in technology seems to increase in exponential fashion. There’s the ever-quoted Moore’s Law, where CPU speeds seem to double every 1.5 years. RAM capacities and HD capacities seem to follow this rate, although the correlation might be coincidental more than anything else. However, network speeds have barely increased in the past decade, it seems. The boon in high-tech, high-throughput technological advancements in modern genetics labs is also a bit of a curse. As the New York Times reports in DNA Sequencing Caught in Deluge of Data:
Sequenced Thoughts from C/S 