on a commercial setting there is more pressure to deliver code then to review it. combine it with the lack of our benevolent dictator for life (that has been on the project the world life cycle, not just recently), there is no one with power to actually say no to changes.
language geeks are novelty seekers. they will use every feature of their language . stronger languages have more features to abuse. so on a commercial setting you will have all the features being used without much thought an architectural design that says you that no, we shouldn't do that.
that's also why I think projects with benevolent dictators for life on the open source ward don't fall these in paths even though they use languages that are stronger.
you could restrict yourself to use languages that have only one way to be used, so python as it was originally. or use a language little abstraction power. but you will suffer in other ways. as abstraction power is genuinely useful. accidental complexity has a way of getting in by expressive means or by social means.
I'm confused. If you can reason about f and g, there is nothing more to know about f o g -- provided f and g are pure functions. The whole thing is about making sure side-effects are properly pushed at the boundaries so that you can keep working with pure functions. Haskell just provides more help (or more constraints) to ensure that you work with pure functions. Because if you aren't, all bets are off, and indeed the case of f o g may be a haze.
f :: Integer -> Boolean
g f n = if (f n) then (g f (n+1)) else (is_it_reachable)
I know this is the atomic bomb case, but you can actually quite easily increase the complexity in realistic programs by just a few compositions, it doesn’t take much.
But if you consider a program implementation of pure functions, this might not be true; for example f and g use a quantity of RAM, but the RAM used by f o g exceeds your computer RAM and thus explodes. Or, if we work with objects, some values (e.g. internal values of the object, or context values) may be changed that make the final result of f o g different from what you would normally expect.
The promise of working "functionally" is to avoid the second class of problems. For the first class this is just a problem of computer systems, but pure functions means that the memory should be able to be reclaimed efficiently. And for the limits of computability theory (like the halting problem), nothing works except oracle machines, but no startup has ever delivered a functional one!
If the halting problem is really your biggest concern when developing software then you're lucky!
What? The ability to reason about f o g (for various definitions of o) is the promise of Haskell and one of its entire ecosystem's foundational principles.
Local reasoning is absolutely possible.
But at the code level - nobody cares at all. It’s like we are writing literature, not building tools.
But Haskell technical leadership sometimes is either lacking/inexperienced or goes down the rabbit hole of overusing the compiler to prevent fuckups to the point where you're compiling way too much code and get into a coupling nightmare.
> become exponentially more complex
obviously this can't be read as "become exponentially more structured" given the tone of the sentence.
and Youtube where I archive my streams: