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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I will not consider functional programming is about pure function. It's much more broad than that. I consider functional programming is about features like: - pure functions, total functions - currying, partial application - lambda - algebraic data types - pattern matching - higher order functions - parametric polymorphism - ad hoc polymorphism / type classes ...
Development of Theory of Computation leads to development of computer. Development in Language Theory lead to Development of High level programming languages. Relational Database Theory lead to Popularity of RDMS. Development of Concurrency Control Theory lead to Development of Transaction Based Systems. As you can see. Most of powerful technologies in computer science have mathematical theory behind it. It help build higher abstraction without breaking things. Functional Programming based from very good theory too: Lambda calculus and Type Theory. But OOP have none.
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.
You should try programming something efficient and really fast in functional style ;) The bug which you just described can be solved by placing two breakpoints
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.
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
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.
Which university teaches haskell as their first programming course?
@@joshhoover1202 sounds like a cool one
@@joshhoover1202 good question
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!
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.
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.
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.
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.
Also Rust
Use object oriented on boundaries use functional programming with in boundries saved your time 30 mins
caesar bala that’s EXACTLY what I was thinking and I am so glad to hear it from such distinguished expert
whats "boundaries"
@@dudespoon4852 I think he is saying un-boundaries
procedural -> fp -> oop
Do the boundaries mean i/o control or else?
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.
You are saying the actual truth here 👍👍
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.
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.
21:04 : this quote, I will never forget
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.
can someone please help me with the link to talk he recommends at 26:40.
I could not find that that with name 'Boundaries'
Dont be a FP or an OOP programmer, be a better programmer.
So... git gud?
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.
Still need control
Of low level stuff
Microservices feels a lot like OO.
I wrote this before I got to 29:00 :)
please show some code in the presentation. sigh!!
He could have created slides to show the highlights of his talk.
Big parts of the presentation have blank slides.
love this talk
procedural -> fp -> oop
What an obnoxious intro sting!
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.
I will not consider functional programming is about pure function. It's much more broad than that. I consider functional programming is about features like:
- pure functions, total functions
- currying, partial application
- lambda
- algebraic data types
- pattern matching
- higher order functions
- parametric polymorphism
- ad hoc polymorphism / type classes
...
Development of Theory of Computation leads to development of computer.
Development in Language Theory lead to Development of High level programming languages.
Relational Database Theory lead to Popularity of RDMS.
Development of Concurrency Control Theory lead to Development of Transaction Based Systems.
As you can see. Most of powerful technologies in computer science have mathematical theory behind it. It help build higher abstraction without breaking things. Functional Programming based from very good theory too: Lambda calculus and Type Theory. But OOP have none.
Also you should search "type class" in Haskell vs "class" in OOP on Quora.
@MrManiak I dont know why you think like that
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.
You should try programming something efficient and really fast in functional style ;)
The bug which you just described can be solved by placing two breakpoints
sounds like somebody didn't understand the principle of encapsulation. Ouch.
In theory, it shouldn't be. But in practice, it usually is.
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.
You obviously haven't coded Java using lambdas and streams (especially reactive stream). ....pfft.
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