The Best OO Language is a Functional One • Pragmatic Dave Thomas • YOW! 2017
HTML-код
- Опубликовано: 8 апр 2023
- This presentation was recorded at YOW! 2017. #GOTOcon #YOW
yowcon.com
Dave Thomas - Author of "The Pragmatic Programmer" @pragdave
ABSTRACT
Object oriented development turns 50 this year. During that time, hundreds of OO languages have come and gone. And yet, with the exception of Smalltalk and a few research languages, none of them were actually object-oriented.
I think we might now be seeing a revival of the spirit of OO, but it is coming from the functional world. I want to show you how to write OO in Elixir, and how liberating this can be. [...]
RECOMMENDED BOOKS
Dave Thomas & Andy Hunt • The Pragmatic Programmer • bookshop.org/a/9452/978013595...
Dave Thomas & Andy Hunt • The Pragmatic Programmer • amzn.to/3N3i0GP
Dave Thomas • Programming Elixir • amzn.to/3Dl6fY7
Dave Thomas & Sam Ruby • Agile Web Development with Rails 7 • amzn.to/3TuWuxj
/ gotocon
/ goto-
/ gotoconferences
#Programming #FunctionalProgramming #OOvsFP #OOP #Transformation #TransformingProgramming #PragmaticProgramming #PragmaticProgrammer
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
ruclips.net/user/GotoConf... 
Наука
I see this as entirely applicable to Scala, which is functional, but with OOP features and a lot of other nice things. FOOP or OOPyFP or whatever, it inherits the best ideas on programming while stepping into parallelism/concurrency. I would love to hear programmers who have done this kind of work to learn their issues, both problematic and opportunities to extend and/or improve the paradigm.
This was insightful and somewhat similar to the actor model. I'll try this mental process myself.
Also, Hangperson 😂
Insightful
25:10 I largely agree but he clearly says “no if statements” not meaning “no ifs” (conditionals) in general. Elixir of course also has the if statement.
52:20 there is coupling though. The schema of the messages sent between two “servers” is coupling the two “servers” together. And I don’t quite get why we need to separate messages into { :some_state, val1, val2 } because it’s really no different from a method call like `some_state(val1, val2)`. The call stack is even somewhat analogous to the history of messages. I get there are differences… like the call stack discards frames as methods return… but this is interesting because we can start to ask question about why these differences exist, do they need to, do the difference tell us something important?
17:45 "there are no ifs" of course they are; but they are hidden by the language's syntactic sugar.
25:22 there are no ifs, only if this, then that XD
While I see the benefits of the functional approach at times, there is a reason why it is not a norm. It's harder to understand, harder to read and in many cases it's magnitudes more verbose; at least as long you keep them pure.
I can agree with some points, when you expose getters and setters, you will not reap the benefits of OOP, but then again - trying to be a purist leads down to a high cost rabbit hole.
Write objects as transaction boundaries, expose business actions, implement them functionally. This way you'll get benefits from both.
E: 38:00 this got a bit silly, touting immutability as something only present in a functional approach. The only difference lies if you persist the cloned state after transformation.
The topic of this talk bears little relation to OOP, it's just a repackage of benefits of functional programming. The problem is that there are different problem domains, some representable by OOP, others by FP; but fundamentally the question is really different: does the data belong to you, or not. If you are in control, OOP is usually best. If you get data from elsewhere to transform, FP languages fit the bill. There is nothing magical about that.
Trying to represent a banking process as a transformation brings only an impendance mismatch. Trying to do OOP with ETL is just asking for pain.
So... There is no big revelation here, no wisdom of 40 years. Just a different paradigm for a different problem, nothing else
E2: cherry on top - "design patterns are crap". 54:34 . They were a solution to the lack of syntactic sugar/first party support in certain language. Calling them 'crap' is like assuming that if you haven't done things right the first time, it's crap. No, it is not. It allowed languages to evolve.
I've struggled through this entire presentation, and frankly, I think I've lost a bit of respect for Dave
So true. When the speaker talked about what the code means, he literally kept having to repeat "IF ... then ...". It's IFs all along, just with an extra mental transformation to hide it in the code.
Does not scale