gabby

why is this so hard to explain sometimes!

i know im the odd one out but i honestly disagree

functional programming and imperative programming both have a lot of issues, and as someone who actively uses both, id much rather apply the concepts of one where it can compensate for the pitfalls of the other, than strictly adhere to a "paradigm"

so yes, if functional programming wont allow me to guarantee strict performance, order of operations, and memory requirements, the point is do to imperative programming a little nicer

lets not forget that the only reason as to why haskell code has okay-ish performance is because GHC thinks it deserves gigabytes for a compiler and a completely unapproachable mess of a codebase consisting of fragile optimizations that dissolve the near-instant you try hand-tuning performance yourself

i think that instead of fixating on the ways in which these paradigms are different and why Our Paradigm is The Better One Actually, we're more productive finding the ways in which these paradigms are the same, or at least can be used in tandem to correct for each others shortcomings

im admittedly biased but i think the fact that CPU instructions can be modelled as endomorphisms is a more interesting observation than hearing functional programmers complain "side effects bad" for the 900th time or hearing imperative programmers complain "recursion bad" for the 900th time