Art of 3D printer in the middle of printing a Hackaday Jolly Wrencher logo

Ask Hackaday: Are Extruders The Only Feasible Tools For Toolchanging?

Toolchanging in 3D printers is no longer something from the bleeding edge; it’s going mainstream. E3D has a high-quality kit for a toolchanger and motion system, our own Joshua Vasquez has shared details about the open-source toolchanging Jubilee design, and just recently Prusa3D formally announced the Prusa XL, which promises toolchanging with up to five different extruders.

A toolchange in progress

It’s safe to say toolchanging on 3D printers has stepped to the front, but what comes next? What kind of tools other than extruders make sense on a 3D printer?

First, let’s explain what makes separate extruders such fantastic tools. Being able to change extruders on-demand during a print enables things like true multi-material printing. Printing in more than one color or material will no longer be done by pushing different filaments through a single nozzle, which limits a print to materials that extrude under similar conditions and temperatures. Toolchanging means truly being able to print in multiple materials, even if they have different requirements, because each material has its own extruder. That’s a clear benefit, but what about tools other than extruders?

Continue reading “Ask Hackaday: Are Extruders The Only Feasible Tools For Toolchanging?”

Ask Hackaday: Why Don’t Automakers Make Their Own EV Batteries?

Sales of electric vehicles continue to climb, topping three million cars worldwide last year. All these electric cars need batteries, of course, which means demand for rechargeable cells is through the roof.

All those cells have to come from somewhere, of course, and many are surprised to learn that automakers don’t manufacture EV batteries themselves. Instead, they’re typically sourced from outside suppliers. Today, you get to Ask Hackaday: why aren’t EV batteries manufactured by the automakers themselves? Continue reading “Ask Hackaday: Why Don’t Automakers Make Their Own EV Batteries?”

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”