feature article
Subscribe Now

Three Radicals Walk Into a Bar…

What Do Engineers, Socialists, and Capitalists Have in Common?

“The young always inherit the revolution.” – Huey Newton

Karl Marx, Charles Babbage, and Adam Smith walk into a bar. 

After ordering drinks, the fathers of modern computing, socialism, and capitalism have a little discussion about the best ways to improve engineers’ productivity and efficiency. Babbage the engineer says that creativity and inspiration are key to innovation; that individual designers and inventors are the foundation of our technological progress. 

Smith says that competition improves the breed. When individuals and corporations compete with one another, the whole industry benefits. Winners overcome losers in the marketplace of ideas. 

Marx, peering through his beard, says that’s nonsense, and wasteful besides. Central planning improves productivity by eliminating redundancy. Competition is inherently inefficient because it results in duplicated effort, much of which will be discarded or wasted. Better to choose a path early and march along it. 

The discussion gets more heated after the drinks arrive. But who’s right? If engineering is all about efficiency, why do we operate in such an inefficient manner? 

Take microprocessors, operating systems, and programming languages as just three examples. Why do we have so many? Is an ARM processor really all that different from an x86, MIPS, RISC-V, or the dozens of other CPU architectures clogging the supply pipeline? Any Turing-complete machine can, by definition, perform the same tasks as any other. So why don’t we just pick a $#@% chip family and move on? 

It’d be great. All software would be compiled for the same instruction set, so there’d be no more compatibility issues. Engineering students could learn the same, standardized, instruction-set architecture and programming model. No more big/little-endian byte-ordering problems. Code size would be predictable. Disassembly much easier. And microprocessor manufacturers could focus on valued-added features instead of these hugely expensive architectural expeditions. 

Just look at all the ambitious CPU vanity projects that have failed: Intel and HP spent billions developing, building, and marketing Itanium. That’s space-program money… completely wasted. Sun/Oracle gave up on SPARC chips. PowerPC has finished circling the drain. Clipper, Alpha, and dozens of other high-end architectures all came to nothing, but only after squandering all the money and the man-hours. If we had just agreed on a single processor – any processor – that effort could have been put to more productive use. 

Same goes for operating systems and programming languages. If everyone used C++ (or Python, or whatever) we could all share code, helpful tips, and source libraries. Programmers would be largely interchangeable from one project to another, and from one company to another. You’d have a much easier time finding a coding job if you didn’t have to narrow your search to the one or two languages you wield with proficiency. 

We already do this on a smaller scale. Most companies use the same CPU, OS, and development tools for all their internal projects. You don’t often see a design team jump from Linux-on-x86 to RTOS-on-ARM and back again. They want to leverage their experience and amortize their investments. They’d also like to be quicker and more efficient, and sticking with the tools you know is the best way to do that. Change is bad. 

All this fragmentation and balkanization doesn’t help the product. Did you buy your smartphone, video game, or TV based on its processor, OS, or development toolchain? The hardware is just a means to an end, and it’s the app layer, not the OS, that provides differentiation. That app development would’ve gone a lot quicker if the programmers had all relied on the same underlying software. 

Marx smiled through his Weiβbier, certain he’d made his case for efficiency and standardization. 

Smith wasn’t having any of it. Carefully setting down his single-malt, he decried any form of mass coordination as unethically monopolistic and against human nature. It’s in our character, our spirit, to compete and search for better solutions. That’s how progress is made. How can we hope to find the best solution to anything – be it hardware, software, or otherwise – with a single decision, never to be overturned? We can’t have innovation by fiat. Surely the nature of engineering challenges changes over time, and we should change with them. Different problems call for different solutions, and who better to discover that solution than the individual inventor, developer, engineer, or programmer? We’ll crowdsource the revolution. 

Furthermore, the prospect of individual gain adds another impetus. Some will pursue engineering challenges purely for the enjoyment of it, but others are driven by the financial upside. We wouldn’t have venture capital without the carrot at the end of that stick. More’s to the good; the customer benefits either way. Let each developer create whatever they may, however they please, and let the invisible hand of the marketplace decide. Yes, there will inevitably be losers, bankruptcies, and layoffs. But there will also be huge successes rewarded by the very customers they’re serving. Competition leads to agility; standardization is stultification. 

Babbage finished his ale in time to observe that we already practice a little of both philosophies. Defense contractors usually do their programming in Ada because it’s required. The language’s constraints make testing, debugging, and maintenance easier, and it levels the playing field among competing contractors. Networking protocols are standardized to enable interoperability. And thousands of hardware interfaces, from disk drives to USB dongles to RJ45 jacks, are also standardized. We may not be able to agree on what an AC power plug should look like in each country, but we convert them all to the same 5VDC for our phone chargers. 

The bartender, being of course the wisest of the group, suggested that these technology trends run in cycles. For a while, everyone wants customized logic, in-house software, and specialized user interfaces. Then the pendulum swings the other way, and everyone rushes toward computing-as-a-service, virtualized hardware, and standard APIs. It seems to follow generational cycles, he observed. Every new crop of engineers thinks their predecessors were idiots. They tear up the rulebook (or so they think) and start over again. 

“It’s all fine with me,” he concluded,” as long as they keep coming into my bar.” Let’s start another round. 

One thought on “Three Radicals Walk Into a Bar…”

Leave a Reply

featured blogs
Mar 28, 2024
'Move fast and break things,' a motto coined by Mark Zuckerberg, captures the ethos of Silicon Valley where creative disruption remakes the world through the invention of new technologies. From social media to autonomous cars, to generative AI, the disruptions have reverberat...
Mar 26, 2024
Learn how GPU acceleration impacts digital chip design implementation, expanding beyond chip simulation to fulfill compute demands of the RTL-to-GDSII process.The post Can GPUs Accelerate Digital Design Implementation? appeared first on Chip Design....
Mar 21, 2024
The awesome thing about these machines is that you are limited only by your imagination, and I've got a GREAT imagination....

featured video

We are Altera. We are for the innovators.

Sponsored by Intel

Today we embark on an exciting journey as we transition to Altera, an Intel Company. In a world of endless opportunities and challenges, we are here to provide the flexibility needed by our ecosystem of customers and partners to pioneer and accelerate innovation. As we leap into the future, we are committed to providing easy-to-design and deploy leadership programmable solutions to innovators to unlock extraordinary possibilities for everyone on the planet.

To learn more about Altera visit: http://intel.com/altera

featured chalk talk

VITA RF Product Portfolio: Enabling An OpenVPX World
Sponsored by Mouser Electronics and Amphenol
Interoperability is a very valuable aspect of military and aerospace electronic designs and is a cornerstone to VITA, OpenVPX and SOSA. In this episode of Chalk Talk, Amelia Dalton and Eddie Alexander from Amphenol SV explore Amphenol SV’s portfolio of VITA RF solutions. They also examine the role that SOSA plays in the development of military and aerospace systems and how you can utilize Amphenol SV’s VITA RF solutions in your next design.
Oct 25, 2023
20,367 views