Live data from Hacker News

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

handmade.network

41–50 of 96 posts

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

#41

What people don't realize is that modern, high-level languages and abstractions give you much more than just speed of development. If you use a garbage collector, you don't have to do manual memory management, which is amazing for security. You also don't need to worry about buffer overflows and weird pointer exploits. If you use web tech, you get a lot of important stuff, like sandboxing, handling of esoteric keyboa…

> If you use web tech, you get a lot of important stuff, like sandboxing, ... for free

That’s very context dependent, no? Electron removes a heap of sandbox limitations does it not?

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

#42

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 car…

> But software of any non-trivial scale is rarely written for one person.

Maybe it should be? Much like how people cook for themselves all the time, it seems reasonable to encourage people to code for themselves at least every once in awhile.

The overwhelmingly vast majority of software I've written, both personally and professionally, has been software with exactly one user: myself. Usually these are indeed "trivial" programs or scripts, but they are indeed software nonetheless, and are crafted to my tastes, much like how the vast majority of the meals I cook are for myself alone and are cooked to my tastes.

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

#43
post #38

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 car…

> As is so often the case, we need a middle ground. This is not a popular opinion here, but: the middle ground is writing handmade native apps using native OS widgets. You get both the speed and a mature environment to work with. If you follow the platform conventions you will probably have better accessibility and internationalisation support than Electron. They will run fast as a bullet. They will consume a puny am…

I mostly agree with you. But which toolkit for Windows is the "native" one? This is a well-known problem with Windows development, so I won't belabor it here. Hopefully Project Reunion improves the situation. But the murky state of native development on Windows is a big reason why developers just throw up their hands and go with something non-native that at least will work consistently all the way down to Windows 7 (or XP before that).

Disclosure: I work for Microsoft, but on the Windows accessibility team, not on a UI framework or developer tools.

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

#44

What people don't realize is that modern, high-level languages and abstractions give you much more than just speed of development. If you use a garbage collector, you don't have to do manual memory management, which is amazing for security. You also don't need to worry about buffer overflows and weird pointer exploits. If you use web tech, you get a lot of important stuff, like sandboxing, handling of esoteric keyboa…

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 r…

I should have said, less common in greenfield projects. oops

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

#45

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 car…

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 pr…

> 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.

You seem to be treating "quality" as a synonym for performance. But it doesn't matter how high-performance your GUI is if someone can't use it because, for example, it doesn't support their language or their assistive technology (e.g. screen reader or alternative input). And supporting these things requires -- guess what? -- abstractions, that take lots of time to implement if you roll your own GUI from the ground up. That's why I stand by my view, which you nicely summarized in your opening paragraph.

Your last paragraph is a tired straw man. No one has the time to develop software that's perfect in every way. When we sacrifice absolute performance, it's not necessarily for the sake of slapping together crap software to make a quick buck. Suppose I set out to solve an urgent problem in my chosen field (accessibility). Shipping my solution faster doesn't just mean that I can quit work faster and start making money. It also means the solution can start making a positive difference in users' lives sooner. In light of that, it would be irresponsible for me to obsess over maximizing speed or minimizing RAM consumption, as much as some vocal nerds might insist that I have a responsibility to do so. My real responsibility is to the users who are waiting for the solution that I'm developing. Now, that doesn't mean that I should absolutely ignore performance or resource consumption, but I shouldn't obsess over them either, and I certainly shouldn't use them as reasons to waste time developing everything from the ground up when there are so many high-quality components I can use.

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

#46
post #38

Earlier quoted context omitted.

> As is so often the case, we need a middle ground. This is not a popular opinion here, but: the middle ground is writing handmade native apps using native OS widgets. You get both the speed and a mature environment to work with. If you follow the platform conventions you will probably have better accessibility and internationalisation support than Electron. They will run fast as a bullet. They will consume a puny am…

I mostly agree with you. But which toolkit for Windows is the "native" one? This is a well-known problem with Windows development, so I won't belabor it here. Hopefully Project Reunion improves the situation. But the murky state of native development on Windows is a big reason why developers just throw up their hands and go with something non-native that at least will work consistently all the way down to Windows 7 (…

Glad to see someone from Microsoft interested in seeing this issue solved. :)

Well, native for me is whatever provides native look and feel. Win32 if you want C/C++, WinForms (yeah I know) if you're ok with C#. Most people featured in the article's website would only consider "truly native" as being Win32, though, which is fine.

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

#47

What people don't realize is that modern, high-level languages and abstractions give you much more than just speed of development. If you use a garbage collector, you don't have to do manual memory management, which is amazing for security. You also don't need to worry about buffer overflows and weird pointer exploits. If you use web tech, you get a lot of important stuff, like sandboxing, handling of esoteric keyboa…

> If you use web tech, you get a lot of important stuff, like sandboxing, ... for free That’s very context dependent, no? Electron removes a heap of sandbox limitations does it not?

Actually it has been adding them back in the renderer process, and encouraging developers to use explicit IPC between the renderer process and the main process.

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

#48

What people don't realize is that modern, high-level languages and abstractions give you much more than just speed of development. If you use a garbage collector, you don't have to do manual memory management, which is amazing for security. You also don't need to worry about buffer overflows and weird pointer exploits. If you use web tech, you get a lot of important stuff, like sandboxing, handling of esoteric keyboa…

If you want the advantages of the garbage collector but the power of native there are languages like D, Go, Rust, Objective-C, Swift.

If you want an "extremely fast, small and lightweight GUI framework" that also handles esoteric keyboards, RTL languages, screen reader accessibility and other things you can use your OSs native controls. I bet most naïve (and native) Cocoa/Win32 app will give you 100x better keyboard navigation than most Electron apps from large companies.

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

#49

Earlier quoted context omitted.

> If you go the handcrafted, lightweight and fast route, you're sacrificing a lot of features, possibly without even being aware of what you lose until it's too late. And, just to amplify the point about accessibility, you may be blocking some people from using your app. So it's not entirely about what you lose. That's not so bad if you're developing a game. But the projects on this site include a programmer's editor…

Handmade GUIs, frameworks drawing on canvas instead of using DOM, and abominations like VNC over web instead of normal desktop apps seem to be the new accessibility plague. We're pretty much done with Flash and Java on the desktop, QT isn't that bad any more, accessibility-wise, but this kind of stuff is now becoming more and more popular. I've heard of systems that promise you better utilization of your licensing re…

Not everything needs to prioritize accessibility. This page is mostly tools for video games which typically have no accessibility. I think you may be bringing a pet concern into an area that isn't relevant.

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

#50
post #16

Earlier quoted context omitted.

Yes, it's being praised here (however this is also in the "hobby" context, supporting my argument somewhat). But what I am saddend, more than annoyed, about, is that it's extremely lopsided in general. I don't have a tally, but reading HN and other tech sources (HN is not an outlier here), these kinds of stories are buried under the mountain of articles and resources that hype up the "software industrial complex" (fo…

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.

I mean, with how connected most computers are these days, even something as simple as a phone charger needs security updates.
Post reply on HN