This is a sample newsletter. Sign up to get email delivery!

A Season of Study and Discovery

In the last newsletter, I told you that August had been a study month. Apparently, my brain told me that I wasn’t done studying. A couple of months later …

I tend to try to reconcile previously held beliefs and see if they match what I currently know. When I get a trigger, down the rabbit hole I go. Maybe it’s not normal, but once I see something that interests me, it’s deep dive time.

Revisiting the 1980s Vision

This recent exploration stems from concepts that seemed readily apparent in the early 1980s. Systems would be straightforward to understand, and a practitioner should be able to examine the system easily from top to bottom. There were examples of this, such as the Lisp Machine and Smalltalk systems. Lisp Machines were actually commercial, while Smalltalk was mainly in the research labs of Xerox PARC.

Researchers held that an operating system was seen as a deficiency of a programming language, not a necessary component of a complete software architecture stack. Of course, there was opposition to this idea, mostly by operating system people who researchers refer to as “high priests of a low religion.”

The 3M Machines: Marvels of the 1980s

Machines today are not comparable to those of yesteryear. The advanced machines of the 1980s were commonly referred to as “3M Machines,” defined as having one megabyte of memory, a one-megapixel display (1024×1024 1-bit pixels), and one million instructions per second (MIPS). These systems cost around $36,000 in today’s dollars.

Even though they were the best of their time, you could actually see the screen being drawn and refreshed—not what we would consider interactive today. For comparison, the CPU alone on a Jetson Nano operates in the 400 MIPS range.

The Trigger: A Modern Project on the Jetson

This reflection was sparked by a project that I am currently working on. I want to be able to look at some data with graphics on the Jetson. There are many ways to do that, of course, but the universal solution for embedded systems seems to be a web interface.

Web interfaces are a mature technology. They’ve been around for a good 25+ years. Yet I see people struggle with them all the time. And by people, I mean me.

The Basics of Web Interfaces

Building web applications should be simple. There’s a boatload of libraries, frameworks, and tools. There’s even debuggers built into web browsers! And yet …

Conceptually, there are two sides to a web application: the server, which creates and sends web pages or data via a web connection, and the client. The server is typically written in one language, such as PHP, Go, C, C++, Python, and so on. The client side consists of three parts: HTML (Hypertext Markup Language) for content, CSS (Cascading Style Sheets) to format and animate the content, and JavaScript for handling data and interactivity. I’ll point out that JavaScript is the most widely deployed programming language in the world, and it’s not even close.

Avoiding Common Pitfalls in Web Development

On its face, it seems straightforward. But there are many mistakes that embedded engineers make when they first start adding web interfaces to their projects. Here are a couple of the biggest mistakes I see people make.

Scale Confusion
Many web servers and libraries are designed to handle massive, planetary-scale systems capable of serving millions of web pages. That’s not a good match for embedded systems, where the demands are much more modest. You don’t need a solution that scales to infinity; you need one to meet your needs and serve a few pages or API calls. But don’t forget about security—you’ll most likely need that if your product is out in the wilds.

Delivery Confusion
Many developers will spend an inordinate amount of time trying to design “magic” web pages with the most “beautiful” interactions and animations. Here’s the thing: none of that matters if you can’t get the basics out the door and into people’s hands. That’s priority number one.

Simplicity and Elegance: Lessons from Swiss and Japanese Design

That doesn’t mean your web page shouldn’t be beautiful. There’s a time-proven way to make your web pages punch above their weight class. It’s called design.

When creating web pages, simplicity and elegance aren’t aesthetic goals—they’re development tools. Take a page from Swiss and Japanese design philosophies. The main idea is to strip away the unnecessary and show the content.

• Use One Font
  Using only one font might sound boring, but some of the biggest pages on the Internet—like Apple, Google, and Facebook—use only one or two fonts. Why? Because it works.
• Minimal Colors
  This trips up many developers. Every graphic designer knows color theory, and the smart ones use only a few colors on their pages. The time you spend messing around with colors is wasted time. There are many resources devoted to color design, and most device manufacturers provide multiple color palettes. I often use Google Material.
• Edward Tufte’s Principle
  Follow Edward Tufte’s principle: “Use the ink on the page to show the data, nothing else.”
• Completion Over Perfection
  Done is the most beautiful color. You can always go back and tweak later, or a designer may come back to refine the page and interactions. If it’s simple and well laid out, it will be elegant. Your design will be better and faster to develop and deliver.

Start Simple and Iterate

The simpler you make the web page, the easier it is to program. Show the minimum to start with. It’s surprising how often this will meet the delivery goal.

Introspection in Lisp Machine and Smalltalk Systems

Going back to the beginning of this article, one of the most powerful ideas behind the Lisp Machine and Smalltalk systems is introspection. This refers to a system’s ability to examine and understand its own structure, behavior, and state at runtime. While this feature isn’t fully realized in most modern systems, we do see partial implementations. For instance, web browsers allow developers to inspect the layout, styling, and step through JavaScript code. Similarly, in IDEs like Visual Studio Code, debuggers enable us to examine variables and step through code in real-time. Dynamic languages take this even further, allowing developers to change the values of variables during runtime.

Programming in the Debugger: A Key Advantage

One difference, however, that those early systems implemented is “programming in the debugger.” Let’s say you have a breakpoint in your code or a “Message not understood” exception. The Lisp and Smalltalk environments provide tools to easily edit the function or method that is having issues and restart the function. This is straightforward from an implementation standpoint—just roll back the activation stack and execute again.

In part, this is easy because of the granularity of those systems. Changing one function does not require recompiling entire files of code, linking, and so on. Modern systems effectively discard this key advantage of dynamic languages, partly due to the lack of proper coding tools.

The Dream of Transparent Systems

Back in the 1980s, the dream was to build systems that are straightforward and transparent, “turtles all the way down,” as it were. Every layer accessible and understandable. Today, despite the incredible power of our machines, we are far from achieving that goal. Part of this is by design, and some argue it’s for security. Yet this simplicity isn’t just nostalgia—it’s a practical advantage.

The Value of “Clarity of Purpose”

“Clarity of purpose” is a term you’ll hear many designers say. There’s even a school of design that stresses functionality over style. There’s a lot to be said for that if you’re creating web interfaces and actually want to deliver.

Simplicity leads to understanding, and understanding makes it easier to deliver results. In your development, strip away the unnecessary. Focus on what matters. Elegant and effective in your development are great goals to shoot for.

Going forward, there are a couple of projects that incorporate some interesting ideas that I am currently working on. The first by-product is an example of a web page which uses websockets to show graphs of the CPU, GPU, and memory utilization. You may have seen the start in the VS Code and Anaconda articles on JetsonHacks. I have been working on a lot more material, which is leading towards a much bigger emphasis on AI on the Jetson.