I’m migrating my research blogging over to my new domain and consequently this blog won’t be used any more. It’s served me well and I’ll leave it be for posterity.


I’ve also been given thought to the future of programming languages. In my humble opinion, the future programming language will deftly handle two upcoming issues: parallelism and weak references. Unfortunately these are also two issues which are not at all handled by my language.

Parallelism probably isn’t an “upcoming” issue so much as something we’re dealing with right now, but still it’s still not being handled by current languages, so i’ll consider it upcoming anyway. Haskell is, to my knowledge, the only language which is trying to attack parallelism in an interesting way. It provides primitive language constructs which are easy to glue together, hides away the implementation details, and, being Haskell, gives you a lot of nice static guarantees. For example, in Haskell’s STM, it’s impossible to reach deadlock. Sadly it is not very efficient, but it’s nice to see it being thought about. Maybe some day soon someone smart will make it practical.

Weak references are things which every modern language handles and handles extremely poorly. Functional languages are ideally set up to handle weak references intelligently, because in principle they don’t make any distinction between data and code, but they don’t do much with them right now. My dream operating system is basically built entirely around the idea of weak references. Why is it that operating systems can cache data, but they can’t cache the execution of a process?

Time Machine is a nice first step at the operating system. For those who’ve used it, I’m sure they might agree with me that it’s more than just a snapshot back-up system with a pretty 3D interface. It is, in my mind, weak references for the file system, which is exactly what I’ve wanted from a filesystem for so long. Basically it allows you a way to mark files as “I need this to stay in memory” versus “it would be nice if you could keep this in memory”, i.e., a weak reference. Since switching to Time Machine, I handle everything on my system very differently. In my address book, my emails, my bookmarks, my list of papers to read, etc. etc. I am constantly distinguishing between “must keep” versus “would be nice if it stuck around”. With Time Machine you distinguish between the two cases by deleting or not deleting something, knowing that once you delete something it’ll probably hang around for a few years still as a weak reference.

So at the programming language level, functional languages are in a nice position to handle weak references. In Haskell, for example, you can create a weak object by handing it the code to create it. Once that code is executed, the resulting data hangs around as a weak object until such time memory needs to be reclaimed. If you decide later on that you needed that data again, no problem, just re-execute the code! The problem is that there is a lot of strategy involved in deciding which weak references to throw out and which to keep.

At this point, no matter what language you use, it seems it’s up to you to keep track of your weak references manually. It reminds me of the days when you managed your memory manually: it worked fantastically as long as your code wasn’t complex, ha!

Dot 1: my supervisors are going away.
Dot 2: I’m in the first year of my Ph.D.
Dot 3: Piled Higher and Deeper is very wise:

I knew there was a reason I took dancing lessons.

Welcome to my new blog. Things you will not find on this blog:

  1. kittens
  2. Jasna

Things which you might find on this blog:

  1. tech writings
  2. opinion rantings

That’s about it :)