Reinventing the wheel: an example of not doing so

posted: November 23, 2019

tl;dr: A prime example of how not reinventing the wheel can pay off big...

Often new computer languages arise from the following situation: a team is developing a new system, either pure software or software + hardware. The team needs to provide some way, either for themselves or their customers, to program the new system. The team members take a cursory look at existing languages but decide that their system is especially unique. Or they want complete control of the language for business reasons. So they invent their own language. Given this logic and the passage of time, a website has been able to collect examples of "hello, world" in more than 500 different languages.

But it doesn’t always need to be this way, as the example I’ll describe here demonstrates. I can’t take any credit for the design decisions made at the time, as they were made by individuals at a company acquired in 2013 by the company I was working for at the time, Westell Technologies. The acquired company was Kentrox, formerly known as Applied Innovation. (Note: how it came to be named Kentrox, which was the name of a company I had worked at years ago on the other side of the country, is a story for a future blog post.)

Kentrox, or Applied Innovation, was in a marketspace which today might be called “industrial Internet of Things”, as contrasted with consumer Internet of Things. Their system had two primary components: probe devices which contained sensors and also hooked up to other external sensors utilizing a variety of protocols; and a centralized management software system, which would receive real-time data from the (typically) hundreds or thousands of probes, collect it, store it, and display it to human operators via visualizations and alerts.

The probes were basically small computers running an embedded variant of Linux. Because the probes could be hooked up to a wide variety of external sensors, there was a need to allow customers to run some code on the probes that would interface to whatever sensors the customer wanted to use.

A Kentrox probe doesn't look like much on the outside, but on the inside it runs Python

The programs, or scripts, which would be written by customers, weren’t expected to be terribly sophisticated: just initialize the sensors, read some data on occasion, format it, and communicate with the centralized management software. The team could have decided to implement their own fairly simple scripting language. Instead, the team decided to use Python.

It was, especially in retrospect, a brilliant choice. I don’t know exactly when the decision to use Python was made, but it had to have been sometime earlier than 2013. Python wasn’t nearly as popular a language then as it is now. Nowadays there are many software developers who know enough Python to immediately begin programming a Kentrox probe, which shortens the learning curve.

From a purely technical perspective, Python offered many other benefits. It already was a rich, robust, field-proven language, with a simple syntax, so it saved all the work of inventing a new scripting language. All the Kentrox folks had to do was write an API that interfaced with the rest of the probe hardware and the centralized management system. Python has advanced features that probably wouldn’t ever be used in the script written for the Kentrox probe, such as metaclasses, but those features were available if someone were crazy enough to use them. Python remains under active development today, meaning that new features continue to be added to the language long after Kentrox adopted it. Kentrox could bring in the new features just by upgrading the Python interpreter.

Python is arguably the open source language that is the most independent of any and all other corporations, meaning that other corporation(s) could not in the future steer the language in a direction detrimental to Kentrox. Python is interpreted, eliminating the need for a compilation step. The Python interpreter is written in C and runs under Linux, which made it very easy to get Python up-and-running inside the Kentrox probe. Python runs on many other platforms and has lots of support from other developer tools such as editors, providing a rich development environment.

It was a smart decision for Kentrox not to invent a new scripting language, and I had nothing to do with making it. I was instead part of the team that made the decision to acquire Kentrox, although Python was not at all a factor in that decision. Instead, Kentrox’s use of Python was one of the reasons that I thought that it would be a good idea to start learning some Python. It’s better to adopt great off-the-shelf technologies wherever possible, rather than reinventing the wheel.