Dan Maloney and I were talking on the podcast about his memories of the old electronics magazines, and how they had some gonzo projects in them. One, a DIY picture phone from the 1980s, was a monster build of a hundred ICs that also required you to own a TV camera. At that time, the idea of being able to see someone while talking to them on the phone was pure science fiction, and here was a version of that which you could build yourself.

Still, we have to wonder how many of these were ever built. The project itself was difficult and expensive, but you actually have to multiply that by two if you want to talk with someone else. And then you have to turn your respective living rooms into TV studios. It wasn’t the most practical of projects.

But amazing projects did something in the old magazines that we take a little bit for granted today: they showed what was possible. And if you want to create something new, you’re not necessarily going to know how to do it, but just the idea that it’s possible at all is often enough to give a motivated hacker the drive to make it real. As skateboard hero Rodney Mullen put it, “the biggest obstacle to creativity is breaking through the barrier of disbelief”.

In the skating world, it’s seeing someone else do a trick in a video that lets you know that it’s possible, and then you can make it your own. In our world, in prehistoric times, it was these electronics magazines that showed you what was possible. In the present, it’s all over the Internet, and all over Hackaday. So when you see someone’s amazing project, even if you aren’t necessarily into it, or maybe don’t even fully understand it, your horizons of what’s possible are nonetheless expanded, and that helps us all be more creative.

Keep on pushing!

It was probably Montesquieu who coined the proto-hacker motto “the best is the mortal enemy of the good”. He was talking about compromises in drafting national constitutions for nascent democracies, of course, but I’ll admit that I do hear his voice when I’m in get-it-done mode and start cutting corners on a project. A working project is better than a gold-plated one.

But what should I do, Monte, when good enough turns out to also be the mortal enemy of the best? I have a DIY coffee roaster that is limping along for years now on a blower box that uses a fan scavenged in anger from an old Dust Buster. Many months ago, I bought a speed-controllable and much snazzier brushless blower fan to replace it, that would solve a number of minor inconveniences with the current design, but which would also require some building and another dive into the crufty old firmware.

So far, I’ve had good enough luck that the roaster will break down from time to time, and I’ll use that as an excuse to fix that part of the system, and maybe even upgrade another as long as I have it apart. But for now, it’s running just fine. I mean, I have to turn the fan on manually, and the new one could be automatic. I have only one speed for the fan, and the new one would be variable. But the roaster roasts, and a constant source of coffee is mission critical in this house. The spice must flow!

Reflecting on this situation, it seems to me that the smart thing to do is work on smoothing the transitions from good enough to best. Like maybe I could prototype up the new fan box without taking the current one apart. Mock up some new driver code on the side while I’m at it?

Maybe Montesquieu was wrong, and the good and the best aren’t opposites after all. Maybe the good enough is just the first step on the path toward the best, and a wise man spends his energy on making the two meet in the middle, or making the transition from one to the other as painless as possible.

This week, the hackerverse was full of “vibe coding”. If you’re not caught up on your AI buzzwords, this is the catchy name coined by [Andrej Karpathy] that refers to basically just YOLOing it with AI coding assistants. It’s the AI-fueled version of typing in what you want to StackOverflow and picking the top answers. Only, with the current state of LLMs, it’ll probably work after a while of iterating back and forth with the machine.

It’s a tempting vision, and it probably works for a lot of simple applications, in popular languages, or generally where the ground is already well trodden. And where the stakes are low, as [Al Williams] pointed out while we were talking about vibing on the podcast. Can you imagine vibe-coded ATM software that probably gives you the right amount of money? Vibe-coding automotive ECU software?

While vibe coding seems very liberating and hands-off, it really just changes the burden of doing the coding yourself into making sure that the LLM is giving you what you want, and when it doesn’t, refining your prompts until it does. It’s more like editing and auditing code than authoring it. And while we have no doubt that a stellar programmer like [Karpathy] can verify that he’s getting what he wants, write the correct unit tests, and so on, we’re not sure it’s the panacea that is being proclaimed for folks who don’t already know how to code.

Vibe coding should probably be reserved for people who already are expert coders, and for trivial projects. Just the way you wouldn’t let grade-school kids use calculators until they’ve mastered the basics of math by themselves, you shouldn’t let junior programmers vibe code: It simultaneously demands too much knowledge to corral the LLM, while side-stepping any of the learning that would come from doing it yourself.

And then there’s the security side of vibe coding, which opens up a whole attack surface. If the LLM isn’t up to industry standards on simple things like input sanitization, your vibed code probably shouldn’t be anywhere near the Internet.

So should you be vibing? Sure! If you feel competent overseeing what [Dan] described as “the worst summer intern ever”, and the states are low, then it’s absolutely a fun way to kick the tires and see what the tools are capable of. Just go into it all with reasonable expectations.

Earlier this year, I bought one of those K40-style laser machines that was listed at a ridiculously low price, and it arrived broken. Well, let me qualify that: the laser tube and the power supply work perfectly, but that’s about the best you can say about it.

On first power-up, it made a horrible noise, the Y-axis was jammed, the X-axis was so off-square that it was visibly apparent, and it turned out that as I fixed one of these problems after the other, that it was just the tip of the iceberg. The Y-axis was jammed because the belts were so tight that they made the motor bind. Replacing them, because they were simply too short, got the stage moving, but it didn’t engage the endstops. Fixing those revealed that the motor was stepped wrong, and flipping the pins in the connector finally got it homing in the right direction. Full disassembly and reassembly steps required at each stage here.

The X-axis just needed adjustment, but the opto on its endstop had been completely crushed by a previous failed homing, and I had to desolder and resolder in a new one. (Keep your junkbox well stocked!) With the machine working, it became obvious that the driver board was barely usable. It accelerates horribly jerkily, which makes the motors skip and stall. It had to be run artificially slowly because it couldn’t make the corners. So I put in a new motor controller board that handles Gcode and does legitimate acceleration ramps.

Movement mostly fixed, it was time to align the laser. Of course, the optical path is all messed up, they forgot the o-ring that holds the focusing lens in place, and the thing keeps powering down randomly. This turns out to be because of the aiming red laser pointer, which has a positive case, which is shorting through the single wrap of electrical tape that “insulates” it from the machine’s frame. When this shorts, the motor driver board browns out. Lovely!

Once I was finally able to start aligning the beam, I discovered that the frame is warped out of plane. The simple solution is to take it all apart again and shim it until it’s flat, but I just haven’t had the time yet. I’m not beaten, but it’s been eating up hours after hours on the weekends, and that time is scarce.

I love DIY, and I love taking a machine apart in order to understand it. Once. But I’m now on my tenth or twelfth unmounting of the motion stage, and frankly, it’s no fun any more. It would have been quicker, if maybe not cheaper, to have built this machine entirely from scratch. At least for the moment, I’ve bitten off more than I have time to chew.

Is a bicycle like a motorcycle? Of course, the answer is it is and it isn’t. Saying something is “like” something else presupposes a lot of hidden assumptions. In the category “things with two wheels,” we have a winner. In the category “things that require gasoline,” not so much. We’ve noticed before that news stories about astronomy often talk about “sun-like stars” or “Earth-like planets.” But what does that really mean? [Paul Gilster] had the same questions, if you want to read his opinion about it.

[Paul] mentions that even textbooks can’t agree. He found one that said that Centauri A was “sun-like” while Centauri B was sometimes considered sun-like and other times not. So while Paul was looking at the examples of press releases and trying to make sense of it all, we thought we’d just ask you. What makes a star like our sun? What makes a planet like our planet?

Part of the problem is we don’t really know as much as we would like about other planets and their stars. We know more than we used to, of course. Still, it would be like wondering if the motorcycle was like that distant point of light. Maybe.

This is one of those things that seems deceptively simple until you start thinking about it. Is a planet Earth-like if it is full of water? What if it is totally covered in water? What if there’s no life at all? But life isn’t it, either. Methane-breathing silicon-based life probably doesn’t live on Earth-like planets.

Maybe Justice Potter Stewart was on to something when he said, “I know it when I see it!” Unfortunately, that’s not very scientific.

So what do you think? What’s a sun-like star? What’s an Earth-like planet? Discuss in the comments.

Don’t even get us started on super-earths, whatever they are. We are learning more about our neighbors every day, though.

We ran a story about a wall-mounted plotter bot this week, Mural. It’s a simple, but very well implemented, take on a theme that we’ve seen over and over again in various forms. Two lines, or in this case timing belts, hang the bot on a wall, and two motors drive it around. Maybe a servo pulls the pen in and out, but that’s about it. The rest is motor driving and code.

We were thinking about the first such bot we’ve ever seen, and couldn’t come up with anything earlier than Hektor, a spray-painting version of this idea by [Juerg Lehni]. And since then, it’s reappeared in numerous variations.

Some implementations mount the motors on the wall, some on the bot. There are various geometries and refinements to try to make the system behave more like a simple Cartesian one, but in the end, you always have to deal with a little bit of geometry, or just relish the not-quite-straight lines. (We have yet to see an implementation that maps out the nonlinearities using a webcam, for instance, but that would be cool.) If you’re feeling particularly reductionist, you can even do away with the pen-lifter entirely and simply draw everything as a connected line, Etch-a-Sketch style. Maslow CNC swaps out the pen for a router, and cuts wood.

What I love about this family of wall-plotter bots is that none of them are identical, but they all clearly share the same fundamental idea. You certainly wouldn’t call any one of them a “copy” of another, but they’re all related, like riffing off of the same piece of music, or painting the same haystack in different lighting conditions: robot jazz, or a study in various mechanical implementations of the same core concept. The collection of all wall bots is more than the sum of its parts, and you can learn something from each one. Have you made yours yet?

(Fantastic plotter-bot art by [Sarah Petkus] from her write-up ten years ago!)

In the world of programming languages it often feels like being stuck in a Groundhog Day-esque loop through purgatory, as effectively the same problems are being solved over and over, with previous solutions forgotten and there’s always that one jubilant inventor stumbling out of a darkened basement with the One True Solution to everything that plagues this world beset by the Unspeakable Horror that is the C programming language.

As the latest entry to pledge its fealty at the altar of the Church of the Holy Memory Safety, TrapC promises to fix C, while also lambasting Rust for allowing that terrible unsafe keyword. Of course, since this is yet another loop through purgatory, the entire idea that the problem is C and some perceived issue with this nebulous ‘memory safety’ is still a red herring, as pointed out previously.

In other words, it’s time for a fun trip back to the 1970s when many of the same arguments were being rehashed already, before the early 1980s saw the Steelman language requirements condensed by renowned experts into the Ada programming language. As it turns out, memory safety is a miniscule part of a well-written program.

It’s A Trap

Pretty much the entire raison d’être for new programming languages like TrapC, Rust, Zig, and kin is this fixation on ‘memory safety’, with the idea being that the problem with C is that it doesn’t check memory boundaries and allows usage of memory addresses in ways that can lead to Bad Things. Which is not to say that such events aren’t bad, but because they are so obvious, they are also very easy to detect both using static and dynamic analysis tools.

As a ‘proposed C-language extension’, TrapC would add:

• memory-safe pointers.
• constructors & destructors.
• the trap and alias keywords.
• Run-Time Type Information.

It would also remove:

• the goto and union keywords.

The author, Robin Rowe, freely admits to this extension being ‘C++ like’, which takes us right back to 1979 when a then young Danish computer scientist (Bjarne Stroustrup) created a C-language extension cheekily called ‘C++’ to denote it as enhanced C. C++ adds many Simula features, a language which is considered the first Object-Oriented (OO) programming language and is an indirect descendant of ALGOL. These OO features include constructors and destructors. Together with (optional) smart pointers and the bounds-checked strings and containers from the Standard Template Library (STL) C++ is thus memory safe.

So what is the point of removing keywords like goto and union? The former is pretty much the most controversial keyword in the history of programming languages, even though it derives essentially directly from jumps in assembly language. In the Ada programming language you also have the goto keyword, with it often used to provide more flexibility where restrictive language choices would lead to e.g. convoluted loop constructs to the point where some C-isms do not exist in Ada, like the continue keyword.

The union keyword is similarly removed in TrapC, with the justification that both keywords are ‘unsafe’ and ‘widely deprecated’. Which makes one wonder how much real-life C & C++ code has been analyzed to come to this conclusion. In particular in the field of embedded- and driver programming with low-level memory (and register) access the use of union is widely used for the flexibility it offers.

Of course, if you’re doing low-level memory access you’re also free to use whatever pointer offset and type casting you require, together with very unsafe, but efficient, memcpy() and similar operations. There is a reason why C++ doesn’t forbid low-level access without guardrails, as sometimes it’s necessary and you’re expected to know what you’re doing. This freedom in choosing between strict memory safety and the untamed wilds of C is a deliberate design choice in C++. In embedded programming you tend to compile C++ with both RTTI & exceptions disabled as well due to the overhead from them.

Don’t Call It C++

Effectively, TrapC adds RTTI, exceptions (or ‘traps’), OO classes, safe pointers, and similar C++ features to C, which raises the question of why it’s any different, especially since the whitepaper describes TrapC and C++ code usually looking the same as a feature. Here the language seems to regard itself as being a ‘better C++’, mostly in terms of exception handling and templates, using ‘traps’ and ‘castplates’. Curiously there’s not much focus on “resource allocation is initialization” (RAII) that is such a cornerstone of C++.

Meanwhile castplates are advertised as a way to make C containers ‘typesafe’, but unlike C++ templates they are created implicitly using RTTI and one might argue somewhat opaque (C++ template-like) syntax. There are few people who would argue that C++ template code is easy to read. Of note here is that in embedded programming you tend to compile C++ with both RTTI & exceptions disabled due to the overhead from them. The extensive reliance on RTTI in TrapC would seem to preclude such an option.

Circling back on the other added keyword, alias, this is TrapC’s way to providing function overloading, and it works like a C preprocessor #define:

void puts(void* x) alias printf("{}n",x);

Then there is the new trap keyword that’s apparently important enough to be captured in the extension’s name. These are offered as an alternative to C++ exceptions, but the description is rather confusing, other than that it’s supposedly less complicated and does not support cascading exceptions up the stack. Here I do not personally see much value either way, as like so many C++ developers I loathe C++ exceptions with the fire of a thousand Suns and do my utmost to avoid them.

My favorite approach here is found in Ada, which not only cleanly separates functions and procedures, but also requires, during compile time, that any return value from a function is handled, and implements exceptions in a way that is both light-weight and very informative, as I found for example while extensively using the Ada array type in the context of a lock-free ring buffer. During testing there were zero crashes, just the program bailing out with an exception due to a faulty offset into the array and listing the exact location and cause, as in Ada everything is bound-checked by default.

Memory Safety

Much of the safety in TrapC would come from managed pointers, with its author describing TrapC’s memory management as ‘automatic’ in a recent presentation at an ISO C meeting. Pointers are lifetime-managed, but as the whitepaper states, the exact method used is ‘implementation defined’, instead of reference counting as in the C++ specification.

Yet none of this matters in the context of actual security issues. As I noted in 2024, the ‘red herring’ part refers to the real-life security issues that are captured in CVEs and their exploitation. Virtually all of the worst CVEs involve a lack of input validation, which allows users to access data in ‘restricted’ folders and gain access to databases and other resources. None of which involve memory safety in any way or form, and thus the onus lies on preventing logic errors, solid input validation and preventing lazy or inattentive programmers from introducing the next world-famous CVE.

As a long-time C & C++ programmer, I have come to ‘love’ the warts in these languages as well as the lack of guardrails for the freedom they provide. Meanwhile I have learned to write test cases and harnesses to strap my code into for QA sessions, because the best way to validate code is by stressing it. Along the way I have found myself incredibly fond of Ada, as its focus on preventing ambiguity and logic errors is self-evident and regularly keeps me from making inattentive mistakes. Mistakes that in C++ would show up in the next test and/or Valgrind cycle followed by a facepalm moment and recompile, yet somehow programming in Ada doesn’t feel more restrictive than writing in C++.

Thus I’ll keep postulating that the issues with C were already solved in 1983 with the introduction of Ada, and accepting this fact is the only way out of this endless Groundhog Day purgatory.