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