Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

handmade.network

Post reply on HN
Print view View original

51–60 of 96 posts

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

#51

Post by ratww »

mwcampbell wrote: post #39
justin66 wrote: post #34

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. The notion that an engineer signing on to make high-performance software in 2020 doesn't know what they're "sacrificing" is a little unreasonable. Conversely, it seems unlikely most people developing the kind of software you're advocating for understand…

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

A lot of VST/AU plugins already use Qt, JUCE or SynthMaker for the GUI and are completely inaccessible.

On the other hand, there are a lot of web pages and Electron apps that are completely inaccessible as well, despite using accessibility-ready web tech.

The problem is not really the lack of an abstraction layer, but more the fact that those developers are doing a shitload of work to make something look über cool and different from everyone else without taking a couple weeks (or maybe not even that much) to iron out accessibility issues.

By the way, at least for plugins, another option is not doing any GUI at all and just exposing all parameters to the host, like the AirWindows guy does [1]. Or using native OS controls. This is both very accessible and EXTREMELY cheap.

[1] http://www.airwindows.com

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

#52

Post by onion2k »

stephenr wrote: post #41
miki123211 wrote: post #21

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?

Electron removes a heap of sandbox limitations does it not?

That's not really web dev. It's the application of web tech to something that isn't web. A slightly pedantic point I guess, but if you choose to give up the benefits of a browser you can't really complain that you don't have them any more.

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

#53

Post by mwcampbell »

ratww wrote: post #51
mwcampbell wrote: post #39

Earlier quoted context omitted.

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

A lot of VST/AU plugins already use Qt, JUCE or SynthMaker for the GUI and are completely inaccessible. On the other hand, there are a lot of web pages and Electron apps that are completely inaccessible as well, despite using accessibility-ready web tech. The problem is not really the lack of an abstraction layer, but more the fact that those developers are doing a shitload of work to make something look über cool an…

No disagreement there. Still, there are also developers who go out of their way to make their software both cool-looking and lean and mean by rolling their own GUI toolkit... and now it would take them way longer to implement accessibility.

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

#54

Post by flohofwoe »

miki123211 wrote: post #21

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…

IMHO these are unrelated problems. There's nothing preventing those 'handmade' libraries from using memory-safe languages and development practices, or calling into accessibility APIs provided by operating systems (assuming they are provided by operating systems), and on the other hand, Electron is the opposite of the 'handmade philosophy', but is still not accessible.

There's required complexity, and unnecessary complexity, and the latter is the worse problem in modern 'industrial' software by far, because industrial software isn't developed by customers needs, but by business needs, and the gap between what customers want and what the industry provides seems to widen more and more each year.

This 'industrial software development' that doesn't serve the user anymore is what the handmade philosophy is providing an alternative to.

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

#55

Post by stephenr »

onion2k wrote: post #52
stephenr wrote: post #41

Earlier quoted context omitted.

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

Electron removes a heap of sandbox limitations does it not? That's not really web dev. It's the application of web tech to something that isn't web. A slightly pedantic point I guess, but if you choose to give up the benefits of a browser you can't really complain that you don't have them any more.

> That's not really web dev.

I didn't claim that it is.

> It's the application of web tech

So you can see then why I quoted the part of the parent comment that says:

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

The parent didn't say "if make a web site" s/he said "if you use web tech".

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

#56

Post by vmchale »

miki123211 wrote: post #21

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 a garbage collector, you don't have to do manual memory management

Also easy higher-order functions. Plus it can be more performant in some cases.

> I will happily shelve a few more bucks for RAM and wait a few more seconds

I have 64GB on my desktop (happily!) but waiting is a bit of a pain! And it's often for silly reasons.

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

#57

Post by gameswithgo »

miki123211 wrote: post #21

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

Some modern languages offer memory safety and very very high performance ceilings as well, if you are willing to learn how and work at. Examples include, C#, Rust, F#, and Nim. There are others!

And any language, taking some time to understand performance pitfalls, and leveraging the language the best you can, can make a huge difference. Sometimes without any major maintenance or dev time penalty. It just takes caring, and practice.

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

#58

Post by fulafel »

miki123211 wrote: post #21

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…

The linked manifesto doesn't seem to be especially against garbage collection. And on their web site the latest news item is a "Lisp Jam"...

The only reference to GC is in this sentencs: "The deadline is approaching or the rent is due or we have taxes to fill out and a manager on our back and someone asking us why we always spend so much time at the office, and we just have to stick the library or virtual machine or garbage collector in there to cover up the places we can't think through right now. "

The situation is kind of choosing-shame-but-ending-up-in-war outcome[1] and is not saying that the referenced techniques (incl gc) would be generally bad.

[1] https://richardlangworth.com/war-shame

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

#59

Post by mwcampbell »

flohofwoe wrote: post #54
miki123211 wrote: post #21

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…

IMHO these are unrelated problems. There's nothing preventing those 'handmade' libraries from using memory-safe languages and development practices, or calling into accessibility APIs provided by operating systems (assuming they are provided by operating systems), and on the other hand, Electron is the opposite of the 'handmade philosophy', but is still not accessible. There's required complexity, and unnecessary com…

> Electron is the opposite of the 'handmade philosophy', but is still not accessible.

On the contrary, Chromium probably has the single most mature and robust implementation of accessibility APIs across platforms. It's true that not all Electron apps are accessible, but it's way easier to make an Electron app accessible than to make a handmade GUI accessible.

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

#60

Post by flohofwoe »

mwcampbell wrote: post #59
flohofwoe wrote: post #54

Earlier quoted context omitted.

IMHO these are unrelated problems. There's nothing preventing those 'handmade' libraries from using memory-safe languages and development practices, or calling into accessibility APIs provided by operating systems (assuming they are provided by operating systems), and on the other hand, Electron is the opposite of the 'handmade philosophy', but is still not accessible. There's required complexity, and unnecessary com…

> Electron is the opposite of the 'handmade philosophy', but is still not accessible. On the contrary, Chromium probably has the single most mature and robust implementation of accessibility APIs across platforms. It's true that not all Electron apps are accessible, but it's way easier to make an Electron app accessible than to make a handmade GUI accessible.

Yeah, ok, but the problem is the same: even though accessibility APIs might be provided (this time by Electron, not the OS), applications don't make use of them.
Post reply on HN