Author Topic: food for thought: code bloat  (Read 15434 times)

0 Members and 1 Guest are viewing this topic.

Offline madiresTopic starter

  • Super Contributor
  • ***
  • Posts: 7697
  • Country: de
  • A qualified hobbyist ;)
food for thought: code bloat
« on: June 26, 2022, 01:14:53 pm »
Code bloat has become astronomical: https://www.positech.co.uk/cliffsblog/2022/06/05/code-bloat-has-become-astronomical/

What do you think? Waste of energy and resources? Lazy software developers? Greedy managers, companies and shareholders?
 
The following users thanked this post: Siwastaja

Offline YurkshireLad

  • Frequent Contributor
  • **
  • Posts: 365
  • Country: ca
Re: food for thought: code bloat
« Reply #1 on: June 26, 2022, 03:32:15 pm »
Legacy supoort, web frameworks and so on. Not reinventing the wheel and not wanting to remove any existing wheels.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #2 on: June 26, 2022, 06:25:14 pm »
It's rather easy to figure out where code bloat comes from, but the interesting point is indeed to consider how wasteful it ends up being as far as resources are concerned, especially in times where software is literally everywhere, and it's only going to get worse.
 
The following users thanked this post: Siwastaja

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #3 on: June 26, 2022, 08:21:46 pm »
Bloat exists because it's currently cheaper to leave piles of shit everywhere than clean it up.

When performance or user experience suffers in any way then it will change.

There's a massive performance and energy usage wall coming up on the hardware side of things that will put the focus back on software efficiency.
 
The following users thanked this post: Ed.Kloonk, boz

Offline AndyBeez

  • Frequent Contributor
  • **
  • Posts: 855
  • Country: nu
Re: food for thought: code bloat
« Reply #4 on: June 26, 2022, 08:31:02 pm »
Good engineering is having the most efficient solution to meet the engineering problem. This is why there are for example, composite materials in mechanical engineering and large scale integration in electronic engineering. But in software engineering?

If you measure 'efficiency' in avation, planes get lighter, stronger and faster over time. In computing, software just gets heavier, slower and fractured with points of failure. Only advances in hardware keep the code bloat from sinking the proverbial airship.

Moore's law not only doubles speed and storage over time but by definition, doubles the amount that can be processed and stored. Ergo, more code can fit into the same space-time variable. More 64bit code to connect my anal-ytics to my anus-ytics in the metaverse fart cloud. Why, because someone else thinks my user experience needs that? Or maybe a case of built it and they will come? No, install that shite and I will find every freakin' way of cleansing it from my valuable SSD.

Once upon a home micro, the 1,786 bytes consumed by this single icon :scared: were enough to run a program. Now you need a server farm the size of Wyoming just to store all of the world's emojis!

Code bloat or the equivalent data puke, means we have far too many computer resources to know what to do with.
 
The following users thanked this post: boz

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #5 on: June 26, 2022, 08:38:03 pm »
Keep in mind nobody knows if there's such a thing as software "engineering".
This has been an ongoing debate for decades.
 
The following users thanked this post: dietert1

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #6 on: June 26, 2022, 08:42:19 pm »
Code bloat or the equivalent data puke, means we have far too many computer resources to know what to do with.

Sort of. At the moment, the constraining cost is energy. That's starting to burn the end users now.

Watch the race to the bottom on energy usage. Which is why ARM is popular suddenly.

Eventually the software will be the constraining factor.

Windows Defender probably has its own ozone hole at the moment  :-DD
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #7 on: June 26, 2022, 08:53:25 pm »
Windows Defender probably has its own ozone hole at the moment  :-DD
 
The following users thanked this post: bd139

Offline CatalinaWOW

  • Super Contributor
  • ***
  • Posts: 5173
  • Country: us
Re: food for thought: code bloat
« Reply #8 on: June 26, 2022, 09:02:12 pm »
This is a problem in all forms of writing.  There is a famous quote attributed variously to Blaise Pascal, Mark Twain and Jane Austen among others.

"I don't have time to write you a short letter, so I am writing a long one."

It takes time, energy and thought to reduce code size.  All of these are of limited availability in development.
 
The following users thanked this post: ROT

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #9 on: June 26, 2022, 09:03:20 pm »
I don't know. I'm next to (I refuse to say I'm with) a team of 300 developers and quite frankly they have enough time to do a proper job of solving all the problems. They just lack the motivation and skill to do so.

I saw them burn 9340 hours on something that took me 30 minutes to fix. No shit. That one was fucking buried as well so the management didn't look like morons.
 
The following users thanked this post: SiliconWizard

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #10 on: June 26, 2022, 09:09:27 pm »
One thing to consider is whether the alleged additional energy required for developers to do a leaner job (and as bd139, even that is questionable) would outweigh, or at least be on par, with the cost of software bloat in terms of energy?

I'm almost certain that the answer is a resounding NO, as the impact of software spreads in very large amounts contrary to that of developers, and also as we humans are surprisingly efficient in terms of energy consumption compared to most machines we ever designed.

 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #11 on: June 26, 2022, 09:15:02 pm »
It also depends on the impact of the software on society. The particular thing I am currently working on allows a whole specialist industry to remote work, thus reducing energy consumption on travel and office space. So really if we are inefficient we might be less inefficient than if we didn't exist.

Things get very complicated very quickly.
 

Offline CatalinaWOW

  • Super Contributor
  • ***
  • Posts: 5173
  • Country: us
Re: food for thought: code bloat
« Reply #12 on: June 26, 2022, 10:18:27 pm »
The energy I was speaking of isn't measured with a wattmeter.  It is the will to do what is often a boring job with little recognition for success.

It appears that in bd139's anecdote time was the only one of three requirements available.
 
The following users thanked this post: bd139

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: food for thought: code bloat
« Reply #13 on: June 27, 2022, 12:10:15 am »
One thing to consider is whether the alleged additional energy required for developers to do a leaner job (and as bd139, even that is questionable) would outweigh, or at least be on par, with the cost of software bloat in terms of energy?

There's a big difference between software used by 10 people and software used by a billion people. For 10 people it's almost always going to be cheaper to buy them a faster machine. Each. It is at least actually a valid engineering and financial tradeoff.

It also depends on whether the costs of hardware to overcome software bloat are borne by the company itself (e.g. web servers) or by their customers (e.g. Microsoft Windows and Office).
 

Offline golden_labels

  • Super Contributor
  • ***
  • Posts: 1185
  • Country: pl
Re: food for thought: code bloat
« Reply #14 on: June 27, 2022, 01:21:07 am »
In ending “the bloat” software devs are happy to follow EE: just lead the way! Stop using readily available and tested discrete components, which waste board space and underutilize characteristics. Instead roll out a new custom chip for each problem. Of course optimized so no watt or square millimeter is wasted.

Each time this kind of topic emerges, it’s not noticing equivalent phenomenon in one’s own domain(1), an ocean of blissful ignorance and attributing the situation to defects in someone’s character. There is a huge variance and, just like in any industry branch, there are extremes. So yes, there are cases like applications ran in embedded internet browser (Electron), similarly like there are barcode scanners built upon a computer running Windows with Internet Explorer for driving the display(2) or solar roadways. But if you use extremes as the benchmark for the entire branch, you just deceive yourself.

You complain that in the past you could fit a program into 1kB and now it takes 1GB?(2) I assure you that you still can go towards sub-megabyte code sizes, ignoring executable file structures and interfacing with the environment. You will also get exactly what you had back then, best pictured by that pixelated screenshot in the article. You will also pay as much as it costed back then and you may forget about ever having non-proprietary software. The quality and reliability will also be limited to the garbage-in-garbage-out philosophy, with “garbage in” being things you would nowadays thought as perfectly normal input.

The alternative is to understand how things actually work. Then you will grasp why, even with most perfect approach and hypothetical hyper-optimised software, for nearly all software products you will not reach improvement reaching even an order of magnitude. Or you may remain in the comfort zone of throwing shit, turning blind eye towards your own domain and imagining a world that never existed.


(1) Not surprising, as for your own domain you understand the situation and can explain the choices. Not so much for a process where you only see the final outcome.
(2) Except for vendored software, which is a management issue forced upon developers, it does not. It’s like measuring size of your smartphone by including the power adapter. Some go as far as including the entire power plant.
« Last Edit: June 27, 2022, 01:22:39 am by golden_labels »
People imagine AI as T1000. What we got so far is glorified T9.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8113
  • Country: fi
Re: food for thought: code bloat
« Reply #15 on: June 27, 2022, 08:18:42 am »
It takes time, energy and thought to reduce code size.  All of these are of limited availability in development.

This is not the problem, it's the opposite. I'm positive that cutting the resources to 1/10th would reduce unnecessary bloat to 1/10th.

It's not about software project managers optimizing the costs, it's the problem of them not optimizing. Rather, the whole software "engineering" (whether that exists or not) is in a long-term crisis that is deep enough that people like managers do not know what is possible. They assume all that complexity is needed.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8113
  • Country: fi
Re: food for thought: code bloat
« Reply #16 on: June 27, 2022, 08:36:18 am »
In ending “the bloat” software devs are happy to follow EE: just lead the way! Stop using readily available and tested discrete components, which waste board space and underutilize characteristics. Instead roll out a new custom chip for each problem. Of course optimized so no watt or square millimeter is wasted.

Bad analogy. Better analogy is this:

You are designing a room thermostat which needs to click a relay to power a heater below certain temperature.

You have absolutely no idea how to do it, so you outsource ten full size server racks full of circuit boards. Each circuit board comes with a twenty 1000-pin connectors, from which 1000-wire flat cables run from random boards to other random board within this server room. What comes to the circuit boards - their designers did not know what to do, so they soldered in sub-boards, 42 per each main board. These sub-boards are then designed by yet another company, and each comes with either 1000 discrete transistors in SMD, some have 20 transistors in metal cans, some have a few electron tubes, and some come with FPGAs, for which the HDL is developed by yet another company.

The room thermostat finally requires a room of at least 50 square meters, and a 3-phase power supply of 3x100A, and compressed air, too. You can't just buy it, it needs to be custom ordered, and it takes 4 years of planning and 4 years of build to finally get it. During commission, the company is able to demonstrate the relay indeed clicks under well specified but untested circumstances, but it does not work after this demonstration. After extending the power supply to 3x200A, and building a new server room extension to the house within the next 3 years, the thermostat starts usually working, but over the weekends it stops working because the control room worker (who is now hired full time in the shack built in the backyard, did I mention?) is not able to make the required trimpot bias adjustments for over 24 hours. But this is not to worry, because it is usually fixed by Tuesday.

And every thermostat is built this way, because everybody thinks there is no any other way.
« Last Edit: June 27, 2022, 08:40:00 am by Siwastaja »
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4924
  • Country: si
Re: food for thought: code bloat
« Reply #17 on: June 27, 2022, 01:12:40 pm »
Yep computers are getting ever more powerful, but software is becoming inefficient at an even faster rate. So putting it all together computers are actually becoming ever slower for the end user.

Back i the day i was early on the smartphone bandwagon and got a phone running Windows Mobile (Not to be confused with Windows Phone, that stuff is garbage) and it ran on a 133MHz ARM CPU with 32MB of RAM later on moved on to a PDA with a 500MHz ARM with 128MB of RAM . And it worked well. It always ran fast, it had the software to do things like play back all modern video formats, render full desktop webpages(including ones with embedded flash), it could play Youtube. etc... Kept doing it for many years and still ran as snappy as on day 1. Every app i launched would start up and be ready in a second. Apps didn't even have a startup splash screen because they load so fast.

These days we have phones with multiple cores running well into the GHz clock speeds on much more powerful ARM processors in terms of work per clock cycle. Yet every single app needs a splash screen upon opening it because it takes multiple seconds for the app to load (otherwise the user would not know it is loading) and yet most apps don't do much that the old PDA could not do. Despite this new phone having easily 100x the computational power it's all so slow.
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #18 on: June 27, 2022, 01:42:05 pm »
I think your understanding of the splash screen is probably wrong. That's a marketing interstitial mostly which can be optionally used to hit the network to try and get the initial screen if it needs it. Most of the apps on my phone at least don't have one and are 100% instant starting. My iPad, which is basically the same thing but bigger, is the only computer I've had that can actually keep up with me it's that fast.

As for windows mobile, I did a lot of development on that for POS and POD systems. I think you have some faulty memories there. It was painful at best.
 

Offline madiresTopic starter

  • Super Contributor
  • ***
  • Posts: 7697
  • Country: de
  • A qualified hobbyist ;)
Re: food for thought: code bloat
« Reply #19 on: June 27, 2022, 02:12:21 pm »
The alternative is to understand how things actually work. Then you will grasp why, even with most perfect approach and hypothetical hyper-optimised software, for nearly all software products you will not reach improvement reaching even an order of magnitude. Or you may remain in the comfort zone of throwing shit, turning blind eye towards your own domain and imagining a world that never existed.

Going to an extreme of hyper-optimization isn't realistic anyway. But there are plenty of opportunities to do things better. The blog post mentioned in the first post also talks about many soft devs never seen good and efficient code, causing them to produce bloat since they never learned other ways to design code. I've seen this also many times. Or in EE terms, if you need just a NAND gate use a 4093 and not a large FPGA just because you used that FPGA in your last project and you are familiar with it.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #20 on: June 27, 2022, 06:19:45 pm »
One thing to consider is whether the alleged additional energy required for developers to do a leaner job (and as bd139, even that is questionable) would outweigh, or at least be on par, with the cost of software bloat in terms of energy?
There's a big difference between software used by 10 people and software used by a billion people.

That was kind of implied in the following: "the impact of software spreads in very large amounts contrary to that of developers".
Of course if the number of users is not significantly greater than the number of developers, that becomes a particular case and the outcome can be different.
(The beauty of partial quotes =) )

For 10 people it's almost always going to be cheaper to buy them a faster machine. Each. It is at least actually a valid engineering and financial tradeoff.
It also depends on whether the costs of hardware to overcome software bloat are borne by the company itself (e.g. web servers) or by their customers (e.g. Microsoft Windows and Office).

The problem here is that you chose to look at it only from the development cost perspective, which is the most usual way of looking at software bloat (and engineering bloat in general when it applies.)

The interesting point that I found in this thread and which I was embarking on was the energy side of it. Not the development (or more generally "production") cost. The immediate cost is what everyone already knows about. Cost cutting is a cause here, not a consequence. In this thread, I was personally only talking about the consequences, not the causes, as I think the OP was also interested in.

And even the economic point of view is trickier than it appears. People tend to look at economy on very small scales and kinda treat it as though it was some magic. While if you look at the big picture, economy basically follows the rules of physics. Except in very groundbreaking (and now relatively rare) cases of managing to do things much more efficiently without any negative side-effect, whatever cost cutting you're managing to achieve is going to be paid somewhere else.

As to the point about developers favoring code bloat out of laziness and/or because their job is boring, that's fun and rather true in general, but that's again just talking about causes rather than about consequences.

Siwastaja pointed it out: the software industry has been in a deep, ongoing crising for decades now and despite numerous attempts, it's still in crisis.
bd139, working in that area as far as I got, is lucid and honest enough about it all that he recognizes how fucked-up it all is while admitting great money can be made out of it.
 

Offline madiresTopic starter

  • Super Contributor
  • ***
  • Posts: 7697
  • Country: de
  • A qualified hobbyist ;)
Re: food for thought: code bloat
« Reply #21 on: June 27, 2022, 08:28:59 pm »
Let's assume MS could make Windows twice as efficient. How much power could be saved in total?
 

Offline radar_macgyver

  • Frequent Contributor
  • **
  • Posts: 687
  • Country: us
Re: food for thought: code bloat
« Reply #22 on: June 27, 2022, 08:55:44 pm »
Some of this may be generational, or following previous designs even when not appropriate.

Case in point, we had some folks visiting from a commercial company with a prototype of a radar they wanted to test alongside some of our equipment. Their RF guy was there to operate the system. He didn't have any software background, but was running code written by their software guy. My jaw dropped a couple of feet when I saw him spin up a docker instance (!!!) to acquire the data from an Ettus Research USRP SDR. Then there was another docker instance to process the data and Matlab to view it. WHY??? I could understand using Matlab for a quick prototype, but docker? Geez!

Sounds like their software dev was someone who had used docker for developing web stuff, and was asked to work on a data acq. system with the above results. They probably consider it either old fashioned or black magic to just write a program to connect to a TCP socket and store the data to disk.
 
The following users thanked this post: bd139

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: food for thought: code bloat
« Reply #23 on: June 27, 2022, 11:37:37 pm »
Back i the day i was early on the smartphone bandwagon and got a phone running Windows Mobile (Not to be confused with Windows Phone, that stuff is garbage) and it ran on a 133MHz ARM CPU with 32MB of RAM later on moved on to a PDA with a 500MHz ARM with 128MB of RAM .

That is very fast and a lot of RAM!

When I was working in a small company writing and selling a J2ME to native compiler for Verizon phones in 2006 to 2008 the typical phone had a maybe 16 MHz ARM7TDMI (running on a 16 bit bus) and 400 KB to 2 MB of free RAM. Some of the lower end phones (and we had literally 200 different models in the office for testing purposes) were I think as low as 1 MHz to extend battery life.
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4924
  • Country: si
Re: food for thought: code bloat
« Reply #24 on: June 28, 2022, 07:00:13 am »
Back i the day i was early on the smartphone bandwagon and got a phone running Windows Mobile (Not to be confused with Windows Phone, that stuff is garbage) and it ran on a 133MHz ARM CPU with 32MB of RAM later on moved on to a PDA with a 500MHz ARM with 128MB of RAM .

That is very fast and a lot of RAM!

When I was working in a small company writing and selling a J2ME to native compiler for Verizon phones in 2006 to 2008 the typical phone had a maybe 16 MHz ARM7TDMI (running on a 16 bit bus) and 400 KB to 2 MB of free RAM. Some of the lower end phones (and we had literally 200 different models in the office for testing purposes) were I think as low as 1 MHz to extend battery life.

Yep this was around 2006 era and these ware the 'flagship' devices so they had an impressive amount of mobile processing power for the time. Also ran on Intels ARM CPUs back when they still made them. That 133MHz OMAP ARM was in a  Motorola MPX200 was i think from the 2003 era.


I think your understanding of the splash screen is probably wrong. That's a marketing interstitial mostly which can be optionally used to hit the network to try and get the initial screen if it needs it. Most of the apps on my phone at least don't have one and are 100% instant starting. My iPad, which is basically the same thing but bigger, is the only computer I've had that can actually keep up with me it's that fast.

As for windows mobile, I did a lot of development on that for POS and POD systems. I think you have some faulty memories there. It was painful at best.
Maybe it was because i was running WindowsMobile on the more powerful hardware of the time.

I did some development on it too, but that was once the .Net framework was running on them. This made software development on it almost as easy as making regular Windows apps on Win XP. The resulting executable would even run perfectly fine on Windows XP and on WindowsMobile.

That being said not all apps on Android are dog slow. Some of the small apps made by single developers (Like TotalComander for Android) start instantly and keep running responsively throughout its use. Yet quite a lot of bigger modern apps take >5 seconds to launch from a cold start and then often hang the UI for 1 second when pressing some buttons. Sure my phone is a midrange device from 5 years ago, but with how much computational power they carry, drawing a responsive UI should NOT be this hard of a task.
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #25 on: June 28, 2022, 07:23:18 am »
Nope I was running on top notch hardware at the time (2004 approx). If was awful. I wrote a POD signature capture engine in c#. It rendered with GDI and compressed a bunch of sampled vectors into binary and HTTP POSTed it to the server before REST was even a thing. The processing was notably horribly slow even after profiling the crap out of it.
 

Offline Vtile

  • Super Contributor
  • ***
  • Posts: 1144
  • Country: fi
  • Ingineer
Re: food for thought: code bloat
« Reply #26 on: July 06, 2022, 09:11:49 pm »
Kkrieger!
https://youtu.be/JLb839wPeIs

... This game demo is 96 kilobytes.
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #27 on: July 06, 2022, 09:56:50 pm »
Plus the hundreds of megabytes of kernel, directX and C++ dynamic linked libraries…

The impressive thing is the packer and the procedural generation.

I wrote a raycasting engine on SDL in macOS 10.4 back in the day and it was 14k compiled and stripped with textures. SDL was about 1Mb.
 
The following users thanked this post: Siwastaja

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19284
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: food for thought: code bloat
« Reply #28 on: July 06, 2022, 10:08:32 pm »
Code bloat or the equivalent data puke, means we have far too many computer resources to know what to do with.

Sort of. At the moment, the constraining cost is energy. That's starting to burn the end users now.

Watch the race to the bottom on energy usage. Which is why ARM is popular suddenly.

Eventually the software will be the constraining factor.

The High Performance Computing mob have traditionally pushed the limits, found the pain points, and invented workarounds.

They realised energy was becoming the dominant consideration a couple of decades ago, and their specifications for new systems started to recognise that.

Isn't software already the constraining factor?
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19284
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: food for thought: code bloat
« Reply #29 on: July 06, 2022, 10:16:17 pm »
Bloat exists because it's currently cheaper to leave piles of shit everywhere than clean it up.

There's other reasons. One particularly pernicious one is where marketeers have to specify whats in product N+1. If those marketeers are inexperienced in the product domain, they will say "just like product N because we need to continue to sell it, but add X and Y". Obviously that leads to a wart being added to the hairball.

But if you ask knowledgeable customers, they will sometimes say " don't duplicate N, do something better".
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #30 on: July 06, 2022, 10:17:03 pm »
Software will push hardware harder and harder to do the "dirty work" of drawing less energy.
By the time it's really *considered* the constraining factor, software development will likely have been handed over to AI, so we'll have only machines to blame.
 :-DD
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #31 on: July 06, 2022, 10:18:38 pm »
Bloat exists because it's currently cheaper to leave piles of shit everywhere than clean it up.

There's other reasons. One particularly pernicious one is where marketeers have to specify whats in product N+1. If those marketeers are inexperienced in the product domain, they will say "just like product N because we need to continue to sell it, but add X and Y". Obviously that leads to a wart being added to the hairball.

But if you ask knowledgeable customers, they will sometimes say " don't duplicate N, do something better".

Eventually it turns into what looks like an Indian train crash.

 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19284
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: food for thought: code bloat
« Reply #32 on: July 06, 2022, 11:11:06 pm »
Software will push hardware harder and harder to do the "dirty work" of drawing less energy.
By the time it's really *considered* the constraining factor, software development will likely have been handed over to AI, so we'll have only machines to blame.
 :-DD

Age old question: in the battle of artificial intelligence vs natural stupidity, which emerges victorious. References to Idiocracy and HHGttG gain bonus points.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: food for thought: code bloat
« Reply #33 on: July 07, 2022, 04:05:43 am »
 
The following users thanked this post: bd139

Offline JPortici

  • Super Contributor
  • ***
  • Posts: 3452
  • Country: it
Re: food for thought: code bloat
« Reply #34 on: July 07, 2022, 05:53:13 am »
sure crayion can try hard provided the correct input  >:D
 
The following users thanked this post: bd139

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #35 on: July 07, 2022, 06:29:17 am »
Crikey. So now we know that this AI is a mentally ill serial killer.
 

Online tellurium

  • Regular Contributor
  • *
  • Posts: 226
  • Country: ua
Re: food for thought: code bloat
« Reply #36 on: July 15, 2022, 06:40:37 pm »
Keep in mind nobody knows if there's such a thing as software "engineering".
This has been an ongoing debate for decades.

Ok, if software is not "engineering", but a joke.
Who are then people like Dennis Ritchie, K. Thompson, Rob Pike , etc etc? Some random clowns? Or perhaps they are engineers?
Open source embedded network library https://mongoose.ws
TCP/IP stack + TLS1.3 + HTTP/WebSocket/MQTT in a single file
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #37 on: July 15, 2022, 06:44:05 pm »
Ironically perhaps Rob Pike is well known for being outspoken about how crap everything is  :-DD

Oh and Unix was a hack.
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: food for thought: code bloat
« Reply #38 on: July 15, 2022, 06:59:23 pm »
Keep in mind nobody knows if there's such a thing as software "engineering".
This has been an ongoing debate for decades.
Ok, if software is not "engineering", but a joke.
No, SiliconWizard didn't claim that.  He wrote that nobody knows ... ongoing debate.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #39 on: July 15, 2022, 07:05:51 pm »
Keep in mind nobody knows if there's such a thing as software "engineering".
This has been an ongoing debate for decades.
Ok, if software is not "engineering", but a joke.
No, SiliconWizard didn't claim that.  He wrote that nobody knows ... ongoing debate.

Yes.
Also, what kind of reasoning was that? Just because it could not be classified as engineering, doesn't mean that it would be a joke.
Engineering has a specific meaning and not all technical activities can be classified as engineering. That doesn't belittle them. Might help a bit to know what points are behind this debate to understand why there is one.
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 2282
  • Country: gb
Re: food for thought: code bloat
« Reply #40 on: July 15, 2022, 08:22:15 pm »
Well, I'm gonna call it - yes, software engineering 'is a thing'.

Maybe this was debatable a few decades ago, but now, every man and his daft dog can be an 'engineer'. It's such a diluted term these days it's not even worth arguing over over. Like it's some kind of 'status' or badge of honour. Not any more, suckers. Search your local job adverts for 'engineer'. Literally, my first result was 'Trainee Drainage Engineer' for 'all aspects of drain and pipe cleaning'. So, there you have it, engineers chasing turds away.
 

Offline nfmax

  • Super Contributor
  • ***
  • Posts: 1556
  • Country: gb
Re: food for thought: code bloat
« Reply #41 on: July 15, 2022, 09:39:27 pm »
Some of this may be generational, or following previous designs even when not appropriate.

Case in point, we had some folks visiting from a commercial company with a prototype of a radar they wanted to test alongside some of our equipment. Their RF guy was there to operate the system. He didn't have any software background, but was running code written by their software guy. My jaw dropped a couple of feet when I saw him spin up a docker instance (!!!) to acquire the data from an Ettus Research USRP SDR. Then there was another docker instance to process the data and Matlab to view it. WHY??? I could understand using Matlab for a quick prototype, but docker? Geez!

Sounds like their software dev was someone who had used docker for developing web stuff, and was asked to work on a data acq. system with the above results. They probably consider it either old fashioned or black magic to just write a program to connect to a TCP socket and store the data to disk.

Perhaps the software guy was wise enough to try his level best to ensure that the prototype software he was tasked to develop would never be shipped to end users...
 

Offline radar_macgyver

  • Frequent Contributor
  • **
  • Posts: 687
  • Country: us
Re: food for thought: code bloat
« Reply #42 on: July 15, 2022, 09:48:06 pm »
Perhaps the software guy was wise enough to try his level best to ensure that the prototype software he was tasked to develop would never be shipped to end users...
Maybe so, but if you have a 'batch mode' process like this, you have to wait for your half-hour of data is recorded before you know if it works, or if the ADC cable was disconnected (yes, this happened). It's just not fit for purpose.
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: food for thought: code bloat
« Reply #43 on: July 15, 2022, 10:08:16 pm »
They probably consider it either old fashioned or black magic to just write a program to connect to a TCP socket and store the data to disk.
If you have netcat, it'd be just one command: netcat -d hostname-or-address port > file.

You can even do it in Bash: bash -c 'cat < /dev/tcp/hostname-or-address/port > file'.  It internally detects paths like /dev/tcp/ and uses a socket instead, and thus works in Windows also (in WSL, and Cygwin bash).

And if they were a proper web dev, it would have been only a dozen lines of Bash or so to create a minimal WebSocket proxy to handle the HTTP handshake and then just pump the raw data from the specified TCP port directly to the user JavaScript and do the entire UI and processing in a browser.  To optimize it a bit, instead of cat one could use e.g. dd with bs=1500 (a typical TCP packet payload size).

I think it was just the typical highschooler they had hired to do the prototype beta version they intended to initially ship to customers.
 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3671
  • Country: gb
  • Doing electronics since the 1960s...
Re: food for thought: code bloat
« Reply #44 on: July 17, 2022, 11:49:18 am »
No surprise to me.

I've just this morning decided to scrap a project on which I have paid out about 4k and which doesn't really work. It was based on an open source web server which is so bloated (for the simple tasks needed) that I have no hope of fixing it, and nobody will want to get into it for less than another similar amount, and I can't afford to pay that. Not sure what to do but will try to write it all myself.

A big part of the issue is crap project management. The manager needs to know enough, or almost enough, to do it himself.

Frameworks are all the rage and most will be dead in 5-10 years' time.
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 
The following users thanked this post: YurkshireLad

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19284
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: food for thought: code bloat
« Reply #45 on: July 17, 2022, 01:17:45 pm »
Frameworks are all the rage and most will be dead in 5-10 years' time.

Most current frameworks will be dead in a decade, some won't.
New frameworks and languages will arise, will make mistakes that were known and soved 10 years ago, but HR departments will insist on hiring newbies that don't know enough to ask the right questions.
There will be another layer pasted on top on the stack of sync-async-sync-async-sync-async-sync-async-... comms protocols.
Salesdroids and shills and fanbois will falsely claim that the new framework makes distributed computation as easy and semantically equivalent to single thread computation. Managers will believe them.

And that's what history teaches.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 
The following users thanked this post: madires, YurkshireLad

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #46 on: July 17, 2022, 07:40:32 pm »
Frameworks are all the rage and most will be dead in 5-10 years' time.

Most current frameworks will be dead in a decade, some won't.
New frameworks and languages will arise, will make mistakes that were known and soved 10 years ago, but HR departments will insist on hiring newbies that don't know enough to ask the right questions.

Sure, they cost less and are much easier to handle. :-DD
 

Offline Fred_47

  • Contributor
  • Posts: 41
  • Country: us
  • Old retired Electric Power engineer
Re: food for thought: code bloat
« Reply #47 on: July 17, 2022, 08:33:13 pm »
Groves giveth, and Gates taketh away. -- unknown probably from IEEE Spectrum about 1992

Andy Groves was the CEO of Intel

Bloat is not a new thing:

Unfamiliar quotation (from Cleveland Engineering Society Newsletter about 1972):

Whenever in doubt, let brevity take precedence over over redundant and superfluous expression of your ideas.

The Lord's prayer has 56 words. Lincoln's Gettysburg address has 266. The ten commandments have 297. The Declaration of Independence has 300. A recent government order setting the price of cabbage had 26,911 words!


I wonder who counted all those words in 1972?
Caretaker at Fred's home for retired test gear.
 

Offline nigelwright7557

  • Frequent Contributor
  • **
  • Posts: 689
  • Country: gb
    • Electronic controls
Re: food for thought: code bloat
« Reply #48 on: July 17, 2022, 09:08:02 pm »
Legacy supoort, web frameworks and so on. Not reinventing the wheel and not wanting to remove any existing wheels.
Worst company for bloatware is Microsoft.
They build so many layers to software and that its almost impossible to copy or replace.
Windows, .net framework, .net core, WPF, Winforms etc etc
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #49 on: July 17, 2022, 09:15:39 pm »
Literally, my first result was 'Trainee Drainage Engineer' for 'all aspects of drain and pipe cleaning'. So, there you have it, engineers chasing turds away.

Yeah. ;D
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #50 on: July 17, 2022, 09:20:27 pm »
Legacy supoort, web frameworks and so on. Not reinventing the wheel and not wanting to remove any existing wheels.
Worst company for bloatware is Microsoft.
They build so many layers to software and that its almost impossible to copy or replace.
Windows, .net framework, .net core, WPF, Winforms etc etc

That’s all the good stuff.

If you want to poke something start with Teams and look at all the shit they are building on top of layers of shit in typescript. The next major version of office is in typescript and electron.
 

Offline YurkshireLad

  • Frequent Contributor
  • **
  • Posts: 365
  • Country: ca
Re: food for thought: code bloat
« Reply #51 on: July 17, 2022, 10:10:45 pm »
Legacy supoort, web frameworks and so on. Not reinventing the wheel and not wanting to remove any existing wheels.
Worst company for bloatware is Microsoft.
They build so many layers to software and that its almost impossible to copy or replace.
Windows, .net framework, .net core, WPF, Winforms etc etc

That’s all the good stuff.

If you want to poke something start with Teams and look at all the shit they are building on top of layers of shit in typescript. The next major version of office is in typescript and electron.


Ugh, Teams is like a fatberg you find stuck in a sewer. Bloated, ugly and no use to anyone.
 
The following users thanked this post: bd139

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #52 on: July 17, 2022, 10:17:59 pm »
isn't VSCode  mostly TypeScript as well? :popcorn:
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #53 on: July 18, 2022, 07:16:00 am »
Yep and it’s getting worse each release. Half the ancillary crap that runs behind the scenes and the remote host for remote machines eat a ton of RAM and resources. I’ve dumped it and gone back to vim recently.
 

Online tellurium

  • Regular Contributor
  • *
  • Posts: 226
  • Country: ua
Re: food for thought: code bloat
« Reply #54 on: July 18, 2022, 04:51:12 pm »
Yep and it’s getting worse each release. Half the ancillary crap that runs behind the scenes and the remote host for remote machines eat a ton of RAM and resources. I’ve dumped it and gone back to vim recently.

Likewise. I try a couple of editors every year for the last 20 years, and always go back to vim.

The nice feature of vscode / sublime I've missed was multiple selection with Ctrl-D then simultaneous edit. Useful for quick renames / refactorings. Though, vim's search + cgn + replacement + .   does the same thing, as I've found out.
Open source embedded network library https://mongoose.ws
TCP/IP stack + TLS1.3 + HTTP/WebSocket/MQTT in a single file
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #55 on: July 18, 2022, 04:58:47 pm »
I tend to use
Code: [Select]
:%s/foo/bar/g for that.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #56 on: July 18, 2022, 05:57:37 pm »
Yep and it’s getting worse each release. Half the ancillary crap that runs behind the scenes and the remote host for remote machines eat a ton of RAM and resources. I’ve dumped it and gone back to vim recently.

I've never used it. ;D
Well, I have tried VSCodium (which is VSCode without telemetry) and was unimpressed. It's slowish, eats up a lot of RAM and I don't like the text editor part itself much (at least compared to what I'm used to.)
The only thing it has going for it is the extension system and the amount of extensions. Which makes it look like any popular software: it is popular because it is popular (so sure the ecosystem grows exponentially). Not because it's particularly good.

The only occasional use I make of it is to edit markdown files. It has an extension for previewing the result, which is handy. If you can point me to a markdown viewer that is not web-based and that works well, I'll be glad to switch!

« Last Edit: July 18, 2022, 05:59:24 pm by SiliconWizard »
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #57 on: July 18, 2022, 06:18:53 pm »
Yea I was using it for markdown as well to maintain internal documentation in GitHub.

I just use plain text files now
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4924
  • Country: si
Re: food for thought: code bloat
« Reply #58 on: July 19, 2022, 05:28:29 am »
The reason that VSCode, VisualStudio, Sublime..etc use so much more resources is also due to the extensive autocomplete functionality they have.

They are basically halfway compiling the code in the background as you type, so it understands what you are referencing in the code and only suggests valid things about that item. This means it has to hold an up to date picture of what every namespace,class,structure..etc looks like in not only your code but also whatever is is exposed by the included libraries.

I personally like code editors that provide good autocomplete and Microsofts Intelisense does a rather good job. These autocomplete features help make me more productive by not making me remember the exact name of everything in my code and saves time with me having to look up what a structure contains or getting it wrong and finding out the name typo at compile time. This is especially true when using outside libraries that i never used before and don't know any of the functions from by head (the whole function prototype appears right there as i type it). Since you can just hit a key and have it autocomplete for you also speeds up typing, reduces chances of a typo and removes the discouragement of using longer names. At the end of the day it helps me get my coding done faster. Computers are better at remembering things than i am. If this comes at a cost of a gig or two of memory so be it, my machine has 32GB.

Could these features be implemented in a more optimized resource efficient way? Yes they certainly could. But until someone actually does it this is the best we got. But you will always have those Arch linux users rocking there good'ol vim on there trusty IBM Thinkpad from 2005
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #59 on: July 19, 2022, 08:02:21 am »
I used to have working autocomplete on a 512MB machine. There is no reason for it to be as painfully large as it is now.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19284
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: food for thought: code bloat
« Reply #60 on: July 19, 2022, 10:50:02 am »
I personally like code editors that provide good autocomplete and Microsofts Intelisense does a rather good job. These autocomplete features help make me more productive by not making me remember the exact name of everything in my code and saves time with me having to look up what a structure contains or getting it wrong and finding out the name typo at compile time. This is especially true when using outside libraries that i never used before and don't know any of the functions from by head (the whole function prototype appears right there as i type it). Since you can just hit a key and have it autocomplete for you also speeds up typing, reduces chances of a typo and removes the discouragement of using longer names. At the end of the day it helps me get my coding done faster. Computers are better at remembering things than i am. If this comes at a cost of a gig or two of memory so be it, my machine has 32GB.

Just so.

But it also needs the right language. Good luck with autocompletion with, for example, Forth or Lisp!

Autocompletion has one other virtue that newbies don't understand. Too often you see statements to the effect that "language X requires s too much typing" and that my language is better because it uses duck-typing. Autocompletion removes the "problem" of too much typing. (Personally I'd rather the compiler told me I'm wrong, rather than have a run-time error.)
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4924
  • Country: si
Re: food for thought: code bloat
« Reply #61 on: July 19, 2022, 04:38:10 pm »
Just so.

But it also needs the right language. Good luck with autocompletion with, for example, Forth or Lisp!

Autocompletion has one other virtue that newbies don't understand. Too often you see statements to the effect that "language X requires s too much typing" and that my language is better because it uses duck-typing. Autocompletion removes the "problem" of too much typing. (Personally I'd rather the compiler told me I'm wrong, rather than have a run-time error.)

Yep this sort of functionality needs a lot of effort to implement than just syntax highlighting. But i tend to end up using the more popular languages so they are usually supported(C, C#, Python etc..). I don't tend to learn new languages until i find something that my existing set of languages doesn't do well.

If strong typing or dynamic typing is better is a topic for another day. My own preference is to have types defined wherever possible. I even use type hinting in Python just so that the IDE can warn me when i try to stuff something into the wrong spot. Even tho the Python language tends to be designed to not give a damn about data types. The autocomplete feature of the PyCharm IDE even tries to be helpful even without type hints by tracking the movement of data trough the code, so that it can do a best guess about the data type, or when accessing the members of a object in the code it assumes the member is part of the object and suggests it for autocomplete (even tho it has no idea what kind of object it is actually dealing with). So it still kinda works but nowhere near as well as in strong typing.

I do admit the strong typing of VHDL did feel annoying to me, always tended to prefer Verilog instead. But both of those languages are pretty terrible and i never found any decent IDE for them. But i just deal with it for when i want to do stuff with FPGAs
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #62 on: July 19, 2022, 06:54:40 pm »
autocomplete crap freaking annoys me to no end, so that's definitely not for me. I don't need
Give me good syntax highlighting, and sensible auto-indentation (which VSCode doesn't have IMHO, but that will of course be highly subjective).

As to a language needing "too much typing"? As I say on a regular basis, if, when developing software, the amount of typing needed takes any significant amount of time/energy compared to the design effort, then you're either writing trivial stuff or you're doing something really wrong. Just my 2 cents. :popcorn:
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #63 on: July 19, 2022, 06:58:25 pm »
That’s where YAML needs to fuck off and die  :-DD
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #64 on: July 19, 2022, 07:10:32 pm »
I don't particularly care for YAML, there are better structured formats out there. ;D
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23018
  • Country: gb
Re: food for thought: code bloat
« Reply #65 on: July 19, 2022, 07:30:26 pm »
There are indeed.

My pet pieve is templated YAML which is just pain and a definite incarnation of Greenspun’s Tenth Rule. Helm I’m looking at you there.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19284
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: food for thought: code bloat
« Reply #66 on: July 19, 2022, 08:33:49 pm »
autocomplete crap freaking annoys me to no end, so that's definitely not for me. I don't need
Give me good syntax highlighting, and sensible auto-indentation (which VSCode doesn't have IMHO, but that will of course be highly subjective).

I've not used VSCode, and I hate DWIM for the reasons that have been articulated shortly after it was first implemented. And recapitulated every day by android spelling chucker/corrupters.

Nonetheless, with the right language, and probably a good editor/IDE, giving the coder instant feedback on the set of possible completions at this point in the code, it can be available assistant.

But the emphasis is on "set", "instant", and "choice".

Quote
As to a language needing "too much typing"? As I say on a regular basis, if, when developing software, the amount of typing needed takes any significant amount of time/energy compared to the design effort, then you're either writing trivial stuff or you're doing something really wrong. Just my 2 cents. :popcorn:

Agreed wholeheartedly.

But those are some of the justifications (and I use that word loosely) claimed by those pushing certain language (mis)features.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: food for thought: code bloat
« Reply #67 on: July 19, 2022, 10:21:14 pm »
autocomplete crap freaking annoys me to no end, so that's definitely not for me. I don't need

I *hate* things flashing up when I'm trying to think and type. If you have to hit a key to get the suggestions then fine.

As for reducing typing, emacs' M-/ command works fine for me. It searches first backwards in the current file, the from the end of the current file, and then other open files, for a word starting with the characters to the left of the cursor, and completes it. That's all you need for not repeatedly typing long and descriptive names.

Quote
Give me good syntax highlighting, and sensible auto-indentation (which VSCode doesn't have IMHO, but that will of course be highly subjective).

I'm not sure what is "good" syntax highlighting. String literals and comments different to other things maybe. I don't need my freaking editor to remind me which things are keywords and type names. I'd rather have plain black text than an editor that looks like a Fisher-Price toy.

Quote
As to a language needing "too much typing"? As I say on a regular basis, if, when developing software, the amount of typing needed takes any significant amount of time/energy compared to the design effort, then you're either writing trivial stuff or you're doing something really wrong. Just my 2 cents. :popcorn:

100%.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19284
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: food for thought: code bloat
« Reply #68 on: July 19, 2022, 11:50:18 pm »
autocomplete crap freaking annoys me to no end, so that's definitely not for me. I don't need

I *hate* things flashing up when I'm trying to think and type. If you have to hit a key to get the suggestions then fine.

Agreed.

ctrl-space turning the "what legally completes this class/variable/method" mode on/off works well.

Quote
As for reducing typing, emacs' M-/ command works fine for me. It searches first backwards in the current file, the from the end of the current file, and then other open files, for a word starting with the characters to the left of the cursor, and completes it. That's all you need for not repeatedly typing long and descriptive names.

Quote
Give me good syntax highlighting, and sensible auto-indentation (which VSCode doesn't have IMHO, but that will of course be highly subjective).

I'm not sure what is "good" syntax highlighting.

Discreet, muted, and can easily be changed so it doesn't offend me nor distract me from reading the text. The "Windows3.1 16 colour palette" falls far short of that!

Quote
String literals and comments different to other things maybe. I don't need my freaking editor to remind me which things are keywords and type names. I'd rather have plain black text than an editor that looks like a Fisher-Price toy.

Quote
As to a language needing "too much typing"? As I say on a regular basis, if, when developing software, the amount of typing needed takes any significant amount of time/energy compared to the design effort, then you're either writing trivial stuff or you're doing something really wrong. Just my 2 cents. :popcorn:

100%.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: food for thought: code bloat
« Reply #69 on: July 20, 2022, 03:30:42 am »
I'm not sure what is "good" syntax highlighting. String literals and comments different to other things maybe. I don't need my freaking editor to remind me which things are keywords and type names. I'd rather have plain black text than an editor that looks like a Fisher-Price toy.
(I prefer gray text on black for whatever reason, and as little of the editor showing as possible; only the text I'm editing.)

I have noticed that when browsing through code new to me, syntax highlighting reduces the cognitive load: it makes it faster for me to understand the code.
When writing my own code, it's probably just eye candy.

I only use colors for highlighting, though.  (Well, with Pluma I use the defaults which does apply italics to certain parts of Doxygen comments, and only my own theme/color palette.)

One quirk in my typing is that AltGr+Space must map to plain space, and not to non-breaking space (U+00A0), because in the keyboard layout I use, { is AltGr+7, [ is AltGr+8, ] is AltGr+9, and } is AltGr+0, and those are very often followed by a space by a finger in my other hand, and I occasionally release the AltGr key too late.  I used to have to modify the layout to do this, but in Linux Mint 20.04 it was this way from the get go.

As to a language needing "too much typing"? As I say on a regular basis, if, when developing software, the amount of typing needed takes any significant amount of time/energy compared to the design effort, then you're either writing trivial stuff or you're doing something really wrong. Just my 2 cents. :popcorn:
I fully agree!  And I often refactor/rewrite my own code.
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4924
  • Country: si
Re: food for thought: code bloat
« Reply #70 on: July 20, 2022, 05:43:52 am »
In almost all the IDEs you can set up syntax highlighting or indenting or autocomplete to work the way you like it.

Syntax highlighting is another thing that is a little productivity boost. I also don't like it when it is too colorful, so i sometimes take a bit to find a good color theme i like. But just gentle color hints around the code make it so that i don't actually need to read everything when just looking over the code. I don't need to look for where a string literal begins or ends, or when those brackets begin or end, what is part of a comment what is not. My vision has a finite amount of text bandwidth it can read, so if i can avoid wasting it to read syntax details that means there is more bandwidth left over for actually reading the code i want to read.

I know computers are better than me at doing some of these things, so i let them do those things for me so that i can focus on actually thinking about the code i want to write. Not on the typing or reading it, those are just a barrier between my brain and the source code file where i want to get my code into.

Maybe i am just really bad at reading quickly or typing quickly, so that having to do more of those slows down my process of coding. Or maybe my memory is so terrible that i can't remember enough of a libraries documentation in my head to avoid having to have to look trough it too often while i code(as this is time spent not coding). I have no idea, all i know is the modern bells and whistles make me get the job done faster in comparison to a bare bones editor.

Try using an advanced editor for a week or so on a project (to get used to the new visual queues) and then switch back to a bare editor to see the difference. It is much like how i started out using Eagle for PCB design in the old days and it was fine, now that i use AltiumDesigner going back to Eagle makes me surprised i got anything actually done in it.
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19284
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: food for thought: code bloat
« Reply #71 on: July 20, 2022, 09:02:38 am »
And I often refactor/rewrite my own code.

That's where a good IDE with a "compliant" language beats any simple editor.

One classic example is to see whether the tool allows you to select a block of code and refactor it into a new method.

Another is to see whether the tool can rename a method or variable, and accurately change all uses to the new name. Anybody using macros (or reflection) deserves what they get :)
« Last Edit: July 20, 2022, 09:06:18 am by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: food for thought: code bloat
« Reply #72 on: July 20, 2022, 02:56:11 pm »
Quote
The only occasional use I make of it is to edit markdown files. It has an extension for previewing the result, which is handy. If you can point me to a markdown viewer that is not web-based and that works well, I'll be glad to switch!

https://typora.io/

https://github.com/marktext/marktext
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: food for thought: code bloat
« Reply #73 on: July 20, 2022, 03:20:12 pm »
Software bloat follows the hardware bloat  ;)

You can ask the same non relevant question for hardware:
In the 80's we only needed 29,000 transistors for an Intel 8088, why do we now need 57,000,000,000 transistors for a mobile M1 processor ?
How much energy can we safe if we go back to 29000 transistors and 4 bit color graphics with a 320x200 resolution ?
Who needs those 4K super real games and movies ?

Totally irrelevant questions IMO. Real software bloat are unused bytes that can be thrown out without compromising any of the end results.
No company will ever invest millions of $ for 20-30% in code reduction, they invest in the next thing. Why ? Because new things have a ROI, while code reductions and cleaning only costs money.

https://en.wikipedia.org/wiki/Transistor_count
 

Offline madiresTopic starter

  • Super Contributor
  • ***
  • Posts: 7697
  • Country: de
  • A qualified hobbyist ;)
Re: food for thought: code bloat
« Reply #74 on: July 20, 2022, 04:27:02 pm »
And companies writing software don't care about code bloat since the customer has to pay for the faster PC needed. Hopefully this will change with rising energy costs. And software has a CO2 footprint too.
 

Online tellurium

  • Regular Contributor
  • *
  • Posts: 226
  • Country: ua
Re: food for thought: code bloat
« Reply #75 on: July 22, 2022, 06:01:45 am »
Totally irrelevant questions IMO. Real software bloat are unused bytes that can be thrown out without compromising any of the end results.
No company will ever invest millions of $ for 20-30% in code reduction, they invest in the next thing. Why ? Because new things have a ROI, while code reductions and cleaning only costs money.

Totally agree on the ROI point.

Not fully agree with the last statement, that code reductions/cleaning only cost money. If the software is a one-off, then yes. But if the software gets reused by a company, and gets bloated, then the technical debt increases with time significantly. I've seen cases when development teams cannot even do anything new - they got busy with fixing bugs that appear faster they can fix them; also the bloat slows down everything. In such cases, it is cheaper to do a cleanup or redesign rather than to throw more bloat.

But that is again, the ROI / money issue, not a "high standards" issue. If you're a head of development presenting on a management meeting, the "high standards" argument does not work. The money argument does.
« Last Edit: July 22, 2022, 06:04:10 am by tellurium »
Open source embedded network library https://mongoose.ws
TCP/IP stack + TLS1.3 + HTTP/WebSocket/MQTT in a single file
 

Offline AkiTaiyo

  • Contributor
  • Posts: 30
  • Country: ie
Re: food for thought: code bloat
« Reply #76 on: July 22, 2022, 08:16:57 am »
I recently took it upon myself to completely rewrite the processing engine in one of our imaging software products because the inefficiency and bloat was really bugging me. 

Most of our software is developed by an offshore team who have the approach that a PC has infinite resources, so there is no need to manage them well.

Our software is written in C# so they were leaving the garbage collector to tidy up frames received from the cameras (30fps 3MP cameras).  The garbage collector was running at least once a second and collecting up to 2GB of unused object each time.

I rewrote the core operation with a strong focus on resource management and making use of processor extensions such as AVX and SSE, as well as ditching a bunch of external libraries. 

The improvements are not just noticeable in how responsive the software is, but it was actually measurable at the socket on the test computer. 
Using the old software, the test PC draws 96W from the wall, with the new software it draws 44W. That’s a considerable reduction in power consumption!
 
The following users thanked this post: Berni, madires, Siwastaja, JPortici, SiliconWizard, Nominal Animal, srb1954, dl6lr

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: food for thought: code bloat
« Reply #77 on: July 22, 2022, 05:15:11 pm »
Not fully agree with the last statement, that code reductions/cleaning only cost money.
Ofcourse as a SDev I know that and you know that. The problem I have encountered the last 22+ working years is that management that has to decide where to spent the fte's on does not see it like that.
They think engineers always want to make things more perfect than necessary, or that SDevs suffer from the "not written by me" syndrome and sometimes that is the case, but fixing bloated software stacks or redesigning them so they become more maintainable costs money but earns itself back on the long term.

Most managers nowadays get rated by short term objectives. Time periods of 1 yr max. I never saw a manager that would get a bonus if their software stack would be improved over 5 years time.
And in my work experience the last 8 years in a SAFe wow it was always what can you demonstrate us you did the last sprints or PI ? It is very difficult to demonstrate you cleaned up the software bloat or architecture and then show the product behaves exactly the same way.
 
The following users thanked this post: Nominal Animal, tellurium

Online tellurium

  • Regular Contributor
  • *
  • Posts: 226
  • Country: ua
Re: food for thought: code bloat
« Reply #78 on: July 22, 2022, 09:57:48 pm »
Most managers nowadays get rated by short term objectives. Time periods of 1 yr max. I never saw a manager that would get a bonus if their software stack would be improved over 5 years time.
And in my work experience the last 8 years in a SAFe wow it was always what can you demonstrate us you did the last sprints or PI ? It is very difficult to demonstrate you cleaned up the software bloat or architecture and then show the product behaves exactly the same way.

Exactly. There is also a career/money dimension to it. Many (all?) developers want nice salaries and be promoted, and there is way easier to get more "karma points" and get promoted by developing something new and "impactful" rather than cleaning up old shit.

For example, if Joe is  the only developer in a company, that wouldn't be a problem. But usually there are many developers. If Joe is the one who cleans the bloat, and Bill from the neighbor team actually produces the bloat ; and then Bill gets promoted, and not Joe.. That is a big demotivator for Joe to do any refactoring/cleanup in the future.
« Last Edit: July 22, 2022, 10:08:40 pm by tellurium »
Open source embedded network library https://mongoose.ws
TCP/IP stack + TLS1.3 + HTTP/WebSocket/MQTT in a single file
 
The following users thanked this post: madires, Kjelt, Nominal Animal

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: food for thought: code bloat
« Reply #79 on: July 24, 2022, 03:10:14 am »
They think engineers always want to make things more perfect than necessary,
Which is true. This thread is proof of that.

People who complain about bloat wasting resources and reducing performance don't understand the goal of the system. It's not to make computing more efficient or better for the environment, and it's certainly not to make engineers feel they have done a better job. Our capitalist society is based on convincing others to pay you for the goods and services you produce. So long as they do that it doesn't matter how efficient you are. In fact the more 'make-work' you can convince them is necessary the more it benefits you.

Moore's law says computing power increases exponentially. But without a matching increase in bloat the computer industry would soon be reduced to the same status as toilet paper. Actually worse, because with efficient software a 10 year old computer can still do everything users need it to even after many years of use, whereas toilet paper can only be used once.

Imagine if the engineers got their way and broke the vicious cycle of bloat. Companies like Intel and Microsoft would become shadows of their former selves as sales dried up. Millions of people (including engineers) would lose their jobs and have to do menial work instead. Consumers would discover they didn't need bloat in other things too, like 4k TVs and oversized SUVs. The ripple effect on the economy would be devastating. 

The next markets to crash would be consumer electronics, motor cars and the oil industry, followed by advertising and the news media. Then the internet would crash because content providers would have to charge users rather than relying on dodgy advertising. Unemployment would skyrocket, bitcoin would drop to zero and all our investments would become worthless as the banks failed. All because a few engineers didn't understand the real purpose of bloat.       
« Last Edit: July 24, 2022, 03:14:16 am by Bruce Abbott »
 
The following users thanked this post: Kjelt

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: food for thought: code bloat
« Reply #80 on: July 24, 2022, 11:01:03 am »
Quote
because with efficient software a 10 year old computer can still do everything users need it to even after many years of use

I think you may be conflating bloat with features. If you compare, say, Windows 7 and Windows 2000 there is quite the difference in size - two order of magnitude just for the system drive. Some of it will be bloat but most of it is usability and features that aren't in W2K. Aero, which I'd class as a useful feature rather than bloat, isn't even a dream for W2K.

New features don't depend on just having the resources to waste on them. Mostly they come about because of previous features and someone seeing that and thinking, "Nice! but wouldn't it be cool to..." and off you go.

The contrast of Windows versions is also illustrative of software engineering itself. If you add features for robustness - perhaps bounds checking on arrays - they that requires more code which looks to all the world like bloat, but it has made the software better. Except for a few cases, you don't get owt for nowt, so if you want the fancy high-level language stuff you pay in resources. And you'll be wanting a bigger, faster machine to run it all.

I am not saying that, uh, 'relaxed' coding ability doesn't lead to bloat and thus the need for faster stuff, but I don't see it as the only, or even major, driver.
 

Offline madiresTopic starter

  • Super Contributor
  • ***
  • Posts: 7697
  • Country: de
  • A qualified hobbyist ;)
Re: food for thought: code bloat
« Reply #81 on: July 24, 2022, 11:11:24 am »
Moore's law says computing power increases exponentially. But without a matching increase in bloat the computer industry would soon be reduced to the same status as toilet paper. Actually worse, because with efficient software a 10 year old computer can still do everything users need it to even after many years of use, whereas toilet paper can only be used once.

Actually, less e-junk and wasted resources would be much better for us to survive on the long term. Based on your reasoning we should limit the lifetime of cars to 5 years, instead of using them for 15 to 20 years or even longer. >:D
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: food for thought: code bloat
« Reply #82 on: July 24, 2022, 11:33:02 am »
They think engineers always want to make things more perfect than necessary,
Which is true. This thread is proof of that.

People who complain about bloat wasting resources and reducing performance don't understand the goal of the system.
Which is to gamble that the inevitable crash does not occur while you have a stake in the game, even when it means that fixing the system is out of the question and the ensuing crash will be harsher and more violent to the people who have to live through it.

Who cares about them, as long as it is not us that have to suffer, right?

This is exactly what we're doing to Africa right now, and have done so for almost half a century.  Anyone who objects, is obviously a right-wing racist nutjob.



Thing is, there is nothing capitalistic about that.  It's just short term gambling mentality.  Sometimes, you gotta take a risk or a hit, because the alternative is just that much worse.  The way open source has changed the computing industry –– even though some members here hate it from the bottom of their hearts because they feel it is stealing profit opportunities away from them, and they do not have any idea how to profit from it legally –– shows that changes are possible without inducing such a crash, especially if it is done gradually enough.

In particular, I'm not interested in refactoring everything to be better.  But I am for doing it to the key systems, which is the gradual approach that does not lead to a systemic crash because grifters no longer can shave their living off of the fat.
 
The following users thanked this post: SiliconWizard

Online tellurium

  • Regular Contributor
  • *
  • Posts: 226
  • Country: ua
Re: food for thought: code bloat
« Reply #83 on: July 24, 2022, 04:36:34 pm »
People who complain about bloat wasting resources and reducing performance don't understand the goal of the system

 Our capitalist society is based on convincing others to pay you for the goods and services you produce.

Yes, tell us about bad capitalist "system". Perhaps also mention a good communist / socialist "system"? How lovely, careful and tender it is, with no consumerism and careful to the people and the planet.
Open source embedded network library https://mongoose.ws
TCP/IP stack + TLS1.3 + HTTP/WebSocket/MQTT in a single file
 

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19284
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: food for thought: code bloat
« Reply #84 on: July 25, 2022, 12:30:17 am »
People who complain about bloat wasting resources and reducing performance don't understand the goal of the system

 Our capitalist society is based on convincing others to pay you for the goods and services you produce.

Yes, tell us about bad capitalist "system". Perhaps also mention a good communist / socialist "system"? How lovely, careful and tender it is, with no consumerism and careful to the people and the planet.

Oooh politics. You don't look good by assuming that engineers won't spot the fallacy in
  • X is bad
  • therefore Y must be good
  • where Y isn't not(X)
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: food for thought: code bloat
« Reply #85 on: July 25, 2022, 12:42:08 am »
Yes, tell us about bad capitalist "system". Perhaps also mention a good communist / socialist "system"? How lovely, careful and tender it is, with no consumerism and careful to the people and the planet.

I'm very happy to see so much pushback here against my Marxist countryman!

Voluntary exchange is the best way to organise an economy, and widely-distributed private ownership of resources and land (*including* endangered environments and habitats) is the best way to preserve them.
 
The following users thanked this post: Siwastaja, tellurium

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: food for thought: code bloat
« Reply #86 on: July 25, 2022, 12:47:40 am »
Oooh politics. You don't look good by assuming that engineers won't spot the fallacy in
  • X is bad
  • therefore Y must be good
  • where Y isn't not(X)

Law of Excluded Middle.

You decide for yourself what to do with your time and your property, or someone else tells you what to do with them. There are literally no other options.

The label placed on the "someone else" and their central planning is irrelevant.
 
The following users thanked this post: tellurium

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: food for thought: code bloat
« Reply #87 on: July 25, 2022, 05:13:59 am »
private ownership of resources and land (*including* endangered environments and habitats) is the best way to preserve them.
There is no ownership of land.
At best you are a temporary caretaker of the land.
The sooner humanity realizes that and handles like it, preferably to pass it on better than when the person got it, the better.
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: food for thought: code bloat
« Reply #88 on: July 25, 2022, 05:19:37 am »
Voluntary exchange is the best way to organise an economy, and widely-distributed private ownership of resources and land (*including* endangered environments and habitats) is the best way to preserve them.
According to historical record, this is true.  Add limited competition (i.e., encourage competition but discourage or ban monopolies and cartels), and you'll get even better results for the humans involved.  It also does not exclude commons.

Things that are still somewhat open questions –– because they heavily involve cultural details –– includes things we consider basic necessities: water, energy, waste management, and so on.  Natural monopolies.

At best you are a temporary caretaker of the land.
Isn't that exactly what ownership (of land) means?  It is to me.



I am personally very interested in the way open source has changed software industry.  Make no mistake, even open source developers need to get paid to live; but fortunately at least some companies do see investment into the projects they rely on as useful and necessary.  Mostly, it is the short-sightedness management that is the major barrier; they just cannot see the benefit of making 20x profit in five years compared to 1x profit in one year, especially if it involves making less than 1x profit in the first year.

Personally, I like the model where a client requiring customization or completely custom software, agrees to an open source license.  The client will always get full sources and documentation to the project, and will be able to continue its development even with a different set of developers.  The developers can reuse the code under the same or a compatible license.  Sometimes there are details, especially business logic that is better kept private/proprietary –– I've even signed NDAs for these ––, but there is no reason to avoid that, or to apply the same license for the entire project.  You just keep the boundary clear.

The state of large software projects in Finland is atrocious.  It is assumed that most projects never produce any kind of useful results, and when a project fails, the leaders don't take any flak.  The same managers just shift to a different project, with zero care that millions of euros just got wasted on nothing.  This should never have been allowed to become the 'norm'; it is much worse, overall, than any single 'crash' could be, because it is continuous loss of resources to players who now design their offers to public projects in a way that allows them to garner a nice profit while failing the project.
It is like code bloat on steroids, really.

Granted, I'm a toolmaker, and not a policymaker.  I like to do things that let people do stuff better and more efficiently than before; and I prefer and like it when both myself and my client benefit from the interaction, even more than I prefer and like personal profit.  So maybe that colors my view overmuch.
 
The following users thanked this post: tellurium

Offline tggzzz

  • Super Contributor
  • ***
  • Posts: 19284
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: food for thought: code bloat
« Reply #89 on: July 25, 2022, 08:05:45 am »
Oooh politics. You don't look good by assuming that engineers won't spot the fallacy in
  • X is bad
  • therefore Y must be good
  • where Y isn't not(X)

Law of Excluded Middle.

You decide for yourself what to do with your time and your property, or someone else tells you what to do with them. There are literally no other options.

The label placed on the "someone else" and their central planning is irrelevant.

Nonsense; there are many alternatives. All have disadvantages, of course.

Your position equally "well" extends to any and all form of social behaviour, not just economics. When implemented history repeatedly demonstrates the results are unpleasant: anarchy and warlords, with a theocracy unsuccessfully attempting to reign in excesses.

But religion and politics have no place on this forum, so I won't comment in more detail.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: food for thought: code bloat
« Reply #90 on: July 25, 2022, 10:50:49 am »
I like the idea of enlightened self-interest.  Sure, it's a murky concept because self-interest can be understood in different ways and different contexts.  You could say its basis is the golden rule and deferred gratification.  As I see it, identity politics and shortsightedness (especially in management!) and moral posturing are very harmful and common behaviour patterns in Western societies right now, and I consider enlightened self-interest an ethical antidote.

As to code bloat, it does make a codebase annoying to work with.  Dependency hell, all sorts of process and library interactions producing unwanted behaviour, and so on... Refactoring and shaving off the bloat every now and then does help keep the maintenance costs down, methinks.  So, to me, removing code bloat is a win-win for everyone.

Or maybe I'm just a one-trick pony who applies the same rules to everything, I dunno.  :-//
 

Offline madiresTopic starter

  • Super Contributor
  • ***
  • Posts: 7697
  • Country: de
  • A qualified hobbyist ;)
Re: food for thought: code bloat
« Reply #91 on: July 25, 2022, 01:43:32 pm »
Another aspect of code bloat is security. Instead of writing a few functions for a specific purpose you simply use a lib since it's less work. Remember log4shell (log4j)? How many applications are still running without the patched log4j version?
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #92 on: July 25, 2022, 06:46:11 pm »
Yes yes. Funny thing is, it's not even always less work to use a third-party library. Between learning how to use it, handling dependencies and updates, and all the wasted time when you actually run into a bug, it's not clear at all. At least for the large number of libraries that are commonly used for trivial tasks. (Not talking about the potentially more complex stuff, which I'd venture represents only a tiny fraction of all the third-party code being used overall.)

Beyond the waste of resources (which is very real) - hardware resources and power - the more code a given system contains, and the harder it is to make it secure and, well, just even correct.
Let alone actually being able to demonstrate that it is both. (Oh good lord, what I just wrote is probably an "insult" to many. Demonstrate what?) Who cares, right, it does make quick money.

But reality and the laws of physics always end up victorious. Something you can be sure of.
If we keep acting as children, we will be treated as such. Either by people with more power than we have, or by the above laws. Just a thought.
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4924
  • Country: si
Re: food for thought: code bloat
« Reply #93 on: July 26, 2022, 05:17:53 am »
Using a lot of libraries in a software project is not necessarily a bad thing.

Some projects are just so complex that implementing a lot of it yourself would take too much time. The developers of the library probably also put a lot of work and knowledge in that library to make it perform well. You don't want to reinvent the wheel after all.

But yes indeed just slapping libraries in there willy nilly can quickly lead to dependency bloat where lots of huge libraries are in there just to do this one simple thing. Same for not taking the time to learn how the library works and ending up using the library in a hacky way, likely making the library do a lot of unnecessary work in the background to waste resources.

Also it is hard to tell how good a library is when you come across it. You only truly see how usable or performant it is once you tried using it, but at that point you already wrote code that does stuff so you don't want to rewrite it for another library and you know how to use this library now so you will be tempted to use it on the next project too. This leads nicely into stuffing in big bloated libraries to do one simple thing that could be done using a single 50 line function.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: food for thought: code bloat
« Reply #94 on: July 26, 2022, 06:50:58 am »
Some projects are just so complex that implementing a lot of it yourself would take too much time. The developers of the library probably also put a lot of work and knowledge in that library to make it perform well. You don't want to reinvent the wheel after all.

Yeah, such as this library in node.js's NPM repository:

Code: [Select]
module.exports = leftpad;
function leftpad(str, len, ch) {
  str = String(str);
  var i = -1;
  if (!ch && ch != 0) ch = ' ';
  len = len - str.length;
  while (++i < len) {
    str = ch + str;
  }
  return str
}

On March 22 2016 a large part of the internet went down because the author of the above difficult to duplicate and super-efficiently written module deleted it (and others) from NPM after a dispute involving a company (Kik) claiming trademark rights over the name of one of his other packages and NPM management siding with the trademark claimant.
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: food for thought: code bloat
« Reply #95 on: July 26, 2022, 08:17:42 am »
Some projects are just so complex that implementing a lot of it yourself would take too much time. The developers of the library probably also put a lot of work and knowledge in that library to make it perform well. You don't want to reinvent the wheel after all.
In that case, you should support the library, however.
If you work on a commercial product, it is an investment into your own business.
If you work on a noncommercial product, show your support by letting the upstream know you're happy for the work they do, and when you find a problem (or one of your downstream users reports a problem), you filter and check the bug report and pass it upstream –– or better yet, investigate it and provide suggested patches with full problem description upstream.

This is just enlightened self-interest, in my opinion.

Also it is hard to tell how good a library is when you come across it. You only truly see how usable or performant it is once you tried using it
Exactly; which is one of the reasons I myself try out all kinds of stuff as a "hobby".

Sure, it means you have an archive of hundreds to thousands of test programs, and you get only-a-little-better-than-superficial opinion based on those test cases, but at least it is preliminary experience, not trusting others opinions to reflect reality.

Years ago, in the early years of GnuTLS, I did exactly that because I prefer to have alternatives (then, to OpenSSL), and ended up submitting some suggestions and patches.  So, it is a good way to contribute back to upstreams you might need later on, too.

I wish other experienced devs did the same, too: it would be one way to shave off the bloat without rocking the boat overmuch.
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4924
  • Country: si
Re: food for thought: code bloat
« Reply #96 on: July 26, 2022, 10:45:58 am »
Yeah, such as this library in node.js's NPM repository:

Ah yes i remember that one.

This is one of the reasons why i like it when a languages standard set of libraries includes a lot of basic string/array manipulation functions. At first i was of the opinion that this is not the languages job. "Pfft why do you need a function for lowercasing a string, this takes like a few lines of C code, What is this training wheels for babies?" But later on found they are indeed nice to have. Prevents these little functions from being scattered around and copy pasted or included from various places. Everyone uses the same functions to do the manipulation so it is easier to read other peoples code too. If you have a function that returns the extension for a filename, you know it does that from the function name alone (even tho the actual string manipulation it does could be done with other more basic functions).

In that case, you should support the library, however.
If you work on a commercial product, it is an investment into your own business.
If you work on a noncommercial product, show your support by letting the upstream know you're happy for the work they do, and when you find a problem (or one of your downstream users reports a problem), you filter and check the bug report and pass it upstream –– or better yet, investigate it and provide suggested patches with full problem description upstream.

This is just enlightened self-interest, in my opinion.

I could see the management being furious about someone submitting a git pull request for a library fix that there employee developed during work hours that they are paying for. Reasons ranging from "Why should we be paying to fix bugs in some guys crappy library" to "This is company property, what is this GPL you are whining about" to "We don't want the competition to use OUR fix". This is probably part of the same reason of why service manuals don't have schematics anymore.

I am not that much about Open Source i use Windows even. But i do provide feedback to open source projects when i have something valuable to share. If i fixed a bug or added a feature to an open source project i share it with the developers. It doesn't cost me anything to share it and the developers are pretty much always happy to see it.
 

Offline madiresTopic starter

  • Super Contributor
  • ***
  • Posts: 7697
  • Country: de
  • A qualified hobbyist ;)
Re: food for thought: code bloat
« Reply #97 on: July 26, 2022, 01:10:43 pm »
I could see the management being furious about someone submitting a git pull request for a library fix that there employee developed during work hours that they are paying for. Reasons ranging from "Why should we be paying to fix bugs in some guys crappy library" to "This is company property, what is this GPL you are whining about" to "We don't want the competition to use OUR fix". This is probably part of the same reason of why service manuals don't have schematics anymore.

A long time ago a common idea of companies writing software was to maintain in-house libs for all the little things always needed. Today many simply use open source libs instead. Another case of privatizing profits and socializing losses?
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: food for thought: code bloat
« Reply #98 on: July 26, 2022, 01:31:44 pm »
I could see the management being furious about someone submitting a git pull request for a library fix that there employee developed during work hours that they are paying for. Reasons ranging from "Why should we be paying to fix bugs in some guys crappy library" to "This is company property, what is this GPL you are whining about" to "We don't want the competition to use OUR fix".
That's exactly where the understanding of how open source works comes in.  I have, and will point out to that management person that that means that "We don't want the fixes our competition does to the core parts that we too use, in OUR products; we want ours to be crappier."  If they start getting red, I'll calmly explain how the ecosystem works for a company whose life depends on profit.  The key is that only an idiot who no self-respecting shareholder would hire into management would value small short-term savings over huge long-term profits.

Then again, it is absolutely ridiculous how management-enrichment schemes that hurt the company bottom line are tolerated by shareholders in general.

I am not that much about Open Source i use Windows even. But i do provide feedback to open source projects when i have something valuable to share. If i fixed a bug or added a feature to an open source project i share it with the developers. It doesn't cost me anything to share it and the developers are pretty much always happy to see it.
Like I said, doing that, and fostering a culture that favours developers doing that, is just plain enlightened self-interest.

If there is management who fails to see how supporting the foundations of the products that the company provides for profit is bolstering and safeguarding that business model, then it is literally a shareholder/owner problem: that management needs to be kicked out, before they run the company to the ground.

Here in Finland, management is The Problem.  The lowly product line workers could do anything, it's just that the management cannot pull their heads out of each others asses to run a business for even a second.

That's a major source of societal structural bloat: middle management.  Whenever you hire a new middle manager, they want to grow their own domain, regardless of how it affects the entire organization.  Unless you cut that fat out regularly, you end up like large Finnish organizations, where you have 2×-3× the people in the middle management pushing paper and internal reports and having meetings over coffee or lunch, compared to the number of people working on the actual products and paying projects.
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4924
  • Country: si
Re: food for thought: code bloat
« Reply #99 on: July 27, 2022, 06:01:27 am »
A lot of people don't understand what open source is.

Lots of companies perceive open source as a threat rather than a help. Classical example of this is Nintendo. They have a huge legal department suing people left right and center for doing pretty much anything to anything with a Nintendo badge on it. According to them you are not even allowed to share video footage of there games running on legit hardware. They try to shutdown people developing emulators for there systems (but fail to do so because it is not ilegal). They even threw DMCA claims at YouTube channels that show how to use emulation. There was a effort to decompile SuperMario64 back into C code. They threatened legal action to it too, even tho it contained no copyrighted data from the original ROM cartridge (Just reimplemented C source and a tool that extracts needed assets like models,textures..etc from a dump of the ROM cartridge that you have to supply yourself). Then after all of that Nintendo starts selling a mini novelty SNES console that was found to use an open source emulator to run the games on a ARM SoC.

As for management of large companies always tends to suck since they almost all just work to please the shareholders. This usually revolves around presenting nice green financial numbers for every quarter. Shareholders treat it like any other stock, the moment they see the numbers looking bad they get the hell out of there and start selling off shares, causing the stock price to drop, causing other shareholders to start selling too..etc.. Sure the shareholders want long term growth, but at the same time they are scared of ending up holding the hot potato of a failing company. So management actually has to prioritize short term gains to keep the shareholders on board. This is a crappy business model that is unfortunately very popular.

Some hierarchical management is required once the company gets large enough since the top management can only have so much bandwidth to deal with things. It is more that the wrong kind of people tend to end up in management roles. In small companies you usually have the founders running everything, those usually are very knowledgeable in the field because they had to be to get started. But then as the company grows the extra management positions tend to get filled with people who have no field expertise, so they tend to make bad business decisions when it comes to any technical topic. To make things worse is that the more incompetent people are usually the ones that fight the most for those promotions. The engineers want to get promoted to senior engineer or lead engineer but not into actual management where they would spend there time shuffling papers around rather than getting real work done. Then once they get really big they start specifically hiring people with MBA degrees into management. Those not only have no technical background but also have no idea what the company just arrived at actually does.
 
The following users thanked this post: madires, Nominal Animal

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: food for thought: code bloat
« Reply #100 on: July 27, 2022, 11:26:27 am »
A lot of people don't understand what open source is.

Lots of companies perceive open source as a threat rather than a help. Classical example of this is Nintendo. They have a huge legal department suing people left right and center for doing pretty much anything to anything with a Nintendo badge on it. According to them you are not even allowed to share video footage of there games running on legit hardware. They try to shutdown people developing emulators for there systems (but fail to do so because it is not ilegal). They even threw DMCA claims at YouTube channels that show how to use emulation. There was a effort to decompile SuperMario64 back into C code. They threatened legal action to it too, even tho it contained no copyrighted data from the original ROM cartridge
Nintendo wrote the code for their games, so it belongs to them. They make money from it by selling the game cartridges and the consoles to play them on. Any method used to get around that potentially loses sales for Nintendo. How is that an example of open source 'helping' them?

The reason Nintendo try to stop people making emulators is obvious - because they know people will use them to play pirated games. 'Decompiling' a game into C is effectively the same as simply copying the game - which is illegal and immoral. The game is their creation so they have the right to maintain control over its IP. Open source is not the same as free, but when the source code is out there it's hard to police your IP. Nintendo trying to do so is perfectly within their right. If they don't it could be claimed that they have abandoned it - so they have to police it. There is still money to be made from SuperMario64, but if you let people copy it freely and run it on an emulator then Nintendo get nothing. Why do you hate capitalism?

Your 'classical example' of companies perceiving open source as a threat is actually a classic example of freeloaders taking stuff that doesn't belong to them, to the detriment of the hard-working producers of it. You think SuperMario64 is a great game and you want to play it? Buy the game and the official machine to play it on. Don't want to part with the money? Write your own great game. Oh, but that's too hard? Now you know why you should pay for it.


 
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: food for thought: code bloat
« Reply #101 on: July 27, 2022, 11:56:42 am »
Nintendo wrote the code for their games, so it belongs to them. They make money from it by selling the game cartridges and the consoles to play them on. Any method used to get around that potentially loses sales for Nintendo. How is that an example of open source 'helping' them?
The same way availability of books free of charge increases the sale of books by the same author, as discovered by Baen Books' Baen Free Library.  It was founded in 1999 by Eric Flint, an author himself, and publisher Jim Baen.

The reason Nintendo try to stop people making emulators is obvious - because they know people will use them to play pirated games.
Yet, there is no actual data backing that "knowing".  In fact, actual experiments and statistics points to the opposite.

Except for a few bad apples who try to make a profit off others (by clandestinely using open source in their commercial projects, usually breaking the license; or by making fake cartridges or copies of games and selling them), a typical "pirate" actually spends more money on games than those who do not "pirate" at all.  Companies didn't ditch DRM because they decided to be lenient towards "pirates"; they did so because it hurt their sales.

But by all means, do take your personal beliefs stemming from stereotypes and other peoples beliefs as "knowledge" and "facts", and completely ignore what results have been discovered by actual independent research.  No, I will not give you any sources or links, because that just leads to the social game of "if you listen to that source, you must be X"; you have to do the research yourself.  The question is, are you willing to risk having your "knowledge and facts" be overturned by actual research, or not?

A bit over two decades ago, I was just like you.  Then, I hired a lawyer to teach me how open source licenses, and copyright licenses in general.  I learned how open source actually works for a company working on ordinary profit-making principles.  Baen Free Library did something very similar to creative literature.  Both of us are still bombarded with arguments from people who insist that their core beliefs trump practical experience, and that what we found to be true, could not be true because their beliefs.  It can be horribly tiring, I suspect something like being Dave on Twitter debunking all kinds of dodgy tech from Batterizer to Solar Roadways.
 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: food for thought: code bloat
« Reply #102 on: July 27, 2022, 12:17:36 pm »
Actually, less e-junk and wasted resources would be much better for us to survive on the long term. Based on your reasoning we should limit the lifetime of cars to 5 years, instead of using them for 15 to 20 years or even longer. >:D
In Japan they effectively do limit the lifetime of cars to 5 years. Due to that policy I was able to buy an 8 year old imported Nissan Leaf when I never could have afforded a new one. Apart from the battery the car is practically like brand new. In Japan Nissan has a replacement program for old batteries, but I live in new Zealand where the Nissan agents aren't at all interested in doing it (either for imports or cars sold locally through them). They want to me to buy a new Leaf - or better yet some polluting gas car that they can make more money out of servicing - every 5 years or so.

And that's how Japanese car manufacturers can continuously innovate while making lots of money. But they make more money from bigger more expensive cars, so that's what they push (who cares about the environment, eh?). Nissan got their CEO Carlos Ghosn (father of the Nissan Leaf) arrested on trumped up charges of fraud. Seems they didn't like the direction he was leading the company, as they have lots of bloated gas cars they still want to sell.

Ironically, we would actually be better off if most gas cars were taken off the road after 5 years - and replaced with electric cars. But not more gas-guzzling SUVs. This same principle also applies to computers. Modern computers can be made much less power hungry and cheaper than older ones with the same functionality. But bloat prevents that from being realized. Microsoft could easily keep supporting older versions of Windows that are less resource hungry and just as capable - but they don't (unless you are the US military) because there's no money in it.

It's all about the money. You know it, I know it, we all know that money makes the world go around. That's how the system works and anything that threatens it threatens our way of life. Long term? In the long run we are all dead. Who cares about after that? Capitalists don't care at all. And we are all capitalists - we wouldn't be part of the system if we weren't.

 

Offline Bruce Abbott

  • Frequent Contributor
  • **
  • Posts: 627
  • Country: nz
    • Bruce Abbott's R/C Models and Electronics
Re: food for thought: code bloat
« Reply #103 on: July 27, 2022, 01:38:24 pm »

The same way availability of books free of charge increases the sale of books by the same author, as discovered by Baen Books' Baen Free Library.  It was founded in 1999 by Eric Flint, an author himself, and publisher Jim Baen.
Books, computer games, they're exactly the same  - right? Wrong.

I ran a computer shop from 1991 to 2002. I can assure you that availability of pirated games did nothing to improve sales of the originals. I sold heaps of blank disks though, and the computers to use them on. Still wasn't enough to save Commodore, because software developers were sick to death of piracy. They put demos on magazine cover disks but it didn't help much. Games that took years to develop were cracked in days (sometimes even before release) and distributed around the world via the pirate networks. By the time the latest games got shipped to New Zealand everybody already had a free copy. A few people were willing pay for the originals, either because they wanted the physical stuff that came with it or they were just too honest. The vast majority didn't care. This eventually led to collapse of the Amiga games market.
 
Quote
The reason Nintendo try to stop people making emulators is obvious - because they know people will use them to play pirated games.
Yet, there is no actual data backing that "knowing".  In fact, actual experiments and statistics points to the opposite.
So you say. But it's not up to you to decide. If Nintendo don't really 'know', and could actually sell more games by letting people play free copies on their PCs, then it's their choice to not do so. You are not on their board of directors, so you don't get a say. One thing for sure though is that Nintendo is one of the few console game producers still in business, and was last year rated the richest company in Japan. They didn't get there by making stupid decisions.


Quote
Except for a few bad apples who try to make a profit off others (by clandestinely using open source in their commercial projects, usually breaking the license; or by making fake cartridges or copies of games and selling them), a typical "pirate" actually spends more money on games than those who do not "pirate" at all.  Companies didn't ditch DRM because they decided to be lenient towards "pirates"; they did so because it hurt their sales.
Yes, DRM hurts sales. But if it wasn't for pirates (which on some platforms is the majority of users if you don't have some DRM) it wouldn't be necessary. Game cartridges are themselves a form of DRM, because they are expensive for the individual to copy and fake cartridges can be impounded. Game console makers got by for years because of this. However today - with modern PCs, emulators, and the net - users don't need to buy any hardware and distribution is essentially free. The only people making money from that are computer hardware vendors, ISPs, and Microsoft.
 

Quote
But by all means, do take your personal beliefs stemming from stereotypes and other peoples beliefs as "knowledge" and "facts", and completely ignore what results have been discovered by actual independent research.  No, I will not give you any sources or links...
I don't need links or studies to show me the practical difference between open source and closed source software. Right now I am using a PC running Linux Lite, which is practically the same as Windows but totally free. How many others are doing so? How much are the authors making from it? All Linuxes combined currently have 2% of the desktop market. Windows has 76%, MacOS X has 16%.  Microsoft didn't get to be number 1 by making their software open source.

Quote
A bit over two decades ago, I was just like you.  Then, I hired a lawyer to teach me how open source licenses, and copyright licenses in general.  I learned how open source actually works for a company working on ordinary profit-making principles.
Good for you. But don't assume that because it worked for you it must work for everyone. Plenty of software developers have started open source and then realized they needed more control over their IP. Hey, maybe some of them were wrong about that. But you don't get to tell them what's best for their situation. The market will decide. If Nintendo is anything to go by then the market has already decided...
 


 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8113
  • Country: fi
Re: food for thought: code bloat
« Reply #104 on: July 27, 2022, 02:00:12 pm »
So you say. But it's not up to you to decide. If Nintendo don't really 'know', and could actually sell more games by letting people play free copies on their PCs, then it's their choice to not do so.

It is their choice yes - but what they actually own, what they can exactly do about it, and who they can target, is all limited by law.

For example, if your neighbor plays music too loudly for your comfort, you have every legal right to complain to the landlord or maybe even press charges, but you can't kill your neigbor, cut their electricity, or attack the company who manufactured their audio equipment, or the one who installed their TV set.

Similarly, the only thing Nintendo can legally do something about is to attack those who distribute the game cartridge images (rom files) because those are copies of copyrighted software.

Meanwhile, emulators, as long as they come without any games, are just completely legal, like your neighbor's audio equipment, even if it can be used to play illegally obtained content.

Similarly, making gameplay or emulator videos on Youtube is completely legal.

Making fraudulent DMCA takedown requests, on the other hand, is, AFAIK, an actual criminal offense: the "cure" is worse than the disease, especially because it attacks different people than those actually responsible. People downplay the seriousness of this, but it is actually a pretty big deal fundamentally. Our Western societies are built on the idea that independent authorities (police, judges) decide if someone is guilty, and only said authorities can limit our freedom of speech, and even then under very strict rules. Laws like DMCA (and similar laws elsewhere) shifted this responsibility to individual private companies; similar to you actually having the right to kill your neighbor, for a good reason explicitly specified in law (e.g., neighbor attacking you and you acting as self-defence). To compensate for this shift, it was made illegal to misuse this power - obviously. This is equivalent to you killing your neighbor when he actually did not attack you - try and see what happens.

Yet, large companies do fraudulent DMCA actions - criminal offenses - all the freaking time without getting prosecuted and convicted. And even more weirdly, there are people on the internet who try to justify these actions with some mental acrobatics. This just demonstrates how ****ed up society we live in.
« Last Edit: July 27, 2022, 02:03:12 pm by Siwastaja »
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: food for thought: code bloat
« Reply #105 on: July 27, 2022, 02:43:19 pm »
I agree with much of what you said there, but...

Quote from: Bruce Abbott
Microsoft didn't get to be number 1 by making their software open source.

They didn't get there by selling to the end user, either. I think most sales were actually the Microsoft tax, where they stiffed vendors selling PCs. It's no coincidence that at one time (not sure about now) it was cheaper to buy a new PC with Windows installed than with no OS at all.

I don't think Microsoft is a good example of either route to big money. Word got to be the de facto office suite because world+dog pirated it, but companies who had to actually pay for stuff then bought it because everyone was used to it. Without the pirating Word probably wouldn't have beat the opponents (or if it did, not as fast), but of course a game cartridge isn't going to be an essential business tool.
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4924
  • Country: si
Re: food for thought: code bloat
« Reply #106 on: July 27, 2022, 03:20:37 pm »
Yep it is the fact that big companies abuse various methods of silencing people/things, rather just taking them to court for what is actually ilegal by the law. Or in the case of Nintendo actually taking a open source project they tried to squash in the past and using it as the core component of a product that they then sell and turn a profit on. Even Microsoft or Sony don't pull evil stunts like that.

Yes, DRM hurts sales. But if it wasn't for pirates (which on some platforms is the majority of users if you don't have some DRM) it wouldn't be necessary. Game cartridges are themselves a form of DRM, because they are expensive for the individual to copy and fake cartridges can be impounded. Game console makers got by for years because of this. However today - with modern PCs, emulators, and the net - users don't need to buy any hardware and distribution is essentially free. The only people making money from that are computer hardware vendors, ISPs, and Microsoft.

In 2020 the developer CD Project Red released one of the biggest games of the year Cyberpunk 2077 completely DRM free. Yet it was found among the top sellers for the year in multiple platforms. The same developer has released a lot of its games in a similar way in the past 15 years and they are doing well, in fact they are racking in huge profits.

DRM is not a requirement for having good sales. Having a good product that is easily accessible for the right price is what brings huge sales numbers.

Yes piracy is bad! If everyone pirated all software then people who create it would go out of business. But there are reasonable lengths to go to when fighting it. For example with any software that businesses use you can focus on hunting down companies that pirate there software. Those are easy to make them pay up handsomely to avoid going to court over something they will surely loose. They also buy 100s of licenses at a time, not just 1 that a home user would.
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: food for thought: code bloat
« Reply #107 on: July 27, 2022, 04:18:15 pm »
Right now I am using a PC running Linux Lite, which is practically the same as Windows but totally free. How many others are doing so? How much are the authors making from it? All Linuxes combined currently have 2% of the desktop market.
And Linux has 100% of the HPC market, and a major piece of the server market (at least twice the next competitor, which is not Windows).
Majority of Linux kernel and library developers get their salary from companies and organizations in this sector.

You think you know Linux by using one on desktop?  You're only leveraging the zero cost aspect of it, and not the things that make it useful and powerful.  You're not willing to pay –– or even to reciprocate by spending time and effort –– for anything, so you and others like you do not even form a market: you're a black hole.  It is exactly the existence of this 'market segment' why nobody sane using Linux for business purposes cares a whit about Linux Desktop market share.  There just isn't any business worth doing there, and a lot of black hole (gimme! gimme! I'm your user, you owe me!) demanders with zero intent on reciprocality or support.  They're not even potential users, they're a burden.

No wonder you have zero understanding of what I was trying to convey.
(I do admit a large part is my failure to convey things in English in concise, understandable manner: me fail English.)
 

Offline madiresTopic starter

  • Super Contributor
  • ***
  • Posts: 7697
  • Country: de
  • A qualified hobbyist ;)
Re: food for thought: code bloat
« Reply #108 on: July 27, 2022, 04:30:21 pm »
It's all about the money. You know it, I know it, we all know that money makes the world go around. That's how the system works and anything that threatens it threatens our way of life. Long term? In the long run we are all dead. Who cares about after that? Capitalists don't care at all. And we are all capitalists - we wouldn't be part of the system if we weren't.

Actually, it's human greed. Money is just a concept. And the economic system also doesn't matter much. You'll find greedy people in all systems.
 
The following users thanked this post: CatalinaWOW, Nominal Animal

Online Zoli

  • Frequent Contributor
  • **
  • Posts: 492
  • Country: ca
  • Grumpy old men
Re: food for thought: code bloat
« Reply #109 on: July 27, 2022, 05:04:45 pm »
Convenience and competition ALWAYS beats piracy - don't look further then the PC game market.
Attached is a study about piracy(pretty old and lonely, 2015), for some details.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: food for thought: code bloat
« Reply #110 on: July 27, 2022, 10:08:51 pm »
By the time the latest games got shipped to New Zealand everybody already had a free copy.

There's most of your problem, right there.

In an age of instant communications you have to do simultaneous launch around the world. There are millions of people who are perfectly willing to pay for the product, but what they are NOT willing to do is sit on their hands for weeks or months while their friends are all using and discussing the latest thing.

Computer games are not heavy. It only takes a plane 12 hours to get from LAX or SFO to New Zealand. (and if it is manufactured in Asia then we are *closer*)

It works the other way too.

I remember when Apple launched the iPhone 3G and/or 3GS. They went on sale on the same date everywhere in the world. At least one of the NZ distributors (I recall it being Vodafone) opened their doors at 00:01 on that date. Shops in California opened at their normal 08:00 or 08:30 or whatever it was.

Some enterprising people managed to buy a dozen or a hundred iPhones in Auckland just after midnight, jump on a flight to California, and sell them on the street in Los Angeles or San Francisco at a large profit before they went on sale in shops there. The 19 hour time zone difference helped, obviously.
 
The following users thanked this post: Nominal Animal, tellurium

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: food for thought: code bloat
« Reply #111 on: July 27, 2022, 10:24:41 pm »
Convenience and competition ALWAYS beats piracy - don't look further then the PC game market.
Attached is a study about piracy(pretty old and lonely, 2015), for some details.



I couldn't immediately find a clip of another Jobs' explanation that if you want a song and download a few copies off Napster or Limewire and check them to see which are mislabeled, which are poor quality etc instead of paying $1 to buy the song on iTunes then "you're working for less than minimum wage".
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: food for thought: code bloat
« Reply #112 on: July 27, 2022, 10:47:53 pm »
Quote
I couldn't immediately find a clip of another Jobs' explanation that if you want a song and download a few copies off Napster or Limewire and check them to see which are mislabeled, which are poor quality etc instead of paying $1 to buy the song on iTunes then "you're working for less than minimum wage".

Currently I purchase books for 99p off Amazon and the first thing I do is run them through Calibre to remove the DRM. I don't share them with anybody, but if I couldn't remove the DRM I wouldn't buy them, and these are the equivalent of the $1 tracks Jobs was on about.

A $1 track is just $1, but you don't have just one track. You tend to have loads of them, so you're really talking loads of $. And the 'middle way' that Jobs speaks of is to lock all that up so you can only access them with some specific software on specific kit at the whim of a mega-corp who doesn't see you as an individual. That's just bonkers.
 

Offline YurkshireLad

  • Frequent Contributor
  • **
  • Posts: 365
  • Country: ca
Re: food for thought: code bloat
« Reply #113 on: July 27, 2022, 11:03:06 pm »
Quote
I couldn't immediately find a clip of another Jobs' explanation that if you want a song and download a few copies off Napster or Limewire and check them to see which are mislabeled, which are poor quality etc instead of paying $1 to buy the song on iTunes then "you're working for less than minimum wage".

Currently I purchase books for 99p off Amazon and the first thing I do is run them through Calibre to remove the DRM. I don't share them with anybody, but if I couldn't remove the DRM I wouldn't buy them, and these are the equivalent of the $1 tracks Jobs was on about.

A $1 track is just $1, but you don't have just one track. You tend to have loads of them, so you're really talking loads of $. And the 'middle way' that Jobs speaks of is to lock all that up so you can only access them with some specific software on specific kit at the whim of a mega-corp who doesn't see you as an individual. That's just bonkers.

Can you download kindle books from Amazon to a PC?
 

Online Zoli

  • Frequent Contributor
  • **
  • Posts: 492
  • Country: ca
  • Grumpy old men
Re: food for thought: code bloat
« Reply #114 on: July 27, 2022, 11:42:04 pm »
Convenience and competition ALWAYS beats piracy - don't look further then the PC game market.
Attached is a study about piracy(pretty old and lonely, 2015), for some details.



I couldn't immediately find a clip of another Jobs' explanation that if you want a song and download a few copies off Napster or Limewire and check them to see which are mislabeled, which are poor quality etc instead of paying $1 to buy the song on iTunes then "you're working for less than minimum wage".
Did you understood what I've written:
Convenience and competition ALWAYS beats piracy
I'm not interested what is Steve Jobs opinion on piracy, since it had his own business to peddle.
The document I've linked is a properly done research, not a personal and biased opinion.
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: food for thought: code bloat
« Reply #115 on: July 27, 2022, 11:49:49 pm »
Quote
Can you download kindle books from Amazon to a PC?

Sure. You install the Windows Kindle app and that downloads your books. You can also use it to read them, but I never do :)
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: food for thought: code bloat
« Reply #116 on: July 28, 2022, 12:01:52 am »
Convenience and competition ALWAYS beats piracy - don't look further then the PC game market.
Attached is a study about piracy(pretty old and lonely, 2015), for some details.



I couldn't immediately find a clip of another Jobs' explanation that if you want a song and download a few copies off Napster or Limewire and check them to see which are mislabeled, which are poor quality etc instead of paying $1 to buy the song on iTunes then "you're working for less than minimum wage".
Did you understood what I've written:
Convenience and competition ALWAYS beats piracy
I'm not interested what is Steve Jobs opinion on piracy, since it had his own business to peddle.
The document I've linked is a properly done research, not a personal and biased opinion.

Why are you attacking me when I'm agreeing with you?

Also, I'd take the real-world vast success of the iTunes store (and others) as far stronger evidence than a hundred academic studies.
 
The following users thanked this post: tellurium

Online Zoli

  • Frequent Contributor
  • **
  • Posts: 492
  • Country: ca
  • Grumpy old men
Re: food for thought: code bloat
« Reply #117 on: July 28, 2022, 01:24:08 am »
...
Why are you attacking me when I'm agreeing with you?

Also, I'd take the real-world vast success of the iTunes store (and others) as far stronger evidence than a hundred academic studies.
Sorry for the misunderstanding, but I don't consider Apple competition friendly; convenience, yes - competition, no. Compare Itunes and Steam policies as example.
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: food for thought: code bloat
« Reply #118 on: July 28, 2022, 07:38:02 am »
In a very real sense, convenience is a root cause for code bloat, too.
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4924
  • Country: si
Re: food for thought: code bloat
« Reply #119 on: July 28, 2022, 08:23:56 am »
Yep i might not be a fan of Apple but they have truly revolutionized the music industry.

It has taken a lot of legal work in the background to even allow Apple to implement its iTunes music selling business model. The record labels really really didn't want anything other than selling CDs in physical stores. But eventually Apple made it happen so that they could make music as conveniently accessible as possible at a good price. This has dealt one of the biggest blows to music piracy ever. For a lot of people it became more convenient to buy a song rather than pirate it from P2P networks. So they instead started buying music. All this was all part of the plan for there iPod ecosystem.

In a very real sense, convenience is a root cause for code bloat, too.
Indeed. Throwing in a library or doing it the dirty inefficient way is usually easier so that's what people do.
 
The following users thanked this post: Nominal Animal

Offline madiresTopic starter

  • Super Contributor
  • ***
  • Posts: 7697
  • Country: de
  • A qualified hobbyist ;)
Re: food for thought: code bloat
« Reply #120 on: July 28, 2022, 09:58:20 am »
Using third party libs comes now with an additional risk:
 Protestware on the rise: Why developers are sabotaging their own code (https://techcrunch.com/2022/07/27/protestware-code-sabotage/)
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: food for thought: code bloat
« Reply #121 on: July 28, 2022, 01:07:38 pm »
Quote
Using third party libs comes now with an additional risk:

It shouldn't do. Surely developers download the lib and it's then there forever (or until they forget to do the backup and the disk dies). Only a moroinexperienced wannabe developer would link to the cloud, or auto-download every compile or auto-update without checking out the update first.
 

Online Zoli

  • Frequent Contributor
  • **
  • Posts: 492
  • Country: ca
  • Grumpy old men
Re: food for thought: code bloat
« Reply #122 on: July 28, 2022, 03:26:52 pm »
Yep i might not be a fan of Apple but they have truly revolutionized the music industry.

It has taken a lot of legal work in the background to even allow Apple to implement its iTunes music selling business model. The record labels really really didn't want anything other than selling CDs in physical stores. But eventually Apple made it happen so that they could make music as conveniently accessible as possible at a good price. This has dealt one of the biggest blows to music piracy ever. For a lot of people it became more convenient to buy a song rather than pirate it from P2P networks. So they instead started buying music. All this was all part of the plan for there iPod ecosystem.
...
My point of view is a little different: when itunes come out, the music industry business model already was under pressure from the digital formats(and not only P2P); without Apple opportunistic grab, the music situation now would be similar of what is now on the video streaming market. And to remind you about how customer friendly is Apple: DRM had been removed when Amazon started to sell MP3's, lossless option had been added when Bandcamp(IIRC) started doing. Presenting Apple as customer focused company is hypocrisy.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #123 on: July 28, 2022, 07:31:22 pm »
In a very real sense, convenience is a root cause for code bloat, too.

Yeah. Well, "convenience" is unfortunately a rather loose concept when it comes to managing a project, let alone running a business.

It's much too often a polite way of expressing what is really "instant gratification", which always has hidden costs.

Beyond the "instant gratification" effect, it basically all comes down to what your objective is: is it to minimize time-to-market or is it to minimize long-term operational costs? Both are often pretty much contradictory.

 
The following users thanked this post: tellurium

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: food for thought: code bloat
« Reply #124 on: July 28, 2022, 08:50:46 pm »
My point of view is a little different: when itunes come out, the music industry business model already was under pressure from the digital formats(and not only P2P); without Apple opportunistic grab, the music situation now would be similar of what is now on the video streaming market. And to remind you about how customer friendly is Apple: DRM had been removed when Amazon started to sell MP3's, lossless option had been added when Bandcamp(IIRC) started doing. Presenting Apple as customer focused company is hypocrisy.

Amazon started selling DRM-free MP3s from EMI and Universal on 25/9/2007.

Apple started selling DRM-free AAC songs from EMI on 10/9/2007.

Apple was first, and it was the labels that were the hold-up, not Apple. Apple had been doing the hard work trying to persuafe them to go DRM-free for years.
 

Online Zoli

  • Frequent Contributor
  • **
  • Posts: 492
  • Country: ca
  • Grumpy old men
Re: food for thought: code bloat
« Reply #125 on: July 29, 2022, 05:05:48 am »
My point of view is a little different: when itunes come out, the music industry business model already was under pressure from the digital formats(and not only P2P); without Apple opportunistic grab, the music situation now would be similar of what is now on the video streaming market. And to remind you about how customer friendly is Apple: DRM had been removed when Amazon started to sell MP3's, lossless option had been added when Bandcamp(IIRC) started doing. Presenting Apple as customer focused company is hypocrisy.

Amazon started selling DRM-free MP3s from EMI and Universal on 25/9/2007.

Apple started selling DRM-free AAC songs from EMI on 10/9/2007.

Apple was first, and it was the labels that were the hold-up, not Apple. Apple had been doing the hard work trying to persuafe them to go DRM-free for years.
Apple had the distribution in place for years; when the Amazon deal came thru, Amazon still had to build up the distribution. Apple had to flip a switch, once the Amazon deal was sealed, that's how he managed to beat Amazon with two weeks. But the most important part of the deal(from the labels POV) wasn't the DRM-free distribution, but the multiple storefronts.
As conclusion to our discussion, care to comment of the original DRM terms, especially the one which locks you in the Apple ecosystem(unlimited copies on Apple devices)?
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4924
  • Country: si
Re: food for thought: code bloat
« Reply #126 on: July 29, 2022, 05:50:51 am »
Apple did the most important part of the work in all this. Getting the legal nitty gritty sorted so that the record labels would allow them to sell music using there 'weird new' song by song model. Said record labels are the same people who wanted to instantiate a tax on recordable media (with the excuse to recoop piracy losses), pushed for embedding copy protection data into all digital audio interconnect standards, or placing rootkit viruses on CDs to keep the music on it locked down if inserted in a PC (but also bluescreen computers sometimes)

To make this deal happen the record labels likely pushed HEAVILY for all sorts of DRM to be implemented, the big bosses there must have been absolutely terrified of Apple just handing out MP3s of there music. So Apple would of course offer to implement forms of DRM that fit well into there vision of what the iTunes Store should be. Given that Apple is about building this ecosystem where all apple devices work seamlessly together means that this is a form of DRM they are on board with.

Then after the iTunes store has taken off like a rocket the big bosses at the record labels saw this "stupid way of selling music" as actually beating there own "tried and tested physical CD sales model" so actually started supporting it. The record labels are a very stubborn bunch, so this was a massive effort on Apples side to force them into taking the first step towards a new way of music distribution.

Of course Apple didn't do this because they wanted music to be more accessible to people. The reason they did this is to differentiate there iPod product from the rest of the MP3 players. You no longer had to be a pirate to obtain MP3 files of music you legit own for use on your MP3 player. If you bought a iPod then all you needed to do is open iTunes and buy any song you want for 1$ then wait a few minutes for the songs to be magically transferred to your iPod device. This makes it very easy (even for non technical users) and convenient to fill up your MP3 player with perfectly legal music. So yes Apple did it for there own profit, but in doing so set the stage for internet music distribution.

In a similar way Steam provides a DRM mechanism for its PC games where these games will only run using the Steam client. But it is so convenient and  unobtrusive that most people actually prefer to buy games on Steam rather than say GOG.com, where you get the game DRM free (as simply a giant zip file that you have to then store on your harddrive for the lifetime of owning it). The Steam DRM is also really easy to defeat by simply replacing one steam DLL with one that simply claims you own all games. It is that simple on purpose because they don't want DRM accidentally locking people out of a product they bought. However Steam still allows game publishers to add in any extra DRM they like, but it is there own fault if there own strict DRM turns away buyers.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8113
  • Country: fi
Re: food for thought: code bloat
« Reply #127 on: July 29, 2022, 06:08:18 am »
In a very real sense, convenience is a root cause for code bloat, too.
Indeed. Throwing in a library or doing it the dirty inefficient way is usually easier so that's what people do.

Yet, instead of convenience, I would say, impression of convenience.

Because too many times you see this pattern that doing X from scratch would be 1-day job or whatever, but you can't be allowed to do that, because it is "not convenient", it is "too tedious", and you need to use "time-saving" strategies like managing library dependencies, learn the library, write wrappers, and whatnot, so that 1-day job becomes 1-month job or even worse, when it is about bloated frameworks instead of small libraries, 1-year job.

Then management people assume that hey, by using this trend framework of the year, which is the best thing since sliced bread (this is universal law of physics, like the speed of light, and it can't be questioned), it took a full man-year to get X done, so "imagine how difficult it would have been without the framework, you would have had to write all this 57 000 000 LoC from scratch, isn't it convenient this is all available to us!"

In other words, I don't prefer, but I can accept the priorization of short-term over long-term, i.e., to ship something quickly. But this is not the trend I'm seeing. In reality, we see fairly simple projects get overly bloated, way over budget, way over schedule, supposedly developed using strategies that make things "quick", but result being the opposite: only the quality matches the "fast&ugly" expectation, but cost is cathedral-level.

Hence, I believe the first step towards rectification of this bullshit situation would be to truly measure the time and money poured into software projects, and start doing that buggy unmaintainable crap quickly and cheaply, because now we have buggy unmaintainable crap done slowly and expensively. I.e., don't try to fix quality first, fix the cost side first.

After we trim all the fat off and get into minimum viable prototypes, we can start building sustainable long-term practices, i.e., improve the quality of the product making short-term sacrifices regarding time and money.

But right now, it's impossible to ask for more time and money, because software projects already are way too expensive.
« Last Edit: July 29, 2022, 06:18:13 am by Siwastaja »
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: food for thought: code bloat
« Reply #128 on: July 29, 2022, 08:20:34 am »
As conclusion to our discussion, care to comment of the original DRM terms, especially the one which locks you in the Apple ecosystem(unlimited copies on Apple devices)?

The record labels were convinced by Apple's security mechanisms, but not by others?

Once they dropped DRM that wasn't important of course.

It was Apple pushing the dropping of DRM.
 

Offline nigelwright7557

  • Frequent Contributor
  • **
  • Posts: 689
  • Country: gb
    • Electronic controls
Re: food for thought: code bloat
« Reply #129 on: October 17, 2022, 09:56:38 pm »
Bloat exists because it's currently cheaper to leave piles of shit everywhere than clean it up.

When performance or user experience suffers in any way then it will change.

There's a massive performance and energy usage wall coming up on the hardware side of things that will put the focus back on software efficiency.
With 5GHz processors and many gigs of DRAM it doesnt matter as much these days.
In the distant past I remember scraping the last byte out of assembly language programs to use less memory and gain more speed.
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4924
  • Country: si
Re: food for thought: code bloat
« Reply #130 on: October 18, 2022, 05:07:32 am »
With 5GHz processors and many gigs of DRAM it doesnt matter as much these days.
In the distant past I remember scraping the last byte out of assembly language programs to use less memory and gain more speed.

It does if you have to wait >30 seconds for a TV to boot up. Or when i open up excel and add a graph of a table with 50k points and the whole program locks up for 10 seconds before the graph suddenly pops in.

Sure we might not have to think about saving every last byte these days, we got plenty to throw around. But at least optimize your software to the point that it feels like it is running on a 5GHz machine rather than on a Pentium II
 
The following users thanked this post: madires, SiliconWizard

Offline nigelwright7557

  • Frequent Contributor
  • **
  • Posts: 689
  • Country: gb
    • Electronic controls
Re: food for thought: code bloat
« Reply #131 on: October 27, 2022, 12:38:12 am »
This is a problem in all forms of writing.  There is a famous quote attributed variously to Blaise Pascal, Mark Twain and Jane Austen among others.

"I don't have time to write you a short letter, so I am writing a long one."

It takes time, energy and thought to reduce code size.  All of these are of limited availability in development.

A lot of people still pile in and start writing code instead of planning it.
If you fail to plan, you plan to fail.
 

Online Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: food for thought: code bloat
« Reply #132 on: October 27, 2022, 08:32:49 am »
A lot of people still pile in and start writing code instead of planning it.
If you fail to plan, you plan to fail.
True.

Although, I do tend to write code before I finalize a plan: I create separate test cases to check the key parts and algorithms of the core logic, to make sure the plan I'm planning on is on a solid ground.  I usually learn a lot about it in the progress, and end up rewriting the part anyway in the actual project, so one could consider it wasted effort, but I don't mind: understanding the key parts of the algorithm is worth the time and effort spent to me.

Example:

In certain types of molecular dynamic simulations, temperature control is implemented by simply scaling particle velocities.  This works well for bulk, but for small independent clusters, the initial random velocities do not cancel out perfectly, and the temperature control just makes them rotate faster.  In some cases this is okay, in others it is unwanted.  So, one solution is to determine the particles that form such clusters, and dampen their rotation.

How exactly do you determine which atoms are part of a cluster, when you have some kind of gas permeating the simulation volume?  You might use rules of thumb, but they'll likely fail.  If the simulation is about growing clusters in a very low density hot gas (a very common real life case), atoms are constantly aggregating into the cluster.  In fact, you don't even know how many clusters you have in the simulation.  Asking the human to select the atoms in the cluster is not viable, since simulations tend to be run on HPC clusters in queues, not interactively.

It turns out there is a trivial solution that costs very little.  It is based on the disjoint-set data structure.  Basically, before each time step, you initialize the disjoint set (with an unique integer for each atom, basically numbering them).  Then, when you calculate pairwise interactions –– these simulations almost always use classical potential models, not quantum mechanical ones –– you merge any sets that are within a cut-off distance, approximating covalent and ionic bonds.  (You can do a more precise rule, based on potential energies and the force between the pair of atoms, but it turns out to not be necessary for this.)
At the end of the time step, you flatten the disjoint set paths, and you end up with a cluster identifier for each individual atom.

To implement this, you wouldn't just start modifying your favourite simulator like Gromacs or LAMMPS –– both are open source, so you're definitely allowed to.  Or, well, you'd start by experimenting and testing, before formulating a plan.

Without a plan, just making changes that seem to produce the results you want, you're risking the results of all simulations done by the modified version!

After doing the initial tests so you roughly know where to add or modify the stuff needed, you write a plan.  Then, you check the plan against the logic of the existing simulator, perhaps talk to the developers on the mailing list for confirmation, and only *then* do you start implementing the actual changes.

Now, this may sound like a lot of work.  Thing is, it actually saves total effort.  (At least if we count in the efforts spent to debug willy-nilly made changes and the ensuing erroneous results and other users' efforts in finding why.)

I do not treat scientific simulations any differently than I do normal applications.  I do not want my applications to silently garble or lose data; at minimum, I want them to tell me whenever they detected something unexpected.  Having them do retries and workarounds is a plus.  None of this is really hard; it just takes developers that care.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #133 on: October 27, 2022, 09:02:04 pm »
This is a problem in all forms of writing.  There is a famous quote attributed variously to Blaise Pascal, Mark Twain and Jane Austen among others.

"I don't have time to write you a short letter, so I am writing a long one."

It takes time, energy and thought to reduce code size.  All of these are of limited availability in development.

A lot of people still pile in and start writing code instead of planning it.
If you fail to plan, you plan to fail.

Yep. But the "trick" here is to clearly define what "planning" means in a given context.

If, as is very common these days, "planning" is almost only about timing - focusing on when things must be done - this is going to please top management (until they realize that was all bullshit anyway and that tech plannings rarely hold), but it's not going to help much otherwise.

Now if by planning you mean "architecturing", then sure. Sadly, this tends to be a forgotten notion in software these days, and if you talk about software architecture, you're likely to be considered a dinosaur stuck in the waterfall days. Yeah. And, yeah, people tend to focus on short-term rewards. Just like in other areas anyway. This isn't just with software development.

But anyway. The current state of software development makes me pretty sad overall. Unless you have full control over what you do and how you do it, I would recommend not walking, but running away from software development. Just do something else. Really. And leave it to the ones who are happily churning along.

 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: food for thought: code bloat
« Reply #134 on: October 28, 2022, 08:25:18 am »
Now if by planning you mean "architecturing", then sure. Sadly, this tends to be a forgotten notion in software these days, and if you talk about software architecture, you're likely to be considered a dinosaur stuck in the waterfall days.
The problem is that the term SW and System architect are watered down to mineral water these days.
I now see architects with less than 5 yrs of work experience f*cking it up because they have no clue what they do except look good and talk the talk to pl and mgt in the ten meetings a day they are sitting in.
I said it before in the 90s the career track was
jr sw eng, mr sw eng, sr sw eng, jr sw arch, sr sw arch, jr system arch, sr system arch.
And between each step there would at least be 3 to 5 yrs experience.

But indeed it is all watered down, having sw engs from a different background like biology or history , they do not know design patterns, the solid principles. If or unfortunately when they become architect in a few years just because they hold an academic grade (in biology) you never know what is going to happen  |O
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: food for thought: code bloat
« Reply #135 on: October 28, 2022, 09:11:48 am »
That's old thinking. Nowadays you architect a product by using Python to glue github modules together. Easy peasy.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: food for thought: code bloat
« Reply #136 on: October 28, 2022, 09:23:25 am »
That's old thinking. Nowadays you architect a product by using Python JavaScript to glue github node modules together. Easy peasy.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #137 on: October 28, 2022, 07:10:07 pm »
That's old thinking. Nowadays you architect a product by using Python to glue github modules together. Easy peasy.

 ;D
 

Offline Bud

  • Super Contributor
  • ***
  • Posts: 6879
  • Country: ca
Re: food for thought: code bloat
« Reply #138 on: October 28, 2022, 08:34:14 pm »
System architect are watered down to mineral water these days.
I now see architects with less than 5 yrs of work experience f*cking it up because they have no clue what they do except look good
Do not know what your justification fot 5 years experience comes from.... Many years ago I had 2 years of Extensive experience working in a specific area and I still carry on decades after and get hired and get paid for the knowledge I got from that time period. Granted, I did not sit twiddling my thumbs during those 2 years, but I firmly believe 2 years is a huge experience absorbing resource. Even 1 year, because in my second year new knowledge influx dropped exponentially - simply there was nothing new to learn.
Facebook-free life and Rigol-free shack.
 

Offline perdrix

  • Frequent Contributor
  • **
  • Posts: 635
  • Country: gb
Re: food for thought: code bloat
« Reply #139 on: October 28, 2022, 08:56:30 pm »
I don't know. I'm next to (I refuse to say I'm with) a team of 300 developers and quite frankly they have enough time to do a proper job of solving all the problems. They just lack the motivation and skill to do so.

I saw them burn 9340 hours on something that took me 30 minutes to fix. No shit. That one was fucking buried as well so the management didn't look like morons.

Been there seen that :(

D.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14315
  • Country: fr
Re: food for thought: code bloat
« Reply #140 on: October 28, 2022, 09:21:45 pm »
I don't know. I'm next to (I refuse to say I'm with) a team of 300 developers and quite frankly they have enough time to do a proper job of solving all the problems. They just lack the motivation and skill to do so.

I saw them burn 9340 hours on something that took me 30 minutes to fix. No shit. That one was fucking buried as well so the management didn't look like morons.

Been there seen that :(

Indeed. :popcorn:
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: food for thought: code bloat
« Reply #141 on: October 29, 2022, 08:05:45 am »
Do not know what your justification fot 5 years experience comes from.... Many years ago I had 2 years of Extensive experience working in a specific area and I still carry on decades after and get hired and get paid for the knowledge I got from that time period. Granted, I did not sit twiddling my thumbs during those 2 years, but I firmly believe 2 years is a huge experience absorbing resource. Even 1 year, because in my second year new knowledge influx dropped exponentially - simply there was nothing new to learn.
Always exceptions and it also greatly varies with the domain and scope you are working on.
Surely you agree understand that the software architecture for lets say an thermostate is more limited than for a tv which is again more limited then for an electron microscope etc.
At my current company a new sw eng will only be productive eg earning money for the company understanding what the work is after two years. My previous company that was two months.

But to answer your question, the 3-5 years was the default HR evaluation period with a local large electronics company in the 80s till 2000s. Nowadays it is more dynamic, eg there are brilliant people that stand out and get a fast track.
« Last Edit: October 29, 2022, 08:15:25 am by Kjelt »
 

Offline IDEngineer

  • Super Contributor
  • ***
  • Posts: 1924
  • Country: us
Re: food for thought: code bloat
« Reply #142 on: November 23, 2022, 08:46:06 am »
Sometimes code bloat IS the most efficient solution. "Good, fast, cheap: Pick any two." It totally depends upon the problem being solved. I bet the Apollo 13 astronauts didn't want to delay their return to wait for code jockies to slash a few cycles. On the other hand, they cared very much about optimizing current consumption because their fuel cells were gone.

Not every problem is a PhD thesis. Sometimes "good enough" is exactly the right answer.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8113
  • Country: fi
Re: food for thought: code bloat
« Reply #143 on: November 23, 2022, 11:03:08 am »
Sometimes code bloat IS the most efficient solution. "Good, fast, cheap: Pick any two." It totally depends upon the problem being solved. I bet the Apollo 13 astronauts didn't want to delay their return to wait for code jockies to slash a few cycles. On the other hand, they cared very much about optimizing current consumption because their fuel cells were gone.

Except that bloated shit usually is expensive, delivered late, and does not work, while efficient software is also delivered in time, cheaper, and works better. The correlation is strong.

This is because poor practices go hand-in-hand. If you can't write decent software, or manage a software project properly, then it will fail in many different ways.

Shaving off the last 1% of performance is of course totally different, but it's never about this really.
 
The following users thanked this post: SiliconWizard

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4924
  • Country: si
Re: food for thought: code bloat
« Reply #144 on: November 23, 2022, 11:03:24 am »
Sometimes code bloat IS the most efficient solution. "Good, fast, cheap: Pick any two." It totally depends upon the problem being solved. I bet the Apollo 13 astronauts didn't want to delay their return to wait for code jockies to slash a few cycles. On the other hand, they cared very much about optimizing current consumption because their fuel cells were gone.

Not every problem is a PhD thesis. Sometimes "good enough" is exactly the right answer.

The code in the apollo computers did pick compromises where appropriate.

A lot of the firmware is in the form of bytecode executed using an interpreter to save program space while some sections of code are executed as raw machine code in order to run faster. The computers they had ware not very fast, so speed optimized code was needed in some cases. These early computers also didn't have power saving states to drop into while running.

Optimizing too much in one direction is often a bad thing.I am not asking for people to optimize every last cycle of speed out of there code. Just do the basics to catch the worst speed bumps or resource hogs in code. Picking a slight shortcut that runs at 10% the original speed is not excusable by "It still runs fast enough on my 11th gen i7 machine"
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: food for thought: code bloat
« Reply #145 on: November 23, 2022, 12:26:41 pm »
The code in the apollo computers did pick compromises where appropriate.

A lot of the firmware is in the form of bytecode executed using an interpreter to save program space while some sections of code are executed as raw machine code in order to run faster. The computers they had ware not very fast, so speed optimized code was needed in some cases.

An obsolete concept.

Once you have registers the same size as the data you are manipulating (including pointers), and enough of them, a well-designed RISC ISA with nearly direct hardware control (i.e. simple decode, no microcode) implemented in the now classic 5 stage pipeline is both as fast as simple hardware can go AND as compact code as any interpreted bytecode.

There is no longer any need to choose between size and speed.
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4924
  • Country: si
Re: food for thought: code bloat
« Reply #146 on: November 23, 2022, 12:51:31 pm »
Yeah it doesn't make sense to do this approach on modern machines. Even just ARMs Thumb instruction set is reasonably compact and flash commonly comes in hundreds of KB these days.

Most of the reason this interpreter approach made a lot of sense on the Apollo guidance computer is that the instruction set on it was very limited (really couldn't do a whole lot per instruction in the couple of instructions it had). At the same time program memory was a lot more expensive when it had to be woven trough ferrite rings by hand and actually increased the total mass of the computer. That interpreter must have been a pretty fancy bit of software engineering back in the day.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf