Functional Programming IS NO BETTER than Object Oriented Programming | Prime Reacts

my code was written using OOP and was inherently trash, then i rewrote everything using FP and now it's functionally garbage

I always follow money oriented programming. whatever the fuck my boss tells me to do.

After a decade of programming, I've realized that no paradigm will cure my stupidity.

This is from an article written in the 80s. It was pretty on point. "What is object oriented programming? My guess is that object oriented programming will be in the 1980's what structured programming was in the 1970's. Everyone will be in favor of it. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is" - Tim Rentsch

"anything you can do in OOP you can do in FP and vice-versa" is just a fancy way of saying: 'You can do everything in assembly, therefore paradigms don't matter'

This guy doesn't understand what he's talking about, when he mentions side effects in haskell or closure. Side effects aren't the point. Of course there is io in haskell and closure, the point about side effects is that your functions will always return the same out put given the same input, and that always happens (at least in haskell) unless there is some sort of bug in the compiler. Of course you can get side effects if you start doing shit like calling unsafeio, but that's missing the point. Of course you can get the job done however you want using oop or fp, but again that is missing the point. Its also missing the point to say which is better oop or fp. This is an argument purely about style. Honestly, however, I wouldn't even make the comparison between oop and fp. OOP is an amorphous concept, where fp has a clear definition--you're attempting to get as close as you can to lamba calculus in a programming language. OOP is way more amorphous, vague, and too many people disagree about what it means. The real distinction here, in my opinion is an imperative programming versus declarative programming. That's a much more sensible topic talk about.

"Academic masturbation" is such a great term for this unquestioning acceptance of a few research papers on hard to measure topics. I was especially peeved when he kept using some research papers to conclude that pair programming is objectively the best way to code.

It's funny to watch you interpret everything Dave says completely differently than me. Like, when he said 'model your problem', I didn't even for a moment think he meant 'ahead of time' or 'at a white board', but rather just that object models align to real world models very nicely in some domains (e.g., user interfaces). Similarly when he said that mapping is almost always slower -- I agree. You have to measure. If you map everything by default and try to parallelize it all, you are likely spending more time in joins. The exceptions are important performance cases but you have to measure. Always measure.

18:00 "Proof of concept, learning from it, and building the final product". Open a 50 year old book (Mythical Man Month) and you have a full chapter about it called "Plan to Throw One Away". It is always crazy to read old things like that and see how most of software managers have not learnt anything.

I agree with the overall take, FP is no better than OOP. However, a language which does not support functions as first class citizens is a bad language.

Procedural is the only paradigm which matches what the machine actually executes. OOP and Functional are just abstractions above procedural and are up to the compiler in how they're implemented and their expected performance

MBOP (Mudball Oriented Programming) is the best. Because in your heart of hearts you all know that is what you have to maintain... so may as well love it ♥

When I did parallel computing for uni, I was taught that parallelising is almost always faster given a large enough dataset. An array with 1k elements, it would be faster on a single core utilising the L caches. 1bil elements, it would likely be faster if it was split to the number of cores. And if you have to search, you might as well search in the parallelised code as well, why wait until it's joined up again.

Stateless functions are good because it's easy to check for errors, find bugs and overall understand what a function is doing. Function that accesses global or even instance variables can be much more difficult to understand.

I kinda feel as if the line where you're veering into OO territory is usually when you start associating functions with objects exclusively, as in "this function is specifically just a thing this one object does". At that point, you have essentially "oriented" the logical module around the object rather than the function existing purely as its own machine with specified inputs and outputs.

Rust's traits are very similar to Haskell's type classes, which is considered a functional programming language. Rust's algebraic data types are very similar to those found in the ML family of languages, which are considered functional programming languages. With these features Rust leans towards the functional programming languages. However, the idiomatic style of programming in Rust is mostly procedural. It is common in Rust to express how a certain algorithm should be executed, while the ideal for functional programming languages like Haskell is to express what the algorithm should accomplish. The emphasis in Rust is also to safely mutate state, while in functional programming the emphasis is on immutable state.

Prime: "You need to be careful with those bold statements" Also Prime: "Whiteboarding is bull SHIT, bull SH**!!"

I just wanted to add that UML diagrams aren't great for building code, but can be good at summarizing code. I wouldn't want to plan out my code with UML, but if I'm asked to create a visual representation of my project, UML isn't a bad way to do it.

Just wanna put it out there, my company spends about 6 months in writing UML with plantUML and when we finish designing the UML, the requirements usually change and we throw everything we did in UML and start writing code.

Rust is multiparadigm. You can do OO for the most part, but it doesn't have inheritance (which to me is a blessing). Structs + impl can somewhat act like a class, and traits are somewhat equivalent to interfaces. Of course they're not exactly the same, but I would still consider Rust to be mostly capable of OO.