Átila on Code

Emacs is my editor of choice, I use it to write nearly everything. I have to write Python at work, which I’m ok with since I’m generally a fan of the language. For that I use ropemacs, (with jedi, flycheck and flake8) which makes it possible to use the rope refactoring library from Emacs. Mostly I use it for “go to definition” but its refactoring features are obviously also super useful.

Now, I like new and shiny tech. I run Arch Linux for a reason. I jumped on the C++11 and C++14 bandwagons as soon as I heard about them. So in the Python version debate, if I have a choice I’d go with Python 3 which has been the default on Arch for a while now anyway.

Imagine my dismay when nothing worked anymore in Python 3. My awesome editing environment gone. Rope has a Python 3 version, but ropemacs and ropemode (which ropemacs depends on) don’t. Sadness.

But wait, open source to the rescue! I forked both ropemode and ropemacs and after some porting and much debugging got to something that works: ropemacs_py3k. Enjoy! I know I will.

My favourite language is now, by far, D. It’s not just not even close. I’ve also been known
to make my opinion on Go be publicly known as “I really don’t like it.”. My work buddy Jeff
is nuts over Go though, and I try not to hold it against him. We keep arguing for “our”
language and disparaging the other guy’s, and it’s all in good fun.

As part of that banter, he sent me a blog post link on Google Plus about flaky tests and what they
tell you about your code. It’s a good read, and exemplifies some of the real-world
engineering problems that happen when developing software. As I read it though, my eyes
roll a bit when I encounter this bit of code:

var Timeout time.Duration
Timeout = time.Duration(conf("timeout", 100)) * time.Millisecond

cache := memcache.New(Servers...)
cache.Timeout = Timeout * time.Millisecond

The first thing I didn’t like about it is that the multiplication by
time.Millisecond looks like C. It’s not that different from
multiplying by a preprocessor macro, with all that entails. Don’t we
know better now? std::chrono from C++ is ugly, but it’s still better
than this.

Related to the C-ness of it, and much more importantly, the second time the code
multiplies by time.Millisecond is the cause of the bug the blog post is about.
And immediately I think: that shouldn’t compile. Maybe it’s my physicist background,
but multiplying time by a time unit shouldn’t work. Or at least you shouldn’t be
able to pass that value to a function expecting a time unit (instead of time squared).

I immediately wrote some D code to make sure I didn’t embarass myself by stating
that in D that would be a compilation error, and to my joy the following code
didn’t compile:

import std.datetime;

void main() {
    auto time = 2.seconds;
    auto oops = time * 3.seconds;
}

foo.d(5): Error: 'time' is not of arithmetic type, it is a Duration
foo.d(5): Error: 'dur(3L)' is not of arithmetic type, it is a Duration

Multiplying time by a scalar works as expected, though, which is what should happen. I showed him the code and he seemed really interested in it, and also wondered
which design decisions led to the current state of affairs. According to him the Go
team likes type-safety, so it seems odd. He also asked me if it would be a compilation
error in Haskell, to which the answer was obviously, in Barney Stinson style, “please!”.

I have to admit letting out a rather childish “sucks to be you” at Jeff today in
the office and basking in my elevated sense of self-worth and computer language choice.

Go D! Pun half-intended.