Simultaneous Invention, All The Time?

February 25, 2023 by Elliot Williams 20 Comments

As Tom quipped on the podcast this week, if you have an idea for a program you’d like to write, all you have to do is look around on GitHub and you’ll find it already coded up for you. (Or StackOverflow, or…) And that’s probably pretty close to true, at least for really trivial bits of code. But it hasn’t always been thus.

I was in college in the mid 90s, and we had a lab of networked workstations that the physics majors could use. That’s where I learned Unix, and where I had the idea for the simplest program ever. It took the background screen color, in the days before wallpapers, and slowly random-walked it around in RGB space. This was set to be slow enough that anyone watching it intently wouldn’t notice, but fast enough that others occasionally walking by my terminal would see a different color every time. I assure you, dear reader, this was the very height of wit at the time.

With the late 90s came the World Wide Web and the search engine, and the world got a lot smaller. For some reason, I was looking for how to set the X terminal background color again, this time searching the Internet instead of reading up in a reference book, and I stumbled on someone who wrote nearly exactly the same random-walk background color changer. My jaw dropped! I had found my long-lost identical twin brother! Of course, I e-mailed him to let him know. He was stoked, and we shot a couple funny e-mails back and forth riffing on the bizarre coincidence, and that was that.

Can you imagine this taking place today? It’s almost boringly obvious that if you search hard enough you’ll find another monkey on another typewriter writing exactly the same sentence as you. It doesn’t even bear mentioning. Heck, that’s the fundamental principle behind Codex / CoPilot – the code that you want to write has been already written so many times that it will emerge as the most statistically likely response from a giant pattern-matching, word-word completion neural net model.

Indeed, stop me if you’ve read this before.

Retrotechtacular: Critical Code Reading, 70s Style

January 5, 2023 by Dan Maloney 30 Comments

Anyone who has ever made a living writing code has probably had some version of the following drilled into their head: “Always write your code so the next person can understand it.” Every single coder has then gone on to do exactly the opposite, using cryptic variables and bizarre structures that nobody else could possibly follow. And every single coder has also forgotten the next part of that saying — “Because the next person could be you” — and gone on to curse out an often anonymous predecessor when equally inscrutable code is thrust upon them to maintain. Cognitive dissonance be damned!

It’s a tale as old as time, or at least as old as programming has existed as a profession. And by 1975, poorly written code was enough of a problem that an outfit called Edutronics put together the animated gem Critical Program Reading: Structuring an Unstructured Program. It’s apparently Part 1 of a larger series on structured programming techniques, and comes to us by way of [Alec Watson], host of Technology Connections on YouTube, by way of his second channel, the delightfully named Technology Connextras.

The film’s three minimally animated characters, each of whom could have been the villain in an episode of Scooby Doo, are tasked by a stern-sounding narrator to analyze a fragment of pseudocode that’s written in a concoction of COBOL, PL/1, and a bunch of other languages. The code is a hot mess, but our heroes muddle through it line by awful line, making it more readable by guessing at more descriptive variable names, adding structured elements, and making logical changes to improve the program’s flow. The example code is highly contrived, to be sure, but the business logic becomes much clearer as our team refactors the code and makes it far more approachable.

For as much as languages have changed since the 1970s, and with all the progress we’ve made in software engineering, the lessons presented in this film are still surprisingly relevant. We loved a lot of the little nuggets dropped along the way, like “Consistency aids understanding,” and “Use symbols in a natural way.” But we will take exception with the statement “Wrong means poor structure” — we’ve ~~written~~ seen plenty of properly structured code that didn’t work worth a damn. We also enjoyed the attempt at socially engineering a less toxic work environment: “Use tact in personal criticisms.” If only they could learn that lesson over at Stack Overflow.

It’s not clear where [Alec] found this 16-mm film — we’d sure like to hear that story — but it’s a beauty and we’re glad he took the time to digitize it. We’re consistently amazed at his ability to make even the most mundane aspects of technology endlessly fascinating, and while this film may be a bit off from his normal fare, it’s still a great find. Continue reading “Retrotechtacular: Critical Code Reading, 70s Style” →

Arduino IDE v2.0 screen with callout tags to identify features

Arduino IDE 2.0 Is Here

September 28, 2022 by Dave Walker 84 Comments

Arduino have released the latest version of their Integrated Development Environment (IDE), Version 2.0 and it is a big step up from the previous release, boasting plenty of new features to help you to develop your code more easily.

As the de-facto way for beginners to get into programming hardware, more experienced users have sometimes complained about what they see as the over-simplistic IDE — even lacking relatively basic features such as autocomplete. The new version provides this, and much more besides. Continue reading “Arduino IDE 2.0 Is Here” →

A Primer For The Homebrew Game Boy Advance Scene

August 29, 2022 by Bryan Cockfield 10 Comments

As video game systems pass into antiquity, some of them turn out to make excellent platforms for homebrew gaming. Not only does modern technology make it easier to interact with systems that are now comparatively underpowered and simpler, but the documentation available for older systems is often readily available as well, giving the community lots of options for exploration and creativity. The Game Boy Advance is becoming a popular platform for these sorts of independent game development, and this video shows exactly how you can get started too.

This tutorial starts with some explanation of how the GBA works. It offered developers several modes for the display, so this is the first choice a programmer must make when designing the game. From there it has a brief explanation of how to compile programs for the GBA and execute them, then it dives into actually writing the games themselves. There are a few examples that [3DSage] demonstrates here including examples for checking the operation of the code and hardware, some simple games, and also a detailed explanation the framebuffers and other hardware and software available when developing games for this console.

While the video is only 10 minutes long, we recommend watching it at three-quarters or half speed. It’s incredibly information-dense and anyone following along will likely need to pause several times. That being said, it’s an excellent primer for developing games for this platform and in general, especially since emulators are readily available so the original hardware isn’t needed. If you’d like to build something from an even more bygone era than the early 2000s, though, take a look at this tutorial for developing games on arcade cabinets.

Continue reading “A Primer For The Homebrew Game Boy Advance Scene” →

A Programming Language To Express Programming Frustration

December 14, 2021 by Bryan Cockfield 26 Comments

Programming can be a frustrating endeavor. Certainly we’ve all had moments, such as forgetting punctuation in C or messing up whitespace in Python. Even worse, an altogether familiar experience is making a single change to a program that should have resulted in a small improvement but instead breaks the program. Now, though, there’s a programming language that can put these frustrations directly into the code itself into a cathartic, frustration-relieving syntax. The language is called AHHH and it’s quite a scream.

While it may not look like it on the surface, the language is Turing complete and can be used just like any other programming language. The only difference is that there are only 16 commands in this language which are all variants of strings of four capital- or lower-case-H characters. The character “A” in the command “AHHH” starts the program, and from there virtually anything can be coded as a long, seemingly unending scream. The programming language is loosely related to COW which uses various “moos” to create programs instead of screams, and of course is also distantly related to brainfuck which was an esoteric programming language created in order to have the smallest possible compiler.

We can’t really recommend that beginner programmers start to learn this language instead of something more practical like Python, esoteric languages like these can teach us a lot about the way that computers work. This language, for example, lets you code in pixels instead of characters. Others are more for fun such as this language which turns your code into an ’80s rock ballad.

Thanks to [Kyle F] for the tip!

Can You Code Without Google?

February 13, 2021 by Jenny List 106 Comments

Imagine for a moment that something has taken out your phone line, cell, and fibre connection so you have no internet. For some of you this may even be reality, but go with it and imagine yourself deciding to use your unexpectedly disconnected lockdown time pursuing that code project you always promised yourself. You pull out your laptop and fire up a code editor. Can you write code that works, without the Internet as a handy crib sheet? [Austin Z. Henley] couldn’t, when he tried writing a straightforward web app. He uses it as a hook to muse on the nature of learning, and it’s certainly a thought-provoking subject.

It has become an indispensable tool for the engineer and the coder alike, to constantly refer to online knowledge. This makes absolute sense, as it provides a reference library that will be many orders of magnitude in excess of anything an individual can possibly hold personally.

This holds true whether the resource takes the form of code snippets from StackOverflow or GitHub, or data sheets from TI or Microchip. Even our calculations have moved online, as it’s often much quicker to use an online calculator on a web page to derive for example an impedance calculation. This is not necessarily a bad thing, instead it’s an enabler; skills that used to take months to master due to slow information access can now be acquired in an afternoon. But it does pose the interesting question, in the Internet age what is the measure of an expert coder? Is it the ability to produce the code effectively with whatever help is available, or is it a guru-like mastery of the code? Maybe it’s both. If you have the Internet, give us your views in the comments.

Code For Hackers

September 19, 2020 by Elliot Williams 57 Comments

Mike and I were talking about two very similar clock projects we’d both built recently: they both use ESP8266 modules to get the time over WiFi and NTP, and they both failed. Mike’s failed because he was visiting relatives in a different timezone with different WiFi credentials, and mine failed because daylight savings time caught me off-guard. In both cases, we hard-coded stuff that could obviously change, but we drew vastly different conclusions.

Mike thought he’d solve his WiFi problem with a fallback to a captive portal, and maybe would have to figure out some web interface for configuring the timezone. A very clean, professional solution. Me? I’ve got good comments in the code, can find the UTC offset (or the WiFi creds) in a few minutes, and flash the new version up simply by fetching a USB cable, for something that happens twice a year. It’s hardly worth the trouble to cobble together a web interface.

We’ve accidentally embodied a quandary that spans both the hardware and software worlds: should flexibility be exposed to the end-user or to the hacker who can peer under the hood or open up the source code? (And what if the end-user is the hacker?) What are the tradeoffs, in project complexity and in ease of use?

And in this, Mike is on the side of right and good, and I’m the heretic. I don’t always write my code to be extensible or re-usable. I sometimes write it to be quickly re-edited and patched whenever I need to. Is it full of magic numbers? Sure! But I know just where they are and how to change them. Heck, most are even well documented in their own header file. You could probably figure it out just about as fast. Would my father-in-law be able to tweak the timezone? Nope! But this ain’t his project anyway.

Dare to code for hackers! Don’t over-generalize or over-abstract. Less is more. Don’t be afraid to edit code. Tweak, compile, and re-flash when the situation changes. After all, that’s how you got the code there in the first place.

And although I’m on the wrong end of history, in this case I was right. You see, before daylight savings time could come around again, and I could have made use of that captive portal that I didn’t bother coding up anyway, my son entered first grade. Everything needs to be changed, from the hardware to the software. Will I code up the next version with flexible time regimes? As flexible as I need it to be, but not more.