4 ms·

The programming language is often only a (relatively small) part of this problem. The choice of the framework (or, I'd say, the pollution of frameworks, as well

The programming language is often only a (relatively small) part of this problem. The choice of the framework (or, I'd say, the pollution of frameworks, as well as 40 MB libraries only imported to do dependency injection), wrong abstractions, wrong data models (if I'd had a penny for every time I've seen some code do a full list scan when it could have indexed the objects into a map I'd be millionaire by now), over-engineering, frameworks that reinvent the wheel (often in a much less optimal way, all in order to provide the developer with a bit of syntactical sugar), they all play a much bigger role in performance degradation than the language itself. On top of it, projects are often lead by managers that are mostly interested in grabbing the low hanging fruits, pack the product with poorly tested features, set unrealistic deadlines and monetize as fast as possible, and they often don't provide developers time to breathe, take a step back and do any refactoring or optimization - those are too often labelled as purely technical tasks with no business impact and pushed down the priority line. Some of the code written two or three decades ago was much more efficient (especially given the hardware available at the time) than today's projects both because developers were aware of building software for machines with a limited amount of resources, and because the software delivery timelines were much more realistic - aggressive marketing, sales and product departments hadn't yet completely taken over the engineering departments, and while agile methodologies were supposed to mitigate these issues they've actually only shrunk even more the delivery windows and made software development more hectic and shortsighted. 30 years ago a program that would choke on a 386 would be refactored until each single but was optimized for the available resources. Today's approach is simply "just throw more RAM/CPU power" - and that's what I frankly find unacceptable.

blacklight 6y ago
Oh, one more reason I forgot in the case of webapps: 3rd-party scripts and trackers. I've been using NoScript for years now, and that forces me to explicitly whitelist any domain used for scripts on a website. Once you start looking at what major websites do, you start to understand the problem. Most of the newspapers on the web, for example, often employ 20 additional script domains on top of their own - for anything from analytics, to tracking, cookie banners, ads, adblock detectors, Hotjar, Taboola, and so on. We often (justifiably) argue that deep learning, as it's done today, is something unsustainable for the environment. I wonder if anyone has ever measured the impact of running tons of non-functional scripts on the web pages rendered every second by billions of devices around the world.

blacklight 6y ago

Oh, one more reason I forgot in the case of webapps: 3rd-party scripts and trackers. I've been using NoScript for years now, and that forces me to explicitly whitelist any domain used for scripts on a website. Once you start looking at what major websites do, you start to understand the problem. Most of the newspapers on the web, for example, often employ 20 additional script domains on top of their own - for anything from analytics, to tracking, cookie banners, ads, adblock detectors, Hotjar, Taboola, and so on. We often (justifiably) argue that deep learning, as it's done today, is something unsustainable for the environment. I wonder if anyone has ever measured the impact of running tons of non-functional scripts on the web pages rendered every second by billions of devices around the world.