The Best OO Language is a Functional One • Pragmatic Dave Thomas • YOW! 2017

[@GOTO-]

We are currently releasing older YOW! videos to serve as a valuable archive, preserving historical content. It is possible that a video is perceived as outdated. We believe it offers insightful glimpses into the past, enriching our understanding of history and development.

[@markhathaway9456]

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.

[@humanlytyped]

This was insightful and somewhat similar to the actor model. I'll try this mental process myself. Also, Hangperson 😂

[@numericalcode]

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.

[@Venthe]

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

[@ntitcoder]

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.

[@br3nto]

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?

[@ismaelgrahms]

Insightful

[@djgreyjoy1495]

Does not scale