Is Functional Programming superior to OOP? Why or why not?

Is Functional Programming superior to OOP? Why or why not?

Attached: functional.png (549x413, 16K)

Other urls found in this thread:

youtube.com/watch?v=4jh94gowim0
play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5d15ac08568da307464a2759e5a542cb
play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=fc10cc3e3b1855768767d5f899c75ed5
myredditnudes.com/
twitter.com/SFWRedditImages

why not both at the same time?

For example?

lambda expressions in java?

Not necessarily. It's a lot more abstract which mades it harder for the uninitiated to understand.

Any attempt to use both at the same time results in a massive clusterfuck that is much worse than using either in isolation.
See Scala.

Then you get abominations like Scala. Nobody uses the OO features in OCaml, either.

B-but Uriel told me thinking abstractly is for pajeets and real programmers™ just worry about fiddling with bits.

Abstraction is critical to programming, but choosing the right abstractions is what makes it so difficult.

>falling for the x > y Jow Forums meme
Both have a use case. Yes, there are some things that functional programming is just better at, but you could say the exact same thing about OOP regarding different problems.
That being said, I do find that OOP seems to be more of a shitstorm when newtards write it
>"Hey why is this in this class"
>"idk, it just is"
>REEEEEEEEEEEEEEEEEEEEEEEEEE

Both have their areas where they shine (I prefer non-retarded OO tho, Java did horrible things to it). I prefer FP because (after some initial learning) I find it easier to reason about my code (because the stronger typing helps me and working in a pure language is a joy once you are bitten enough times by mutable global state) and I like to think about programs as a huge chain of functions that do one thing well. Also design patterns in FP tend to be more general and trustworthy than in OO. It is seems to be easier to fuck up the implementation of a visitor pattern in OO that to fuck up the implementation of a monad in FP.

So scala?

Scala is a terrible language that illustrates the problems with merging OO and FP.

Explain how Scala is an abomination/cluster fuck? The amount of lines in the grammar is comparable to Haskell.

Like literally all modern programming languages that draw from multiple paradigms.

Scala is literally the best designed language out there.

I can't wait until dotty is released, all the haters will get BTFO.

It was never designed, it simply accreted poorly interacting features over time. Like sepples.

positives:
>testing
>easy to reason about
>easy to write
>easy concurrency (not parallel)
>easy to use all cores properly and write synchronous looking code

negatives:
>not as fast performance wise, usually
>can be heavily autistic and overwhelming depending on who you ask about it


"functional style" is better than "functional programming" though IMO, you can just enforce the rules when and where they are needed (99.9% of the time) but then just use OOP libraries or whatever language you want. Especially when it comes to job openings and actually getting shit done.

Rust.
It has both without the bullshit from both camps.

C# while a bit bloated does draw a bit from functional programming.

Nearly every modern language does.

FP makes it easier to reason about problems, data manipulation, and concurrency.
90% of all code is map, filter and reduce. Classic for FP

I played around with it for a bit and found it very unpleasant

>rust

Attached: rust.png (793x2011, 256K)

youtube.com/watch?v=4jh94gowim0

The core idea of functional programming of keeping functions as pure as possible is great and I apply it as much as I can when programming otherwise OOP programs.
But pure functional is a bitch because computers are inherently stateful and it's pretty hard to use state elegantly in a purely functional language (such as Haskell).
Still like Haskell though.

>computers are inherently stateful
They are not, though.
"State" itself is an abstraction built on top of stateless logic gates.

OOP and FP (at least pure functions) are unrelated thing and not mutually exclusive.

fundamentally any function that doesnt have IO (veriable input to the program) can be pure.

member variable can be seen as implicit input to member functions.

Gates are used to build non-abstract stateful components.

Kek, sounds like he has no idea what he is doing.
Actually ECS with Rust and Lua souds fun. I might try it someday.

He has a very good idea. I was there in that thread and talked to him. Rust's borrow checker effectively means that you can't use closures in your code to handle interaction logic between objects. The best thing rust apologists could come up with in that thread was that this was not the intended use case of rust. Look it up in the archives.

Yes. OOP is the worst thing that's happened to computers.

what the fuck is with that retard?

Literally the person who contributed the most to your wonderful language.

Alright, it seems like it's me who has no idea what he is doing.
I assumed ECS is just what Unity does, since it utilizes entities and components. But actually this approach is much more interesting. It might be fundamentally incompatible with Rust, I don't know. But it's definitely something I'd like to try out.
Also it appears there are some other libraries that already implement it in Rust.

Attached: Fuck!.png (237x246, 53K)

Ok, I don't get the System-Any part. Why not just do:
play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5d15ac08568da307464a2759e5a542cb
as_any can be removed when they add supertrait coercion. Also no need for HashMap since you can just as_any() and is().

Also you can make world pass self reference into the lambda, to use it even if it's locked outside. I'm pretty sure I've seen it already before.

I don't know about the former because I don't use Rust but for latter even if you pass reference, when you call a function for that reference, it's still called from outside of object, and it would still be locked, or at least that's what I got from my discussion with him. It's an actual issue that he had and if you find it in archives there's some code for you to look at.

elaborate. what exactly did you find unpleasant?

The issue is that when you create a lambda that uses world, it borrows it. So you can't borrow it for the lambda and for wordl::update method as well(assuming one of them requires mutable reference).

The solution would be to do:
world.update(|world_ref, e| {
update_pos(world_ref.get().x, world_ref.get

world_ref.get() will still lock because it's not called from inside an object, it's called from a lambda created in some different object.

>No need to store
No need to store/clone data before calling update. That's just stupid.

It doesn't lock anything, because world_ref is an argument. It exists only inside lambda and it's locked only inside it.
play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=fc10cc3e3b1855768767d5f899c75ed5
This works without any problems.

Rust has no TCO

Yes, you're right about that, this one works. But what if there are multiple systems in the chain of calls, and the reference to world wouldn't actually be useful, since you need to use a system which is already locked between call to update() and your closure?

Dunno, I would have to see live example. It's my first experience with ECS too.
99% of problems like that came from bad architecture/approach. But it might be different in this case, I don't know.

It has no need for TCO.

I used it for spark streaming and just felt like I was writing an elaborate typed sql query

I like SQL.

I don't like that it hobbles algebraic operations. I wish it was more formal

I don't know what that is.

It's operations between sets of elements.

Oh wait, I read your post wrong. Hobbles algebraic operations. Any code examples? From my C++ background I ever had any issues with how postgres treats algebraic operations.

Idiots, idiots everywhere

That shit is called Scala, son.

Newfags dont know, but this has been said by guys like C.A.R. Hoare in late 60s.

Actually, everything has been solved by late 80s (ML, Miranda, Haskell) the only innovations are in an implementation side.

Fuck zoomers.

This nigga done his homework.

Fucking zoomers have no idea what kind of guys did the design.

Fucking JS is what you deserve.

youtube.com/watch?v=4jh94gowim0

>Is saw superior to hammer? Why or why not?

>I have spent an enormous amount of time with a spec and it's garbage. It is imposs- it is so out of date with implementation that it's actively harmful.
By lead Scala developer.

I've done my fair share of both kinds, and I can't call either one superior to the other per se.

If you know what you're supposed to do and there is little need of abstraction, an imperative language will get you there.

If you have a partial knowledge of what's going on and you want to see how far it gets you, do some partial evaluating, then functional programming is your friend.

exactly this, the opposite of FP is Imerative and the opposite of OOP is Monolithic, but tards gonna tard. tons of languages currently combine FP and imp paradigms (C#, Scala, Python, etc) and tons before them probably have as well

not about to listen to some smooth brained individual complain about not understanding basic concepts for 2 hours. I just picked up scala yesterday and i'm already enjoying it quite a bit. will have to see if i like it once i build something halfway large in it but i'm not about to form an opinion about a topic from someone who's screaming about how he can't understand it.

>We choose to go to the brothel! not because it is easy, but because I am hard!
- 12th president of the USA, Alberto Einsterino

both are shit compared to procedural

/thread

map and reduce are noice

>logic gates
>stateless

It makes sense to try and use the best of both worlds if possible.

Applicative programming a best.

Attached: 1545875175568.jpg (560x560, 233K)

you ever taken a college course where you had to program in functional? seeing %90 people think imperatively then fail was fucking depressing and pretty funny

RAM is state
Do you know what CPU reads?
Dumbfuck

Not him but I had a course where we learn 5 PLs in one semester.
That was so fun, but I doubt they had that much trouble with it. You could pass it by just doing really simple task in each language.

Yes, logic gates are pure functions.

But that's not Scala. Spark is just a library.

This user gets it
Logic gates are just transfer functions. Yes, you can connect them in a positive feedback loop to create memory, but they can still be described functionally.
Look at all the HDLs, they're basically stateless, pure functions.

>Yes, you can connect them in a positive feedback loop to create memory
protip: this is just a monad

I studied EE, not mathematics, be patient with the crayon eaters, yes?

I just want to illustrate that electrical engineers and functional programmers arrived at the same idea for implementing statefulness.
Implicitly feeding the state of combinatorial circuits back into themselves to construct sequential circuits is the same way functional programming languages add side effects to pure functions.

how do functional languages handle failover?

I'll have to look into Haskell one day.
In the meanwhile I'm thinking about an elegant representation of stateful systems in Clojure, based on the very principle you describe. If you learned discrete-time systems control, I want to reach a model of:
next-state = F(input, current-state).
Perfectly recursive, no "state" required.

>no "state" required
what do you think the stack is?

Refer to the state monad. Cont is another interesting monad if you're familiar with Scheme.

The language specification has no guaranteed TCO, but the only available compiler backend is LLVM, which will do TCO.

>member variable can be seen as implicit input to member functions.
By that retarded definition basically everything is a pure function including IO.
The only logical definition is that the output has to only depend on the explicit arguments of the function.
Could you be more specific?
Confusingly, Unity has both an "entity-component" architecture as well as a newer "entity-component-system" architecture.

>Could you be more specific?
what happens when the machine(s) running your app crashes?

You'd handle it in the same way as in any imperative language. IO is normally done in a pseudoimperative style using state monads or just straight up imperatively in a multiparadigm language.
Or are you getting at something else?

OOP has limited use cases where it excels.
FP has nothing but masturbatory gimmicks.

so what fills the gap where OOP doesnt excel?

Regular old procedural programming.

all paradigms are shit except for structured

OOP scales better for large code bases, FP is cleaner and faster to execute in general.
They have the same decision power.

Why would OOP scale better for large code bases? You can have modularization and hiding of implementation detail in FP aswell - if anything, I would argue that FP scales better, since there is no global state that starts fucking things up over time.

>FP is cleaner and faster to execute in general.
i wish. i love languages like scheme but they just don't perform like c. i do mostly embedded work. the new guile is fast as hell but too large to cram.

Attached: curse.jpg (1156x824, 99K)

In general, large code bases are worked on by developers of various skill levels. Safely putting Rajesh in his own sandbox where he can shit to his heart's content is preferable to letting him wreck the entire software with scope errors.

all paradigms are shit

Doesn't matter who did the design. The result is shit.
I know it's hard to believe in today's society, where academics and "scientists!!1" are worshiped like literal gods, but that's how it is.

>i love languages like scheme but they just don't perform like c. i do mostly embedded work. the new guile is fast as hell but too large to cram.
Ever looked up Chicken Scheme? It may be what you're looking for.

i've used it a little as well as tinyscheme. the main problem is getting it to run on a lot of embedded systems. with chicken i ended up writing more c glue code than scheme just to get the hardware talking. embedded systems are getting more beefy every year though, so it probably won't be long before we can have some real language choice without hacking half the language apart to get it running.

Structures are bloat. So are functions.

All you need is some directives to define variables, ifs and whiles.

Attached: maxresdefault.jpg (1280x720, 51K)

Since there seems to be a lot of confusion around this topic: In basically any non-trivial program you will have state which needs to be managed somehow. For this, an imperative (and sometimes OO) approach is very useful.

The code managing said state should be cleanly separated from the rest of the code base. And, you probably guessed it: For the stateless part of the program, functional style is usually a good approach (yes, there are rare exceptions).

IO, State and ST Monads are far superior (if sometimes more verbose) to plain imperative programming since the state can even be analyzed by the type checker and threaded properly.

A lot of his complaints have either been fixed or will get fixed in dotty.