[crimsonalucard]

Thanks for letting me know rust isn't OOP. I never said it was. Funnily.

>Ignoring type systems and just looking at functional vs imperative, the advantage for functional is immutability making functions easier to reason about. Haskell in particular is also lazy, and therefore enables you to not be concerned with evaluation order.

Sans the part about laziness, for which the formal term is "normal order evaluation" FYI, OOP guys say the exact same thing about objects word for word.

[leshow]

I don't see how that could be true, as OOP is inherently about encapsulating mutation not preventing it. The problem with OOP is you're also free to alias mutable objects.

> Sans the part about laziness, for which the formal term is "normal order evaluation"

If you want to be pedantic, Haskell is 'call by need', not 'normal order'.

[crimsonalucard]

Sure but this is what they say and what they believe. Literally. Armies of programmers believe this and your statement won't convince them.

It always goes into philosophical mumbo jumbo. I'm looking for quantitative and logical proofs that say definitively why functional is better. You do see how your statement will just trigger a vague retort from an OOP guy which will trigger a bunch of other vague retorts and counter examples from you. The end game is it goes nowhere.

If I want to be pedantic, the official term is normal order. You are wrong on this. See SICP chapter 1.

[leshow]

> If I want to be pedantic, the official term is normal order. You are wrong on this. See SICP chapter 1.

SICP isn't going to help you, we're talking about Haskell's 'call by need' evaluation. It's not the same as 'normal order', feel free to look up the definition where ever you like.

I don't think a 'logical proof' is even possible, so I'm not really sure what you're asking for. We could definitely use more research on paradigms and their effects. There are a few studies on types providing benefits, but nothing that I'm aware of about FP. I think the problems stems from the fact that "functional programming" is itself a pretty loose definition.

edit: something you can read about evaluation order,

https://en.wikipedia.org/wiki/Evaluation_strategy#Non-strict...

[crimsonalucard]

All right I'll give you that on evaluation order. Did not realize that Haskell took it two steps further.

Logical Proofs are possible for most things that have logical definitions.

There are aspects of FP that can be enforced in your proof. You don't have to have a vague definition of good design or a vague definition of FP. Follow a strict but commonly agreed upon definition of both and derive a proof from there. It's very possible.

[leshow]

> You don't have to have a vague definition of good design or a vague definition of FP. Follow a strict but commonly agreed upon definition of both and derive a proof from there

There is no such definition, just like there isn't one for OO. You could of course make one up and then test it qualitatively, but that's far & away from a proof.

I don't believe a 'proof' for something like this exists, if you disagree, I challenge you to find such a proof, or link to any resource describing one.

[crimsonalucard]

I am indeed talking about making something up. Similar to how an the signal to noise ratio for rating signals is made up. It can't be that hard.

Following the analogy for the SNR, you can indeed prove that one signal is "better" in terms of SNR to another signal, simply by calculating the number.

I get a bit more into something like this in another reply: https://news.ycombinator.com/item?id=22071522

Obviously the "ratio" I describe in my example above is something I pulled out of my ass and has serious flaws but I'm talking about traveling in a similar direction to find a rigorous "proof." You would need to define a minimal turing complete assembly language and and do the same for OOP and FP to even begin to proceed forward with such thing.

Of course what I describe can only say a given FP program is "better" then a given "OOP" program. The way to a general proof would be to find something like all the ratios of all possible foundational programs with one or two assembly primitives for OOP and FP then by induction we prove that because all programs are built from these foundational primitives the paradigm with the the foundational primitives with the "better" numbers are indeed better.

There's probably other numbers as well like the amount of references.