Rants from the Ballmer Peak

Kerf timestamps done almost right: conclusions

After implementing Kerf's timestamps in several programming languages we should take a look again at Scott's original Kerf article and review its final lessons for future language authors:

META NAVIGATION START This is a really long article (Look at my horse!) which has been split in different chapters because it is (My horse is amazing!) unsuitable for today's average attention span and lets me maximize (It tastes like raisins!) page ads. META NAVIGATION END

a new type? Nim C++ Swift WTF… Java? conclusions You are here!

Scott's lessons for future language authors

1. If you query from a database, that type needs to be propagated through to the language as a first class type. If this isn't possible to do directly, there should be some way of quickly translating between classes in the DB and classes that doesn't involve parsing a string representation.

And you know what? I agree! The implementation in the different languages is as optimal as it can get to Kerf's timestamp, since internally it is handled just like in Kerf, as a simple 64bit value storing elapsed nanoseconds since the Epoch. If you programming language doesn't support propagating integers as a first class type, you are out of luck from the beginning. I don't think many new future language authors would want to make the decision of not supporting plain integer values.

2. timestamps should be a first class type in your programming language. Not an add on type as in R or Python or Java.

I disagree on this one. The implementation of our custom timestamp in Nim, C++ and Swift has shown that it is not necessary to bake timestamps as a language feature, it is enough to have a language which allows extension by programmers.

But then, Scott makes a jab at Python or Java, which are known for being terrible languages in terms of performance (no idea about R, sorry). Yes, you can find specific performant Java code which has been optimized for benchmarks or you can use JNI to call native C libraries. And you can find Python code which runs C underneath for speed, but that's essentially accepting that the language generally sucks and you always need to externalize the performance critical paths of your program.

3. timestamps should have performant and intuitive ways of accessing implied fields

Every time the word intuitive is used in the context of programming, which is one of the most alien tasks known to humanity, along with maths or statistics, a programmer is forced to write Java code. Run, fools, run if you hear this word, for somebody is trying to sell you a bridge! Accessing implied fields is a matter of taste, and it can be done anyway. Remember when I added the len variable to the String type in Swift just because I'm worth it? If I had a date library or type which didn't do what I wanted I could extend it myself without problems.

There is no performant type for anything, because performance is context sensitive. For some tasks Kerf's timestamp will be the most performant solution. For others it will fail miserably. This is Scott's faulty generalization, trying to apply the lessons from Kerf's niche audience to general language programmers.

4. it would be nice if it handles nanoseconds gracefully, even though it is hard to measure nanoseconds.

That's OK, I like nice things too. Again, not a problem unless you are dealing with a terrible terrible programming language.

Implementation summary

I'm glad I decided to start writing these articles. They didn't really take a lot of time to implement and I found some interesting things in the process, but since I have other priorities in life it simply dragged for weeks. In fact I believe that writing the articles explaining the implementations took me more time that the implementations themselves, but I never bothered to check, shame on me. As usual implementing stuff in Nim is a pleasure. C++ was surprising as well, the syntax sucks but it could deal with the problem like a champ. Swift was a mixed bag, but I'll let it slide due to its compiler being relatively very new. Java, LOL, nice try. Here is a summary table with the score I give to each implementation for its final fidelity to Kerf's timestamp type:

Language	Fidelity	LOCs	Pleasure to use	Extra notes
Nim	95%	411	100%	The only thing that keeps Nim from being 100% exact to Kerf is that there is no custom syntax to match, and the differences are minor in any case.
C++	75%	654	70%	Overloading the STL is icky, and the syntax is complex and sometimes obscure. Fortunately the full functionality of the type can be reproduced, but I fear that testing more cases than the ones presented in these articles could be problematic. C++ compiler errors are well known for their unfriendliness towards beginners.
Swift	65%	443	50%	The fidelity should be higher than C++ once the bugs about complex expressions are ironed out and more compact operators can be used. Right now the biggest drawback of this language is the extremely slow compiler.
Java	10%	571	-42%	Don't worry Java, you will always be special.

In case you don't like tables for some reason here is a graphical representation of the table above in a single picture:

Lessons for future blog article writers

1. Try to avoid writing sweeping generalizations. You'll always find somebody annoyed enough to contradict you with little details that don't matter for the point that you are trying to make (making your stuff attractive for people to buy it).
2. If you use anecdotes to illustrate your case try to not base the article on them, anecdotes tend to be flimsy when scrutinized. Prefer source code comparisons which also serve to bore your readers to death and thus prevent any complaints about factual errors or mistakes in your logic (dead readers don't complain).
3. Beware of programming language discussions, they are a religious topic. Tread carefully to avoid stepping on landmines. If you can't resist comparing languages, at least try to compare yourself to equivalent languages who can stand their own in a fight. Comparing yourself to lesser languages doesn't have merit, it would be like claiming you are the fastest runner on earth and showcase this comparing yourself to a Korean pop idol.
4. Put random unrelated pictures or GIFs to spice your endless walls of text. Readers are still humans, you know? They'll appreciate the distraction and will hopefully have something to laugh about other than your sad article.