2 ms·

Follow up thought: To me, dynamic features are useful, and a net win for maintainability, when they allow you to write smaller, simpler code. Just picking some

Follow up thought: To me, dynamic features are useful, and a net win for maintainability, when they allow you to write smaller, simpler code. Just picking some magic numbers out of thin air, say I can get the same job one in 100 lines of Python or 1,000 lines of Java. It's likely, if not guaranteed, that the Python code base will end up being easier to maintain in the long run. I think that sometimes maintainability comparisons fail to be entirely fair because they rely on cross-language comparisons of codebases of similar size, rather than of similar levels of functionality. Which is only natural, since substantive opportunities for the latter kind of comparison are rare in the wild, but still. To take a concrete example: The original Smalltalk system was this enormously featureful piece of software, even by today's standards. And it was written in one of the most dynamic languages ever, but it was also famously maintainable. My impression (admittedly based only on poking around at the edges a bit and not actually living in Smalltalk in any serious way) is that the reason for this is that the whole thing was implemented with so little - and such simple - code that, in stark contrast to just about any other GUI environment, it was feasible for a single person to read and understand the whole thing in a reasonable amount of time.

drchopchop 6y ago
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.

drchopchop 6y ago

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.