3 ms·

This article, like many similar to it, makes the (imo flawed) assumption that a dev tool ought to be evaluated on only a few variables--e.g., code quality, perf

by bmpafa 10y ago

This article, like many similar to it, makes the (imo flawed) assumption that a dev tool ought to be evaluated on only a few variables--e.g., code quality, performance, package size. If writing software is about making users' lives easier, happier, or better, though, I think we ought to optimize for that and that alone. I say let the market and communities of users decide which software they want to use. I use Nylas b/c I like the UX better than Ubuntu's Evolution, despite its flaws. I use Caret (electron markdown editor) because I wanted a cross-platform tool and I have > 4 gigs of ram. Hell, millions still use the Facebook Android app, despite the fact that it sucks down battery juice like your crazy uncle sucks down Miller Genuine Drafts before lecturing you on how terrible millennials are (happy Thanksgiving, btw). Of course, it's important we know the trade-offs of the decisions we make, so we need critical pieces like this. But to be as prescriptive as this article is to miss the forest for the trees. Love it or not, JS is a point of entry for a hell of a lot more ppl than C++ is, so expanding its reach into new arenas is not only net-good, but I'd argue also inevitable. That said, the article does skirt an issue I've thought about a little, and I'm interested to hear others' takes. If software collectively moves more towards higher-end systems, e.g., with SPAs and electron apps and all their cpu-intensive renders, are we further limiting a great web UX to those with the money to afford the latest laptops? We spend a lot of time thinking about accessibility standards for our products (A11Y, etc.), but when should we begin to think about accessibility from a socioeconomic perspective? Or are performant computers now so accessible that we needn't worry?

rootlocus 10y ago
> If writing software is about making users' lives easier, happier, or better, though, I think we ought to optimize for that and that alone. That's (imo) your flawed assumption. And no, just choosing electron won't make your users happier. > Love it or not, JS is a point of entry for a hell of a lot more ppl than C++ is C++ is not the only alternative. And considering the staggering amount of frameworks and tools one must learn to get started with JS other alternatives are actually easier. Unfortunately, not as cool. > That said, the article does skirt an issue I've thought about a little, and I'm interested to hear others' takes. Is this a joke? I had to google what skirt means: "attempt to ignore; avoid dealing with." That's the exact opposite of what the article does. Let me quote it for you: About electron: "One of the slowest, least memory efficient [...]" About terminal: "They’ve taken one of the most lightweight and essential tools on your computer and bloated it by orders of magnitude. " About lossless-cut: "For the price of 200 extra MiB of disk space and an entire Chromium process in RAM and on your CPU [..]" The conclusion that "people will require more money to buy more hardware to run bloated software" is not something only you thought about, it's only one step away from what the article says. And it's actually hilarious (read: infuriating) that you don't see the problem with that way of thinking. NASA put people on the moon with computers less powerful than a mobile phone. The article criticizes people who write bloated software, but you argue it's fine, because users are happy. Then you go on wondering if it's a problem that users won't afford the latest laptops to run bloated software. WAT?
- bmpafa 10y ago
  > just choosing electron won't make your users happier. Ah thanks, I lost some clarity in a post-write edit. My point wasn't that choosing electron would do that, it was that we should look more at end-user satisfaction and less at often pedantic technical analyses of solutions. Re: C++: You may be right, but we can't deny that popularity and cool factor has a significant effect on hard metrics--eg, more frameworks, more libs, more components == faster dev speed & iterations, which I think is a good thing. ex: Mac hasn't been "better for graphics" in over a decade, but the 'cool factor' has made it the de facto choice for designers, which has resulted in a bulk of the latest designer tools being Mac only (a problem which, coincidentally, electron & its ilk aim to solve). Last: no, it wasn't a joke. I know what the article said. My point was that the point of socioeconomic accessibility was mentioned, as you note, in the last line, but for the most part, the supporting data were more asserted as intrinsically bad. If it was a key argument of the author's, I think the data would've been tied coherently to the conclusion instead of requiring a diligent reader such as yourself to farm & cobble them together into a patchwork argument. So, if you'll forgive me for borrowing a little of your snark: next time you google a word, for instance, 'skirt', you should probably prefer the first definition ("go around, past the edge of") instead of the fourth definition, as you've done here. To be clear, my thesis is, in tl;dr form: "Anything that makes reaching users in the environments they prefer easier is probably good, but the extent to which this trades off with accessibility is unclear to me."
  - rootlocus 10y ago
    > you should probably prefer the first definition ("go around, past the edge of") instead of the fourth definition, as you've done here. That was the third definition. The first definition was "a woman's outer garment fastened around the waist and hanging down around the legs." /snark > we should look more at end-user satisfaction and less at often pedantic technical analyses of solutions. They aren't orthogonal. User satisfaction comes from a smooth experience. Regardless of how shiny something is, if it slows down the rest of the system (or is itself laggy) users will notice. I choose to run foobar instead of other music players because it's small and fast. > are we further limiting a great web UX to those with the money to afford the latest laptops? This is what infuriates me. People have been talking about how the "free lunch" is over [1] since 2009. About how CPUs have stopped getting faster, and how we should make the best out of the current hardware by learning to paralelize. Yet javascript is the most popular language and it's fundamentally single threaded. High quality software is not about having "a great web UX". VLC doesn't have it (great web UX). Blender doesn't have it. Intellij IDEA doesn't have it. And they're not only extremely complex and efficient softwares, they also have great UIs. Our computers are extremly powerful. The fact that someone would wonder if they're not enough to run pretty clipboard managers and fancy text editors is making me cringe. [1] http://www.gotw.ca/publications/concurrency-ddj.htm http://www.gotw.ca/publications/concurrency-ddj.htm

by bmpafa 10y ago

rootlocus 10y ago

> If writing software is about making users' lives easier, happier, or better, though, I think we ought to optimize for that and that alone. That's (imo) your flawed assumption. And no, just choosing electron won't make your users happier. > Love it or not, JS is a point of entry for a hell of a lot more ppl than C++ is C++ is not the only alternative. And considering the staggering amount of frameworks and tools one must learn to get started with JS other alternatives are actually easier. Unfortunately, not as cool. > That said, the article does skirt an issue I've thought about a little, and I'm interested to hear others' takes. Is this a joke? I had to google what skirt means: "attempt to ignore; avoid dealing with." That's the exact opposite of what the article does. Let me quote it for you: About electron: "One of the slowest, least memory efficient [...]" About terminal: "They’ve taken one of the most lightweight and essential tools on your computer and bloated it by orders of magnitude. " About lossless-cut: "For the price of 200 extra MiB of disk space and an entire Chromium process in RAM and on your CPU [..]" The conclusion that "people will require more money to buy more hardware to run bloated software" is not something only you thought about, it's only one step away from what the article says. And it's actually hilarious (read: infuriating) that you don't see the problem with that way of thinking. NASA put people on the moon with computers less powerful than a mobile phone. The article criticizes people who write bloated software, but you argue it's fine, because users are happy. Then you go on wondering if it's a problem that users won't afford the latest laptops to run bloated software. WAT?

bmpafa 10y ago
> just choosing electron won't make your users happier. Ah thanks, I lost some clarity in a post-write edit. My point wasn't that choosing electron would do that, it was that we should look more at end-user satisfaction and less at often pedantic technical analyses of solutions. Re: C++: You may be right, but we can't deny that popularity and cool factor has a significant effect on hard metrics--eg, more frameworks, more libs, more components == faster dev speed & iterations, which I think is a good thing. ex: Mac hasn't been "better for graphics" in over a decade, but the 'cool factor' has made it the de facto choice for designers, which has resulted in a bulk of the latest designer tools being Mac only (a problem which, coincidentally, electron & its ilk aim to solve). Last: no, it wasn't a joke. I know what the article said. My point was that the point of socioeconomic accessibility was mentioned, as you note, in the last line, but for the most part, the supporting data were more asserted as intrinsically bad. If it was a key argument of the author's, I think the data would've been tied coherently to the conclusion instead of requiring a diligent reader such as yourself to farm & cobble them together into a patchwork argument. So, if you'll forgive me for borrowing a little of your snark: next time you google a word, for instance, 'skirt', you should probably prefer the first definition ("go around, past the edge of") instead of the fourth definition, as you've done here. To be clear, my thesis is, in tl;dr form: "Anything that makes reaching users in the environments they prefer easier is probably good, but the extent to which this trades off with accessibility is unclear to me."
- rootlocus 10y ago
  > you should probably prefer the first definition ("go around, past the edge of") instead of the fourth definition, as you've done here. That was the third definition. The first definition was "a woman's outer garment fastened around the waist and hanging down around the legs." /snark > we should look more at end-user satisfaction and less at often pedantic technical analyses of solutions. They aren't orthogonal. User satisfaction comes from a smooth experience. Regardless of how shiny something is, if it slows down the rest of the system (or is itself laggy) users will notice. I choose to run foobar instead of other music players because it's small and fast. > are we further limiting a great web UX to those with the money to afford the latest laptops? This is what infuriates me. People have been talking about how the "free lunch" is over [1] since 2009. About how CPUs have stopped getting faster, and how we should make the best out of the current hardware by learning to paralelize. Yet javascript is the most popular language and it's fundamentally single threaded. High quality software is not about having "a great web UX". VLC doesn't have it (great web UX). Blender doesn't have it. Intellij IDEA doesn't have it. And they're not only extremely complex and efficient softwares, they also have great UIs. Our computers are extremly powerful. The fact that someone would wonder if they're not enough to run pretty clipboard managers and fancy text editors is making me cringe. [1] http://www.gotw.ca/publications/concurrency-ddj.htm http://www.gotw.ca/publications/concurrency-ddj.htm