3 ms·

> Since the volume is always >= the surface You'll find out that analogies to Euclidean geometry do not hold for software structure in general. That's a nice

> Since the volume is always >= the surface You'll find out that analogies to Euclidean geometry do not hold for software structure in general. That's a nice heuristic though. Just be wary that if you follow it blindly, you will inevitable optimize things into a counterexample where everything breaks down while your proof still finds it's the optimal. Static analysis is good, in moderation; dynamic validation is good, in moderation; accepting errors and dealing with them is goo, again, in moderation. All of those things turn bad if you do them out of dogma.

chipdart 2y ago
> Static analysis is good, in moderation; Care to point out your best example on when static code analysis ceases to be good? I don't think there is possibly any copout to justify away the benefits of static code analysis. Either your code works by complying to the interface, or it doesn't and violates interfaces. The only thing static code analysis does is force you to acknowledge the real interfaces.
- marcosdumay 2y ago
  Hum... You mean you've never encountered complex interfaces dictated by their types? I was about to make a Haskell joke, but it's actually Java that is most famous for this. There are lots of "enterprise Hello-Word" published on the internet if you want some done on purpose.
  - chipdart 2y ago
    > Hum... You mean you've never encountered complex interfaces dictated by their types? I asked you what you personally believe is your best example on when static code analysis ceases to be good. I fail to see how anyone's opinion or personal experiences determine your own personal opinion on a subject. Can you provide any example on how static code analysis can be anything other than a good thing? > There are lots of "enterprise Hello-Word" published on the internet if you want some done on purpose. I'm sorry, what does this have to do with static code analysis?
wokwokwok 2y ago
Sure, maybe the metaphor doesn't make perfect sense. ...but, strictly, if you have a module with K public functions and P private functions the maximum possible number of unique external dependencies you have to track on the module is K. If P > 0, then the 'api surface' of the module is smaller than the total set of functions. If K = 0, the module has no external dependencies and you can do whatever you want. I'm going to say with complete confidence that creating 'boxes' in your software where you minimize K creates maintainable software. When K = P, you have a dumpster fire.

chipdart 2y ago

> Static analysis is good, in moderation; Care to point out your best example on when static code analysis ceases to be good? I don't think there is possibly any copout to justify away the benefits of static code analysis. Either your code works by complying to the interface, or it doesn't and violates interfaces. The only thing static code analysis does is force you to acknowledge the real interfaces.

marcosdumay 2y ago
Hum... You mean you've never encountered complex interfaces dictated by their types? I was about to make a Haskell joke, but it's actually Java that is most famous for this. There are lots of "enterprise Hello-Word" published on the internet if you want some done on purpose.
- chipdart 2y ago
  > Hum... You mean you've never encountered complex interfaces dictated by their types? I asked you what you personally believe is your best example on when static code analysis ceases to be good. I fail to see how anyone's opinion or personal experiences determine your own personal opinion on a subject. Can you provide any example on how static code analysis can be anything other than a good thing? > There are lots of "enterprise Hello-Word" published on the internet if you want some done on purpose. I'm sorry, what does this have to do with static code analysis?

wokwokwok 2y ago

Sure, maybe the metaphor doesn't make perfect sense. ...but, strictly, if you have a module with K public functions and P private functions the maximum possible number of unique external dependencies you have to track on the module is K. If P > 0, then the 'api surface' of the module is smaller than the total set of functions. If K = 0, the module has no external dependencies and you can do whatever you want. I'm going to say with complete confidence that creating 'boxes' in your software where you minimize K creates maintainable software. When K = P, you have a dumpster fire.