In Search Of The First Comment

Are you writing your code for humans or computers? I wasn’t there, but my guess is that at the dawn of computing, people thought that they were writing for the machines. After all, they were writing in machine language, and whatever bits they flipped into the electronic brain stayed in the electronic brain, unless punched out on paper tape. And the commands made the machine do things, not other people. Code was written strictly for computers.

Modern programming practice, on the other hand, is aimed firmly at people. Variable and function names are chosen to be long and to describe what they contain or do. “Readability” of code is a prized attribute. Indeed, sometimes the fact that it does the right thing at all almost seems to be an afterthought. (I kid!)

Somewhere along this path, there was an important evolutionary step, like the first fish using its flippers to walk on land. Comments were integrated into programming languages, formalizing the notes that coders of old surely wrote by hand in the margins of the paper first-drafts before keying it in. So I went looking for the missing link: the first computer language, and ideally the first program, with comments. I came up empty handed.

Or rather full handed. Every computer language that I could find had comments from the beginning. FORTRAN had comments, marked by a “C” as the first character in a line. APL had comments, marked by the bizarro rune ⍝. Even the custom language written for the Apollo 11 guidance computers had comments — the now-commonplace “#”. I couldn’t find an early programming language without comments.

My guess is that the first language with a comment must have been an assembly language, because I don’t know of any machines with a native comment instruction. (How cool and frivolous would that be?)

Assemblers simply translate mnemonic names to their machine instruction counterparts, but this gives them the important freedom to ignore anything starting with, traditionally, a semicolon. Even though you’re just transferring the contents of register X to the memory location pointed to in register Y, you can write that you’re “storing the height above ground (meters)” in the comments.

The crucial evolutionary step, though, is saving the comments along with the code. Simply ignoring everything that comes after the semicolon and throwing it away doesn’t count. Does anyone know? What was the first code to include comments as part of the code itself, and not simply as marginalia?

Ask Hackaday: What’s In Your Fastener Bin?

A Saturday afternoon. The work week was done, the household chores were wrapped up, and with almost a week left until Christmas, there was just enough wiggle room to deny that there was still a ton of work left to prepare for that event. It seemed like the perfect time to escape into the shop and knock out a quick project, one that has been on the back burner since at least March. I’m nothing if not skilled in the ways of procrastination.

This was to be a simple project — adding an aluminum plate to a plastic enclosure that would serve as an antenna entry point into my shack. Easy as pie — cut out an rectangle of aluminum, cut and drill a few holes, call it a day. Almost all of my projects start out that way, and almost every time I forget that pretty much every one of those builds goes off the rails at exactly the same point: when I realize that I don’t have the fasteners needed. That’s what happened with this build, which had been going swimmingly up to that point — no major screw-ups, no blood drawn. And so it was off to the hardware store I trundled, looking for the right fasteners to finish the job.

Finding hardware has long been where my productivity goes to die. Even though I live a stone’s throw from at least half a dozen stores, each with a vast selection of hardware and most open weekends and nights, the loss of momentum that results from changing from build-mode to procure-mode has historically been deadly to my projects. I’m sure I’m not the only one who has run into this issue, so the question is: what can a hacker do to prevent having to run out for just the right fasteners?

Continue reading “Ask Hackaday: What’s In Your Fastener Bin?”

Ask Hackaday: Why Did GitHub Ship All Our Software Off To The Arctic?

If you’ve logged onto GitHub recently and you’re an active user, you might have noticed a new badge on your profile: “Arctic Code Vault Contributor”. Sounds pretty awesome right? But whose code got archived in this vault, how is it being stored, and what’s the point?

Continue reading “Ask Hackaday: Why Did GitHub Ship All Our Software Off To The Arctic?”

Ask Hackaday: Are 80 Characters Per Line Still Reasonable In 2020?

Software developers won’t ever run out of subjects to argue and fight about. Some of them can be fundamental to a project — like choice of language or the programming paradigm to begin with. Others seem more of a personal preference at first, but can end up equally fundamental on a bigger scale — like which character to choose for indentation, where to place the curly braces, or how to handle line breaks. Latest when there’s more than one developer collaborating, it’s time to find a common agreement in form of a coding style guide, which might of course require a bit of compromise.

Regardless of taste, the worst decision is having no decision, and even if you don’t agree with a specific detail, it’s usually best to make peace with it for the benefit of uniformly formatted code. In a professional environment, a style guide was ideally worked out collaboratively inside or between teams, and input and opinions of everyone involved were taken into consideration — and if your company doesn’t have one to begin with, the best step to take is probably one towards the exit.

The situation can get a bit more complex in open source projects though, depending on the structure and size of a project. If no official style guide exists, the graceful thing to do is to simply adopt the code base’s current style when contributing to it. But larger projects that are accustomed to a multitude of random contributors will typically have one defined, which was either worked out by the core developers, or declared by its benevolent dictator for life.

In case of the Linux kernel, that’s of course [Linus Torvalds], who has recently shaken up the community with a mailing list response declaring an overly common, often even unwritten rule of code formatting as essentially obsolete: the 80-character line limitation. Considering the notoriety of his rants and crudeness, his response, which was initiated by a line break change in the submitted patch, seems downright diplomatic this time.

[Linus]’ reasoning against a continuing enforcement of 80-char line limits is primarly the fact that screens are simply big enough today to comfortably fit longer lines, even with multiple terminals (or windows) next to each other. As he puts it, the only reason to stick to the limitation is using an actual VT100, which won’t serve much use in kernel development anyway.

Allowing longer lines on the other hand would encourage the use of more verbose variable names and whitespace, which in turn would actually increase readability. Of course, all to a certain extent, and [Linus] obviously doesn’t call for abolishing line breaks altogether. But he has a point; does it really make sense to stick to a decades old, nowadays rather arbitrary-seeming limitation in 2020?

Continue reading “Ask Hackaday: Are 80 Characters Per Line Still Reasonable In 2020?”

What’s In A Name? Tales Of Python, Perl, And The GIMP

In the older days of open source software, major projects tended to have their Benevolent Dictators For Life who made all the final decisions, and some mature projects still operate that way. Guido van Rossum famously called his language “Python” because he liked the British comics of the same name. That’s the sort of thing that only a single developer can get away with.

However, in these modern times of GitHub, GitLab, and other collaboration platforms, community-driven decision making has become a more and more common phenomenon, shifting software development towards democracy. People begin to think of themselves as “Python programmers” or “GIMP users” and the name of the project fuses irrevocably with their identity.

What happens when software projects fork, develop apart, or otherwise change significantly? Obviously, to prevent confusion, they get a new name, and all of those “Perl Monks” need to become “Raku Monks”.  Needless to say, what should be a trivial detail — what we’ve all decided to call this pile of ones and zeros or language constructs — can become a big deal. Don’t believe us? Here are the stories of renaming Python, Perl, and the GIMP.

Continue reading “What’s In A Name? Tales Of Python, Perl, And The GIMP”

Ask Hackaday: How Would You Build This Flight Tracker For Kids?

You’ve got to hand it to marketers – they really know how to make you want something. All it takes is a little parental guilt, a bit of technical magic, and bam, you’re locked into a product you never knew you needed.

This prototype flight tracking nightlight for kids is a great example. Currently under development by Canadian airline WestJet, the idea is to provide a way for traveling parents to let kids know how long it is until Mommy or Daddy gets home from their trip. The prototype shows a stylized jet airliner with Neopixel lighting in the base. A pair of projectors in the wings shine an animated flight path on the child’s darkened bedroom ceiling, showing them when the wayward parent will return. Get past the schmaltz in the video below, and perhaps get over your jealousy of parents with kids who still eagerly await their return, and it’s actually a pretty good idea.

Now for the ask: how would you go about building something like this? And more importantly, how would you make it work for any plane, train, or automobile trip, and not just a WestJet flight? A look at the “How it will work” section of the page shows several photos of the prototype, which suggests the hardware end is dead easy. A Raspberry Pi Zero W features prominently, and the projectors appear to be TI’s DLP2000EVM, which we’ve featured before, mounted to a riser card. The Neopixels, a 3D-printed case, and the superfluous flashlight fuselage would be pretty easy, too.

On the software side, a generic version that tracks flight from any airline would need an interface for the traveler to define a flight, and something to check an API like FlightAware’s, or similar ones for whatever mode of transportation you’re using.

Seems like a pretty straightforward project. WestJet claims they’ll have their Flight Light ready sometime this summer; think we can beat them to it?

Continue reading “Ask Hackaday: How Would You Build This Flight Tracker For Kids?”

Ask Hackaday: What Skills Would You Give A Twelve Year Old?

In several decades of hanging around people who make things, one meets a lot of people fascinated by locks, lock picking, and locksport. It’s interesting to be sure, but it had never gripped me until an evening in MK Makerspace when a fellow member had brought in his lockpicking box with its selection of locks, padlocks, and tools. I was shown the basics of opening cheap — read easy from that padlocks, and though I wasn’t hooked for life I found it to be a fascinating experience. Discussing it the next day a friend remarked that it was an essential skill they’d taught their 12-year-old, which left me wondering, just what skills would you give to a 12-year-old? Continue reading “Ask Hackaday: What Skills Would You Give A Twelve Year Old?”