Hacker News Reader

> 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 the tradeoffs they've made at all.

This is all simply about where engineers start off today, and how woefully uninterested they often are in expanding their horizons, and how uninterested they tend to be in studying the history of their discipline.

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.

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

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.

I agree, but it sounds to me that the issue then is not with lean and mean code per se. Both AirWindows and people using native interfaces in plugins are leaner, meaner and more accessible than your example.

And by the way, to keep on topic, "handmade" audio software people are not really creating their own GUI toolkit. That's the big boys at Waves, Native Instruments, IK Multimedia, etc.

The problem to me is that people are trying to make things that look exactly the same everywhere with complete disregard for both the user and the particularities of each platform.

And by platform I don't just mean the OS: one of my pet peeves with audio software are plugins that skip the DAW's preset saving and implement their own. The walked an extra mile only to give me a shitty interface when I wish I could just use Logic presets or whatever.

There are much deeper and more sophisticated reasons why inaccessibility to screen readers is not really the core of why we should consider audio production software to be inaccessible.

This is a debate/discussion I've been having for 20+ years now (as the original author of Ardour).

The GUI of a typical DAW (or even a moderately sophisticated plugin) serves as memory aide for sighted users. 48 tracks? Which ones did I mute? A sighted user doesn't have to remember - they can just look.

Sight-impaired/blind users of older hardware mixing consoles use the tactile experience of those devices to partially fulfill the same role, which is why modern full digital consoles with tap-only-LED-lit buttons are so much harder for them to use: they have to either remember or investigate which features are enabled and which are not.

In addition, most DAW and many plugin GUIs present information in ways that are more or less inconceivable for screen reader presentation. Waveforms are the obvious example, although here perhaps sight-impaired users have what some would consider an advantage, in that they are forced to work entirely by ear, rather than use on-screen representations that have only a debatable relationship with the sound.

But routing presents another area where it can be very difficult to present the current state in a way that could ever be rendered meaningful by a screen reader.

Please don't think that I don't view accessibility or i18n as of critical importance - I absolutely do. But I also think that when application niches (like audio production) evolve their own highly-developed visual language to supplement and assist (sighted) users, that the correct/better answer for sight-impaired users may be non-graphical applications rather than trying to figure out to how speech-render the graphical representation.

This is one area in which Linux is far ahead of Windows and macOS: there are numerous command line applications available for audio production which would strike utter fear into the hearts of most sighted users, but that turn out to be incredibly great for sight-impaired users. Ecasound, I'm looking at you (among others).

You obviously know way more about this field than I do. I'm a dilettante when it comes to recording in general, never mind developing a DAW. Thanks for sharing your thoughtful insights.

> the correct/better answer for sight-impaired users may be non-graphical applications rather than trying to figure out to how speech-render the graphical representation.

This cuts to the heart of a long-standing debate among accessibility advocates and blind techies. It's true that tools tailored specifically for blind people can be more productive and easier to use. But they can also isolate the blind community from the sighted mainstream. For example, would a DAW developed specifically for blind people enable them to collaborate with sighted peers, or to use one-of-a-kind plugins that are developed for mainstream DAWs with a visual interface? This is why, while retrofitting accessibility onto a GUI is often suboptimal, it's necessary.

What do you think about the following trade-off? (a) make a software accessible to 99.9% of the population with base-level quality-of-life (b) only be accessible to 98% but increase quality-of-life by 5% for the rest

(I am not trying to make a point, just curious.)

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 should have said, less common in greenfield projects. oops

What is your point? The way refcounted smart pointers are used in modern c++ doesn't come close to addressing all the memory safety issues. Iterator invalidation, bounds checking, use of uninitialized memory, use after move, dangling reference (outside the aforementioned cases), etc.

What they're pretty good at is solving for use after free. Even there, caveats apply (see widely documented thread safety fiasco of shared_ptr).

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.

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

Sure, we still have to fight that uphill battle. But it's way easier for a web application to implement ARIA than for a Win32 application with a custom control to implement UI Automation. Maybe that problem is unique to Windows.

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

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

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.

> I bet most naïve (and native) Cocoa/Win32 app will give you 100x better keyboard navigation than most Electron apps from large companies.

That may be true for Cocoa, but it actually isn't for Win32. It takes work to make keyboard navigation work correctly in Win32, unless you're using a dialog with nothing but standard controls (note: dialog means something specific in Win32). Windows Forms helps with this. Also, as soon as you depart from the stock Win32 controls, you have to implement the UI Automation accessibility API entirely on your own, and that's not an easy task even for a single custom control. So there are actually good reasons why Win32 isn't a good choice for new projects.

There's another reason why web applications tend to be more navigable with third-party Windows screen readers than native applications. For the mainstream web rendering engines, third-party screen readers enable a sort of virtual cursor that let's the user navigate the DOM in a linear way by pressing the up and down arrow keys. This makes it straightforward to navigate to anything in the document, even if the application itself doesn't implement keyboard navigation. Now, this same navigation model could just as well be applied to native applications, and the Narrator screen reader built into Windows actually does offer that option. The fact that third-party screen readers restrict that option to web content is arguably a deficiency, but one that developers who care about accessibility should consider when targeting Windows today.

Disclosure: I work for Microsoft on the Windows accessibility team, primarily on UI Automation and Narrator. These are my own opinions though.

Doesn’t the ImGUI UI library have pretty good accessibility now without sacrificing on memory consumption and performance?

JavaScript is difficult to program in a safe way, so I’m going to assume the Messenger app is written in something safer too.

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

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

> 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 and a debugger, both of which are completely inaccessible with a screen reader because, of course, they use a handmade GUI.

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 resources, but what they do is put your precious 10 computers with some expensive software on the internet, letting any employee with a web browser book some time and access them via Web VNC. That's a brilliant way to turn a perfectly-accessible Windows app into something you can literally do nothing with.

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.

What we, or at least I, want to ensure is that developers outside of the gaming context don't get too fired up by this manifesto, develop non-game-related tools in that spirit, and thereby block someone from doing their job because the tool is inaccessible.

Not everything is going to work for everyone from the very start. You don't need to stomp on every piece of software because it doesn't have niche features that you care about intensely. Pick your battles, each of these programs were created by a single person and are open source. They aren't government websites, they aren't even the only way do the things they do.

Pretty sure OP’s article is advocating completely removing that whole massive stack of trash of web tech and instead use technology designed for the particular computer they are running on.

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

So bizarre to claim Messenger is secure because it was written in Javascript.