2 ms·

It's not about having a name in front of the static method, it's about e.g. say I have IO readers, and I want to provide a method to drain a reader, or copy a r

It's not about having a name in front of the static method, it's about e.g. say I have IO readers, and I want to provide a method to drain a reader, or copy a reader to a writer, why should such methods have to be class members? If the only reason is because the language doesn't permit otherwise (like Java) then it's essentially nothing but extra boilerplate. When you write a lot of code, this all adds up. Inevitably, over time, folk will grumble. There are simpler ways to express such things in other languages. Sometimes less is more.

giancarlostoro 6y ago
> If the only reason is because the language doesn't permit otherwise (like Java) then it's essentially nothing but extra boilerplate. When you write a lot of code, this all adds up. Inevitably, over time, folk will grumble. There are simpler ways to express such things in other languages. This is also part of why Kotlin so easily sells itself, despite not being perfect, it removes a lot of what you refer to as boilerplate (I prefer the ceremony of Java / some OOP-only languages).