Monomorphic

After 13 months and 51 posts, my experiments in blogging continue, although they are perhaps better described as polymorphic than monomorphic. Maybe it’s time for some reflections.

On the whole blogging in this format and at this frequency has been a pretty fun and fulfilling process. I get to practice writing free-form, nonscientific texts, and even if many of them might not be read by so many people, the idea that they might be turns it into a useful exercise.

Recently Flattr buttons were added to this blog, which allows users who use the service to donate money and show appreciation for my texts (some such people indeed exist – thanks a lot, all two of you!). Initially I had a single button for the entire blog, but now I am trying out a format where I have one button per post.

I’ve noticed, on this blog and elsewhere, that I can’t quite decide if I should write with British or American English. I feel culturally uncertain as a writer of this language. But recently I’ve come to think that I should embrace my European background, so more of the British variety in the future is a likely prospect.

Topics have been varied. The tag and category systems have been used in an attempt to bring some order to the table, but they’ve become too chaotic to be useful. A restructuring is perhaps in order during the next 13 months.

One of the most popular topics I’ve written about has been the Scala language. People tend to google Scala a lot, and it’s actually really uplifting to see the interest in it (since I hold it to be a way forward). If you are a blogger who wants to get a billion page views, write about Scala. I don’t want to consciously pander to the readers too much, so in itself it is not a reason for me to write about the topic. I will write about Scala when I want to say something about it. (A difficult principle to really practice.)

I’ve tried out some different WordPress themes occasionally, but so far I haven’t found anything I like better than this “Infinimum” theme. It feels very clean, functional and modern.

That will be enough of the reflections for now.

In research and academia, one of the fundamental activities is the invention and subsequent examination of new concepts. For concepts, we need names.

One way of making a name is stringing words together until the meaning is sufficiently specific. E.g. “morphism averse co-dependent functor substitutions in virtual machine transmigration systems”. Thus the abstruse academic research paper title is born.

Sciences sometimes give new meanings to existing words. This could be called overloading, following the example of object-oriented programming. E.g. a “group” in mathematics is something different from the everyday use of the term. A “buffer” in chemistry is something different from a software or hardware buffer, even though a fragment of similarity is there. And so on. This overloading of words gives newcomers to the field a handle on what is meant, but full understanding is still impossible without understanding the actual definitions being employed.

Sometimes new terms can be created using inventors’ names and everyday words. E.g. a “Lie group” or the “Maxwell equations”, or “Curry-Howard correspondence”. This is potentially useful, but perhaps not something you can do freely with your own research without seeming like you’re trying to inflate your ego excessively. (Even though researchers love inflating their egos, nobody wants to admit it.)

There’s a similar problem in software development. When we invent names of functions, classes and variables, the lack of words becomes very clear. Intuitively, what is an “adapter registry”? An “observer list”? Or an “observer list mediation adapter?” My feeling is that we often end up compounding abstract words because we have no better choice. And here lies a clue to some of the apparent impermeability of difficult source code. We need better ways of making names. We’re inventing ideas faster than our language can stretch.