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
Apr 11, 2021
https://youtu.be/D29rGqkkf80 Made in "Hawaii" (camera Ziyue Zhang) Monday: Dynamic Duo 2: The Sequel Tuesday: Gall's Law and Big Ball of Mud Wednesday: Benedict Evans on Tech in 2021... [[ Click on the title to access the full blog on the Cadence Community sit...
Apr 8, 2021
We all know the widespread havoc that Covid-19 wreaked in 2020. While the electronics industry in general, and connectors in particular, took an initial hit, the industry rebounded in the second half of 2020 and is rolling into 2021. Travel came to an almost stand-still in 20...
Apr 7, 2021
We explore how EDA tools enable hyper-convergent IC designs, supporting the PPA and yield targets required by advanced 3DICs and SoCs used in AI and HPC. The post Why Hyper-Convergent Chip Designs Call for a New Approach to Circuit Simulation appeared first on From Silicon T...
Apr 5, 2021
Back in November 2019, just a few short months before we all began an enforced… The post Collaboration and innovation thrive on diversity appeared first on Design with Calibre....

featured video

Meeting Cloud Data Bandwidth Requirements with HPC IP

Sponsored by Synopsys

As people continue to work remotely, demands on cloud data centers have never been higher. Chip designers for high-performance computing (HPC) SoCs are looking to new and innovative IP to meet their bandwidth, capacity, and security needs.

Click here for more information

featured paper

Understanding Functional Safety FIT Base Failure Rate Estimates per IEC 62380 and SN 29500

Sponsored by Texas Instruments

Functional safety standards such as IEC 61508 and ISO 26262 require semiconductor device manufacturers to address both systematic and random hardware failures. Base failure rates (BFR) quantify the intrinsic reliability of the semiconductor component while operating under normal environmental conditions. Download our white paper which focuses on two widely accepted techniques to estimate the BFR for semiconductor components; estimates per IEC Technical Report 62380 and SN 29500 respectively.

Click here to download the whitepaper

featured chalk talk

Thunderbolt Technology Overview

Sponsored by Mouser Electronics and Intel

Thunderbolt is the closest thing we’ve got to universal interconnect between a wide variety of devices and systems. With a universal USB-C connector, it can do video, power, data communication - all at scalable rates with smart adjustment. In this episode of Chalk Talk, Amelia Dalton chats with Sandeep Vedanthi of Intel about the latest in Thunderbolt technology - Thunderbolt 4, which brings a number of benefits over previous versions.

Click here for more information about Intel 8000 series Thunderbolt™ 4 Controllers