Stupidly Obscure Programming in a Troubled Time

Since obsessively underlining passages in a tattered copy of Goodbye to Berlin hasn't proven to be the uplifting diversion I was hoping for, I resolved to bash my head against some really complicated scala code that I'm not qualified to write and that nobody is asking for either.

So that this exercise in self-abuse could pass for a reasonable use of my time - but not too reasonable, since that would be a giveaway - I decided to link it to an existing, longstanding obsession of mine: paradigms and constructs for concurrency.

Warning of what's …

Donald Knuth famously opined:

“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”

I broadly agree. It's incredibly difficult to guess which parts of our code will turn out to be performance bottlenecks, and, conversely, which parts will become development bottlenecks because of the obscurity introduced by manual optimization. Eventually one develops instincts for this sort of thing, though they may be of less general applicability than we think …

Thou whoreson zed! thou unnecessary letter!

- King Lear, 2.2.61

Partial functions are great in theory. By "great in theory", I mean that the basic idea is pretty simple but with very little additional research you can make weighty pronouncements involving the words "in" and "theory", as in, "in category theory, something something surjective algebra manifold."

The simplest example of a partial function is something like the logarithm, which isn't defined for arguments less than or equal to zero. Of course, it's also not defined for arguments that are strings or colors or egg-laying mammals, a restriction we usually …

Synecducers

Great computer languages, like monarchs and planets, become emblems of what surrounds them. The greatest computer languages are barely there, as nearly everything we file under their names could be described as a library or other customization. It's not unusual and not even absurd to find a question about socket() on a C language forum: Linux is arguably a morphogenic implication of C. Clojure, too, is formally minimal, but it induces composition. Much of what we specifically admire about it isn't the language itself so much as an expression of it.

Clojure provides Communicating Sequential Processes (CSP) via the …

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 …

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 …

Marcus Ljungblad is going to give an amazing Scaladays talk about the process of learning Scala, and he put out a call to his fellow hackerschoolers for suggestions. I was glad to chip in, because I enjoy the opportunity to blurt out opinions without the obligation to structure them eloquently, and talking in front of people is scary, so it's awesome to have somebody else do it. Still, I kind of like my suggestions, and with Marcus' permission, I'm going to offer them here. This isn't a getting started guide, and it certainly isn't a tutorial. I'm assuming you …

I totally agree with Paul Chiusano that the Reactive Manifesto not even wrong. In addition to the breezy non-falsifiability of its assertions, I have trouble with the name itself. Manifestos seldom work out well, in the sense of there not being a lot of corpses. (Plus which, "reactive" is acually a word, and a "reactive manifesto" doesn't sound like it would be very proactive, like.)

BUT reactive programming is important, it's useful, and I need to understand it better. Herewith, then, I shall:

1. Very briefly introduce reactive programming as I understand it.
2. Complain that I don't understand why they call …

In another post, I prattled on at some length about the scala Set class. To understand its nuances, it was helpful to print out a graph of class and trait inheritance. Here's a contrived example that's simpler than Set:

trait C1 {}
trait C2 {}
trait D extends C1 with C2 {}
trait E1 extends D {}
trait E2 extends D {}
trait E3 extends C2 {}
trait F extends E1 with E2 with E3 {}

The hierarchy of F looks like:

           C1   C2
             \ / \
              D   \
             / \   \
           E1  E2  E3
             \ /__/
              F

which the proposed utility will display as:

interface F
  interface E1
    interface D
      interface C1
      interface C2 …

Around a year ago, there was a lively debate about the type invariance of the immutable Set in Scala. Dogpile argumentation on a subject far outside the popular interest is of course thrilling in itself, but the topic also provides a nice focal point for exploring and clarifying some important aspects of the Scala type system.

We recall that Scala collections (and other higher kinded classes) can be invariant, covariant or contravariant in their type parameters, corresponding repectively to declarations as class Whatever[A], class Whatever[+A] or class Whatever[-A].

• In the case of covariance, a Whatever[B] will …