This is a weblog about computing, culture et cetera, by Miikka Koskinen. Read more.
Clojure people sometimes talk about hybrid maps. What are they talking about?
A map, in general, is a data structure that associates keys with values. There are two common usage patterns for maps in Clojure:
- As records. The map acts as a collection of fields with predefined keys. For example, a row in a relational database is a record. When you query the database, you know what columns the result will have. Typically in Clojure, you get a map or a collection of maps as a result of database query.
- As indices. The map acts as a collection of objects indexed by something. For example, you could represent a database table as a Clojure map of rows indexed by the primary key of each row.
See LispCast for a more extensive discussion of these patterns.
A hybrid map is a map that acts as a record and as an index at the same time. This pattern is not common – usually it’s better to have the index map as a field in the record. One case where it works nicely is the Clojure map destructuring syntax:
(let [{var1 :key1 var2 :key2 :keys [key3] :as result}
(some-function-call ...)]
...)
Here :keys and :as work like record fields, but the bindings for var1 and var2 work like an index.
What about heterogenous maps?
A map is heterogenous if it can contain keys and/or values of multiple types. If a map is not heterogenous, it’s homogenous. Here are some examples:
{:a 1 :b 2} ; homogenous
{:a 1 :b "hello"} ; heterogenous values
{:a 1 "b" 2} ; heterogenous keys
{:a 1 "b" "hello"} ; heterogenous keys and values
{} ; could be either!
This concept is not discussed much in the Clojure community, because Clojure maps are heterogenous by default. An example of less-heterogenous map in Clojure is data.int-map, where the keys must be integers. The values can still be anything, though.
The concept of heterogenous maps, and of heterogenous collections in general, is more interesting in statically typed languages like Scala and Haskell. Expressing the type of a homogenous map is straightforward, but typing a heterogenous map is more complex. This is can be seen in how there are separate libraries for heterogenous collections, like the popular shapeless library for Scala.
What’s the relationship between hybrid maps and heterogenous maps? There’s no relationship, really. Like records, hybrid maps often are heterogenous, but there’s no reason for why you couldn’t use a homogenous map for a hybrid purpose.
ZuriHac, the Haskell hackathon in/near Zürich, took place this weekend and it was again great!
These days hackathon usually means a prototyping competition. ZuriHac is a hackathon in a different sense. There’s no competition. Instead, people come there to collaborate, to learn, and to have fun together. Together we worked on open-source projects, taught each other Haskell, and had good time drinking beer by the lake.
There were some talks, too. The keynotes were given by seasoned Haskellers, but my favorite was the talk given by Mario Meili and Cyrill Schenkel. Mario and Cyrill are students in HSR Hochschule für Technik Rapperswil, where the event took place. They presented their work-in-progress master’s theses.
Mario’s part turned out to be a quite provocative conversation opener. His thesis is about what prevents the wider adoption of Haskell in the industry. He had gathered often-presented concerns about Haskell like its poor performance. The listeners were quick to shoot these claims down, but Mario does have a point – people really do believe these things about Haskell.
My take is that Haskell’s lack of industrial success is not about its drawbacks. The lack of compelling benefits is the actual problem. It’s hard to make a concrete case for Haskell.
While on the plane back home, I read this article about the rOpenSci’s Unconference. Sean Kross describes the Unconf like this:
Some have described it as a hackathon, but I think that’s a mischaracterization. Though a great deal of code is written in a short period of time, a substantial proportion of the attendees make large and important contributions while hardly writing any code. The Unconf is not a competition, and it’s intensely social and collaborative.
Sounds like Unconf’s spirit is similar to ZuriHac’s spirit! This is a great event format for programming communities – it’s more social and more collaborative than the usual conferences. After all, everybody seems to agree that the social part is the best part of conferences.
A couple of years ago I wrote about how I hoped that writing good commit messages is worthwhile. It never paid off.
Turns out it’s never my commit messages I’m reading. It’s my coworkers’ messages, or open-source contributors’ messages. It’s not enough that you write good messages, you need to foster a culture of good commit messages in all the projects you work with.
Even people who write good commit messages most of the time sometimes create commits with messages like “make it work” or “WIP” or “blargh”. For some reason it’s always these commits that contain the mysterious bugs or the unclear code.
Even if you do write good commit messages, if you use GitHub, it’s likely that nobody reads the messages. GitHub’s user interface isn’t designed for reading commit messages. When you do a pull request, the commit titles are in small font and the bodies are hidden. If you use GitHub, it’s better to spend time on writing good pull request messages. They do get read.
For more posts, see archive.
