7 ms·

This article is the problem. It's the same freaking fallacy I see again and again on here - It's simple, easy to understand, and dead fucking wrong. The vast

This article is the problem. It's the same freaking fallacy I see again and again on here - It's simple, easy to understand, and dead fucking wrong. The vast majority of the complexity you're dealing with in modern computing comes from three sources. In the order of impact 1. Networking. It turns out there are real and hard limits on how fast we can pass data around over copper wires. Fiber is better, but you just literally cannot move faster than light, and latency is a big deal when the items you're accessing and changing live somewhere else (and basically everything of value does live somewhere else, or thinks you are "somewhere else"). 2. Security. This is a direct consequence of number 1. When everything is connected, everything is connected. You can't just lock the lab door and call it a day now. 3. Compatibility. This is a direct consequence of both 1 and 2. Value is a consequence of compatibility (this is why a good chunk of you on here still support IE, even though you don't want to). We have more devices, of more kinds than ever before. We have more people, with more use cases than ever before. There is value in being as compatible as possible with all those devices and people. All those devices are connected in ways designed to keep them compatible, but also secure. It turns out this is not an easy task. If you'd like to go wank off over how fast your pre-network, unsecured, unsupported, inaccessible and manually configured systems are, be my guest (oh, and I hope you read english...). The rest of us will continue to produce items of value.

sheepz 6y ago
No, it's the other way around. Advances in computer hardware have allowed the use more inefficient programming languages allowing more inexperienced and unskilled programmers to create programs leading to more resource hungry programs. When there are little resource constraints the only real constraint becomes developer time. I don't see how having IDEs implemented in browsers has anything to do with security, the speed of light or compatibility. It's just the lack of constraints allowed by advances in computer hardware. Most software is written with no performance considerations in mind at first and the performance issues are addressed only when they become visible. However, if there is abundant memory available, why bother?
- baryphonic 6y ago
  > I don't see how having IDEs implemented in browsers has anything to do with security, the speed of light or compatibility. It's just the lack of constraints allowed by advances in computer hardware. This isn't a compatibility issue? We've seen about 8-16 branches of the write-once, run-everywhere tree over the past 25 years, I'm not sure how that isn't seen as a constraint on programmers. JWT, Swing, Web, Cordova, QT, React/<web front-end> Native, Xamarin, Electron, Flutter and even quirky ones like Toga have all attempted to solve this problem. The only unifying thread has been that managers follow greedy algorithms and choose the lowest common denominator platforms as possible. QT, the Java tools and Xamarin at least can't be lumped into the inefficient language bucket, though the UX is just awful. Other than hardware drivers, it's hard to think of a clearer example of compatibility constraints.
  - Sebb767 6y ago
    > JWT, Swing, Web, Cordova, React/<web front-end> Native, Xamarin, Electron, Flutter and even quirky ones like Toga have all attempted to solve this problem, and ... and for the most part they have. You can write your app right now and the only thing you need to worry about is screen size. If you use bootstrap, even this is mostly solved. Your app is accessible on Windows, Linux and Mac; Chromebooks and Tablets; iPhones, Android and even the one Symbian user. Of course it's not perfect yet, there are edge cases and you cannot do everything, but let's not act like things have gotten worse. > The only unifying thread has been that managers follow greedy algorithms and choose the lowest common denominator platforms as possible. Yes, I agree. But for nearly every use case, it's good enough. Take HN as an example: Does it need anything more? Of course, if you need access to specific hardware, you'll have to go deeper. But if you do not, it would simply be you taking the lowest common denominator. And I'd argue that the framework probably did a more thorough search.
    - baryphonic 6y ago
      I basically agree, with the caveat that I'd still prefer a world where our write-once-run-everywhere lowest common denominator at least required native widgets and an ability to integrate new platform-specific capabilities at the expense of writing a small amount of native code, rather than barfing up web UI/UX at users (e.g. the execrable MS Teams).
deleted 6y ago
[deleted]
badsectoracula 6y ago
None of the above require software to be as slow as it often is. Windows being able to run Win32 applications isn't what makes Windows Calc slow nor is anything else you mentioned - you do not need a supercomputer to download currency conversion rates (which, btw, is bloat by itself and could be handled by a dedicated program instead of being shoved into calc) and even the ability to download a CSV or whatever from a remote server via HTTPS (all you'd really need to make such an update) is something the OS can provide to every application and keep secure for everyone (and you know what, this sort of functionality was something Windows provided ever since Win98, but how many people use it vs bundling their own?).
- hnick 6y ago
  Calc is my favourite example too. Win+R+calc+enter and start typing, it used to work no matter how fast I was. Not anymore, I sit waiting at its convenience. Android is pretty inconsistent too, the same series of steps are instant or hang the UI for 5 seconds depending on the current moon phase or something I haven't worked out yet.
  - userbinator 6y ago
    The Windows 10 calculator even has a loading screen. The UI is hideously large. It's like a joke of what "modern" software has become, except that it's actually serious.
tedunangst 6y ago
Not sure how any of this explains why a text editor can't fit in some countably finite number of kilobytes.
- akkartik 6y ago
  Compatibility might contribute?
akkartik 6y ago
Your list is interesting because of how it overlaps with yet reframes mine (from http://akkartik.name/about http://akkartik.name/about): A. Backwards compatibility considerations. Early mistakes in the design of an interface are often perpetuated indefinitely. Supporting them takes code. Projects that add many new features also accumulate many missteps. Over time the weight of these past adaptations starts to prevent future adaptation. B. Churn in personnel. If a project lasts long enough early contributors eventually leave and are replaced by new ones. The new ones have holes in their knowledge of the codebase, all the different facilities provided, the reasons why design decisions were made just so. Peter Naur pointed out back in 1985 (http://akkartik.name/naur.pdf http://akkartik.name/naur.pdf) the odd fact that that no matter how much documentation we write, we can't seem to help newcomers understand our programs without talking to the original authors. In-person interactive conversations tend to be a precious resource; there's only so many of them newcomers can have before they need to start contributing to a project, and there's only so much bandwidth the old hands have to review changes for unnecessary complexity or over-engineering. Personnel churn is a lossy process; every generation of programmers on a project tends to know less about it, and to be less in control of it. C. Vestigial features. Even after accounting for compatibility considerations, projects past a certain age often have features that can be removed. However, such simplification rarely happens because of the risk of regressions. We forget precisely why we did what we did, and that forces us to choose between reintroducing regressions or continuing to cargo-cult old solutions long after they've become unnecessary. --- I can't really rebut anything you say. I'm going to keep it on my radar as I go about my project. It's currently pre-network, unsecured and inaccessible. And will always be manually configured, for reasons described in the link. But it's supported, for what that's worth.
mcguire 6y ago
The speed of a signal in wire or fiber is largely irrelevant. Most of your latency is taken going up and down your ginormous software stack. Take a look at what is required for wire-speed processing. Security is improved by reducing the number of disparate components.
Negitivefrags 6y ago
Networking isn't the bottleneck. As John Carmack quipped, "I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that?" Usually if there is latency caused by networking in an application it's usually unneeded roundtrips caused by inefficient programmers or inefficient layers in the software stack. It's insane how much overhead there is.
- cmrdporcupine 6y ago
  I am completely baffled by this quip. At speed of light in a vacuum, from New York to London is 19ms. That's the physical limit of what a network could ever hope to accomplish, but in reality in fiber it's apparently about 28ms. At 60fps we need to present a new set of pixels to the screen every 16ms. So in the time that a packet goes in one direction to Europe we could have presented almost two full frames of pixels. Even on the rather slow old SoC in the Google Nest Home Hub platform that I work on, we're able to do quite a bit of pixel crunching in that 16ms. Even with code written in JavaScript, or Dart. Enough to make our users mostly happy. John Carmack is much smarter than me, so I can't believe he meant this literally, or it's been taken out of context. The network is definitely a bottleneck.
  - justin66 6y ago
    You haven't even tried to take the shocking amount of latency introduced by the hardware and the software stack into consideration, and it's what prompted Carmack to make his comment.
  - jecel 6y ago
    A new set of pixels every 16ms is about throughput and we do have that. But the latency today is worse than in the VGA era. If you have a completely black screen and want to draw a tiny white circle in the middle of it, it will take your processor or GPU less than a microsecond to change the bytes. Less than 16 milliseconds later (an average of 8ms, actually) the updated bytes will be flowing through the HDMI wires and into the monitor. There they will be stored into a local buffer. If there is a mismatch between the image format and the LCD panel then it will probably be copied to a second buffer. Some DMA hardware will then send the bytes to the drivers for the LCD and the light going through those pixels will change. All that can easily add up to 50ms or more.
IncRnd 6y ago
That's just not true. 1. Networking isn't the number one source of complexity, since local apps can be bloated, slow, buggy, and complex. 2. Security is not a consequence of networking. A non-networked system can be insecure, and a networked system can be secure. Security is more normally viewed in the context of confidentiallity, integrity, and availibility along with the concepts of authentication, authorization, and accountability. 3. Compatibility is not a consequence of either networking or security. Your comment makes it seem that you believe complexity comes from having to adhere to constraints. That attitude is the issue! Not wanting to adhere to constraints is why software is bloated, complex, full of thousands of components, slow, etc.
- akkartik 6y ago
  It still seems useful to consider how security and compatibility add complexity to our software stacks, even if the causal chain of networking -> security -> compatibility isn't right.
elihu 6y ago
Regarding 3, I think part of the problem of ecosystem fragmentation has to do with large tech companies finding their favorite niche and being reluctant to compete with each other. I have a theory that this has something to do with incentives: competition can be good for the company that is able to grab another's territory, but on average it's usually a loss. That's especially true from the perspective of shareholders, most of whom don't just hold one stock but many. Some competition is necessary, but too much is inefficient. If you own stock in both Apple and Google, you're happy with them each having their own group of loyal phone buyers. Spending more money than necessary to try to attract the other company's customers to switch is almost a pure loss from the point of view of the shareholder. Companies might not explicitly collude to divide markets (which would be against anti-trust law), but they're still subject to the disapproval of their shareholders if they rock the boat too much. Sometimes I think it makes more sense to think of all publicly-traded companies as being a sort of loosely-structured single corporation rather than truly separate competing entities. So we have all these different software ecosystems that all these different businesses have built their respective walled gardens around, but software developers suffer because they can't just write to one platform and have their application be portable. Instead, they need a totally different application if they want to be accessible to desktop PC users, Android, iPhone, the web, tablets, servers, enterprise customers, HPC, cloud, game consoles and so on. Sure those users all have different needs, but surely they could have quite a bit more cross-platform consistency and common tools and standards than what we have now.

sheepz 6y ago

No, it's the other way around. Advances in computer hardware have allowed the use more inefficient programming languages allowing more inexperienced and unskilled programmers to create programs leading to more resource hungry programs. When there are little resource constraints the only real constraint becomes developer time. I don't see how having IDEs implemented in browsers has anything to do with security, the speed of light or compatibility. It's just the lack of constraints allowed by advances in computer hardware. Most software is written with no performance considerations in mind at first and the performance issues are addressed only when they become visible. However, if there is abundant memory available, why bother?

baryphonic 6y ago
> I don't see how having IDEs implemented in browsers has anything to do with security, the speed of light or compatibility. It's just the lack of constraints allowed by advances in computer hardware. This isn't a compatibility issue? We've seen about 8-16 branches of the write-once, run-everywhere tree over the past 25 years, I'm not sure how that isn't seen as a constraint on programmers. JWT, Swing, Web, Cordova, QT, React/<web front-end> Native, Xamarin, Electron, Flutter and even quirky ones like Toga have all attempted to solve this problem. The only unifying thread has been that managers follow greedy algorithms and choose the lowest common denominator platforms as possible. QT, the Java tools and Xamarin at least can't be lumped into the inefficient language bucket, though the UX is just awful. Other than hardware drivers, it's hard to think of a clearer example of compatibility constraints.
- Sebb767 6y ago
  > JWT, Swing, Web, Cordova, React/<web front-end> Native, Xamarin, Electron, Flutter and even quirky ones like Toga have all attempted to solve this problem, and ... and for the most part they have. You can write your app right now and the only thing you need to worry about is screen size. If you use bootstrap, even this is mostly solved. Your app is accessible on Windows, Linux and Mac; Chromebooks and Tablets; iPhones, Android and even the one Symbian user. Of course it's not perfect yet, there are edge cases and you cannot do everything, but let's not act like things have gotten worse. > The only unifying thread has been that managers follow greedy algorithms and choose the lowest common denominator platforms as possible. Yes, I agree. But for nearly every use case, it's good enough. Take HN as an example: Does it need anything more? Of course, if you need access to specific hardware, you'll have to go deeper. But if you do not, it would simply be you taking the lowest common denominator. And I'd argue that the framework probably did a more thorough search.
  - baryphonic 6y ago
    I basically agree, with the caveat that I'd still prefer a world where our write-once-run-everywhere lowest common denominator at least required native widgets and an ability to integrate new platform-specific capabilities at the expense of writing a small amount of native code, rather than barfing up web UI/UX at users (e.g. the execrable MS Teams).

deleted 6y ago

[deleted]

badsectoracula 6y ago

None of the above require software to be as slow as it often is. Windows being able to run Win32 applications isn't what makes Windows Calc slow nor is anything else you mentioned - you do not need a supercomputer to download currency conversion rates (which, btw, is bloat by itself and could be handled by a dedicated program instead of being shoved into calc) and even the ability to download a CSV or whatever from a remote server via HTTPS (all you'd really need to make such an update) is something the OS can provide to every application and keep secure for everyone (and you know what, this sort of functionality was something Windows provided ever since Win98, but how many people use it vs bundling their own?).

hnick 6y ago
Calc is my favourite example too. Win+R+calc+enter and start typing, it used to work no matter how fast I was. Not anymore, I sit waiting at its convenience. Android is pretty inconsistent too, the same series of steps are instant or hang the UI for 5 seconds depending on the current moon phase or something I haven't worked out yet.
- userbinator 6y ago
  The Windows 10 calculator even has a loading screen. The UI is hideously large. It's like a joke of what "modern" software has become, except that it's actually serious.

tedunangst 6y ago

Not sure how any of this explains why a text editor can't fit in some countably finite number of kilobytes.

akkartik 6y ago
Compatibility might contribute?

akkartik 6y ago

Your list is interesting because of how it overlaps with yet reframes mine (from http://akkartik.name/about http://akkartik.name/about): A. Backwards compatibility considerations. Early mistakes in the design of an interface are often perpetuated indefinitely. Supporting them takes code. Projects that add many new features also accumulate many missteps. Over time the weight of these past adaptations starts to prevent future adaptation. B. Churn in personnel. If a project lasts long enough early contributors eventually leave and are replaced by new ones. The new ones have holes in their knowledge of the codebase, all the different facilities provided, the reasons why design decisions were made just so. Peter Naur pointed out back in 1985 (http://akkartik.name/naur.pdf http://akkartik.name/naur.pdf) the odd fact that that no matter how much documentation we write, we can't seem to help newcomers understand our programs without talking to the original authors. In-person interactive conversations tend to be a precious resource; there's only so many of them newcomers can have before they need to start contributing to a project, and there's only so much bandwidth the old hands have to review changes for unnecessary complexity or over-engineering. Personnel churn is a lossy process; every generation of programmers on a project tends to know less about it, and to be less in control of it. C. Vestigial features. Even after accounting for compatibility considerations, projects past a certain age often have features that can be removed. However, such simplification rarely happens because of the risk of regressions. We forget precisely why we did what we did, and that forces us to choose between reintroducing regressions or continuing to cargo-cult old solutions long after they've become unnecessary. --- I can't really rebut anything you say. I'm going to keep it on my radar as I go about my project. It's currently pre-network, unsecured and inaccessible. And will always be manually configured, for reasons described in the link. But it's supported, for what that's worth.

mcguire 6y ago

The speed of a signal in wire or fiber is largely irrelevant. Most of your latency is taken going up and down your ginormous software stack. Take a look at what is required for wire-speed processing. Security is improved by reducing the number of disparate components.

Negitivefrags 6y ago

Networking isn't the bottleneck. As John Carmack quipped, "I can send an IP packet to Europe faster than I can send a pixel to the screen. How f’d up is that?" Usually if there is latency caused by networking in an application it's usually unneeded roundtrips caused by inefficient programmers or inefficient layers in the software stack. It's insane how much overhead there is.

cmrdporcupine 6y ago
I am completely baffled by this quip. At speed of light in a vacuum, from New York to London is 19ms. That's the physical limit of what a network could ever hope to accomplish, but in reality in fiber it's apparently about 28ms. At 60fps we need to present a new set of pixels to the screen every 16ms. So in the time that a packet goes in one direction to Europe we could have presented almost two full frames of pixels. Even on the rather slow old SoC in the Google Nest Home Hub platform that I work on, we're able to do quite a bit of pixel crunching in that 16ms. Even with code written in JavaScript, or Dart. Enough to make our users mostly happy. John Carmack is much smarter than me, so I can't believe he meant this literally, or it's been taken out of context. The network is definitely a bottleneck.
- justin66 6y ago
  You haven't even tried to take the shocking amount of latency introduced by the hardware and the software stack into consideration, and it's what prompted Carmack to make his comment.
- jecel 6y ago
  A new set of pixels every 16ms is about throughput and we do have that. But the latency today is worse than in the VGA era. If you have a completely black screen and want to draw a tiny white circle in the middle of it, it will take your processor or GPU less than a microsecond to change the bytes. Less than 16 milliseconds later (an average of 8ms, actually) the updated bytes will be flowing through the HDMI wires and into the monitor. There they will be stored into a local buffer. If there is a mismatch between the image format and the LCD panel then it will probably be copied to a second buffer. Some DMA hardware will then send the bytes to the drivers for the LCD and the light going through those pixels will change. All that can easily add up to 50ms or more.

IncRnd 6y ago

That's just not true. 1. Networking isn't the number one source of complexity, since local apps can be bloated, slow, buggy, and complex. 2. Security is not a consequence of networking. A non-networked system can be insecure, and a networked system can be secure. Security is more normally viewed in the context of confidentiallity, integrity, and availibility along with the concepts of authentication, authorization, and accountability. 3. Compatibility is not a consequence of either networking or security. Your comment makes it seem that you believe complexity comes from having to adhere to constraints. That attitude is the issue! Not wanting to adhere to constraints is why software is bloated, complex, full of thousands of components, slow, etc.

akkartik 6y ago
It still seems useful to consider how security and compatibility add complexity to our software stacks, even if the causal chain of networking -> security -> compatibility isn't right.

elihu 6y ago

Regarding 3, I think part of the problem of ecosystem fragmentation has to do with large tech companies finding their favorite niche and being reluctant to compete with each other. I have a theory that this has something to do with incentives: competition can be good for the company that is able to grab another's territory, but on average it's usually a loss. That's especially true from the perspective of shareholders, most of whom don't just hold one stock but many. Some competition is necessary, but too much is inefficient. If you own stock in both Apple and Google, you're happy with them each having their own group of loyal phone buyers. Spending more money than necessary to try to attract the other company's customers to switch is almost a pure loss from the point of view of the shareholder. Companies might not explicitly collude to divide markets (which would be against anti-trust law), but they're still subject to the disapproval of their shareholders if they rock the boat too much. Sometimes I think it makes more sense to think of all publicly-traded companies as being a sort of loosely-structured single corporation rather than truly separate competing entities. So we have all these different software ecosystems that all these different businesses have built their respective walled gardens around, but software developers suffer because they can't just write to one platform and have their application be portable. Instead, they need a totally different application if they want to be accessible to desktop PC users, Android, iPhone, the web, tablets, servers, enterprise customers, HPC, cloud, game consoles and so on. Sure those users all have different needs, but surely they could have quite a bit more cross-platform consistency and common tools and standards than what we have now.