Rob Cook


Home | Donate

Native code and minimalism


2020-01-30

As programming languages have developed over the years, the trend has been to stray further and further from the native hardware. We have virtual machines running atop OSes hosted in containers, or some trickery to do similar magic inside the web browser. Add to this standard libraries that are thousands of classes in size, vast eco systems of packages, and the countless frameworks designed to "simplify" your task. If programming were a musical style, it would be seventies era prog rock. In short, programming has disappeared up its own arse.

I say this as a long time C# programmer, who thinks more often in terms of abstract classes instead of byte arrays and pointers. Not only is the platform bloated with abstraction, but the code that gets written atop is too. Factories that return adapters to bridges, pattern after pattern of code doing little that is tangible. I have made a concious effort in my current job to minimise the abstract. To focus on code that actually does stuff and not turn to object orientation when simple procedural will do. It kinda works, but it goes against the grain of the language philosophy, so ends up getting tangled in all the messy abstractness at some point.

Looking to other languages is a good way to take stock of your own. Lua has been an illuminating example. The language is minimal yet powerful. The syntax eschewing all but the most essential syntactic sugar. Likewise its standard library is compact yet useful. It really is small enough that you could memorise it all. (Try that with .Net or Java.) While some of its features are but thin wrappers of native C routines, it is still a high level language in terms of the abstractions it exposes you to, and the code is still interpreted.

Native code is making something of a comeback. Go seems to be leading the charge as a C for the 21st century, with languages like Rust and native versions of Scala and Kotlin coming up fast. As too is the desire to avoid external dependencies. Forget virtual machines, some of these languages avoid any external code at all and compile to a single static binary.

With hardware getting ever more complex, it may seem paradoxical to want to get closer to the metal. Its because of this change however, that older, more abstracted endeavours are failing us. Developers want full access to the many features of the underlying device and the power to use all those cpu cores. Performant code, native speed, these seem to be back at the top of the list of developer desires.

If it results in the crumbling of old layers of abstraction, I don't necessarily think that's a bad thing.

end