"First this is a stupid metrics because to have less code or less classes is super easy just remove features. For example if you want to have less classes in Pharo just remove the refactoring engine for example and you will instantaneously less class. " That's a straw man argument. When people say that having a lot of code or a lot of classes is a sign of poor design, they mean "a lot of code/classes FOR WHAT IT DOES". It's like me saying "hey, I can typically rewrite a Java program in Smalltalk and use only about a quarter as much code". That carries the impicating "WITHOUT sacrificing functionality.:" Second, whether having a lot of classes is an indication of poor design is an empirical question. Whatever dogma says, it MIGHT be and it might NOT be. We should approach that by empirical software engineering, looking at repository histories. Is there a correlation between class count and code churn or is there not? For example, one way to get a lot of classes or methods or SLOC or whatever is to reimplement something that's already in the library. Doing your own persistence instead of using Fuel, maybe. Another way to get excess classes is to do an incomplete analysis and fail to notice that two things are actually the same thing seen from different perspectives. On Sat, 10 Feb 2024 at 22:14, stephane ducasse <stephane.ducasse@inria.fr> wrote:

https://wordpress.com/post/pharoweekly.wordpress.com/4226

Stéphane Ducasse http://stephane.ducasse.free.fr 06 30 93 66 73

"If you knew today was your last day on earth, what would you do differently? ....ESPECIALLY if, by doing something different, today might not be your last day on earth.” Calvin & Hobbes