Archive for June, 2016

Dynamic typing in the long run

There’s a lot written around static vs dynamic types. More and more, I’ve tended to favor static typing; I like compile-time checks and static analysis, I like the strong contracts established between caller and callee, I like the readability of knowing what a function expects and returns from looking at its signature, and I like the refactoring capabilities that IDEs can bring forward from being able to trace references at compile-time. Even with my bias, I’ve never worked on a codebase that’s lived for 10 years, and I found The Long-Term Problem With Dynamically Typed Languages to be an interesting perspective.

Unit testing to prove correctness:

…relying on a giant test suite and test infrastructure to prove the correctness of renaming a function or adding a parameter, in practice, is a significant coefficient of friction on the software’s ability to evolve over time.

Broken windows:

Not improving core APIs results in a kind of broken windows effect. When APIs are confusing or vague, people tend not to notice other confusing or vague APIs, and it slows everyone down in the long term.

Thus, instead of easily refactoring the legacy APIs, people think “I’ll just make a new one and migrate the code over!” And now you have two hard-to-change APIs. And then three. And the cycle continues. Additionally, this cycle is fed by architect types who know or think they know a better way to do things, but can’t be bothered to update the old systems.

Cost of change:

…a type system flattens the cost of change curve. Small API or performance improvements that otherwise wouldn’t be worth it suddenly are, because the compiler can quickly tell you all the places that need to be updated.

Data flow and mental understanding

…the most important component of understanding software is grasping data flow. Programs exist to transform data, and understanding how that’s done is paramount. Types accelerate the process of building a mental understanding of the program, especially when lightweight types such as CustomerId (vs. Int) are used.

Cost of change is interesting, as the flexibility of dynamically-typed languages is usually viewed as beneficial and yielding shorter development times.


I wrote a little desktop application to capture short videos and turn them into GIFs. I call it Reel. It’s still rough around the edges but you can grab an early version of it below.

Reel 0.1 (Windows Install)

I’ll have a Linux/Ubuntu version soon. Maybe an OS X version… I have to jump through a few extra hoops here as Apple still refuses to allow OS X to be virtualized.

Reel - Drinking Bird

Aside from its utility, this was also an experiment piecing together some technologies I’ve written about here before: XUL + XPCOM + SocketBridge, video capture using web tech and, in general, using web technologies for desktop applications.

Relative paths in Desktop Entry files

I was playing around a bit with Desktop Entry files which provide a nice facade for hiding the execution details of a desktop application. However, a somewhat odd limitation is that relative paths are not supported. At least for the Exec key, I found a nice solution which makes use of bash and the %k field code allowed for the Exec value.

[Desktop Entry] Version=1.0 Name=Run Comment=Runner Test Application Exec=bash -c 'cd $(dirname %k) && ./runner-linux-x86_64/dist/bin/run --app application.ini' Path= Icon=/usr/share/icons/hicolor/scalable/status/application-running.svg Terminal=false Type=Application Categories=Utility;Application;Development;

The code above presumes that the application to run is at runner-linux-x86_64/dist/bin/run, relative to the location of the .desktop file.