3 ms·

The Handmade metaphor masks a key difference between software and physical goods. IIUC, mass-produced physical goods are inferior to their handmade counterparts

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 https://news.ycombinator.com/item?id=24186711

commandlinefan 6y ago
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.
- mwcampbell 6y ago
  > 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.
ratww 6y ago
> 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 amount of memory. They will have dark mode for free on macOS. They will look like most other applications that come with the OS. It probably also has a graphical editor that will make your job easier (.NET, MFC, Cocoa, all have). If it's something like .NET you won't even have to worry much about the "Turkish internationalisation Problem" that we were discussing yesterday. [1] Things like localisation that require a framework/library in the web world are probably handled by the libraries provided by the OS vendor. If it's "handmade", you're already putting a lot of effort that you wouldn't put in your day job. Why not use that effort to port directly to each platform, instead of recreating everything from scratch? For Linux the situation is more complicated, of course, but maybe Qt is acceptable? [1] https://blog.codinghorror.com/whats-wrong-with-turkey/ https://blog.codinghorror.com/whats-wrong-with-turkey/
- mwcampbell 6y ago
  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.
  - ratww 6y ago
    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.
yellowapple 6y ago
> 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.
stonemetal12 6y ago
> 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. It could be written for one person and mass-distributed with the understanding that you are using software written for Bob's needs. >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. You have mixed up cause and effect here. Internationalization is a concern caused by mass distribution, not an existing concern not being addressed. The same goes for accessibility. Handmade software will meet the accessibility needs of the one person it is written for. Have different accessibility needs? That is a different piece.

commandlinefan 6y ago

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.

mwcampbell 6y ago
> 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.

ratww 6y ago

> 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 amount of memory. They will have dark mode for free on macOS. They will look like most other applications that come with the OS. It probably also has a graphical editor that will make your job easier (.NET, MFC, Cocoa, all have). If it's something like .NET you won't even have to worry much about the "Turkish internationalisation Problem" that we were discussing yesterday. [1] Things like localisation that require a framework/library in the web world are probably handled by the libraries provided by the OS vendor. If it's "handmade", you're already putting a lot of effort that you wouldn't put in your day job. Why not use that effort to port directly to each platform, instead of recreating everything from scratch? For Linux the situation is more complicated, of course, but maybe Qt is acceptable? [1] https://blog.codinghorror.com/whats-wrong-with-turkey/ https://blog.codinghorror.com/whats-wrong-with-turkey/

mwcampbell 6y ago
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.
- ratww 6y ago
  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.

yellowapple 6y ago

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

stonemetal12 6y ago

> 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. It could be written for one person and mass-distributed with the understanding that you are using software written for Bob's needs. >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. You have mixed up cause and effect here. Internationalization is a concern caused by mass distribution, not an existing concern not being addressed. The same goes for accessibility. Handmade software will meet the accessibility needs of the one person it is written for. Have different accessibility needs? That is a different piece.