Names and the little details of an API matter. I’m going to pick on one small example I came across recently. In unagi-chan, a very fast lock-free queue implementation, we have the following API:
There are lots of things that could be improved about the world, and many things to be unhappy about. You’ve probably got a long list of such things, like everyone else. Now, what are you going to do about them? No, really, what are you going to actually do?
FS2: Functional Streams for Scala is nearing the 0.9 release finally, and the first 0.9 milestone release came out this week!
Technologists like to think about tools from the persepective of technical merits (“Lisp is better than C—it can do XYZ and C can’t!”). Lots of arguments take place at this level. Here, I want to consider another perspective. Let’s think of new technology like we would a new species entering an ecosystem. From this perspective, what matters is whether the species has attributes that allow it to survive and propagate itself. For new “technology species”, surviving means attracting and retaining development resources (people, money, time, etc), and propagating means increasing adoption.
Very often when functional programming we specify the types first. Then once that’s done, we implement the term. Writing some tricky code? First, write out the type! By announcing (some) aspect of our intent to the compiler, we get an “accountability partner” that will verify we’ve remained true to our declared intent. That’s one part of it. But as Conor McBride likes to emphasize, types aren’t just about policing errors or checking: