Handmade: A Community for Self-Rolled Performant Software (2016)

Software industrial complex is a great description.

Everything is about software; thus the collective incentivizing of writing more and more software. We see it as a bad sign when the commits stop flowing. Despite the source being there, it is viewed as stagnant.

Nobody even stops to ask if the project is simply done, and doesn't need anything else.

The Handmade metaphor masks a key difference between software and physical goods. IIUC, mass-produced physical goods are inferior to their handmade counterparts because of the trade-offs that enable profitable mass production. So we have a strong emotional attachment to handmade things being better, and the Handmade movement plays on that emotional attachment.

But the metaphor breaks down if you think about it. A carpenter making a single piece of furniture can tailor it to the person who will be sitting on it. A cook making a meal for one person can tailor it to their dietary requirements or tastes. But software of any non-trivial scale is rarely written for one person. Even when it's developed according to the ideals of the Handmade movement, it will be mass-distributed.

I actually think that, contrary to our intuition about handmade things, Handmade software tends to have compromises compared to software that builds on well-established components. I won't repeat miki123211's top-level comment [1]. I'll just add here that it's precisely the economics of large-scale software distribution that allow concerns such as internationalization and accessibility to be addressed, while a solo Handmade project will probably not have these important things.

So, while slinging JavaScript code with no regard for performance and packaging it with Electron is certainly not the ideal, I strongly believe that the Handmade approach isn't either. As is so often the case, we need a middle ground.

[1]: https://news.ycombinator.com/item?id=24186711

A pedantic point, buffer overflow protection and the GC are separate things. Buffer overflow protection is bounds checking, GC's are ensuring memory that is no longer in use is reclaimed. But the boundaries on the programs you mention, are more to do with the system not allowing these actions than the language.

Also, there are other ways to achieve memory safety for all but maybe a few cases without a GC. One being ref counted structures that have loops in the links. Another case, but it has work arounds, is postponing the cleanup until a later time. But C++ provides guarantees like, at scope end the destructors(finalizers) are run and the values are cleaned up. This allows for more than memory safety and can include other resources too. This is easier in greenfield projects where old idioms/C compatibility are more common.

To add to your point, high level abstractions allow for optimal code as it is more declarative. The low level constructs to make it fast are of no concern to the caller. And one can build upon this for new higher level abstractions.

I figured this point of view would come up in this discussion. What you're really implying here, though, is that it's impossible to produce quality "hand-crafted" (that is, zero-dependency) software, or that it's so time-consuming that it might as well be considered impossible.

I'm not 100% sure I even agree that it takes longer to produce software that builds on top of a tower of dependencies than it does to just program the damned thing yourself, but it seems indisputable that the finished product will be higher quality than the one that defers as much functionality off to external dependencies as possible. Why? Because for an external dependency to be useful, it has to address many different use cases. To do that, it has to expose abstractions that only exist to allow reuse. The unused use cases cause memory bloat (that even tree shaking won't address all of) and the abstractions slow things down at runtime.

But beyond that... why are you guys always in such an almighty goddamned hurry? You do realize that if you succeed in rushing out an inferior, shameful, mass-produced crud app, there's either another one waiting in the wings immediately after this one, or there's no reason to keep you around? Why not take pride in your work and insist on spending the time needed to produce the best quality, most efficient, smallest footprint, most user-friendly, snappy, responsive software possible? Users despise the software 99% of us churn out and I don't blame them - it feels like somebody was putting in the least work possible so they could leave work a half hour early in time to make it to the golf course.

You make good points. And I do think miki123211 is conflating memory safety with GC.

But the concerns about Handmade software lacking important user-facing things like accessibility and internationalization are real. TO take one particularly ironic example, lots of tools in the field of audio production roll their own GUIs, and invariably, these UIs are completely inaccessible to screen reader users. I say this is ironic because "blind musician" is such a stereotype. To dispense with a straw man, it's true that Electron would not be a good fit for these tools. But maybe their developers could accept the size of something like Qt in exchange for a GUI that works for all users without having to roll it themselves. You say that engineers should be aware of trade-offs, but in my experience, way too many, even very talented engineers, seem to ignore this one.