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?”

Before Computers: Notched Card Databases

It is hard to remember that practical computers haven’t been around for even a century, yet. Modern computers have been around an even shorter period. Yet somehow people computed tables, kept ledgers, and even wrote books without any help from computers at all. Sometimes they just used brute force but sometimes they used little tricks that we’ve almost forgotten. For example, only a few of us remember how to use slide rules, but they helped send people to the moon. But what did database management look like in, say, 1925? You might think it was nothing but a filing cabinet and someone who knew how to find things in it. But there was actually a better system that had fairly wide use.

Continue reading “Before Computers: Notched Card Databases”

Arduino Reads Punch Cards

Punch cards were a standard form of program and data storage for decades, but you’d never know it by looking around today. Card punches and even readers are becoming rare and expensive. Sometimes it takes a bit of hacking [YouTube link] to get that old iron running again!

[Antiquekid3] managed to score an old punch card reader on Ebay, but didn’t have a way to interface with it. The reader turned out to be a Documation M-1000-L. After a bit of searching, [Antiquekid3] managed to find the manual [PDF link] on BitSavers. It turns out that the Documation reader used a discrete output for each row of data. One would think the Documation reader would be a perfect fit for the PDP-8 lurking in the background of [Antiquekid3’s] video, but unfortunately the ‘8 lacks the necessary OMNIBUS card to interface with a reader.

Undaunted, [Antiquekid3] threw some modern hardware into the mix, and used an Arduino Uno as a Documation to Serial interface. The Arduino had plenty of I/O to wire up with the card reader’s interface. It also had a serial interface which made outputting data a snap. The ATmega328 even had enough power to translate each card from one of IBM’s many keypunch formats to serial.

[Antiquekid3’s] test deck of cards turned out to be a floating point data set. Plotting the data with a spreadsheet results in a nice linear set of data points. Of course, no one knows what the data is supposed to mean! Want more punch card goodness? Check out this tweeting punch card reader, or this Arduino based reader which uses LEGO and a digital camera to coax the data from the paper.

Continue reading “Arduino Reads Punch Cards”

Retrotechtacular: Once Upon A Punched Card


Ah, the heady days of the early 60s, where companies gave their salesmen exquisitely produced documentaries, filled with incidental music written by the best composers of the era, and a voice actor that is so unabashedly ordinary you would swear you’ve heard him a hundred times before. It’s a lot better than any PowerPoint presentation anyone could come up, and lucky for us, these 16mm films are preserved on YouTube for everyone to enjoy. This one was sent out to IBM sales reps pushing a strange technology called a ‘punched card’, a system so efficient it will save your company tens of thousands of dollars in just a few short years.

Like most explanations of what a punched card does, this IBM documercial begins with the history of the Jacquard loom that used punched cards for storing patterns for textile weaving. In a rare bit of historical context befitting IBM, this film also covers the 1880 US census, an important part in the evolution of punched cards being used not as instructions for a loom, but data that could be tabulated and calculated.

The United States takes a census every ten years. The tenth census of 1880 took so long to compile into the data – seven years – it was feared the next census of 1890 wouldn’t be complete until the turn of the century. This problem was solved by [Herman Hollerith] and his system of encoding census data onto punched cards for tabulation. [Hollerith] would later go on to found the Tabulating Machine Company that would later merge with two other companies to form IBM. Isn’t it great that IBM chose to include that little nugget in their film.

As a point of interest, the film does contain a short pitch for IBM punched card writers, sorters, and calculators – the backbone of IBM’s medium to large size business sales. At the time this film was produced (1964) IBM was ready to announce the System/360, what would become the de facto mainframe for businesses of all sizes.  Yes, the /360 also used punched cards, but we wonder how many angry phone calls the sales reps received months after showing this film.