@ke5uq1we8h
"It's not about objects, it's about sending a message" :-)
@ducodarling
I feel like I'm in programmer church, listening to a sermon
@h4plugins334
"You can write crap code in ANY paradigm" - You been looking over my shoulder ? :)
@mike.hawk_
Non programmers: Oh programmers seem so smart, you have to be some kind of genius to understand code Programmers: Unga bunga OOP tribe sucks
@travis1240
As for any dogmatic approach to software engineering, I'm over it. The best paradigm is what gets the job done with the least cognitive load. When you get too dogmatic about it you can pat yourself on the back but you will end up with less readable, less maintainable code and your successor will curse you.
@Mark73
"We've identified all the paradigms that there are to find" Reminds me of that legislator around 1900 that wanted to shut down the patent office because "everything has already been invented".
@sryx
I wrote software for years before finally starting to actually study coding paradigms. The personal breakthroughs in my journey really began once I read The Little Schemer. It made me go back and see how much complexity I had created because I didn't understand recursion. It also radically changed the way I wrote code in all kinds of languages.
@ianollmann9393
Appreciate the experienced perspective. For those of us who cut our teeth on “anything goes” languages, it is more intuitive that different approaches work better for different problems, and a one-constraint-fits-all design ties your hands unnecessarily in very painful and unconstructive ways at times that do not benefit the end product.
@magiclover9346
Even with a few errors a very articulate argument and well presented. I often find myself borrowing from both philosophies. Especially the immutability approach of functional when dealing with multi threaded or async systems. Following functional guidelines can also help when designing slim micro services, which in the current landscape of cloud focused computing is a bonus. However I also like the encapsulation and polymorphism concepts of OO. When it comes to data persistence I've always found it easier to think of it from an OO stand point.
@Pedro5antos_
10:54 "let's be clear, you can write crap code in any paradigm!"
@ModernSoftwareEngineeringYT
It looks like I am going to have to fire my extensive team of copy editors 🤣
I am afraid that I made several typos in this video, and then missed them in my review before release.
So here are the corrections, and I promise to try and do better in future.
4:09 It is "Edsger Dijkstra" not "Esgar"
4:25 "Constrains" not "Contrains" then I copy-pasted the same typo to 6:44, 7:09, 7:15 and then 7:48 - Doh!
Last but not least (maybe not even last?) is the biggy, I mistyped the Scala code example!
I usually prefer to copy a screen-snapshot of code to avoid this dumb kind of mistake, but thought that I would try something different for these simple examples - Lesson learned!
13:56 The Scala example should read:
val x = someCollection.foldLeft(0)((y,c) => y + c.size)
not
val x = someCollection.foldLeft(0)(y,c) => c.size)
No wonder it wasn't the clearer representation!
Very sorry for these mistakes, but I hope that they don't detract too much from the ideas in the video.
@user-hk3ej4hk7m
The thing I envy about fp languages is the expressiveness of their type system. Function composition, partial application, mappings are all impossible to implement without abusing the type system with most programming languages, even though using these constructs is extremely easy to do: f(g(x)), f(a, b, c), out[i]=f(in[i]). This lack of expressiveness is really what makes me think "I really wish I could write this in Haskell".
@sunshinelizard1
One plus of functional programming is the ease of writing tests against the functions. Work in Clojure for a while honed my attention to the testability of any code I write, so I got better at writing smaller functions.
@williamheymann8180
Overall I prefer a Hybrid approach. In some things I just find that OO maps really well to a problem I am solving and in other parts I find that functional maps really well. Most languages commonly used today can freely switch between the two styles as needed. You can even use purely imperative approaches for some types of problem where you need mutable state for really high performance.
@fburton8
The mistake is to believe a single paradigm is the best approach to solving all problems.
@rhbvkleef
You essentially described Erlang with that message passing example.
@foxoninetails_
I think you've hit the nail on the head with your constraint-based definitions. In my experience, the thing that a lot of "paradigm essentialists" (if you will) miss most often is that these paradigms are most powerful, and most useful, when you mix them. Over-applying any one constraint to your entire system leads to all sorts of workarounds, messiness, and general nonsense, as you try to fill the holes created by using that paradigm outside of its comfort zone. It's when you apply constraints carefully and thoughtfully in the places they're most needed that they really shine. For example, I tend to structure most of my programs with an object-oriented interface - anyone interacting with my code from the outside, myself included, will typically see it as a collection of objects and structures that offer specific sets of functionality for different use cases. Using that constraint helps me keep my code organized and modular, by allowing me to encapsulate specific concepts as "entities" within my system, and define rules about how they interact, as well as making it easy for others to conceptualize and understand at a high level. But a lot of my internal code, the implementation behind how those objects interact, is based on functional principles - breaking their operation down into pure or semi-pure functions, and reducing the code space to stringing together well known high-level operations. Using that constraint helps me ensure that I can quickly and easily reason about how things are functioning internally, and be confident that the smaller building blocks I've created work properly as I string them together into larger and more complex pieces. By mixing the two constraints to fulfill different needs, rather than sticking religiously to only one or the other, I achieve a greater whole in the long run. That view of mixing paradigms reflects how I try to treat everything in programming - as a tool. Far too many people seem to get religiously attached to an idea, a paradigm, a framework, a formatting style, what have you, rather than seeing each individual piece as a means to an end. They get too attached to their hammer, and everything starts to look like a nail. It's when you take a step back, let go of those attachments, and pick the right tools for the job that you can really start to do great work.
@marcosdiez7263
I coordinated a public Logo workshop in the early 90's that ran for 4 years with about 30k attendants, in which we tried to verify Seymour Pappert's theoretical approach. Logo was devised as a learning system in which the screen were used to reflect the way we think about the world around us and the problems we try to model and solve, bringing awareness of Jean Piaget's genetic epistemology (the process that generates our knowledge). The language was devised as a way to implement this learning/researching system, and a key concept for this was the "sintonicity" property: the language should be as closest as possible as the way you express your thoughts to minimize the interference of the translation effort between your own natural language and the computational one, hence one of its features was that the primitive instructions were translated to the final user's language (you had Logo in English, in Swedish, in Spanish, we even contributed to translate it to Quechua). Logo was a functional language, initially a LISP shell (you had lists to manage data and it heavily resourced on recursion). As to be allowed to proof Pappert's ideas that challenged Piaget's ones regarding the immutability of the order of concepts children learns at early ages to understand spatial concepts, the turtle was used, either a robot able to move drawing lines like a kid does following instructions a kid can formulate (move forward 10 steps, turn right 90 degrees) and reproduce, or a triangle drawing in the screen. The thing is, Logo succeeded in this "sintonicity" property when drawing graphics for the programmer could do by themselves exactly the same the turtle would and understand where their ideas on how to solve a problem divert from the reality, but then failed misserabily to provide a similar sintonicity to manage pure abstract data because lists and its operators weren't a natural way to think and arrange data. Now, there's an article in Scientific American from 1971 that described Smalltalk as an attempt to address this very issue and find a more "sintonic" way to deal with the data. Back then the language didn't implement inheritance (it would appear in Smalltalk '80), but just the idea of messages being sent back and forth between entities that "learned to do things" by following the same principles from Logo. The entities were initially turtles instantiated and addressable by a given name, which could "learn" about data. So you'd create a turtle called Paul and tell it (sending a message) to learn that "age" was "12", you would teach the turtle (a new function or method) how to do some math, and you could ask for the "age" or to do the taught math and return the answer. Eventually you'd create another turtle Susan and would teach it how to ask Paul for the "age" or for it math to do something more complex and either return or act accordingly to the answer. Hence the name "small talk". The concept has proven so sintonic that it evolved into OOP paradigm as seen nowadays: having turtles that managed data but didn't appear on screen to draw stuff didn't make sense, and addressing every entity as a turtle got in the way of the sintonicity, hence in Smalltalk '80 inheritance appeared defining a basic object from which other entities inherited its "knowledge" (of how to answer to certain messages) and the turtles became objects specialized in drawing stuff on screen. Hence, there was a path connecting functional languages (LISP and Logo) to OO ones (Smalltalk) with the explicit goal of allowing us to represent our ideas of the world "sintonically", e.g in our own terms instead of the ones sufficing the computer requirements, which in turn determine how "expressive" a language is to model certain kinds of ideas.
@nathanarnold7661
I write with a mix of paradigms these days, where the deciding factor is usually readability. Most of the time, that's functional. I don't think the FP examples in this video were fairly chosen. Good functional code does not need to be so cryptic, but I do agree that it requires understanding some different concepts. I'd like to share and resonate the point that you can obtain the benefits of either paradigm in any language (or almost any) with some discipline, and this is why it's a good idea to learn both. I'm sure this extends to other paradigms as well.
@mikefromwa