> Most developers are working on a codebase where they did not personally write that "void main(...)" boilerplate Most developers yes. Most programmers, no; Ex

> Most developers are working on a codebase where they did not personally write that "void main(...)" boilerplate Most developers yes. Most programmers, no; Excel is the most popular programming language in the world by far. Imagine if Java were used instead of Excel to solve the same kind of problems Excel is used for today. Think about how much extra boilerplate would be in this world for no reason. Because the many hundreds of millions of people using Excel have done so for their purposes without missing the features you claim are essential for team development. And maybe they are! But to my point, if you're not doing team development, then why do you need to even think about these features that aid in team development? If you are not trying to implement an object-oriented system, then using a tool that prescribes a maximalist object-oriented design philosophy is going to add a lot of extra work with no clear tangible benefit to the actual problem you're trying to solve. This is incidental complexity, and it's going to slow you down no matter how fast you type compared to a system that excludes this complexity. The system that eliminates incidental complexity will provide the least amount of friction between you and solving your problem. That's the ideal. Any tooling you add to the task is going to introduce some complexity. That complexity may ultimately be beneficial or it could get in your way. It depends on what you want to do.