9 ms·

They are usually not hidden, so they are at least easier to identify.

kstenerud 4y ago
This is the crux of the matter. Every paradigm is argued about using small program examples, but the real-world issues come as the codebases become large (1M LOC or so). Then the cracks become worriesome. Imperative non-OO codebases become swamps of maybe (hopefully?) layered code, where each layer contains its own sinkholes and completely bizarre structure (or lack thereof). It's basically a bunch of mini-codebases that meet in an ad-hoc manner, making it very difficult to understand what the hell is going on. OO codebases encapsulate a LOT better, but working around its straitjacket design becomes harder and harder as you go through rituals like dependency injection, interfaces, adapters, facades, class clusters, and byzantine inheritance hierarchies. Now, rather than a swamp of despair, you have pebbles of functionality. And while these were great when your codebase was 50k LOC, it's now a gravel pile where you can't figure out where anything starts or ends. FP codebases like to push the details out of the way, making it easier to see at a high level what's going on. But as the codebase grows, you now have multiple iceberg problems, where the devils in the details begin to derail your code in production, and suddenly you find yourself needing to delve down rabbit hole after rabbit hole, chasing issues that weave and bob in utterly chaotic ways due to the lazy evaluation. Reasoning about what it will actually do in what time becomes more and more difficult (putting it in vulgar terms: You're basically exchanging topical complexity for temporal complexity). TANSTAAFL
- Capricorn2481 4y ago
  Do you pick the lesser of 3 evils, or are there solutions to these cracks?
- peheje 4y ago
  I haven't worked with a big FP codebase, but I actually thought about this when doing even small toy programs in FP. Sometimes I'm like... do they merge the multiple-sequential-maps that's possibly being done here? Does the code re-use the elements of map that doesn't change? Whereas was it C# or Go, I could just read it. OTOH isn't that just - you need to know what the function you are calling is doing and how, and read the doc. Whereas in imperative you would implement it yourself, with the pitfalls of that. If you are coding in Python and you are using a lot of numpy you need to know how to feed data in, how to get data out, etc. so maybe FP programming should treat the STD-lib more like an external library because the building blocks are a bit more high-level?

This is the crux of the matter. Every paradigm is argued about using small program examples, but the real-world issues come as the codebases become large (1M LOC or so). Then the cracks become worriesome. Imperative non-OO codebases become swamps of maybe (hopefully?) layered code, where each layer contains its own sinkholes and completely bizarre structure (or lack thereof). It's basically a bunch of mini-codebases that meet in an ad-hoc manner, making it very difficult to understand what the hell is going on. OO codebases encapsulate a LOT better, but working around its straitjacket design becomes harder and harder as you go through rituals like dependency injection, interfaces, adapters, facades, class clusters, and byzantine inheritance hierarchies. Now, rather than a swamp of despair, you have pebbles of functionality. And while these were great when your codebase was 50k LOC, it's now a gravel pile where you can't figure out where anything starts or ends. FP codebases like to push the details out of the way, making it easier to see at a high level what's going on. But as the codebase grows, you now have multiple iceberg problems, where the devils in the details begin to derail your code in production, and suddenly you find yourself needing to delve down rabbit hole after rabbit hole, chasing issues that weave and bob in utterly chaotic ways due to the lazy evaluation. Reasoning about what it will actually do in what time becomes more and more difficult (putting it in vulgar terms: You're basically exchanging topical complexity for temporal complexity). TANSTAAFL

Capricorn2481 4y ago
Do you pick the lesser of 3 evils, or are there solutions to these cracks?
peheje 4y ago
I haven't worked with a big FP codebase, but I actually thought about this when doing even small toy programs in FP. Sometimes I'm like... do they merge the multiple-sequential-maps that's possibly being done here? Does the code re-use the elements of map that doesn't change? Whereas was it C# or Go, I could just read it. OTOH isn't that just - you need to know what the function you are calling is doing and how, and read the doc. Whereas in imperative you would implement it yourself, with the pitfalls of that. If you are coding in Python and you are using a lot of numpy you need to know how to feed data in, how to get data out, etc. so maybe FP programming should treat the STD-lib more like an external library because the building blocks are a bit more high-level?