[leshow]

> However, ADT's can be used in procedural programs or OOP programs as well. See Rust.

Rust isn't OOP. Funnily, it's type system is pretty much the same as Haskell's but stops just before higher kinded types.

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.

[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.