Clojure/West 2013

Jeremy Sherman's Headshot
Jeremy Sherman

I stumbled from the red-eye into the airport shortly after dawn. Bleary-eyed and back on the ground in Atlanta at last, Clojure/West, and its talk of Lisp and browser and JVMs, seemed already a distant memory. My laptop hadn’t left its TSA-friendly bag for the past week. My notebook was full of scribbles and mindmaps. What was a Cocoa programmer like me to make of it all?

Cocoa is a collection of large frameworks for an elegant object-oriented extension of C.

Clojure is a multi-platform Lisp with rich support for immutable data structures and high-level concurrency constructs. Its community is very open to exploring academic ideas in an industrial context, which generates interesting projects and great content at a rapid pace.

Despite their differences, both communities face the same problems. Multicore is language-blind; mobile doesn’t care what language you hack in; and bugs crawl into our code whether it’s chock-full of square brackets or all-over parens.

Same problems, different solutions:

  • Making sure the right things happen at the right time without an explosion of fiddly state can be a pain. (Especially with GUIs. Special cases everywhere for those prima donnas.) Functional reactive programming takes a good shot at solving that. Javelin adopts a spreadsheet-flavored approach to functional reactive programming with an elegantly narrow API. ReactiveCocoa applies a more conventional signals-and-behaviors approach structured around blocks, KVO, and C macros.

  • Turning data into meaning is a problem that just won’t go away. Core Data gives us save, fetch, and a sometimes too-magic ORM. The rest is up to us. Core.Logic lets you convert data drawn from a database into facts and relations and declaratively answer questions and generate new assertions about that information. It plays nicely with relational data as tuples.

  • Undo remains a higgledy-piggledy mess. Undo with Core Data adds an extra spice to the mix. But treating the database as a persistent data store, as Datomic does, greatly simplifies the problem. No more “oops I just stepped on that data”. No more “let me compute the opposite maneuver and register it”. Instead, just, “let me just back up a bit in history”.

  • Build dependency management remains an issue. Xcode doesn’t handle any unit bigger than the file very well, and good luck keeping a diverse list of dependencies up-to-date and correctly installed. Clojure’s building on Java meant they got to start with a substrate with established dependency management systems, but those systems were also Clojure-agnostic. Clojars is a couple years older than CocoaPods. Both have some growing to do, but looking at what Clojars does might provide some good ideas for where CocoaPods might head next.

I'll post more about these in the future, but my main point is that it’s not just tools and projects a Cocoa programmer could take from Clojure. It’s ideas:

  • Program with values, not variables.

  • Focus on transforming data, not pulling levers in a grand contraption.

  • Compose programs out of modules that present a limited, clean interface.

Recent Comments

comments powered by Disqus