Please, reinvent the wheel

You can read this article on my own blog, if you prefer that to medium.

Reinvent the wheel is an idiom which is invalidated by the very metaphor it uses. That’s because the wheel is one of those things that has been successfully reinvented throughout history an unimaginable number of times.

The materials we used for it changed, from countless types of stone and wood to innumerable metal alloys and carbon based substances. The contents and proportions of the wheels have changed.

From somewhat circular, full and broad wheels.

To perfectly circular, thin and hollow ones with hundreds of spokes.

The components a wheel interacts with, such as the tire and the axle, have changes, prompting thousands of wheel re-designs to work with them. The terrain and machinery for which the wheel is used has also changed quite drastically, giving rise to many other reinventions of the wheel.

Indeed, even the basic shape of the wheel is not safe, with variations going from the good old circular wheels to square ones.

The best way to envision the millions of reinventions of the wheel and the progress this has helped achieve, is to think of how it has been used throughout time.

Wheels have gone from curiosities which slightly eased labor, to objects we rely upon for the safe landing of flying fortresses weighting thousands of tons, carrying weapons of mass destruction that could spell an end to civilization if those wheels happened to fail.

Wheels can now be small enough that they are unperceivable to human senses, versatile enough to carry a tank through any type of terrain, strong enough to support train rushing at up to 500km/hr for hours on end and smart enough to usher robots through the unpredictable terrain of other planets.

Props to the guys and gals that invented the first wheels, they did a great job considering the circumstances. But, I’m rather glad that when my cab arrives it won’t be using anything remotely close to those wheels.

Let’s tie this back into programming

I hope the deconstruction of the metaphor has helped spur an idea about how utterly baseless this idiom is when it comes to software. Some of the most widely used and essential pieces of software ever created are reinventions of a wheel.

Linux is a reinvention of Unix, MariaDB is a reinvention of MySQL, MySQL being a reinvention of PostgreSQL/OracleDb.

Modern C++ is a reinvention of C++, which is a reinvention of C (which is a reinvention of B which is a reinvention of BCPL). Rust is a reinvention of modern C++ and C. Clojure is a reinvention of LISP. LISP is a reinvention of IPL and Lambda calculus. Haskell is a reinvention of System FC, which is a reinvention of System F, which is a reinvention of Lambda calculus. DOT is a reinvention of OO, Kotlin is a reinvention of Java.

Vim is a reinvention of Vi. Wayland is a reinvention of Xorg. Systemd is a reinvention of about 500 different piece of software. Ubuntu is a reinvention of Debian. Arch is a reinvention of Gentoo and even the core of OS X is an unfortunate reinvention of BSD.

I could keep going for as much as I like…

Many advances in software are not done by adding to an existing code-base, but by reiterating on it and coming up with something better. That’s why for every popular repository on GitHub there are hundreds of forks. For any use-case imaginable you have dozens of variations of tools to choose from.

Invent your very own wheel, for your very own needs and, who knows, maybe the general public will end up considering it a better wheel.

People are often discouraged from “reinventing the wheel”, despite the fact that most advances in computer science are exactly those related to reinventing the wheel, rather than creating something that is completely new.

Change is incremental, we re-iterate upon an already existing concept and slowly modify it and make it better, until you can’t even fathom how you got from the original to where you are. And the amazing thing is, it costs us nothing but time to do so, that’s the great thing about programming, there’s no resource scarcity, no matter how crazy your reinvention, you can create it.

Instead, what we should focus on, is telling people how and when to reinvent the wheel. I’ve allowed myself to put together a quick list.

Reinvent the wheel when no wheel fits your cart

That is to say, instead of designing an inferior software or product to cope with existing libraries, create the library or tool you need, it’s very likely someone else will need it as well.

This approach can take longer, but it can be fun and it can result in a better product.

Obviously you have a to be a bit flexible and pick your battles, otherwise, you end up being one of those C “programmers” who insists they must write their own lists and vectors or one of the JavaScript “developers” that takes part in the 100,000+ daily downloads of the is_odd library.

Where you draw the line is an open question, with no single answer.

A very good example of this is Julia, a programming language which is very similar to Python in all but three aspect:

• It’s easy to deploy without needing virtual environments.
• It’s much faster for vector operations
• It’s designed with large scale parallelism in mind.

It does what could “theoretically” be done with a combination of virtual environments, Cython, proper usage of C/C++ libraries, some coding guidelines and a bit of patience.

But Julia does these things out of the box and it just kind of works. It ends up saving large amounts of time and making development more enjoyable. It’s probably one of the most amazing languages of the 21st century.

Reinvent the wheel if there have been no recent reinventions

Another reason to reinvent the wheel is that none has tried to do so as of late. This could mean that the current wheel is very good and needs no major improvements, but it often means that there’s a lot of people who would like a better one, they just don’t have the time or will to make it.

It often happens that a problem is “fixed” in an imperfect way, then left to the wayside, since our current technology and mental frameworks can’t find a better solution.

One can often find, looking at these kind of problems a few years down the road, that technology is now up to speed and they can be solved in a much better way.

A great example of this is image recognition, which was thought of as the job for “classic” classifiers. Loads of incremental improvements were done to these classifiers and by 2010 you had pretty good results using stuff like the fisher kernel.

Still far from something you’d use to detect cancerous tumors or drive a car, something that was somewhere between a clever parrot and an elephant in terms of precision, number of labels it could train on and training time.

Up until someone had the idea to adapt the less popular wheel of convolution neural networks to use modern GPUs and improve on some of the models for image recognition initially developed in the 90s.

Out came the famous AlexNet & Co in 2012, which, in a short few years, lead the way to the amazing image recognition technology of today. Nowadays, on medium sized datasets, we can actually outperform humans.

Reinvent the wheel if the wheel is proprietary

This is the case with many great open source projects, things like Linux, GCC and git where just reinventions of already existing software.

However, they were better in certain areas and they were open source, which meant more people used them and contributed to them. Thus making them become exponentially more amazing, quickly becoming the superior choice all around.

Reinvent the wheel if you think it could be fun

There’s nothing wrong with having a take at reinventing a perfectly good wheel either. You may fail, but you will better understand why the current design was chosen and you will probably learn a lot.

After all, many interesting problems are already solved, but solving them again can be very enjoyable. There are millions of people that took a crack at proving the Pythagorean theorem or creating a “new LISP”, most of them, arguably, just ended up reinventing a shittier or similar wheel, but there’s no harm in it as long as they enjoyed themselves.

And on the off chance that your wheel is somewhat better, you’ve just done something to help humanity by doing something you enjoy.

In conclusion

Go out there and reinvent the wheel. Because it could certainly do with some improvements.

Whenever someone tells you that what you are doing is useless, remind them that what you are doing is one of the fundamental processes by which our field progresses.

Whenever you think you are taking a crack at a problem that’s been already solved by better men in better ways. Remember that a 31 years old nerd with little knowledge of astrophysics or math and a few dozen millions of dollars, managed to humiliate NASA, CNSA, the ESA, Roscomos, the US&Russian&Chinese military and many other “prestigious” organizations, with budgets of dozens or hundreds of billions, with dozens of thousands of PHDs and hundreds of thousands of engineers working for them.

By inventing a rocket that is much cheaper, more powerful, safer, simpler, quicker to manufacture and can land within centimeters of precision on a planet.

So maybe, you taking a crack at making a more intuitive & prettier JavaScript plotting library, a faster JITC for Python, a cheaper to manufacture ALU, a better version of shopify or a more memory efficient implementation of a lookup table, isn’t that far-fetched after all.

If you enjoyed this article you may also like:

• Stop future proofing software