4 ms·

Perhaps, but: * As the size of the codebase increases, dynamic languages fare worse. Refactoring 10K lines of Python in a sweeping fashion is much harder than

Perhaps, but: * As the size of the codebase increases, dynamic languages fare worse. Refactoring 10K lines of Python in a sweeping fashion is much harder than 100 * How many of those 1000 lines of Java are boilerplate, and could be generated/hinted at by IDE's? * The more you're abstracted away from what's actually going on (types, memory, etc), the harder it is to optimize for performance, or even let it become part of your initial design/thought process. This rears its head later in the process * How much does static analysis prevent you from creating bugs in the first place? If it takes longer to write error-free code, then the line count comparisons aren't always that meaningful

Nextgrid 6y ago
I'd argue that if the code is boilerplate and can be auto-generated then it shouldn't be necessary in the first place, the compiler should be able to infer it by itself.
mumblemumble 6y ago
> How much does static analysis prevent you from creating bugs in the first place? In my experience, basically not at all. It might help you catch some bugs a bit sooner, but, outside of languages like C that have no guard rails to speak of, the bugs I've seen cause problems in production are rarely, if ever, the kinds of bugs that static analysis tools are even trying to look for. I am a big fan of linting, but it's primarily because I like anything that makes the code less surprising to future readers. For a similar reason, I see the Java boilerplate as a maintenance liability because, while the IDE can write it for you, it's a readability burden. Future readers have to look at that boilerplate, recognize it as such, and then read more closely to make sure it is perfectly standard boilerplate before they actually know what the code is doing. And any small deviation creates uncertainty. Was that deviation intentional or was it a mistake? The thing is, boilerplate is boring, so nobody actually does that. In short, it's a classic example of the paradox of automation.

Nextgrid 6y ago

I'd argue that if the code is boilerplate and can be auto-generated then it shouldn't be necessary in the first place, the compiler should be able to infer it by itself.

mumblemumble 6y ago

> How much does static analysis prevent you from creating bugs in the first place? In my experience, basically not at all. It might help you catch some bugs a bit sooner, but, outside of languages like C that have no guard rails to speak of, the bugs I've seen cause problems in production are rarely, if ever, the kinds of bugs that static analysis tools are even trying to look for. I am a big fan of linting, but it's primarily because I like anything that makes the code less surprising to future readers. For a similar reason, I see the Java boilerplate as a maintenance liability because, while the IDE can write it for you, it's a readability burden. Future readers have to look at that boilerplate, recognize it as such, and then read more closely to make sure it is perfectly standard boilerplate before they actually know what the code is doing. And any small deviation creates uncertainty. Was that deviation intentional or was it a mistake? The thing is, boilerplate is boring, so nobody actually does that. In short, it's a classic example of the paradox of automation.