Mutt: What will be the appropriate designation for the upcoming period of solar rotation in the Anno Domini system as devised by St. Dionysius Exiguus?

Jeff: Why don't you just look at the pie?

Mutt: Couldn't you just answer the question? Why do you always have to be a sarcastic asshole?

Jeff: Seriously, look at the pie.

Mutt: Huh. Yeah. I see what you mean. Sorry dude.

Jeff: No problem, my tinhorn peer. It is after all New Years.

Ens.: And to all a good night.

TL;DR

Consciously uncouple from the yoke of technological precision, using nothing but precision …

In the alternate universe where I am very honest, my résumé contains a line item for the aggregate year I've spent fiddling with init.el. It does not, however, list emacs lisp among the languages I know, because (in this alternate universe) I have too much self respect to flaunt cut and paste skills.

In the present universe, this is going to be awkward, because I will have to present really crappy elisp code without apology.

What this is about.

1. One of the things you get in an industrial strength IDE, in exchange for giving up your favorite editor, is …

To everyone who attended yesterday's NYC Clojure Meetup: thanks for listening to me, asking good questions and providing some pretty great answers as well.

Here are the slides. For more detail on nearly everything, see previous posts.

(Navigate using the compass arrows. Up/Down within a section; Left/Right betwen sections; ESC for overview.)

Were you at Clojure/conj in Washington last week? If so, hello again. Wasn't that a great conference? If not, head to Clojure TV, where all the talks are ready for streaming. Assuming some moderate level of Clojure obsession on your part, I couldn't recommend skipping any of them, so the full catch-up might take you a while, but there are two in particular that I strongly recommend.

Avoiding altercations

The first is actually the very last talk of the conference. Brian Goetz, whom you may have encountered previously as the author of Java Concurrency in Practice or heard of …

How strange to think that, a mere week ago, the world had not yet heard my public pronouncement that transducers ought to be stateless. True, the media frenzy has died down a bit, but in its stead comes the quiet awareness that life will never be the same. Anyway, that's the way I like to think about it.

TL;DR

1. Storing state in the transducer makes it mutable, which might be unfortunate on general principles. In any event, it interferes with the metaphor of transducers as recipes for transformation and arguably makes code more difficult to understand.
2. A natural place …

After my recent attempt to provide type annotations for transducers, several people pointed out that I wasn't accounting for state. The signature of a pure function transformation, whether in Clojure

  (t/defalias Transducer (t/TFn [[a :variance :covariant]
                                 [b :variance :contravariant]]
                (t/All [r] [[r a -> r] -> [r b ->r]])))

or Haskell

  type Transducer a b = forall r . (r -> a -> r) -> (r -> b -> r)

nowhere acknowledges that the transducer might need to maintain, for example, the previous value in the series, in order to remove duplicates.

The failure is most obvious to hardcore Haskell programmers, who, as a rule, would …

TL;DR

1. As noted earlier, transducers can be properly annotated in Clojure using core.typed and they probably should be.
2. But... there are a few tricks necessary to make it work.
3. Transducers in Scala require tricks too, but different ones.
4. Oh, but they're so lovely in Haskell.

Update 2015-01-12

Were you led here by Clojure Gazette? Eric Normand is usually more discriminating, but don't worry, this will only waste a little of your time. Per the previous batch of updates, just below, and various subsequent posts on more or less the same topic, it should be clear this wee bagatelle …

Back in August, I wrote two posts about an experimental framework for distributed functional programming called Girder. The idea, in summary, was to make distributed code look as much as possible like ordinary Clojure, as opposed to structuring it explicitly around message passing (as in the actor model) or data flows (as in map/reduce, storm, et al). As I say, it was an experiment, but it was also something a cri de coeur (a mini-manifesto, if you will) against extraneous impingements on my code. Anyway, it sounds interesting, go back and read the posts, but you don't need to …

In two previous posts, I went on about lenses in Clojure. Pinholes comprised a small library of higher order functions to formalize and simplify the viewing and manipulation of complex nested structures. Tinholes did essentially the same thing, but with macros instead. In both cases, there's recursion going on, as we burrow through layers of nesting, but macros had the advantage of doing it all before compilation, giving core.typed a chance to check our work.

The macro post was inexplicably popular, catapulting me to levels of fame I never expected to achieve without consciously emulating an early De Niro …

In a previous post, I built up a framework for lens-like constructs in Clojure: essentially some fancified versions of assoc-in and get-in to allow for bidirectional transformations along the nesting path and some utilities to generate special-purpose getter/setter functions. The name, "pinhole," is supposed to suggest a more primitive, utilitarian mechanism for achieving focus.

While still ruing (sort of) other mistakes, I found myself worrying that a triumphal sentence near the end of the piece

What's more, thanks to the expressive power of dynamic Clojure,
and higher order functions, these lenses are not just simple to
use but …