> The more you want your code to be small, the more you're gonna need a programming environment (language/API/runtime/framework) doing things for you under the hood. And there's nothing wrong about it!
Or have your code do one thing and only one thing, a single purpose, with clear, well defined interfaces and then compose things doing only one thing to a bigger thing that you can reason about more easily because the interfaces and processes are well-defined.
One thing I've seen too much of in my professional life is complex projects trying to do too much, with ill-defined roles and implicit, poorly documented interfaces.
Simplicity of a language works well as long as your projects are kept simple. You can build fairly complex solutions by composing multiple simple projects with well defined interfaces.
I think we agree that simplicity of a language works less well when the scope of a single project is too large and too arbitrarily defined.
Or have your code do one thing and only one thing, a single purpose, with clear, well defined interfaces and then compose things doing only one thing to a bigger thing that you can reason about more easily because the interfaces and processes are well-defined.
One thing I've seen too much of in my professional life is complex projects trying to do too much, with ill-defined roles and implicit, poorly documented interfaces.
Simplicity of a language works well as long as your projects are kept simple. You can build fairly complex solutions by composing multiple simple projects with well defined interfaces.
I think we agree that simplicity of a language works less well when the scope of a single project is too large and too arbitrarily defined.