7 ms·

Given it's Jonathan Blow, I feel compelled to say yes. More seriously, while program overheads have undoubtedly gotten higher, that's always been in exchange f

by ATsch 6y ago

Given it's Jonathan Blow, I feel compelled to say yes. More seriously, while program overheads have undoubtedly gotten higher, that's always been in exchange for something else, even if non-technical, like a better developer experience and platform support. Nobody writes slow programs on purpose, but people are very willing to trade it off for things that are more important in the grand scheme of things. Low level programmers love to smugly pretend that those tradeoffs do not exist but they do.

ChrisMarshallNY 6y ago
> Nobody writes slow programs on purpose No, but we are in a place where most development projects are really "stitching" dependencies together, and those dependencies can get heavy. On the other hand, this may help apps written in things like Ionic to speed up like crazy, because WebKit is now insanely fast.
- ATsch 6y ago
  > we are in a place where most development projects are really "stitching" dependencies together Is there anything wrong with that, though? If there's any common thread in the history of computing, it's that progress happens when things become abstracted enough to allow for another layer of building blocks. That's not to say that those layers don't have a cost, or we don't need to learn how to do them well, but gluing together components is really all software development has ever been.
  - ChrisMarshallNY 6y ago
    It's both good and bad; depending on how much care is taken in selecting dependencies. It's hard to use a lot of dependencies, regardless of their quality, without introducing bloat. Lots of redundancies. For example, each dependency may have its own messaging or thread management system, or its own memory management system. Or it may include other dependencies that have their own "special sauce." For myself, I use lots of little packages; mostly written by Yours Troolie, and only occasionally use third-party dependencies. Each of my packages is usually crafted towards a certain discrete function, and has its own project lifecycle. I think that's a good thing about using dependencies. I believe that modules with encapsulated lifecycles are a good way to ensure quality (or not, if I "choose poorly," as the Knight Templar said in the Indiana Jones movie).
zamfi 6y ago
> Nobody writes slow programs on purpose, but people are very willing to trade it off for things that are more important in the grand scheme of things Wait, of course they write slow programs on purpose, because "premature optimization is the root of all evil," right? A developer might use Electron because it's "fast enough" and halves your development time, and "fast enough" is always a perceptual metric, and not a technical one. Faster hardware means even less optimization is needed before something is shippable -- great for developers! -- and a recipe for software continuing to feel just as slow as before, because we only optimize until it's "fast enough". And despite the M1, or any of the advances of the last decade, the perceptual line that is "fast enough" hasn't changed. EDIT: Yes of course Knuth was talking about optimizing noncritical paths, but the sprit he’s espousing lives on in system design: use electron, or something else that makes your product more maintainable and easier to understand (because you didn’t build your own bespoke cross-platform app scaffold, and electron is well-documented, etc.), until you’re sure you can’t anymore. Well, the bar for “can’t” is raised every time there’s more cpu to support rapid, maintainable, “nonoptimal” development, and here we are.
- Apocryphon 6y ago
  One wonders if VC-funded startups or "move fast and break things" firms like Facebook or Uber (as opposed to say '90s Microsoft or Sun or IBM or Bell Labs) becoming the vanguard advancing the cutting edge of some categories of software has created perverse incentives that reward this behavior. A cultural shift in Silicon Valley software development.
  - ATsch 6y ago
    People used to talk about Java in the same way people talk about electron now so I feel like that's a definite no.
    - nalekberov 6y ago
      Programs written in Java runs on top JVM. On the other hand programs written for Electron comes bundled with Chromium. And we all know how it manages memory.
deleted 6y ago
[deleted]
eivarv 6y ago
More seriously, while program overheads have undoubtedly gotten higher, that's always been in exchange for something else, even if non-technical, like a better developer experience and platform support. Software architecture usually entails trade-offs in many directions, between NFRs, etc. – but it feels to me like the intepretation of the performance-scale (as well as developer experience, really) is warped by two things: - Many devs aren't familiar with the real breadth of possibilities and discount some approaches without understanding them (using "developer experience", "platform support", and "too low level" as excuses), thereby skewing towards familiarity and preference. As most devs are familiar with web tech, this tends to win out. Other legitimate issues might not be even be understood (HCI, attack surface, accessibility, etc.) - The performance hit might not be significant enough to notice on a dev-grade machine (e.g. M1-processor, 32GB of RAM, etc.) and/or in isolation, but will become noticable when regular users run several apps built using the same heavy stack. The latter is particularly apparent if you try to run multiple Electron-apps simultaneously on a low-to-medium specced laptop – which I find pretty egregious as a user, as multitasking computer systems has been a thing for a while now. My interpretation is that many people (or companies) will usually write software that's no more performant than what they can get away with – which can be summed up, if cynically, as "users won't see any major performance gain or increase in capability in their day-to-day usage because of shitty software."
0xCMP 6y ago
> Given it's Jonathan Blow, I feel compelled to say yes. This is also how I felt watching the video, but on the other hand I have a really hard time finding serious faults with his point. HN keeps things light. My personal website is super light. But the product I work on? What's a few MB gzipped down to less than a MB? 100ms? 300ms? Who can tell the difference[0]. [0]: I can, but certainly not the people who the feature matters to much of the time.
- hadsed 6y ago
  And even if you could, you're getting more value by getting that thing sooner. Or an even better argument: in the end, maybe it took just enough resources at the quality you got to even be born in the current market. Yeah most things are frivolous... you can survive without a better camera in your phone for another year. But that ham-fisted implicit cultural aspect is what also brings people medical devices 5-10 years sooner than it could have. We all know these gains compound over time. So maybe it's ok if our programs are a little slow. We buy the truly mission critical technology faster with that frivolity. But I'll also say, I still get mad at my phone and throw it pretty often. Just the way it is.
  - sudosysgen 6y ago
    It's not an either or. Cutting edge technology has always been a bit slow and rough around the edges. That's not an excuse for your chatroom client to use 450MB of RAM.
curyous 6y ago
Slow code is usually written due to ignorance rather than choice. Lots of people only know OOP, which is slow and unoptimisable by default.
zarkov99 6y ago
The thing is the tradeoff makes more sense for the developer, who gets his job done quicker, than to the customer who pays for the sloppy bloat every time he uses the software.
geodel 6y ago
> Nobody writes slow programs on purpose, Well problem is developers are not writing fast programs on purpose. That they did not write slow on purpose but it nevertheless turned out to be slow is real problem to me as a user.
flohofwoe 6y ago
> Nobody writes slow programs on purpose True, but nobody writes fast programs on purpose either, only "fast enough" programs. The optimization work stops as soon as it "feels" fast enough and, this "feels fast enough" has been the same over the last few decades no matter how fast the underlying hardware is. Any advance in hardware will ineviatably be eaten by software within a year or two. That's why running old software on new hardware feels so increadibly fast. I also disgree that we got better developer- or user-experience out of the "deal". Most commercially developed applications have a "peak version", but still continue to be stuffed with new features that nobody asked for. E.g. name one feature that was added to Microsoft Word, Outlook or Excel in the last two versions which really added to the "user experience".
- sigotirandolas 6y ago
  Not just old software, but with a lot of open source software you usually have a spectrum of choice between more basic, lightweight software and more elaborate, heavyweight software. Think LXDE vs XFCE vs KDE vs Gnome as desktop environments, or nano vs Sublime vs Code/Atom vs IntelliJ as text editors, for example. However, when it comes some software areas prone to capture, there's not only no choice, but rather a multitude of incompatible-by-design options. Due to WFH, I need to have four different bloated chat/videoconference software on all the time which all offers the same features to me. When I want to watch a live stream, I need to open YouTube or Twitch or Facebook Live which all offer the same basic functionality but no one is interested in standardizing their interface so I can just point my familiar video player to it (at least without it breaking all the time due to cat-and-mouse fights between the platform and open source developers). I'm not generally in favour of regulation, but mandating some basic degree of interoperability so platform and software can compete separately seems like the only option.

by ATsch 6y ago

ChrisMarshallNY 6y ago

> Nobody writes slow programs on purpose No, but we are in a place where most development projects are really "stitching" dependencies together, and those dependencies can get heavy. On the other hand, this may help apps written in things like Ionic to speed up like crazy, because WebKit is now insanely fast.

ATsch 6y ago
> we are in a place where most development projects are really "stitching" dependencies together Is there anything wrong with that, though? If there's any common thread in the history of computing, it's that progress happens when things become abstracted enough to allow for another layer of building blocks. That's not to say that those layers don't have a cost, or we don't need to learn how to do them well, but gluing together components is really all software development has ever been.
- ChrisMarshallNY 6y ago
  It's both good and bad; depending on how much care is taken in selecting dependencies. It's hard to use a lot of dependencies, regardless of their quality, without introducing bloat. Lots of redundancies. For example, each dependency may have its own messaging or thread management system, or its own memory management system. Or it may include other dependencies that have their own "special sauce." For myself, I use lots of little packages; mostly written by Yours Troolie, and only occasionally use third-party dependencies. Each of my packages is usually crafted towards a certain discrete function, and has its own project lifecycle. I think that's a good thing about using dependencies. I believe that modules with encapsulated lifecycles are a good way to ensure quality (or not, if I "choose poorly," as the Knight Templar said in the Indiana Jones movie).

zamfi 6y ago

> Nobody writes slow programs on purpose, but people are very willing to trade it off for things that are more important in the grand scheme of things Wait, of course they write slow programs on purpose, because "premature optimization is the root of all evil," right? A developer might use Electron because it's "fast enough" and halves your development time, and "fast enough" is always a perceptual metric, and not a technical one. Faster hardware means even less optimization is needed before something is shippable -- great for developers! -- and a recipe for software continuing to feel just as slow as before, because we only optimize until it's "fast enough". And despite the M1, or any of the advances of the last decade, the perceptual line that is "fast enough" hasn't changed. EDIT: Yes of course Knuth was talking about optimizing noncritical paths, but the sprit he’s espousing lives on in system design: use electron, or something else that makes your product more maintainable and easier to understand (because you didn’t build your own bespoke cross-platform app scaffold, and electron is well-documented, etc.), until you’re sure you can’t anymore. Well, the bar for “can’t” is raised every time there’s more cpu to support rapid, maintainable, “nonoptimal” development, and here we are.

Apocryphon 6y ago
One wonders if VC-funded startups or "move fast and break things" firms like Facebook or Uber (as opposed to say '90s Microsoft or Sun or IBM or Bell Labs) becoming the vanguard advancing the cutting edge of some categories of software has created perverse incentives that reward this behavior. A cultural shift in Silicon Valley software development.
- ATsch 6y ago
  People used to talk about Java in the same way people talk about electron now so I feel like that's a definite no.
  - nalekberov 6y ago
    Programs written in Java runs on top JVM. On the other hand programs written for Electron comes bundled with Chromium. And we all know how it manages memory.

deleted 6y ago

[deleted]

eivarv 6y ago

More seriously, while program overheads have undoubtedly gotten higher, that's always been in exchange for something else, even if non-technical, like a better developer experience and platform support. Software architecture usually entails trade-offs in many directions, between NFRs, etc. – but it feels to me like the intepretation of the performance-scale (as well as developer experience, really) is warped by two things: - Many devs aren't familiar with the real breadth of possibilities and discount some approaches without understanding them (using "developer experience", "platform support", and "too low level" as excuses), thereby skewing towards familiarity and preference. As most devs are familiar with web tech, this tends to win out. Other legitimate issues might not be even be understood (HCI, attack surface, accessibility, etc.) - The performance hit might not be significant enough to notice on a dev-grade machine (e.g. M1-processor, 32GB of RAM, etc.) and/or in isolation, but will become noticable when regular users run several apps built using the same heavy stack. The latter is particularly apparent if you try to run multiple Electron-apps simultaneously on a low-to-medium specced laptop – which I find pretty egregious as a user, as multitasking computer systems has been a thing for a while now. My interpretation is that many people (or companies) will usually write software that's no more performant than what they can get away with – which can be summed up, if cynically, as "users won't see any major performance gain or increase in capability in their day-to-day usage because of shitty software."

0xCMP 6y ago

> Given it's Jonathan Blow, I feel compelled to say yes. This is also how I felt watching the video, but on the other hand I have a really hard time finding serious faults with his point. HN keeps things light. My personal website is super light. But the product I work on? What's a few MB gzipped down to less than a MB? 100ms? 300ms? Who can tell the difference[0]. [0]: I can, but certainly not the people who the feature matters to much of the time.

hadsed 6y ago
And even if you could, you're getting more value by getting that thing sooner. Or an even better argument: in the end, maybe it took just enough resources at the quality you got to even be born in the current market. Yeah most things are frivolous... you can survive without a better camera in your phone for another year. But that ham-fisted implicit cultural aspect is what also brings people medical devices 5-10 years sooner than it could have. We all know these gains compound over time. So maybe it's ok if our programs are a little slow. We buy the truly mission critical technology faster with that frivolity. But I'll also say, I still get mad at my phone and throw it pretty often. Just the way it is.
- sudosysgen 6y ago
  It's not an either or. Cutting edge technology has always been a bit slow and rough around the edges. That's not an excuse for your chatroom client to use 450MB of RAM.

curyous 6y ago

Slow code is usually written due to ignorance rather than choice. Lots of people only know OOP, which is slow and unoptimisable by default.

zarkov99 6y ago

The thing is the tradeoff makes more sense for the developer, who gets his job done quicker, than to the customer who pays for the sloppy bloat every time he uses the software.

geodel 6y ago

> Nobody writes slow programs on purpose, Well problem is developers are not writing fast programs on purpose. That they did not write slow on purpose but it nevertheless turned out to be slow is real problem to me as a user.

flohofwoe 6y ago

> Nobody writes slow programs on purpose True, but nobody writes fast programs on purpose either, only "fast enough" programs. The optimization work stops as soon as it "feels" fast enough and, this "feels fast enough" has been the same over the last few decades no matter how fast the underlying hardware is. Any advance in hardware will ineviatably be eaten by software within a year or two. That's why running old software on new hardware feels so increadibly fast. I also disgree that we got better developer- or user-experience out of the "deal". Most commercially developed applications have a "peak version", but still continue to be stuffed with new features that nobody asked for. E.g. name one feature that was added to Microsoft Word, Outlook or Excel in the last two versions which really added to the "user experience".

sigotirandolas 6y ago
Not just old software, but with a lot of open source software you usually have a spectrum of choice between more basic, lightweight software and more elaborate, heavyweight software. Think LXDE vs XFCE vs KDE vs Gnome as desktop environments, or nano vs Sublime vs Code/Atom vs IntelliJ as text editors, for example. However, when it comes some software areas prone to capture, there's not only no choice, but rather a multitude of incompatible-by-design options. Due to WFH, I need to have four different bloated chat/videoconference software on all the time which all offers the same features to me. When I want to watch a live stream, I need to open YouTube or Twitch or Facebook Live which all offer the same basic functionality but no one is interested in standardizing their interface so I can just point my familiar video player to it (at least without it breaking all the time due to cat-and-mouse fights between the platform and open source developers). I'm not generally in favour of regulation, but mandating some basic degree of interoperability so platform and software can compete separately seems like the only option.