[horsawlarway]

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]

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]

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

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

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

[sheepz]

While there is certainly more complexity in modern software, it does not necessarily need to translate to increased memory, CPU usage and increased latency for the user. Are you saying that this increase in software complexity definitely increases these requirements?

Java is definitely not a good example of a memory-efficient language when compared to its non-GC alternatives.

It all comes down to economics, software is written as inefficiently as possible as long as it does it jobs and is not hindered by this and this actually the crux of "Wirth's law".

[dfox]

The “Java bloat” mostly has nothing to do with the language itself, but is caused by the ecosystem around it. On one hand you have overly abstract frameworks and on the other you have inexperienced programmers who don't understand how such frameworks are supposed to be used and write code that actively fights against the framework...

[k__]

"allowing more inexperienced and unskilled programmers to create programs"

You realize that this is a good thing, right?

[secondcoming]

Good for them, or for me?

[k__]

For all of us.

[mcguire]

Until you ask those inexperienced and unskilled people to do something important.

[Negitivefrags]

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]

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.

[shash]

Here’s his reasoning: https://superuser.com/a/419167

“ The bad performance on the Sony is due to poor software engineering. Some TV features, like motion interpolation, require buffering at least one frame, and may benefit from more. Other features, like floating menus, format conversions, content protection, and so on, could be implemented in a streaming manner, but the easy way out is to just buffer between each subsystem, which can pile up to a half dozen frames in some systems.”

What he’s talking about is (in his opinion) unnecessary buffering that causes a delay in the pixel actually appearing on screen.

He blames the driver and the display’s internal software, so his argument could be made out to support OP, but I think the situation is a bit more complex than Wirth’s law here.

[cmrdporcupine]

Well, yes, I suspected it was something like this.

I'm well aware of this kind of bloating (guess I should have said something in my comment to avoid the downvotes...) but it still doesn't support the OP's comment.

Network latency is not only high, but there's literally nothing that can be done of it -- because of the speed of light!

(I am somewhat lucky to work on something where we can optimize away much of the crap you're talking about here, as we own the whole package.)

[justin66]

The person you initially negatively responded to said "networking is not the bottleneck," and if it's possible to have a meaningful negative reaction to that, it might involve asking "the bottleneck in what system?" I think he's right, but it's a blanket statement and it's fair to ask for more context.

More context: typical network latency is good enough that video games rendered on a remote server are becoming practical, or at least salable. "Network latency is high" is a vague enough statement that it could mean anything, but if being able to render video games remotely and stream the output to the client doesn't make you reconsider, I question what you would ever consider network latency that's not too high.

The kicker with these games, that perhaps speaks to the original, crazy post by horsawlarway, is that it's normal for a TV set and set of controls to introduce a lot more latency than the network connection itself: the network is not the bottleneck. There's a good excuse for the latency in involved in networking, rooted in physics, but this is not true for the hardware and the software stack.

[cmrdporcupine]

Well, yes, I recently worked on the video receiver component for Stadia on Chromecast. So I know a little about these things.

[jecel]

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.

[justin66]

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.

[anonymoushn]

You have presented almost 2 full frames of pixels in 28ms, but how many frames out of date were they when they made it to a human's retina?

[badsectoracula]

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]

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]

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.

[akkartik]

Your list is interesting because of how it overlaps with yet reframes mine (from 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) 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.

[IncRnd]

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]

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.

[mcguire]

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.

[tedunangst]

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

[akkartik]

Compatibility might contribute?

[elihu]

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.