Arnold Kling has returned to blogging as of um.. yesterday, looks like. I quit reading EconLog after he quit, so I’m very glad to see he’s blogging again.
While on hiatus he was working on an education/app startup, apropos of which he says
Just as computer programming these days relies a great deal today on shared code libraries, with “reinventing the wheel†an awful sin (and I have a hard time giving up sinning),
and I agree, it’s considered an awful sin. Here’s why I think that belief is shortsighted.
First off, it has to be “the wheel” that you’re reinventing in order for it to be sinful and mockable. Reinventing yourself is a time-honored metaphor; Reinventing the Toilet is a current topic in developing countries. “Reinventing Health Care” sounds laudable. Why harp on about reinventing the wheel?
In programming we generally use “reinventing the wheel” to describe the student or novice practice of writing everything yourself and not taking advantage of previously-written code. But what about when the code you’re supposed to take advantage of is buggy, slow, and dangerous? Then you might find yourself writing your own C++ string class (a classic example derided as “reinventing the wheel”). Happened to me in 2006; I discovered the system’s std::string used a broken, non-thread-safe version of Copy-on-Write that actually was slower than naïve malloc/free. Rather than try to find a better implementation, I coded up just the subset I needed. It took a day, solved the problem we were dealing with, and we moved on. When we got to a system with a non-broken std::string, I retired it (just last month, in fact).
Or what about a learning task? Maybe the best way to learn how to make wheels is to spend some time inventing wheels, building various versions of them. Linus Torvalds reinvented the POSIX-compliant OS in order to teach himself 386 assembly. That turned out pretty well.
Or maybe what you perceive as reinventing the wheel is actually inventing something different. From the perspective of locomotive design, early automobiles looked like an inferior imitation.. but were ultimately a different product. So maybe the programmer next to you isn’t reinventing the wheel, but rather making rocket-powered roller skates.
Of course — it’s a trope because the failure mode is common. I think the worst reinvent-the-wheel story I’ve heard was the E4 team (engineering students) who were trying to build an electronic controller for a laser/cryogen gun using Radio Shack parts: resistors, capacitors, transistors, etc. They didn’t even know about the stockroom — let alone reach for a programmable IC. On the other hand, the members of that team who continued in engineering will probably never forget the experience…
Ever reinvented the wheel? Was it a disaster? The comment box is right there…
I’ve reinvented several wheels. In 1993-4 as a group project in a C programming class we chose to write a standalone hypertext system even though Hypercard was well-known to all of us. (It was a primitive graphical “browser,” ask your parents, kids.) It was a good learning experience, but I can’t recommend it as more than that.
In the real world, I’ve implemented various utility functions, like boost::string::join because Boost was not available on that platform or the management felt the added functionality would not outweigh the overhead of having to build a new library as well as the ongoing dependency risk if the library stopped getting updated. Makes sense to me.
I also checked out Facebook’s open source std::string replacement, that was a piece of work. As I recall, it had three different regimes, with different behavior for up to 32 bytes (all allocation performed at initialization), up to 256 bytes (allocated from a freelist), and larger strings got copy-on-write. Again, makes sense to me if memory is at a premium but you also want fast small strings. https://github.com/facebook/folly/blob/master/folly/docs/FBString.md
For me, one warning sign is the thinking along the lines of “This is too complicated. I’ll just re-invent it without all the extra cruft.” Most of the time, that “extra cruft” was important. Now, if someone can explain what all the “extra cruft” is, why it was added, and why it isn’t needed anymore, the chance of success goes way up.
The example I always think of involves network protocols. “TCP is too complicated. We’ll just implement basic reliability over UDP.” Eventually, problems were encountered with inadequate window scaling, MTU discovery, and a few other issues.
@Walt – yeah, we had in-object string allocation and a freelist of pre-sized blocks for anything >64 bytes. Nice to see that I’m not the only crazy one.
@James Or “let’s use UDP to get around traffic limitations on TCP”. Or “multicast is hard, let’s just broadcast all updates” aka how Doom got banned from the dorm networks and Ted Lilley schooled id Software’s developers.