Functional Programming Is No Better than Object Oriented Programming • Dave Farley • GOTO 2024
HTML-код
- Опубликовано: 4 июл 2024
- We’re so pleased to having teamed up with Dave Farley, author of “Continuous Delivery” and frequent GOTO Conferences speaker, for a monthly video series featuring ideas about continuous delivery, DevOps, test-driven development, BDD, software engineering and software development in general.
Find plenty more from Dave on his @ContinuousDelivery channel.
Dave Farley - Continuous Delivery & DevOps Pioneer, Award-winning Author, Founder & Director of Continuous Delivery Ltd.
RESOURCES
Dave
www.continuous-delivery.co.uk
/ davefarley77
www.davefarley.net
Links
• Object Oriented Progra...
ABSTRACT
In this follow-up to the hugely popular video 'Object Oriented Programming vs Functional Programming' ( • Object Oriented Progra... ), Dave Farley again expresses his thoughts on the argument. Including looking into the question, "ARE THEY ACTUALLY THE SAME THING?".
Which of these software paradigms will offer you the best chance of success in which instances?
CD TRAINING COURSES
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses
bit.ly/DFTraining
RECOMMENDED BOOKS & LINKS
You can grab Dave Farley's new book 'Continuous Delivery Pipelines' here:
leanpub.com/cd-pipelines
David Farley • Modern Software Engineering • amzn.to/3GI468M
Dave Farley & Jez Humble • Continuous Delivery • amzn.to/3ocIHwd
Forsgren, Humble & Kim • Accelerate • amzn.to/367RI5o
/ gotocon
/ goto-
/ gotoconferences
#GOTOxDaveFarley #FunctionalProgramming #ObjectOrientedProgramming #Programming #FPvsOOP #OOPvsFP #DaveFarley #GOTO #GOTOcon #Complexity #ProgrammingTutorial #SoftwareEngineering
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
ruclips.net/user/GotoConf... 
Наука
6:40 You absolutely can call `print` from a lambda in Python, unless you're using (by now long deprecated) Python2. If you meant that you tried to do `map(lambda x: print(x + ":
"), words)` and it did nothing, that is because `map` produces a lazy generator that only applies the function once it is iterating over the particular element. The simplest way to force `map` to apply to all elements is to wrap it in a `list(...)` call
Functional programming is not function pointers and an immutable data structure.
Function pointers let you pass a function as an argument, but don't let you construct a function at runtime, or let you pass a function expression as an argument to a function.
Immutable data structures are nice, but ultimately they're a means to the end of having referential transparency and enabling equational reasoning.
If you want to compare functional programming to object oriented programming, it's expression oriented programming. Everything is an expression.
Structured procedural immutable programming is the best
14:58 I guess we forget that entire programs/systems can be thought of as functions too. E.g. any program that persists data somewhere is a closure of that data, whether the program is running or not. The data is accessed and manipulated through the program when the program executes, just like how a closure function accesses and manipulates data when it is executed.
I think it is equally possible to write bad code in functional and in object oriented style.
But if for example your main problem is shared state, you can solve it with OO languages as well as FP languages. And adage is FP regarding shared state is - avoid shared state.
So if the architecture is bad no programming style or any (sic!) programming style will save it. Its like thinking that painting with oil instead of watercolor will make your results better because you have much better control of the brushstroke.
9:50 I guess Dave meant Stack instead of Set (which is actually an interface) when discussing bad design of Java libs
I find the argument itself is superfluous. I often miss criteria to decide which tool/ algorithm to use in a given situation. We have lots of "tools" in our toolbox. Sticking to what you're familiar with can be a problem.
You forgot about functional composition and recomposition. It's much easier to reason about (another thing you didn't cover, comprehensibility), much easier to change and less coupled as everything is a function calling another function. Overall I think functional patterns (not functional programming) leads to more cohesive, more decoupled code.
I think it's not OO that's the problem, rather the issue is mostly with inheritance and subsequent inheritance hell, I agree. Also FP kinda doesn't need dependency injection because of function composition. I don't think at the current level of software complexity one might get away with a purely OO or purely FP language to do anything meaningful.
I much prefer to work with FP languages like Elixir and OCaml, but I do respect things coming from the Java folks like DDD, TDD and BDD.
I think that even for those approaches, FP languages are much better tools! But in the end it is much more important to work with good colleagues, making the tools secondary
Also, Haskell folks have done so much damage to FP in the last decades by screaming the M word. The good FP people are the ones building business software! Look at folks like Dr. Michael Sperber and Scott Wlaschin as a good reference (and none of them are using Haskell)
TDD pushes us toward functional programming because pure functions are easier to test and reason about.
Space invaders in SQL? Challenge accepted.
@black-show database query will be next level😂. No need for loading screen😂. Data will already be there
It's a lot easier though
8:50 "If you create a window or a button on your display it's through inheritance you can resize or click it" - WHAT? Why do you need inheritance for that? How does it even look like? Is it like PressedButton extends UnpressedButton or something? That sounds really backwards to me, but I'm not a UI guy, period. Could someone elaborate?
It would be something like Button inherits from Clickable and Resizable.
I don’t get the comparison or confusion either. Objects are things that can carry multiple closures over the same set of date. OOP is just advanced FP. It gives us more choices. Besides that, there’s syntax like for, switch, if, import, pointers, try/catch, using, etc, that is separate from both OOP and FP, more aligned to theory of computational in general.
There's two types of programmers: those who think they figured out The Best Way to code and those who know everything is a trade-off and there are no silver bullets.
I am not getting the vibe you understand FP. The idea isn't to eliminate all side effects, a happy user is ultimately a side effect.
The idea is to be really wary of side effects and try to avoid them when possible, since they are way, way harder to reason about that pure functions. FP languages then serve this goal by marking the places where you have this trap, so you can easily spot them, and in cases this trap is not necessary, fix them.
You seemed to talk as if FP doesn't have side effects at all, which is just wrong. Say, reading a file example is a common way to demonstrate usefulness of FP: You'd recognize that file reading itself is not possible by pure function. However, any processing of the bytes of that file after they've been read, likely can be handled by pure functions. You can do parsing by pure functions, say. You have now isolated the one part where non-local failure can break your system, while most of the logic is safe, testable, unaffected by all kinds of hard to predict mutations, corruptions, race conditions etc.
Yes, you are correct. He doesn't understand FP. He only limits the discussion to his limits of understanding of FP which is very shallow I'm afraid.
Once you truly grasp the power of FP and actually put it in use, you can’t go back to other paradigms.
Don’t listen to all those pseudo-gurus and their armchair philosophies.
I don't understand why it's "functional vs OO". It's really "functional vs procedural". OO is just a way to structure code and data, and that can be done with functional languages as well. Functional vs Procedural is a much simpler comparison, too.
Because functional is closer to procedural (though very different). OO is about independent agents communicating and functional is about workflow and data transformation. Correct me if you think it's not something more like that.
@@PaulSebastianM I'll have to ponder that (I'm quite slow), but doesn't that mean we're still making an apples/oranges comparison?
OO is an entire philosophy of modeling programs as nouns with agency, which is why it's so awful.
15:50, can we not have the bank account example again, I cringe EVERYTIME I hear bank and example together, for the love of god, can the textbook example change JUST FUCKING ONCE
ledger is the original immutable data store
Your metric for code quality at 21:09 suggests that javascript produces the highest quality code which indicates it's a bad/useless metric.
You are misunderstanding "functional core imperative shell". Your argument is "every solution is a mixture of functional and imperative, therefore it's all the same" which is wrong.
The point of "functional core imperative shell" is that you want to make the imperative shell as small as possible because the functional code is easier to maintain. It is similar to "don't put business logic in the UI layer".
Here is the easiest to understand argument for why FP code is more maintainable:
"If I adhere to FP principles (immutability, no side-effects etc.) then I can look at a function and understand/debug it without looking at any other functions. For OO code I always have to worry that another function has changed a global variable/state/mutable variable under the hood while debugging."
First comment 🎉
Inheritance is always bad. Never good. It isn't just doing it well. Inheritance is always bad.
tl;dw discard everything Dave Farley ever says. He's just trying to sell his weird book by making normal things look bad
All I know is real programmers don't use Pascal. That language is reserved for quiche eaters.
I don't even like Quiche.
Sadly it is commercially often used for making quick data-base front-ends, that is probably the Quiche reference.
I made a complicated engineering documentation system, with drawing tools and spreadsheet in it,
but due to lack of funding I had to stop.
Sadly, companies prefer short-lived data-base front-ends over more advanced tools.
ObjectPascal is great due to its module system, and easy user-interface system.
It can be very low level too.
With the range-checking and easy string-type system, it avoids 90% of C-bugs.
The delphi based system was also resistant to run-time bugs, as you could keep the program running after a pointer or range error. Which could help the user to save a backup before restarting. This gave users the
impression that the program could not crash at all.