> I think that when the word 'bloat' is used to often doesn't imply just an increase in > size (as in size on disk or size in memory). I think it often means the 'bloat' of > slower code that comes from advanced language features like virtual methods, multiple > layers of interface, descriptive instead of optimized data structures, etc. That > stuff does impact performance and I think it's what most people are concerned with > when they talk about bloat. > > References Please Bryan. Let us all know how you got to this conclusion.
Just from reading lots of comments on these forums and the resulting discussions. Also from inferring people's true feelings based on what they said when it wasn't clear exactly what they meant. I could be totally wrong but I think that there are lots of people that perceive relative performance decreases in MAME as being due to bloat; I think that's a commonly repeated sentiment.
> If this is true, where are the groups of QA people checking out the code to ensure > that the requirements of the project are met? Otherwise unchecked project creep on > how many forks?
I'm not sure I understand you here, but keep in mind that there are no paid QA engineers on the project and people almost certainly focus on what they believe is interesting and relevant, and many of those people are more likely focused on bugs than performance. And also, I believe that people who are interested and motivated enough to do QA for the MAME project probably have a better understanding gleaned through the same kinds of discussions as this about the reasons for 'bloat' and don't think of it as a bug that needs QA attention.
> Wirth's law is quite ironic when you look at large software projects. I imagine Mame > getting slower and slower when the accuracy of the project's goal becomes more > realized.
Also I think Wirth's law is a crock of shit, excuse my frankness. Software is getting more and more complex all the time because it's doing much much more than it used to. Also like I said, you can develop software faster (or equivalently, with fewer human resources) with more modern tools that do create slower running programs; you can say that the software is getting slower without any benefit but there is a benefit: more rapid development, and more maintainable code.
Index 
Flat 
Re: Tredding on toes again
Reply
