Khoa wanted to give a friend a microcontroller programmer(cache), but didn’t want to spend the money. He found almost every part he needed inside of a broken monitor he had in the closet. The only parts he had to provide were the perf board and the serial port. Even the socket was in the monitor. It was too wide, but he just cut out the center spar and made the socket narrower.
Programming languages are generally defined as a more human-friendly way to program computers than using raw machine code. Within the realm of these languages there is a wide range of how close the programmer is allowed to get to the bare metal, which ultimately can affect the performance and efficiency of the application. One metric that has become more important over the years is that of energy efficiency, as datacenters keep growing along with their power demand. If picking one programming language over another saves even 1% of a datacenter’s electricity consumption, this could prove to be highly beneficial, assuming it weighs up against all other factors one would consider.
There have been some attempts over the years to put a number on the energy efficiency of specific programming languages, with a paper by Rui Pereira et al. from 2021 (preprint PDF) as published in Science of Computer Programming covering the running a couple of small benchmarks, measuring system power consumption and drawing conclusions based on this. When Hackaday covered the 2017 paper at the time, it was with the expected claim that C is the most efficient programming language, while of course scripting languages like JavaScript, Python and Lua trailed far behind.
With C being effectively high-level assembly code this is probably no surprise, but languages such as C++ and Ada should see no severe performance penalty over C due to their design, which is the part where this particular study begins to fall apart. So what is the truth and can we even capture ‘efficiency’ in a simple ranking?
Continue reading “Assessing The Energy Efficiency Of Programming Languages”
We’re not sure exactly what Tulip is, because it’s so many things all at once. It’s a music-making environment that’s programmable in Python, runs on your big computer or on an ESP32-S3, and comes complete with some nice sounding synth engines, a sequencer, and a drum machine all built in. It’s like your dream late-1980s synthesizer workstation, but running on a dev board that you can get for a song.
And because Tulip is made of open-source software and hardware, you can extend the heck out of it. For instance, as demonstrated in this video by [Floyd Steinberg], you can turn it into a fully contained portable device by adding a touchscreen. That incarnation is available from Makerfabs, and it’s a bargain, especially considering that the developer [Brian Whitman] gets some of the proceeds. Or, because it’s written in portable Python, you can run it on your desktop computer for free.
The most interesting part of Tulip for us, as programmer-musicians, is that it boots up into a Micrypython REPL. This is a synth workstation with a command-line prompt as its primary interface. It has an always-running main loop, and you make music by writing functions that register as callbacks with the main loop. If you were fast, you could probably live-code up something pretty interesting. Or maybe it wants to be extended into a physical musical instrument by taking in triggers from the ESP32’s GPIOs? Oh, and did we mention it sends MIDI out just as happily as it takes it in? What can’t Tulip do?
We’ve seen some pretty neat minimalist music-making devices lately, but in a sense Tulip takes the cake: it’s essentially almost entirely software. The various hardware incarnations are just possibilities, and because it’s all open and extremely portable, you can freely choose among them. We really like the design and sound of the AMY software synthesizer engine that powers the Tulip, and we’re sure that more synthesizer models will be written for it. This is a music project that you want to keep your eyes on in the future.
These days, most of our microcontroller boards come with bootloaders so you can squirt hex into them straight over USB. However, you don’t need to do things this way. If you’re more old school, you can program your AVRs right from a Commodore 64. [Linus Akesson] shows us how.
Programming an AVR isn’t that hard. By holding the chip in reset, it’s possible to flash code via a serial protocol using just three wires. However, that’s pretty impractical to do with modern PCs — they don’t come with addressable IO pins anymore. Normally, you’d use a dedicated programmer to do the job, but [Linus] found his had died on a Friday night. So he set about turning his C64 into one instead.
He decided to use the pins of the C64’s Joystick Port 2, with pins 1, 2, 3, and 4 hooked up to SCK, MOSI, Reset, and MISO on the AVR, respectively. 5 V and Ground were also provided courtesy of the C64’s port. He then whipped up a simple bit of assembly code to read a bit of AVR hex and spit it out over the Joystick port following the in-circuit programming protocol. With a 1541 Ultimate to load files on to the C64 in hand, it was easy to pull his compiled AVR program off his modern PC, chuck it on the C64, and then get the old Commodore to program the AVR in turn.
It’s not the first time [Linus] has wowed us with a C64 in hand. If you’ve got your own fresh projects for the best-selling computer of all time, don’t hesitate to let us know!
Suppose you decide you want to become a novelist. You enroll in the Hackaday Famous Novelists School where your instructor announces that since all truly great novels are written in Russian, our first task will be to learn Russian. You’d probably get up and leave. The truth is, what makes a great (or bad) novel transcends any particular language, and you could make the same argument for programming languages.
Despite the pundits, understanding the basics of how computers work is more important than knowing C, Java, or the language of the week. A recent post by [lackofimagination] proposes that we should teach programming using BASIC. And not a modern whizz-pow BASIC, but old-fashioned regular BASIC as we might have used it in the 1980s.
Certainly, a whole generation of programmers cut their teeth on BASIC. On the other hand, the programming world has changed a lot since then. While you can sort of apply functional and object-oriented techniques to any programming language, it isn’t simple and the details often get in the way of the core ideas.
Still, some things don’t change. The idea of variables, program flow, loops, and arrays all have some parallel in just about anything, so we can see some advantages to starting out simply. After all, you don’t learn to drive by trying it out in the Indy 500, right?
What do you think? If you were teaching programming today, would you start with BASIC? Or with something else? You can modernize a little bit with QB64. Or try EndBasic which just recently had a new release.
The ongoing story of bogus analytical data being submitted to the public OctoPrint usage statistics has taken a surprising turn with the news that a second plugin was being artificially pushed up the charts. At least this time, the developer of the plugin has admitted to doing the deed personally.
Just to recap, last week OctoPrint creator [Gina Häußge] found that somebody had been generating fictitious OctoPrint usage stats since 2022 in an effort to make the OctoEverywhere plugin appear to be more popular than it actually was. It was a clever attempt, and if it wasn’t for the fact that the fake data was reporting itself to be from a significantly out of date build of OctoPrint, there’s no telling how long it would have continued. When the developers of the plugin were confronted, they claimed it was an overzealous user operating under their own initiative, and denied any knowledge that the stats were being manipulated in their favor.
Presumably it was around this time that Obico creator [Kenneth Jiang] started sweating bullets. It turns out he’d been doing the same thing, for just about as long. When [Gina] contacted him about the suspicious data she was seeing regarding his plugin, he owned up to falsifying the data and published what strikes us as a fairly contrite apology on the Obico blog. While this doesn’t absolve him of making a very poor decision, we respect that he didn’t try to shift the blame elsewhere.
That said, there’s at least one part of his version of events that doesn’t quite pass the sniff test for us. According to [Kenneth], he first wrote the script that generated the fake data back in 2022 because he suspected (correctly, it turns out) that the developers of OctoEverywhere were doing something similar. But after that, he says he didn’t realize the script was still running until [Gina] confronted him about it.
Now admittedly, we’re not professional programmers here at Hackaday. But we’ve written enough code to be suspicious when somebody claims a script they whipped up on a lark was able to run unattended for two years and never once crashed or otherwise bailed out. We won’t even begin to speculate where said script could have been running since 2022 without anyone noticing…
But we won’t dwell on the minutiae here. [Gina] has once again purged the garbage data from the OctoPrint stats, and hopefully things are finally starting to reflect reality. We know she was already angry about the earlier attempts to manipulate the stats, so she’s got to be seething right about now. But as we said before, these unfortunate incidents are ultimately just bumps in the road. We don’t need any stat tracker to know that the community as a whole greatly appreciates the incredible work she’s put into OctoPrint.
Wiremold is great stuff — it’s relatively cheap, easy to work with, and offers all sorts of adapters and angle pieces which take the hassle out of running (and hiding) wires. But [Dr. Gerg] found a shortcoming of this otherwise very flexible product: since each run is intended to start and end in a surface mounted box, he couldn’t find an end cap that would let him close off a section.
The solution? A desktop 3D printer and a chunk of OpenSCAD code telling it what to extrude. When you break it down, the Wiremold profile is fairly straightforward, and can be easily described with geometric primitives. A handful of cylinders, a cube or two, tie it all together with the hull() function, and you’re there.
We’d say this would be a fantastic project to cut your OpenSCAD teeth on, but since [Dr. Gerg] was kind enough to share the source code, you don’t have to figure it out on your own. Though there’s still benefit in reading over it if you’re looking for some practical examples of how the “Programmers Solid 3D CAD Modeller” gets things done.
So why would you want a Wiremold endcap? In the case of [Dr. Gerg], it sounds like he was trying to cover up a short run of wire that was running vertically. But we could imagine other applications for this basic design now that it’s out in the wild. For example, a short length of Wiremold outfitted with a pair of printed caps could make for a nice little enclosure if you’ve got a small project that needs protecting.
