Functional Programming vs OOP

What is the benefit of adopting a functional programming paradigm rather than an object-oriented one?
My IQ is around 140 so please don't hold back on complex answers.

Attached: Intelligent Gentleman.png (666x607, 158K)

Other urls found in this thread:

interprolog.com
en.wikipedia.org/wiki/Three-valued_logic
twitter.com/SFWRedditGifs

Better encapsulation.

Pure functions are much easier to test and more modular. Having less mutable state overall makes your program more predictable.
That said, FP is good, but not always the best choice.

>140
>thinks it's any good
object = state
functional = stateless

>fp is good
-- SP.hs -- Dijkstra's Shortest Path Algorithm (c) 2000 by Martin Erwig
module SP (
spTree,spLength,sp, -- shortest paths
dijkstra
) where

import qualified Heap as H
import Graph
import RootPath
expand :: Real b => b -> LPath b -> Context a b -> [H.Heap (LPath b)]
expand d p (_,_,_,s) = map (\(l,v)->H.unit ((v,l+d):p)) s
dijkstra :: Real b => H.Heap (LPath b) -> Graph a b -> LRTree b
dijkstra h g | H.isEmpty h || isEmpty g = []
dijkstra h g =
case match v g of
(Just c,g') -> p:dijkstra (H.mergeAll (h':expand d p c)) g'
(Nothing,g') -> dijkstra h' g'
where (p@((v,d):_),h') = H.splitMin h

spTree :: Real b => Node -> Graph a b -> LRTree b
spTree v = dijkstra (H.unit [(v,0)])
spLength :: Real b => Node -> Node -> Graph a b -> b
spLength s t = getDistance t . spTree s
sp :: Real b => Node -> Node -> Graph a b -> Path
sp s t = map fst . getLPath t . spTree s

I'm definitely smarter than any frogposter.

Your point being?

it's so elegant

Easier to maintain.

FP might be the only paradigm with zero encapsulation you absolute twat.

9 out of 10 dentists agree that functional programming is ideal if you aim to enter a nonstop 3 month long dick sucking rampage.

Attached: 1534953771471.jpg (750x724, 43K)

Imperative > Functional >>>>>>>>> OOP

oop is imperative

>not writing declarative OOP

You're clueless. A lack of effects grants near-perfect encapsulation.

Not when everything works in terms of
List(T a, U b)
T List::fist()
U List::second()
with your "encapsulation" strategy being to rename things.

In theory no side effects. In practice mental masturbation and circlejerk

OOP language features are just poor man's modules. If your language does not have a decent module system, you must use OOP, period. If it does, OOP is worthless.

And OOP as a way of modelling the reality is wrong and broken. Do not ever do it.

I've always found functional programming is just a change in philosophy that forces the programmer to think through their program entirely and define all steps and edge cases. Everything needs to make sense at compile time and if it doesn't you'll be told right away. With OOP you can easily end up with an edge case you haven't thought about causing bugs that are difficult to track.

Ah yes. The prolog Java bindings
interprolog.com

there is none. Functional programmers are memelords who don't actually write software.

>My IQ is around 140
Why havent you invented facebook yet user

Functional programming is good for problems where the intermediate state doesn’t matter like compilers. OOP is good for guis. Imperative is good for fine tuned high performance programs like games. And web developers are faggots and should be lynched.

It's to flex on others that you program as merely an exercise in pure math rather than anything practical

OOP is imperative for fucks sake

Functional programming has nothing to do with side effects, Haskell is the only notable one which enforces purity at all.

if FP isn't about functional purity then what is it about?

Functional style is about creating a pipeline of pure functions via composition, basically the unix model. You can do this in most languages, but the syntax and features of a functional language are designed to make this elegant. Other common features are pattern matching, streams, and tail-call-recursion optimization.
Some would bundle immutability as a functional feature, but this isn't strictly the case in practice.

Kind of. I’m thinking more of imperative in essence. OOP is spahgetti code in nature lots of callbacks, virtual funcs, etc. Imperative I mean here in like a step by step order where everything is neat and tidy and you sacrifice some flexibility.

It's about using function composition and recursion over stateful objects and loops.

>pattern matching
there's nothing about this that makes it particular to functional languages. It's just a more useful switch, it should be in every language

Having no state is the same thing as functional purity

It's not, because purity requires no side effects at all. That includes stuff like doing any IO or reading/writing from volatile memory.

>That includes stuff like doing any IO or reading/writing from volatile memory.
ie. state
without state there are no side effects, and without side effects no state is being changed

Does a function which only waits on user input have a state? I'd say it has no state, because it discards the result, but is still impure because it's operation is dependent on IO.

>Does a function which only waits on user input have a state?
Yes. Waiting for input, not waiting for input.

I'm not sure what pure language would even look like by this definition.
I'd think any program would be stateful by simply saying:
>It's either computing or it's not
Which I guess is true on a deeper implementation level, but even Haskell isn't pure at that point.

a pure functional program just takes an input and returns an output instantaneously
no functional programming languages are entirely pure because it'd just be fucking useless

A pure/stateless functional program doesn't exist because it's a paradox. Haskell isn't 100% statless, it just tries it's best to limit how much of a state programs can have

You have it backwards. Functional programming is all about purity, ie referential transparency. Function composition and recursion is merely the tools used to write programs in such a manner.

>It's not, because purity requires no side effects at all.
A function that internally uses impure code can still be pure as long as the side effects doesn't escape the outer function. From the callers perspective, it's still a pure function then, because the side effects that happened during the computation are encapsulated within the function.

>What is the State Monad.

something that either emulates the functionality of state while not being state or an impurity

>My IQ is around 140 so please don't hold back on complex answers.
Nice way to slip your IQ into your post.

Attached: punch_gif.gif (835x805, 499K)

Congratulations user. You are a retard.

what language is this? looks somewhat like erlang but not quite

it's basically a whole bunch of syntactic sugar
you could do the same thing by having f (x, state) return (result, newstate) and just pass it around as an argument normally. it would just be a pain in the ass to do function composition and shit

you're a retard if you think something can either be another other than 'state' or 'not state'

Haskell

> My IQ is around 140
Ok then, I will try to speak your language

Since your IQ is highly intellectual like mine, when Rick turned into a pickle in an oop paradigm the original Rick does not exist anymore, while in a functional world the pickle would be a modified copy of the old, smart original Rick

oh right, should have known, g is infested with haskellets

They are not mutually exclusive. Anything who thinks so is a brainlet. Most of this board thinks you have to be one paradigm only.

en.wikipedia.org/wiki/Three-valued_logic
checkmate cunt

what does that have to do with anything?

Frogposters are objectively high IQ, and as decided by me-- this cannot be disputed.

i guess something could be "maybe state"
like a function that either puts its return value in some pointer or returns it by value depending on an argument
but that would be real bad code

>like a function that either puts its return value in some pointer or returns it by value depending on an argument
both are state
there's really no question here

The State Monad describes statefulness, just like global variables do or any other model to describe statefulness pragmatically. Its doesn't "emulate" anything.

global variables exist indepedently of any function being run
passing things in and getting results out isn't state, even though you can emulate state by doing so

That's true, but you shouldn't say that.

Monads are also an abstract data type so you can use them to define abstractions over the abstract monad structure.

For instance you have languages that implement some monads as syntactic sugar. Like javascript async/awaits that is just sugar for .then() calls, but it doesn't have a way to access or work with a generic monad structure. Which kinda misses the whole point of monads.

Not him but, when you say "emulate", what do you mean?

A compiler can grab the description of a stateful computation denoted via the State Monad and produce the same binary that a description via global variables and whatnot.

Note that in FP you don't write down a program like a set of instructions to be executed by the computer, but you merely provide a description of what the program does. As the State Monad denotes statefulness behavior can denote a program that does so (again, it is not sound to call this "emulation").

It's expressive, easy to write, easy to maintain. All the benefits are high level. Generally speaking, it's harder for a compiler to optimize. Compiler level optimizations for FP are relatively new. Performance takes a hit. But it's definitely a step towards the future of programming for better or worse.

emulate as in it provides the same utility as X without actually being X, at least in the context of the programming language, the compiled binary is obviously all stateful machine code

Neither actually IS, they are both mere descriptions of behaviors (be it imperatively given or declarative). In that sense, don't you think, both are in that case "emulation"?

It took me a while to get used to this idea, specially when you get into really wacky monads and monads transformers that describe pointer algebras and more low level shit.

>Neither actually IS, they are both mere descriptions of behaviors
one is the description of state, another is a description of another pattern that can be used to emulate the behaviour of state
not sure what you're trying to say here

OOP has the habit of tempting programmers to micro-encapsulate their code and it fucking sucks. You wind up having to refactor constantly because your initial design didn't account for everything. On top of that you feel like you're trying to solve the problems of philosophy with stupid questions like "what is a chair?". Functional or procedural programming is the default way to program and you wind up getting a lot more work done because you don't have to deal with an overengineered mess or worry about how the giant tower of encapsulated objects is supposed to talk to one another without breaking encapsulation or having god objects. Just stick with FP man.

>On top of that you feel like you're trying to solve the problems of philosophy with stupid questions like "what is a chair?"
it's like you're implying OOP is the only time you run into architectural concerns

It really fists you up the ass with OOP.

maybe if you're making the newbie mistake of trying to make your objects analagous to real-world concepts, but choosing how to divide up your classes is no different than choosing how to divide up your data or modules or functions in a procedural program

Yes, it was an example. The micro-encapsulation of state in objects is what the real pain is.

that's not any different a struct

If you make all the data members of the class public, sure. Most OOP programs don't do that, however.

You have no idea what you're talking about. The state monad is exactly equivalent to global state. Please read about CAFs in GHC.

>The state monad is exactly equivalent to global state
unless its existence supercedes the the functions its being passed between, no it isn't
>Please read about CAFs in GHC
Do you brainwashed Haskell drones expect everyone to speak your language?

I do, encapsulation is retarded

Not quite. I can speak about the implementation of any of the major programming languages because I'm a good software engineer.

Unless you actually work with Haskell knowing its acronyms or its compiler doesn't make you a good software engineer, it's basically programming trivia

This.

I know how all of the major languages work so I can choose the right tool. I'm not content basing my decisions on trends like most engineers (and I use that term incredibly liberally).

If you have 2digit IQ use OOP
Otherwise you can use FP

Haskell is a trend though and not a major language
stop pretending to be unbiased

Just combine the two:

Functional for all computations and program flow.
OOP for any element that gets reproduced.

No point making an OOP sorting algorithm or a functional UI button.

learning scala

Attached: fp.jpg (1419x674, 124K)

Any examples.of languages with good module systems?

That's pretty much exactly the way the algorithm is defined intextbooks. Is this supposed to show Haskell is bad or are you just false-flagging?

SML, Haskell

This is only true of statically typed languages. There are plenty of FP languages which let you shout yourself, like Lisp.

>thinking IQ means anything
Anyway there's no solid answer, and one isn't really better than the other. It depends on what makes sense to you as an engineer.
I prefer functional because it's easier for me to think that way, and it just feels a lot cleaner. To me it makes sense to have a verb, that takes a noun, and does something with it.
Lots of people like OO because it makes more sense to them. They like the idea of having Nouns, that are descended from similar nouns, and have siblings that share a common ancestor.

Just do what works for you, don't go looking for a high horse to get on.

Both. Scala. Common Lisp.