You misinterpreted my intention - that’s how I normally present things from my domain of expertise and I was actually making an effort to simplify it and not use too much domain specific slang.
Since you’ve pulled the expertise card out, I’m a Technical Architect with 30 years experience in software engineering, having working all the way up from a software developers, in several countries, several domains of software engineering and even for several industries, and amongst other things that includes Android, iOS, Linux-based and Windows-based systems, both frontend and backend, which is applicable for modern centralized user control systems for cars as well as infotainment systems, and those are just a fraction of the kind of areas in software design and developement I worked in.
I only said I was a hobbyist very specifically in embedded systems software because even though I have an EE degree and have 3 decades of professional experience in other software development domains, I only ever did software for embedded systems for fun - though I have some years of it - not for work, and I was hardly going to claim I was a bloody professional in a specific domain of software engineering were I did not work as a professional.
So yeah, if there’s something I know about is how the number of inputs and outputs influences the size of the code (very little, as that’s not were the complexity lies) and how software running in weaker computing units is way smaller and much more optimized than software running in powerful computing units because the very software developers themselves (at all levels, including OS and libraries) learn from experience very different lessons about how much time they should spend making their code small and tight when they are working with weaker processing units versus working with powerful processing units.
You misinterpreted my intention - that’s how I normally present things from my domain of expertise and I was actually making an effort to simplify it and not use too much domain specific slang.
Since you’ve pulled the expertise card out, I’m a Technical Architect with 30 years experience in software engineering, having working all the way up from a software developers, in several countries, several domains of software engineering and even for several industries, and amongst other things that includes Android, iOS, Linux-based and Windows-based systems, both frontend and backend, which is applicable for modern centralized user control systems for cars as well as infotainment systems, and those are just a fraction of the kind of areas in software design and developement I worked in.
I only said I was a hobbyist very specifically in embedded systems software because even though I have an EE degree and have 3 decades of professional experience in other software development domains, I only ever did software for embedded systems for fun - though I have some years of it - not for work, and I was hardly going to claim I was a bloody professional in a specific domain of software engineering were I did not work as a professional.
So yeah, if there’s something I know about is how the number of inputs and outputs influences the size of the code (very little, as that’s not were the complexity lies) and how software running in weaker computing units is way smaller and much more optimized than software running in powerful computing units because the very software developers themselves (at all levels, including OS and libraries) learn from experience very different lessons about how much time they should spend making their code small and tight when they are working with weaker processing units versus working with powerful processing units.
That’s nice but it doesn’t change the facts:
The software that you are stating “gets bloated” is in all vehicles, not just EVs.
Combistion vehicles have more inputs and outputs to incorporate in the bloated software than EVs.