elega Elega Corporation

C++ And The Fight To Save Close-To-Hardware Coding




When I began my career in software development, it was like many today: figuratively born into a world of interpreted languages like Python, frameworks like Microsoft .NET, and in which JavaScript is the language of the web. Long before any of the common realities we know today, there was the primary concern of knowing exactly how to provide instructions to specific hardware. Well, we have all seen the direction. Languages run a bit slower but they pack more of a punch for business in the form of shorter development timelines. A great example of this is Python with its bracketless syntax and wide community support. But the normal CPython runtime that executes the code is considerably slower than compiled code.

As it happens, the simple contrast between compiled speed versus interpreted speed is illustrative of the power that still lies in compiled languages. When you optimize C and C++, there is little else as powerful. It remains highly popular for game development, VR experiences, embedded systems, and demanding real-time trading applications (to name just a small list). In my own personal interest, I am a late millennial fascinated by the pre-internet computing technology. It is enthralling as a software developer to see amazing things happen with hardware that is not very powerful by modern standards. I cannot help but feel, at least at some emotional level when looking at the accomplishments of retro tech, that perhaps we have gone the wrong direction when developing these higher and higher levels of abstraction. Compiled, optimized C is still incredibly powerful on even a Raspberry Pi.

Understanding this perspective, I do not intend to mean that we should go backward in time or anything like that. It makes sense to continue moving forward in terms of hardware power and having the kinds of development tools that we are all now comfortable with today. What I am suggesting, though, is that we need to renew our respect for the hardware, for efficiency, and for performance. Performance is suffering and many do not notice, nor care. We are all dealing with tradeoffs when we enter software development: we do not want to grow old working on a tiny sliver of functionality just to see that it runs within a few milliseconds as opposed to several hundred. But if you had asked thousands of developers back in the 1980s or 1990s where they thought things would go with the kind of hardware power we have today: they would not have said, not much of anywhere different.

The operating system landscape is still about the same: Microsoft continues to lug out updates that consist of several gigabytes in size. As CPUs get faster developers adopt user interface libraries that look pretty but run about as fast as paint dries. People became accustomed to websites loading within a couple seconds& during the dial-up era. Today, the standard is the same. We have machines that outperform their predecessors in terms of the computational power by more than 30x. Yet, its fine if we take the same amount of time to click through a menu, or load a page, or look at a picture, or whatever. Again, decades ago: the expectation would be that everything would be yours in an instant. The one thing that would have been a bizarre prediction is that in so many ways: things would remain exactly the same.

The most violent offenders on this front are businesses. Good enough in corporate business application culture equates to: if it is taped together shoddily but it works then its worthy of production use. I know this attitude all too well. Performance is simply not a concern, and then the experience of waiting seconds as opposed to an instant becomes the social norm. People will give you weird looks if you tell them that things should feel like they are happening almost at the speed of light (you know, the way electricity is traveling along the circuits of the CPU).

So, everything old is new again. C++ can be looked at with a fresh fondness, especially as a giant number of developers enter the field being self-taught, and without a thorough knowledge of computer science itself that you would gain from a college degree. Learning C++ can also be an exercise in learning the machine itself, and that provides benefits even if you choose not to dive forward with tons of coding in the low-level language.

In my case, as an entrepreneur and leader of a start-up, the notion is attractive to me to re-discover what can be done with inexpensive hardware. If you can make something blazing fast on a weak machine, imagine what might be able to be done on what we have today: if only the other clunker programs will be able to get out of the way of the machines physical resources. My curiosity is alive, and now I descend into the rabbit hole of extreme performance& or you know, the performance of the 1990s.