The Dogecoin Foundation recently celebrated the release of libdogecoin v.0.1.0. This is a standalone library that gathers (right now some of) the core intelligence of Dogecoin in one single, small, self-contained, documented, tested, and easy-to-use package.
This is interesting and exciting and important for lots of reasons. Let’s start with the obvious ones.
Parlez-Vous ABI?
I’ve written before how translations into spoken and written languages are so important, but I haven’t emphasized how the same goes for programming languages.
I personally really like the Perl programming language, though for Dogecoin I write a lot of C++ and Python. In my professional life, in the past year, I’ve written Perl, Python, Go, Haskell, Elm, pl/pgsql, shell, Bazel, Typed Scheme, a little language we invented ourselves, Java, and I’m sure I’ve forgotten something. IfDogeThenWow even has vanilla JavaScript running.
It’s rare that any developer can get by running only one language, and it’s especially rare that any developer deploys code only to a single place.
I have projects I’d like to run in the cloud and other projects I want to run on my desktop and others running on a Raspberry PI in a rugged enclosure up in the attic or the corner of my tool shop somewhere. Some machines have essentially unlimited storage and others are running off an SD Card.
I can’t count on the same thing running the same way everywhere; I want the flexibility of Perl when I’m prototyping something or gluing things together where my productivity is paramount. I want the predictability of C or C++ or Golang when I want to throw a single binary somewhere. I am content with Python when I need to collaborate with a bunch of other programmers at various skill levels. The list goes on and on.
One thing all of those languages has in common is that they can all communicate with native libraries that understand the platform ABI. You don’t have to know what that means other than “this is what you get when you compile a C program for the platform”. That goes for Linux, Windows, MacOS, the BSDs, and a host of other operating systems you’re likely to encounter.
If you want to write something that can be available on just about any platform and if you want it to be useful from just about any language on those platforms, C is a good choice. (You can do this in Rust or C++ as well, if you use a mechanism to provide a C ABI. All of those are fine choices.)
This is a long-winded way of saying “libdogecoin is written in C” and “this
enables a lot of interesting uses”.
Reason one then, is: libdogecoin can and will run on a lot of platforms. It’s
not like the Dogecoin Core, which works well on servers and desktops but
requires a lot of network and storage.
The Sapient Worf Hypothesis
I wrote earlier that I’ve used a lot of programming languages lately. If I wanted to, say, generate and validate Dogecoin public and private keys from Perl, I could create a pull request against a pure-Perl library which generates keys with the right algorithm. That’s not too much effort if someone’s already done the hard work of implementing the algorithm and putting a nice API around it.
If I wanted to do the same thing from Python, Elm, and Golang, I’d have to reimplement the algorithm in each one of those languages. (I actually ported an algorithm for generating Merkle-ish UUIDs from Go to Python a few months back and it was… memorable.)
Now I don’t have to do that.
In fact, I read the documentation for generating keypairs with libdogecoin, and reimplemented the Python example code in a few minutes, and had a working Perl version.
I know how the algorithm works and I could implement it myself, but not in the ten minutes it took (and that’s including the time to connect Perl to the library).
It’s possible to extract the code from Dogecoin Core, whether by copying and pasting or creating a library or reimplementing. I have the skills to do that, but it’s less work to reimplement. Now it’s less work to re-use.
I believe very few things in technology are magical, but this felt like a good trick.
Reason two then, is: libdogecoin means sharing code, not just ideas, in ways
that make reuse and repurposing easy.
Just What I Choose It To Mean
One of the character flaws longtime Perl users like me suffer from is that we sometimes believe the implementation is the specification. (I may have tried to argue, good-naturedly, with Patrick Walton on Twitter the other day about a Perl feature we don’t agree exists.)
There’s the hand-wavy description about what’s happening, and then there’s the code that actually runs, and you’d better believe the latter has more details than the former, even if you have to run a bunch of test cases and black-box experiments against the latter if you’re going to discover what’s actually going on.
It would be better if everything were written down in sufficient detail that an interested person could write their own code that conforms to the specification and interoperates with other code that also conforms to the specification. That makes a healthier ecosystem: more eggs in more baskets, fewer points of failure, more effort to define that specification, et cetera.
The same thing is happening here.
By consolidating the desirable Dogecoin network behavior (keys, transactions, etc) in one little free library (not the kind you find on street corners, but adorable and lovable all the same), the Dogecoin Foundation is creating a specification for what Dogecoin is and should be.
It’s creating code that you can read and run and use to demonstrate how that specification works in practice.
It’s creating documentation about how to use that code.
I mentioned the documentation earlier, when explaining how easy the Perl port of the Python bindings are. This documentation is really good. It’ll make the next port easier, and the next, and the next.
This documentation is really, really good, especially for the first release of a library.
Reason three then, is: the Dogecoin Foundation has executable code and documentation to point to when describing what Dogecoin is, technically. It’s easier for everyone to agree on what that is, how it works, and what it means now.
Bundled Up All Cozy
What happens next?
I’ll keep working on my Perl bindings, unless someone beats me to it. Shafil Alam has Dart bindings. I think I’ve seen JavaScript and PHP mentioned.
The core library ships with Golang and Python bindings. Using this code from Rust or C++ is trivial.
The code runs on Linux and other Unixes, MacOS, and Windows.
It should be architecture independent, so running on 32-bit machines or ARM machines should be straightforward.
This should run on iPhones and Android phones and tablets and satellites and embedded boxes and all sorts of places we haven’t though of it.
Even though this is only a v0.1.0 release, there’s a lot going on, and this unlocks a lot.
I’m enthusiastic to see where it goes, and hopefully you have at least three reasons to be excited too.
