feature article
Subscribe Now

Programming Below Decks

REST and the Furtherance of the Two-Class System

Do you remember that scene in Titanic where the lower-class passengers are trapped behind locked gates and left to drown? (To be fair, it’s more than one scene; it’s about half of the movie.) Their cabins are small, the viewing portholes are nonexistent (they’re probably below the waterline anyway), and there are no linen tablecloths, or polished silverware, or string quartets to be seen. It’s an us-versus-them world of transatlantic travel.

The same thing is happening with programmers. We’ve got the dinner jacket programmers who deal with abstract, high-level concepts. And then we’ve got the programmers working below decks, toiling away in the boiler rooms of the world’s hardware companies that make the world go ‘round.

The first group keeps their hands and noses clean. The second group sweats and grunts and labors on the sharp and uncomfortable underside of our daily products. As with any society, you can tell the plebes from the patricians by their language. The white-tie crowd speaks in Java or HTML5, while the hoi polloi converse using assembly language or C. Those with aspirations of moving up in the world might try learning C++, but that’s often just pretentious affectation.

I’m not saying that there’s anything inherently wrong with this. Only that it didn’t used to be this way. Class distinctions have been a recurring part of history. But it used to be that we all graduated from a single class. We were all programmers. Now we’re [__fill in the blank__] programmers.

This division was driven home to me when m’colleague Bryon Moyer pointed out how often the term “RESTful” interface programming had started to crop up in conversation. Everyone used RESTful as a desirable adjective, sort of like “paid vacation” or “free beer.”

REST, for those who are not au courant, is an acronym for representational state transfer, and it means coding a Web interface using nothing but the standard HTTP functions like GET and PUT. In a sense, you make your application look to all the world like it’s a browser.

The purported advantages of REST are that it’s scalable, since you’re relying only on functions that the whole world has already standardized; and that it’s easy to use. I mean, how hard can it be to memorize a four-word vocabulary: PUT, GET, POST, and DELETE? By definition, then, the Web itself can be called RESTful – a characterization I’m sure many nonprogrammers would dispute.

RESTful programming is also fault-tolerant, just like servers and browsers. RESTful programming calls are supposed to be idempotent and nullipotent – two words you don’t get to use very often – which basically means that you can accidentally repeat commands with no ill effects. That’s important when you’re working over a flaky Internet connection. For example, repeating a PUT command n number of times shouldn’t screw up the database you’re talking to.

That’s all swell… but it’s not programming. That’s more like snapping LEGO blocks together and calling it architecture, or finishing a paint-by-numbers velvet painting and calling it art. The programmers who rely on REST are able to do so only because the real programmers built the underlying code that makes it all work. I’m all in favor of building atop the work of others. Just don’t call it programming. The suits parading around on the upper decks of Titanic aren’t the ones making it go.

REST makes a fine knothole for cloud-based interfaces, but lately it’s being touted as a panacea; an API for all seasons. “Hey, we can code our entire application using RESTful interfaces!” Yes, and you can also run it on a CPU with exactly one instruction. That doesn’t make it a good idea.

Managers sometimes see REST as a safety net. With only four HTTP verbs and a stateless client-server model, how much trouble can your programmers get into? They’ll create simpler, safer, and more “robust” programs (whatever that means). But if that’s the manager’s major concern, perhaps he should consider removing sharp objects from the programmers’ lab. Or just hire better programmers. Supplying them with plush toys and special jackets with really long arms would make them safer, too. But not necessarily more productive.

I recently spoke with a large European industrial firm that is shifting all of its code development to Java. The company felt that standardizing on Java, rather than C or C++, would make its programmers more productive. They’d spend less time writing (and debugging) low-level code and more time thinking about high-level problems to be solved. They want their programmers to be “subject-matter experts,” not code smiths.

That approach makes sense – for them. In this specific case, with their products and their market focus, Java is perfectly capable of doing what they want. It’s enough of a “real” language that developers can implement just about any function they could need, but also abstract enough that they can gloss over some of the low-level detail their managers are hoping to avoid. If it works out as they hope, their programmers will indeed become subject-matter experts, proficient in various application niches.

But somebody, somewhere, still has to write the Java virtual machine they’re all going to rely upon. In fact, they’ll need several JVMs, because the company’s hardware is varied and nonstandard. In short, somebody will still have to do the hands-on, down-to-the-metal programming that this team will build upon.  It’s a team effort, even if you never meet the other members of the team. 

Leave a Reply

featured blogs
Jul 25, 2021
https://youtu.be/cwT7KL4iShY Made on "a tropical beach" Monday: Aerospace and Defense Systems Day...and DAU Tuesday: 75 Years of the Microprocessor Wednesday: CadenceLIVE Cloud Panel... [[ Click on the title to access the full blog on the Cadence Community site. ]]...
Jul 24, 2021
Many modern humans have 2% Neanderthal DNA in our genomes. The combination of these DNA snippets is like having the ghost of a Neanderthal in our midst....
Jul 23, 2021
Synopsys co-CEO Aart de Geus explains how AI has become an important chip design tool as semiconductor companies continue to innovate in the SysMoore Era. The post Entering the SysMoore Era: Synopsys Co-CEO Aart de Geus on the Need for AI-Designed Chips appeared first on Fro...
Jul 9, 2021
Do you have questions about using the Linux OS with FPGAs? Intel is holding another 'Ask an Expert' session and the topic is 'Using Linux with Intel® SoC FPGAs.' Come and ask our experts about the various Linux OS options available to use with the integrated Arm Cortex proc...

featured video

DesignWare Controller and PHY IP for PCIe 6.0

Sponsored by Synopsys

See a demo of Synopsys’ complete IP solution for PCIe 6.0 technology showing the controller operating at 64GT/s in FLIT mode and the PAM-4 PHY in 5-nm process achieving two orders of magnitude better BER with 32dB PCIe channel.

Click here for more information about DesignWare IP for PCI Express (PCIe) 6.0

featured paper

Hyperconnectivity and You: A Roadmap for the Consumer Experience

Sponsored by Cadence Design Systems

Will people’s views about hyperconnectivity and hyperscale computing affect requirements for your next system or IC design? Download the latest Cadence report for how consumers view hyperscale computing’s impact on cars, mobile devices, and health.

Click to read more

featured chalk talk

Just 1-Wire to Power and Operate I2C or SPI Endpoints

Sponsored by Mouser Electronics and Maxim Integrated

If you are working on a connection or IO constrained design, a one wire solution could be a great way for you to power and operate your I2C or SPI endpoints. In this episode of Chalk Talk, Amelia Dalton chats with Scott Jones from Maxim Integrated about the DS28E18 communications bridge: a one wire solution that can help you address a variety of system level challenges including protocol conversion, wiring limitations, and communication distance concerns.

Click here for more information about the Maxim Integrated DS28E18EVKIT Evaluation System