Thoughts on Whatnot
A blog about .
Introducing WDTE
This last semester, I took a class on compiler design. Towards the end of the semester, I suddenly realized that something I’d been mildly interested in working on for a while was in fact quite a bit easier than I had originally expected: Writing my own scripting language. I began work on it and had a working prototype in just a week or two. I worked on it pretty much non-stop for a bit, and I had originally intended to write this introduction back a few months ago, but some stuff came up and I was busy and… Either way, here it is.
The Problem with Interfaces
In a recent talk, Russ Cox asked Go developers to write about problems they’ve run into with Go in an attempt to help steer the design process for Go 2. In this post, I would like to attempt to do so by explaining some of the issues I have with Go’s interfaces. To start with, I think it’s best if I explain the problem I think that Go’s interfaces solve before explaining where I think they fail.
I would like to take this opportunity to announce Signage. I recently (Yesterday, actually.) stumbled accross the White House’s signed legislation list. I thought it was neat, but I was quite disappointed to find that it doesn’t seem to have an RSS feed. So I wrote one. Signage is in two parts: A package that provides a very simple API for fetching and scraping the lists of legislation from the whitehouse.
Composition vs. Inheritance
There’s a situation that, while it doesn’t happen too commonly, annoys me when it does happen. Someone comes to Reddit, or golang-nuts, or somewhere else, and asks about the often repeated refrain about composition vs. inheritance. Sometimes, they get the right answer. Sometimes, someone makes some out-of-nowhere remark about embedding. The problem is that embedding is not in and of itself composition. It can be used in composition, but composition is not a syntactic or behavioral choice in the language; it’s a design pattern.
Go Plugins
The release of Go 1.8 inches steadily closer, bringing with it many interesting and useful features and improvements, including shorter compilation times, an even faster GC, and, my personal favorite, initial support for plugins. Plugins, essentially Go’s version of C’s dlopen() and related functions, are an interesting one. The ability to dynamically load packages at run-time has been one of my most wanted features in Go since I first figured out how interfaces work.
A Quick Rant about MonoDevelop

So, for the last couple of months I’ve been working on a project for school which has required me to use MonoDevelop. I first used MonoDevelop around 9 or 10 years ago or so when I was using C# fairly regularly. Back then, I remember MonoDevelop being a fairly competent, if somewhat limited feature-wise, Linux and GTK# alternative to Visual Studio Express and Windows.Forms, so I wasn’t particularly worried about using it for this project, despite not having used it in a while.

Apparently, I should have been.

Redefining Go Templates
In Go 1.6, a new template action was introduced in the text/template package that allows for both defining and executing a template at the same time. This action, block, seems at first to be somewhat pointless. Even the docs describe it as simply being shorthand for defining and then immediately executing a template, and what’s the point of that? Why would you want to execute an inline template immediately after defining it?