Speed doesn't matter if you're doing the right thing.
Writing code can't be done quick without knowing what you need the outcome to be.
Then speed is set by how fast you type.
But it's a theory, and practice no one writes code without having to put thinking into it.
So speed is not a measurement I would ever count as a good trait in terms of quality. And quality cannot be measured, so we're back to why speed is even interesting in productivity of software creation
Ideally, but that's not always the case. For example, let's say my goal is to write the program that outputs Hello World. In some languages it's as fast as writing the literal characters. The only extra burden is maybe to put quotation marks around them.
"Hello World"
13 characters total. But if I did this in Java for instance, well that's a different story. Now the program looks like this:
class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World");
}
}
87 characters total. The original program could have been written 6 times over in the time it took to write just this one. But that's not the real issue. The real issue is that not only do I have all that extra syntax, I have a whole bunch of new concepts to contend with including classes, scopes, functions, function composition, console arguments, lifetimes, access, types, arrays, objects, and methods. I can't just do a thing, I have to do all this extra work before I can do the thing. In the first case I have a single concept in my mind: String. In the second case I have to keep not only N concepts straight, but how they compose as well, and all the arcane rules therein.
This is like those reviews of operating systems that are 50% about the installation process, even though most people install their own operating system at most once, and most likely zero times. Then go on to use it for years and years. Making the "issues" listed in the review something that affects 0.01% of the time interacting with the product being reviewed.
Most developers are working on a codebase where they did not personally write that "void main(...)" boilerplate! Someone else did all the initial scaffolding, they joined the team years later, and they're adding new feature "X".
In terms of productivity, all of those things you listed as negatives due to the mental load they impose are absolutely essential for this scenario of a team member joining and having to modify a large code base. Scopes, lifetimes, classes, interfaces, etc... are the levers for the mind that enable teams to work together successfully.
> 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.
I'm not really sure what the parent poster was trying to say. It seems like an abstract example, but then goes into way too much detail about the actual language concepts Java brings to the table.
Obviously one can't take the time from zero to Hello World as a benchmark for productivity.
Writing code can't be done quick without knowing what you need the outcome to be.
Then speed is set by how fast you type.
But it's a theory, and practice no one writes code without having to put thinking into it.
So speed is not a measurement I would ever count as a good trait in terms of quality. And quality cannot be measured, so we're back to why speed is even interesting in productivity of software creation