Very enlightening, as a CS student whose first course was in Haskell, and now doing OOP in Java, this really broadened my understanding of the problem domains to apply FP to, and where to Apply OOP.

Use object oriented on boundaries use functional programming with in boundries saved your time 30 mins

Encapsulation is definitely misunderstood and misapplied, but it's definitely not that it's used in all sorts of inappropriate places. It's that people somehow conflated encapsulation with getters and setters which were a peculiar feature of Java Beans. Proper encapsulation is essentially the black box principle. The users of objects should not care about the implementation details of the objects in question. FYI, getters and setters actually break encapsulation by allowing the users of objects to monkey around with internal state and are pretty much always bad practice, especially when compared to proper block box encapsulation.

Very nicely said. I use both and feel it is not about one over the other but it is about where & when to use what.

Thank you, Mr Goetz, for this talk that tries to tear down borders. I am a guy that grew up on the imperative side of things, and remember having big aversion (what the F should I use this for) to the functional side when it was introduced with Java 8. In the time since then, I really embraced it, and I have to say, it's very powerful. But still, mutable state is something you cannot just declare away (as in pretend to be evil and not be useful), so I agree with the talk: Just leverage both!

Isn't the whole idea behind languages like Scala and OCaml to combine the power of functional and object oriented programming? Clojure, too has some neat ideas how to at least use the good parts of object oriented programming in a functional language. Not to mention that a lot of object oriented languages have adopted some functional programming stuff by now.

Just use what works best for the given task. Some problems have very beautiful functional solutions. In the real world, problems often are more complex. If the actual problem is best represented as a system of communicating objects, OO doesn't seem like such a bad idea.

IO monad is that separation between your pure, functional core and side-effectful / imperative code that is being proposed, except it's also enforced via the type system. If you don't like the enforced separation then something like F# (or OCaml) take a more "ideal" approach with functional first, OO when necessary (if at all), and no enforced separation between pure/impure code.

In my opinion we should always think how easy to read the code in fp, if the readability is bad i dont care if it fp or oop , its would be bad and painfull to refactor.

OOP or FP both are ways to look at the problem & solve, so both are good/bad in their own ways. But people take their differences to make their own money, rather concentrating to understand the issues properly as none is a silver bullet like people try to advertise their favorite language. So such people are like who pull the others down to rise.

can someone please help me with the link to talk he recommends at 26:40. I could not find that that with name 'Boundaries'

Wisdom is knowing there's no one size fits all solution to everything. The real world is complicated. Even first principles of physics don't have a unified theory. Wave or particle, it could be both.

Brian keeps repeating the there is no encapsulation with procedural C programs, but aren't symbols with internal linkage exactly that? C programs are composed of many individual translation units and each one can be mostly sealed with well-defined interfaces that have external linkage.

21:04 : this quote, I will never forget

What about Logic and constraint programming, where one writes Relations instead of Functions ... your program can run forward and backwards ... reuse is exponentially better than in OOP or FP ... people should learn more about Logic programming too.

Dont be a FP or an OOP programmer, be a better programmer.

please show some code in the presentation. sigh!!

love this talk

He could have created slides to show the highlights of his talk.

Microservices feels a lot like OO.

Big parts of the presentation have blank slides.

Object oriented programming is about encapsulated data surrounded by functions that work on that data called methods. Functional programming wants to ignore or play hot potato with data as data is considered a smell. Programming is obviously about code and data so useful functional code has to use a totally not functional database to hold all it’s smelly parts. These approaches are not equivalent. If there really is a good idea that is objectively better than existing techniques then let’s use that technique in the situations where it is useful. To this I totally agree. Functional programming, at it’s core, is about pure functions that according to the functional religion, can’t include random numbers, today’s date, input/output or files. What kind of language would be useful without data we can change, files or IO? I can’t predict the future but such a flawed concept isn’t it. It might be PC to give everything respect and the same level on the platform to all programming approaches but that is obviously not helpful or correct. Software development is not Math. Logic is not just the province of Math. Many great ideas and useful techniques have been made and used in CS that is not Math. A function in Math is a statement of fact not a machine for changing one kind of data into another. That is what happens in computers. Math is about infinity and rules that are true all the time but programming is mostly about the exceptions rather than the rule. I love Math and have used it in all my 40 plus year career but I am not a Mathematician any more than a Chemist or Economist who uses Math all the time. Let’s actually talk about the distraction called Functional programming and take what ideas have merit and discard the rest without feeling we need to apologize for pointing out the obvious flaws in FP.

procedural -> fp -> oop

What an obnoxious intro sting!

So, the conclusion of this talk is... to use Scala ! Because Java is not the middle language described in this talk. It's almost impossible to do FP with Java. Java is exclusively an OO PL. Java 8 streams are not FP.

Not really to the point. This 45 min video can be cut down to 15 min to the point video

The argument between OO and FP is NOT like the argument between tabs or editors. I've just worked for over a day on a damn subtle bug where a field was read before it was set. OO is like playing with fire which is useful in extremely rare cases but you shouldn't give your junior developers and 99.999999% of "senior" developers access to it.

The talk is complete bullshit with no real examples only full of his own opinion, although I agree with his point that there is no single complete programming model that solves all. Just scroll to 42:18 and you get what he is trying to say

didn't get it. fp rulz! lol