I’ve been telling people for years that I want this written on my headstone: “It’s equally easy to write shitty code in all languages.” - Tom Mornini, 1999
I think this is especially clear in Objective C. Messages are not method calls. The language is C with a smalltalkish layer upon, totally orthogonal to the language.
@@edincanada I don't have a lot of experience with OO programming(or programming in general), but for me using inheritance adds extra complexity for little to none benefit.. The way I see OO is kind of like c structs with methods that can act upon the data.. not sure if this is a reasonable approach, guess it depends on the language to use..
Non-programmers: "I have 75 MBAs and get paid three billion dollars an hour. Scrum master, CEO, CEO, scrum master. What is a see-sharp? I am not concerned about the programming part, that gets itself done automatically. Sales are what matter." Programmers: "One more day driving to the office, where I will take it up the ass by someone with an IQ 20 points lower than myself, who gets paid 3 million times as much and takes my job for granted."
But the real question is: is the number of paradigms in which one can write crap code equal to the number of paradigms in which one can write good code? And is that question best phrased in OOP or functional code?
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.
Yeah, I mean, here's an idea that nobody seems to be having. Mix paradigms in your code, don't use just one, use them all when they make the most sense to use them. I dislike Java because it forces OOP. You don't need singletons in C++ because you can just "encapsulate" functions into a namespace, so it syntactically looks like OOP, but it's actually structured. EDIT: I meant to say procedural.
The best approach is the one that makes future usage, development, and identification of errors simple. Cognitive load on one day is nothing compared the long term cost arising from the unnecessary demand to reduce cognitive load on that day.
Yep! It's best to write your code while keeping in mind the effort required to understand it by the next person who has to read it. The first time I was told to rewrite code to make it simpler for the maintenance coders, I was pretty pissed because my code bloody worked! _Why should I rewrite something that works???_ 😮 But I was also very young and naive. Now, decades later, I'm totally on board with writing simple code to make the lives of the code maintenance staff easier. The simple fact is: If the maintenance coders can't reliably change the code, the system is never updated, and then it's pretty quickly replaced with something that they can actually handle.
"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".
Good that they didn't, as Einstein would have not been hired and could have not been so bored that he started to wonder about why time was so relative...
I felt a bit wtf when I heard the ironic "I rest my case" to that short, concise and totally beautiful sum definition :). How is FP bad for modelling here when most OO languages miss half of expressive power by not supporting union types? How are we not "guided in our analysis by the problem" in FP or how is this guidance only bestowed on OO guys? Recursion is very readable, because it closely models decomposition of a problem into smaller problems, thats why its in most books before any mention of OO. Moreover, it a bridge between FP and structured world. I don't think FP folks are motivated by some hatred of OO to point out its flaws, but I think it's no coincidence, that a lot of good practices in OO are also very much FP practices (composition over inheritance, SOLID). And I say that as an everyday java guy, so I'd like to stay out of any strict labelling.
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.
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.
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.
I think coding for so long gave you understanding so that you can see where you can improve. I started learning JS and a few weeks later been introduced to OOP not having a proper base knowledge. This lead to confusion and a year after I still don't know if I'm functional or OOP programmer which is embarrassing.
@@pawel7196 JS is a prototyping language. Only it's recent version started supporting Classes and even now those classes are really prototypes underneath. Prototypes are very similar to Classes and objects (in OOP), you should read more about it. That said I still don't like programming in JS. Unless you follow some unwritten rules, the code you write is very hard to read and understand afterwards.
@@pawel7196 Javascript is a weird language, very malleable but weird indeed . You should go with typescript. And, what do you mean you're a functional or OOP programmer? as Iamcho00 pointed out, you can use prototyping to maskerade as classes. But, you've definitely never programmed anything under the functional paradigm. You're confusing things, maybe you should read about it. Languages like Lisp and Haskell, are functional. Haskell has the pure implementation of functional paradigm, or almost pure, if you don't include IO. You can program following functional paradigm practices, using javascript, but i can guarantee you that you didn't do that. Functional programming is all about not using changing-state and mutable data, which most programmers do using imperative or OOP paradigms.
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".
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.
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.
@MP-mx9nf that is absolutely not true. Read about managed side effects feature that most of the functional languages and newer languages like rust have and you will understand why inherently writing tests in current OOP languages like java,c# will be harder and more error-prone.
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.
I just wish there was more info on FP. I am self taught and found that at least the problems I was dealing with were often better handled through FP. I had complained to some programmer friends that OOP is weirdly obtuse for the stuff I was doing and they kind of made me feel like I was a dumbass until I found that there's another paradigm. It made for TONS of friction and stress on my learning path. Even when I learned there was this FP thing it took me a while to grok anything about applying it because all the conversation is so saturated by ppl being dogmatic.
I think, depending on the kind of the problem you are solving you need 90-99.9% FP and 10-0.1% OOP, most of which can be handled relatively well in pure FP languages too (monads, IO-functions, etc), but there is a small remainder, which is so much harder to do well in pure FP languages, still tend to stick with basically programing FP as much as possible inside OOP language and use the freedom to mutate exclusively where it really helps performance or simplicity against correctness. In simple cases that never change even inheritance can be the simplest and best solution. You need lots of discipline to do it right, but it pays off and rewards good things of both worlds.
I know that OOP encompasses a wide range of languages, so my initial reaction might be misplaced here. But you did mention Java, and it is striking to me just how much my experience with it was the opposite of "bringing me closer to the problem" as opposed to functional programming. The core idea of functional programming to me is composition. Because the functions are pure, you do not have to orchestrate them in a way that takes into account their side effects (as you would e.g. with imperatively creating a connection, imperatively committing it to a pool, imperatively checking if it is still open, imperatively disposing of it, etc). If a function does something in one context, you have a guarantee that it will do that exact same thing in any other context, which ultimately makes it cognitively cheaper to think on much higher levels of abstraction. Maybe Java wins in the loop-sum example, but looking at it gave me flashbacks to the nightmares I created in the early days, summing various quantities simultaneously in inner and outer loops and trying to keep them all in sync. The imperative approach is not clearer here. Had I learned to express what I was doing in a functional style, the odds are good that I would have escaped that quagmire much faster (and maybe even realized that what I was doing was not actually necessary for the program). I've heard it said before that object oriented programs let you use objects to model a problem. In my experience that has been a false promise. Objects create a layer in between you and the problem. Almost universally in programming, the problem is in the data: some input has to be turned into output. Functional programming is not short of ways to model that data and define transformations on it. What it avoids doing is handing the data off to a sovereign domain of control that might mutate it according to its own opaque rules. When functional programming works, it works because it links the program's input to its output in an unbroken chain. I have never seen anything comparable actually achieved in a Java program. When it comes to polymorphism, it seems like this potential strength of OOP is unavoidably tied to what I see as its greatest weakness, which is that objects are opaque to the caller of a method. If one is careful with side effects, I do see how polymorphism can help build reusable code. I'll just add that many functional programming languages use duck typing to accomplish the same thing. Instead of defining a class or interface that future implementations must extend, one defines the contract of a function in terms of what is true of its type. In this system, things can interoperate by virtue of their common traits, regardless of whether they share the same explicit interface or abstract class. Of course this idea does have its drawbacks as well.
Ideally, interfaces in OO languages such as Java shouldn't be huge lists of things that needs to be implemented. When I'm creating interfaces in Java, I try to make them as small as possible, preferably a single method. Since classes in Java can implement more than one interface, and by having very small interfaces, you can come close to duck typing. You don't have to worry that a particular interface is implemented together with 20 other interfaces in one class, you're only interested in a tiny portion of a class' implementation.
Oh man, this functional folks always use the bad examples of other things to show their point... It is PERFECTLY possible to work with composition using OO paradigm avoiding bloated inheritance. It is PERFECTLY possible to work with functional programming and OO at the same time. Just use the best of both worlds, it seems people have the NEED to be in a "club" and talk shit about other "clubs". I still remember the early Ruby days, where every Ruby programmer felt like they were in the higher ground, talking shit about java, php, etc... and that ruby was the best language. And now, is dying... Not because is bad but rather because competition is fierce and new generations have new tastes. So please, step down from that ivory tower because things change, and change fast.
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.
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.
This is where I'm at as well. After spending the first half of my career deeply plumbing the depths of OOP and trying to be a purist there, I got a job where I spent a lot of time with Clojure. I can't overstate how much driving into the functional paradigm and writing with a functional language was a game changer. These days I mostly write in python where I do what Dave mentioned, I chose my constraints based on the problem. Some things are best done as objects, some in a functional style. Python lets me do both, but has more support for making classes and objects.
@@breadman5048 6 months to a year? It's not that different from learning a new language. You get proficient in just a few months of study and practice, then keep ramping up as you go.
I find oo much easier to read, compnentdidmount is easier understand than usereffect... componentdidunmount is way easier to read than another usereffect... To me only more readable in functional is this. -writes. In functional you dont need to refer this.variable or function. How ever setting state is much more readable just write inside class: state = {yourAge: 36, yourStyle: blonde} where in functional you have to define each states by separate assignments. OO is way easier to read. Another topic is OO constructor but there is a way to simulate constructor in functional but again it looks like HACK and way much more harder to read.
In particular I'd dispute his point that functional programming isn't suited to intuitive modelling. Reading Scott Wlaschin's excellent book Domain Driven Modelling Made Functional opened my eyes to the potential of powerful FP type systems for expressing practical line-of-business domains.
I really really dislike OOP. It makes things so much more complicated. Without any necessity. In over 14 years of programming I needed inheritence exactly ONE time. You can do almost everything with functions. Use OOP only where it makes sense, everywhere else, use functions.
@@I_am_Raziel did you watch the video..? Maybe try to understand the bit around OO is really about the flexibility in messaging leveraging polymorphism not inheritance. It's a real shame how some see OO as inheritance and forget encapsulation and polymorphism as the benefit to building complex systems.
@@mattrenyard8712 Encapsulation is one of the features of OOO that I often use. Nevertheless it has been one more year since I wrote the initial message and still the same applies: you can do almost everything with functions. Most of the time (>98%) OOP in all of its complexity is not necessary.
I do agree about everything said here. My only complain nowadays is the overcomplicated codes I find in OO around. Things you could easily solve with a script or a sql procedure are solved using a huge amount of things, using a lot of memory and processing.
That paradigm you explained at the end about multiple modules sending data between each other and otherwise being single threaded is pretty much exactly Communicating Sequential Processes (CSP) as described by Tony Hoare in 1978, and published in a book in 1985.
That's pretty much exactly what I do with socketpair(), fork(), exec() and select() on Posix systems. I hate threads for anything other than, say, matrix manipulation or other such tasks where no signals need to be sent other than start_thread and thread_ended. So why has CSP never been widely implemented, while threads seem to be everwhere? IMO it's because the dominant OS, Windows, makes launching new processes painful and expensive, and has poor inter-process communications.
@@TigercatDesigns CSP is what go-lang uses. However, CSP is basically a somewhat broken version of the Actor model of concurrency. CSP is based on lambda calculus but Actor is based on physics in that it is capable of representing unbounded nondeterminism which lambda calculus cannot. Most famous example of the Actor model is Erlang which was designed to implement high availability high concurrency telephone switch operations. It's truly remarkable and about to undergo a Renaissance I think.
@@benjaminscherrey2479 Thanks for that! I've never come across the Actor model before in any of my design pattern books, although I have heard of Erlang. Looking at the Actor model stuff online, I agree it could/should undergo a Renaissance.
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.
True. On the other hand, a certain amount of _consistency_ is definitely needed for all the paradigms, to actually reap the benefits. No doubt one of the reasons for Java's success is that it was the first mainstream language which had enough OO-constraining built in _enforced_ so even teams of largely unexperienced programmers would produce quite robust applications in it. (That is, what-Java-calls-OO constraining.) I personally find that quite annoying when I have to write Java - but then again, you can of course employ other paradigms in it, only, this can require some verbose wrappers which make it obvious. That has the downside of feeling slow & clunky to develop compared with, say, Python, but the advantage that it's less likely that the project will devolve into a mess of incompatible conventions. Likewise, even though Haskell is purely functional, it is quite possible to write imperative code in it - really imperative with in-place memory updates! - it just needs to be made explicit with a suitable monad. That way, you can again mix paradigms, but avoid bugs where one developer expects foo to be purely functional, but another decides to give it a side-effect that was not considered and breaks code elsewhere.
Sounds good, specially if you work solo on projects, like I do. MCU firmware programer here - I know only the native assembler of two midrange family of MCU and a couple of directives native to vendor compilers mainly used to control data and code allocation. What I would like to know: is this war on paradigms not a direct result of a clash of diferent company cultures inherited by programers working for them? I feel it is. And that is why I liked the vid above and your remarks so much. Most people working in institutions have their mindset made up by those same institutions. The bigger, the stronger. They seem not to have the freedom to try a new thing. As a final sociological remark: people in big institutions seldom know the ends they work towards. The means they are allowed to come by seem also over-normalised. Megachurch stuff, I bet. Let me know your remarks.
@@SimonWoodburyForget I think our disagreement here can be summed up quite succinctly around your assertion that "the larger number of paradigms you follow, the higher the complexity of your code base". In general, this is true; it's easy to go too far in the other direction and jump between paradigms too much, creating issues and mess for yourself and your coworkers. However, you miss a key bit of nuance in that statement - there are times when forcing yourself to stick to the same paradigm, even in the face of a problem which that paradigm does not solve well, increases complexity as well. Not everything is easiest to think about in the same way! Switching paradigms is a tradeoff to be considered, not a sin to be avoided at all costs. Take Haskell, for example. Haskell is _excellent_ at creating and connecting tiny functional building blocks that can be easily reasoned about in isolation, so you can build a larger whole more easily. It's terrible, however, at anything outside of that specific focus area - any time you need to touch the outside world of messy IO and unpredictable inputs, it becomes an absolute nightmare. The language restricts you, quite forcibly, to a single paradigm, and while that is in many respects a benefit, it is also a detriment in others. Were you able to switch paradigms away from that strict, purely functional dogma and the hacks and workarounds needed to break outside of it and do real work, in favor of a paradigm better suited for that environment, your code would benefit greatly from momentarily stepping beyond a restriction that, while beneficial in other areas, is doing you no favors in that one. Programming is not a religious endeavor. There is no benefit to sticking so closely to a specific dogma that you refuse to part from it even for a moment. It's about _solving problems_, and preferably in a way that you can understand, replicate, extend, and maintain easily. When switching tools, like paradigms for example, makes things work more smoothly, the only thing you gain by refusing to do so is frustration.
@@klausehrhardt4481 I agree in general, though I think the heat of the discussion is exacerbated by internet outrage culture even more so than insular company cultures. People stick to the ideas and technologies that they know, and many people - especially in a culture that either reflects back those ideas as an echo chamber or screams at them that they're idiots for having those ideas - refuse to broaden their perspective beyond their first impressions.
I tried out functional programming but I think I like it more for what it taught me than for what it actually offered. The theory behind functional programming, particularly the idea of pure methods, has definitely made me think differently about the way I write OO code. But in the end, I still find it quicker and easier to read and write code in C#.
I think this is the best way to deal with it too. My two cents: OOP languages are still better supported all over the board and have more/better libraries and allow sometimes more control, even if doing the right thing requires a lot more discipline and some more code in most cases. I would always keep things as pure as possible and leave the part that needs mutability/IO centralized on the outside of the application (debug/log code is an exception here), but have the ability open the Pandora's box in these rare cases where it makes sense, eg. to use purpose specific pooling and custom memory/resource management. But if so, then only with a lot of care and caution taken. The little extra time invested to build such architecture, very soon starts to save time over the entire lifecycle.
Keeping code readable + maintainable to me is the hardest part no matter if you're using oop / functional paradigm. Good and bad code can be written in either they just help you out in different areas :)
Human readers are terrible code interpreters. They can only track about 7 items at a time, values and program flow can go out of scope for no reason, etc. So it helps for coding style to target the weakest architecture that will read it, other coders, in order to at least maintain correctness.
@@ZigzauerLT Management who were once developers are actually the worse because they think they know sh*t. Often times they weren't even good developers and even if they were, most of their knowledge is now outdated and/or misplaced.
@@parlor3115 lol but they're not wrong. You're young and have no experience. When I grew in my experience I'm discovering that they're more right than wrong.
@@parlor3115 You're a very naive grasshopper. Programming concepts have not changed much over the past 30 years. The names of things have changed, and many things have come full-circle. Functional programming was around long before OO. Kubernetes/Containers were around long ago, Agile programming books were around 25 years ago. A manager that still subscribes to the waterfall method has always been outdated and misplaced.
I strongly disagree with a notion of a perfect language. There's just too much complexity. It's impossible to get everything you might want in a single language - in some cases, it's mathematically impossible. Also, please don't let it be a visual language. Those have all the design problems of regular languages, plus a million more introduced by the difficulty of mapping things to visual elements. There's a reason all existing visual language are either incredibly simple or "regular programming but you use unwieldy blocks instead of easy typing"
@@LegendLength I don't think there's an "ultimate" programming language, because all languages involve tradeoffs and different tasks require different tradeoffs. A real-time safety-critical system needs a language that is highly amenable to verification and validation and that supports a time-deterministic runtime (so no automatic garbage collection - and possibly no dynamic heap storage to *need* garbage collection). I usually see that done in a subset of Ada. But the program I needed to parse texts marked up in XML to determine linguistic characteristics of the text (in an academic context) had no such constraints; it didn't matter if it took a couple of minutes to produce results, testing gave adequate-for-the-purpose confidence in correctness, but I needed it soon, and cheap (in terms of my own time) so I used Python. I don't see how a language can enforce the constraints of the former and still allow the flexibility of the latter.
@@LegendLength If you depend on different back ends for GC and non-gc, you're getting into a world of pain with libraries - do they depend on GC or not? does the compiler protect you from calling a GC library from non-GC code? And do you have to go through all the detail of smart pointers, if it's going to be garbage collected anyway? Does the compiler protect you from using simple pointers if there's no GC? And other differences I mentioned - there's a reason bondage-and-discipline languages are preferred for safety-critical systems, because they force progammers to express their intent in more detail, which is known to reduce bugs. Do we enforce that on non-critical scripts, or do we make it a language feature that can be turned on and off? Hmm, it's starting to look like multiple languages, isn't it?
@@ContinuousDelivery Or if you want to go more mainstream with java or its more functional sister scala, you get this using akka. It's heavily inspired by Erlang and OTP.
Yes, I worked in Erlang for quite a while and I was thinking the same thing. It really does make coding complex distributed systems a lot easier. A feel that Go is a promising candidate for a fairly contemporary language which can do this, and also ticks a lot of other boxes in terms of the good parts of OO and functional.
It sounds to me very much like pi calculus. It's a bit like lambda calculus in how it's a mathematical model that keeps itself very simple in concept. But everything is passing messages. Computation itself is passing messages.
As far as I understood what he meant, I think he's talking about C. A. R. Hoare's [Communicating Sequential Processes](ora.ox.ac.uk/objects/uuid:e0143106-e414-4f02-bd3d-3f3f8db34e88/download_file?safe_filename=H77%252520-%252520Communicating.pdf&file_format=application%2Fpdf&type_of_work=General+item). And while I do agree with him that we are unlikely to have seen every programming paradigm that can ever be, we have certainly seen this one.
For anyone interested in this discussion, I suggest reading the paper "Why functional programming matters" by John Hughes, who takes the view that we shouldn't focus on what FP *doesn't* allow (no side effects, no flow of control) but what it does enable (modularity, through higher-order functions and lazy evaluation).
I think most programmers find functional programming because they never had to deal with it's constraints. Their brains are wired to write a different kind of code and that's why it looks harder. If you want to compare the sum example, I think a better comparison would be a "map" vs a "for". Which one will be easier for someone that has never coded before? Regarding the asynchronous modules that send messages to one another, that's what Erlang and Elixir do for many years and yes, this is really powerful and for me it seemed a lot easier to understand in a shorter amount of time than Python, JavaScript and C++ code in a professional setting.
Agreed, except I would say that is why it *is* harder - when you're used to a different paradigm. It's not about it being __inherently__ more difficult. Then again, many people say math is hard, and I think that too is mostly a misunderstanding. (Although there is very advanced mathematics that truly is hard, but I think this is true of basically any subject that has been studied much by mankind...)
This is absolutely true, I have worked with elixir in the professional scene for about 6 years now. If we talk about developer efficiency, maintenance and overall product quality, beating elixir or erlang in the field of distributed, highly concurrent applications is something you will not be able to do with one of the alternative languages currently on the market be it go,java or python. Immutable code is easier to reason about, is thread safe by design, pure functions are easy to reason about in a big and complex codebase, easy to test and debug and inherently have less bugs by design. It is argued that you can write functional code in most languages however that is not entirely true, languages like java were not designed for optimization of immutable structures, can't handle concurrency race-free on immutable structures, there are no managed side-effects. These things cannot be implemented as libraries, they need to be at the core of the language and runtime and impact directly the performance of the designed system. The way concurrency and OO concepts were implemented in erlang are superior by years to any languages I've seen nowadays. I could literally show you 45 minute presentation on how concurrency works in the runtime and even a kid will understand it, as it doesn't involve any low-level crap like mutexes, threads, race conditions, locks as the runtime and language abstracts everything for you, providing you great abstractions to get things done, not to reinvent the wheel on how to handle concurrency. I've not even mentioned to this point about fault-tolerance, a killer feature exclusive to erlang, that takes the combination of all these concepts to the next level and allows parts of the system to fail and self-heal with zero downtimes.
As a fulltime C# developer, and spare-time Haskell developer, I must say, that the absolute elegance of 'sum = foldl (+) 0' was what won me over! There is a reason that mathematical notation is the way it is, and not like English. Once you know the symbols, it becomes hugely expressive.
Uh. Bad example. There is no such thing as standard mathematical notation. Maths papers usually carefully define the particular notation used throughout the paper for that reason. Without proper context, a mathematical statement can mean pretty much anything: |A| can be the magnitude of a vector A, or the determinant of a matrix A, or the absolute value of an integer A, or the absolute value (aka modulus, aka magnitude) a complex value A... C++ is guilty of this - an expression like auto x = y() tells you _nothing_ about the type of x or y and the operation performed. Could be anything from a ctor call, to a function call, to an operator call on a class instance. Horrible. It gets even worse if you add initializer lists when expressions like f({1, 2}) become impossible to decode without tooling or context ({1, 2} could be an initializer list, an implicit tuple, a std::pair, a ctor call to a class that accepts two arguments that can be implicitly converted from ints, etc.)... I don't want my programming language to be like that. IMHO, expressiveness is overrated. A developer spends far more time reading and contemplating code than writing code and clear code is always better than clever code when it comes to understanding.
Mathematical notation is a language. If you're not fluent in it at all, functional programming is hard. If you are, it's intuitive. Unfortunately, almost no one is fluent in it. Most people don't even realize there is something to be fluent in.
@@totalermist I agree with your last argument that clear code is better than clever code. However, I don't think code needs tons of boilerplate to be clear - in fact, I think boilerplate reduces the readability massively. In functional programming languages like Haskell, there are also clear ways vs. clever ways to implement something. I think the example he gave with "sum" is very clear to someone who is familiar with FP. It basically comes down to this: Do we want something that is accessible or something that is elegant? I for one do not want to settle for the lowest common denominator. But that's just my take.
@@oShinobu Clear code doesn't have to mean lots of boilerplate either. There are quite a few languages that strike a nice balance, such as Python, C# (though that suffered from feature creep as well), F#, Swift and even TypeScript or Ruby and Kotlin. It's nice that you personally don't want to settle for less, but the vast majority of developers deal with rather mundane tasks and line of business apps. Employers want to be able to hire staff that don't have a Master's degree or a PhD and would get bored rather quickly with LOB apps, UIs for interfacing databases and maintaining vast existing code bases written in "boring" languages like Java. That's why Go was created and its success seems to support this observation. (not that I personally like or endorse Go, but I understand why it exists)
@@totalermist He did say “mathematical notation” rather than “standard mathematical notation” . Haskell has its own standard and any Haskell programmer will roughly know what foldl means. If they don’t, this definition of sum is a good motivation to learn. But I think foldl is a good example of where Haskell takes good ideas too far. The default definition of foldl is ` foldl f z t = appEndo (getDual (foldMap (Dual . Endo . flip f) t)) z`, where t is some foldable object. This is not easy for beginners to grasp and leads to some really confusing error messages when you make a type error. The good idea is type classes. It’s a wonderful idea. The problem is it’s such a good idea that there is no clear line which should not be crossed in applying it. I think they crossed a line, but I’m not sure where. Perhaps `foldl f z t = foldl f z . toList t` would have been a better default. Who’s to say?
I think one of the strengths of an imperative style is also it's weakness. I can look at an imperative block of code and navigate through it, line by line "executing" it in my mind to figure out what it does. It allows me to figure things out bit by bit. This is also a weakness though; if I don't execute the code with different inputs, and if I don't execute it completely (i.e. I just skim through the code) I won't truly understand this. Never mind the fact that any time there is a branching statement, I have more execution paths to consider. More functional code allows me to abstract away imperative logic to somewhere else. A sub-procedure means I don't have to concern myself with the details of a procedure, just what it's arguments are and it's return. In a pure functional style, I can rest assured that even if I don't understand the function fully, it won't mess with the state of anything else so I am less likely to get strange behavior in other parts of my program. However, and I think this is to your point, I NEED to understand whatever my function is doing right up front. I cannot execute and reason my way through the code. I either know what a "map().filter().reduce()" does, or I don't. Given the nature of how abstract those functions are, it can also be difficult as a beginner to fully grasp. As a side note, I slightly disagree that the core concept of OO paradigms are polymorphism. Or rather I should say, I think a MORE core concept of OO is encapsulation. I often find closures and dynamic typing to be much more polymorphic than what the more strict OO languages provide.
I think it's about the trade-off between the specification and the execution gaps of a programming language... Closer to hardware meaning easier to translate the program to machine-executable instructions hence lesser execution gap, whereas ease of translating a problem to a program in the language refers to the specification gap
Meaning that any language that allows for inheritance is not really a true OO-language, since inheritance also makes you inherit all the private fields/internal data. Inheritance as a concept is more similar to using patch-files to describe modifications of code than anything else. Rust is a more object-oriented language than Java, because it uses traits (which actually preserves encapsulation) and doesn't allow inheritance.
@@tobiasbergkvist4520 That's nonsense. You inherit an implementation, but you don't inherit the private data unless you use reflection to poke at them, which you explicitly aren't supposed to do.
@@Christobanistan What I mean is that you inherit the knowledge that these private fields exist, and get the ability to modify them. This means that it can be dangerous to change the implementation details of a class in the future, in case someone that inherited from it relies on something that is not part of the public interface.
I write in C, and i've also started thinking more in terms of limiting side-effects of procedures, after learning of functional programming. This is a very good video. Thanks.
I like the focus on constraints. In a sense it is close to a way of thinking mathematically. I just think that computer science is beautiful and I simply enjoy learning it and working with it. I do feel sometimes people dislike something because you can not understand it immediately or without using more maths or logic. But many times once you learnt those things they become pretty simple and obvious (and readable!).
To be hones't i think people have a hard time understanding functional is just because they mostly started learning in oop. I teached programming to a few people (with python) and introducing them to oop concepts was the last thing i did. They mostly where more confused by oop than by functional programming. All the side effects, encapsulation, inheritances etc. was overwhelming to them. While functional is relatively straight forward, there is your "box" -> "data" goes in -> new "data" comes out.
"... functional is the new kid in the block" considering that lisp is inspired by lambda calculus, which is equivalent and contemporary to turing machines, the basis of computing, you can argue that in some sense functional programming came _before_ computers and programming, so yeah, thinking about functional as the new kid in the block is quite a mistake
how did we go from "we can argue that" to "you're wrong"? I think it isn't wrong to think of functional programming as rather new considering its popularity among new languages in the recent years, sure, it may have existed before but it was never a standard in the programming world as OO is, until now.
I think he meant that async/await ruins that constraint he was proposing - you write async code as synchronized with async/await and that's what he would like to avoid. Which means you basically hide concurrency from yourself by doing async/await. Good when there's no actual concurrency (e.g. when you await for database to return a query result), bad when there's actual concurrency happening. Not sure that "asynchronous only" constraint would lead to more readable code though. But definitely would make developers think about possible concurrency issues.
@@AntonMochalin I think the key was threading And him saying messaging passing by it’s nature does not rely on cpu tricks hiding the apparent multi threading from you like asynchronere wait. I agree with him and use events and message passing between modules . If you need to scale just start up many of the same modules and use a queue group to load balance each being given work to do . You can do this pattern inside a single binary of many processes or servers with no code change if you use good message passing patterns
The methodology described at the end of asynchronous message passing between modules is very nicely implemented in go(lang). Alan Kay’s description of object orientation was very much described as asynchronous objects that process messages received and likely generate new asynchronous messages of their own. His objects were much closer to Actors in today’s parlance: objects that do things rather than objects that are things…
Watched this a few weeks ago, and let it sink. Then watched it again now, paused at many points and took some notes. Organised the arguments and key points, wrote them down in an .md file and put it among my personal notes and studies. This is a brilliantly formatted line of thoughts one can bring up on a lecture, interview, or in a pub! Thank you very much, 10/10, would watch again, will seek out your other videos as well!
I do agree with the sentiment that "paradigms" are just "tools" to "help" programmers make good, maintainable code. Good habits learnt during mastery of a paradigm is actually applicable across lots of programming languages.
This video provides a good overview, I specifically enjoyed the brief history lesson at the start. However, I disagree with some points. I don't fully buy the "functional programming = math" premise, and the "therefore, OO is easier to understand" argument. I consider it a straw man. I am not a mathematician, nor am I thinking like one, yet I am perfectly able to understand FP. I don't agree that OO is better suited to modeling a problem domain. I can recommend the talk "domain modeling made functional" by Scott Wlaschin, and his book of a similar name. He demonstrates, how modeling a problem domain is very well suited to the functional paradigm. See the talk here: ruclips.net/video/PLFl95c-IiU/видео.html Similarly, the comprehensibility examples are less "functional vs not functional", more "declarative vs imperative implementation". But that doesn't matter. What counts is the "public interface" (so to speak) of a function. All the examples are "pure" (as in: effect-free), and can be considered functional. In fact, the Java example is a pure function, who cares about the internal implementation details? Overall, the issues expressed in this video with functional programming come from a place of inexperience with the paradigm, I believe. That being said, FP does have many issues. Off the top of my head: 1. I recommend "The Death of Tagless Final" by John A. De Goes, who goes deep into issues with abstraction on the higher end of functional programming. 2. A high learning curve, especially for (arguably) necessary abstractions to build entire systems in FP. 3. Requires lots of support from the runtime or libraries to be efficient (e.g. persistent data structures, tail call optimization, etc.).
My introduction to programming in Python was mostly using the numpy library, so I inadvertently learned to code in more of a "functional paradigm" than not. When I started to look into Haskell I was struggling to find the difference between how to code in Haskell and how I was already coding in Python, funnily enough. Thankfully I think I learned in a way that exposed me to the best and the worst of both paradigms at the same time. It's really nice not having to subscribe to one "side" or the other, just use whatever makes the most sense for that use-case.
Also maybe worth mentioning is that there are at least two languages that I know of that are working with interesting paradigms for sending messages between asynchronous modules: Golang and Elixir
And about this same subject of concurrency and paradigms, there is one very interest article I read recently that compares the conditions that lead to the advent structured programming with the current way we work with concurrency. And proposes an interesting way of restricting the creation of new threads in order to make the code more predictable and provable: vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
Great and informative as always! What I find funny is that while I'm not a functional programmer by any stretch, I do try to write my code as declarative as possible and actually find the functional examples in the video *a lot* easier to read :)
Yes, I was surprised by some of them, though many examples that I looked through took a while to pore over to unpick. Good code is readable whatever the paradigm and bad code is not.
@@ContinuousDelivery Functional programming can be extremely abstract, but a "basic" example is actually easier to understand for a beginner who doesn't know anything about any programming language. Consider your "sum" example. In functional programming, the code is pretty close to natural language: if there aren't any numbers, the sum is 0. If there are, the sum is the first number plus the sum of the rest. In imperative programming, the code is more complicated. First you declare a counter and set it to zero, because you haven't added anything yet. Then, using a "for" loop, you need a counter to keep track of the index of the element you need to add next (it starts in zero, it's valid until you reach the number of elements in the array, and you add 1 to this index counter at each step). Think of it as your "finger" pointing to the list. Wow, okay... Then you need to access the value that it's in the list using its index and accumulate said value to the result counter you first initialized. Then return the value. Sure, the imperative approach improves massively if you use a "foreach" loop, and it also resembles natural language: foreach element in the list, add it to the accumulator. So what about sorting a list? Haskell's approach to this problem always blows my mind :-)
@@ContinuousDelivery One thing I am periodically and unexpectedly sidelined by is how what is readable changes, especially when working on teams with members who span generations or disciplines. I have had project managers be surprised when explaining that, no, just because we are all programmers doesn't mean we can somehow understand each other automatically.
The "limiting synchronicity" idea you described sounds a lot like Observables in the rxjs world. what would be interesting is if that were more common in desktop use cases, and if an observable response could be sent along a separate thread than it was initiated from
Dave, as someone who strongly prefers functional programming, I really appreciate your balanced perspective here. I am curious if you're familiar with material on modeling in FP, such as Scott Wlaschin's "Domain Modeling Made Functional" -- I feel that I model early and deeply in FP, so it's a little hard to agree that OO is "more" focused on modeling; it seems orthogonal to choice of paradigm. That said, I mix and match OO and FP based on need (inasmuch as I try to limit and centralize mutable state as much as I can), so maybe I'm an outlier?
Thanks, I tend to use a mix of OO and FP too, though mine is certainly OO with bits of FP rather than the other way around. I was trying to play this with a straight bat. I try to highlight the points where I am aware that my own prejudice may be involved. Thanks for the reference to the Domain Modeling in FP stuff, that sounds like something I will enjoy.
I'd be interested to get your take on Rust that takes little bits of inspiration from all different kinds paradigms, including both OO and functional, but eschews embracing any particular one wholly, such as implementing polymorphism, closures, and immutability by default, but purposefully leaving out inheritance.
Rust is my number one programming language to develop with at the moment, but I wish they'd add an option for strict aliased types. The reason being that the borrow restriction almost always leads to structuring and manipulating your data by having bunch of structs inside a vector and another vector of usize values that has index values pointing to the real data vector. When your algorithms grow more complex, it becomes hard to make sense which usize value points to which vector of data. With strict aliased types you could alias the usize to have specific label for each specific data vector, and while doing so the compiler would prohibit you from using the wrong aliased type at wrong context. At the moment if you make a function that accepts aliased usize as its argument, you can pass any aliased usize type to that function as well as a regular usize value. There should be way to make this more strict. You can achieve this in theory by creating a new struct that has only 1 usize member, but it adds too much friction since you need to name that usize and access it every time with the dot operator.
Of all those pros and cons mentioned, the ability to naturally run functional programs in parallel is the unique key reason that it became more popular than before. Functional languages existed long long ago but they were never been mainstream like those procedural / OO paradigm back then during the days most of our machines cpu were just single core. Many of these older FP languages like Scheme were more like a computer science / AI research language where you can auto generate programs genetically by view FP as trees and crossover with their nodes.
Thank you for this. I haven't done much software development, but I have done an awful lot of maintenance, mainly of a complex C++ project started in the 90s by some Fortran programmers who got to page of 4 of their C++ book and said "well, we don't know what we're trying to achieve, but we definitely need a big ol' class hierarchy". Later, when I had a medium-sized project of my very own, I went for: A lean class hierarchy, concise interfaces, minimal use of new, passing by const reference wherever possible, and RAII wherever appropriate. And it worked pretty well. After watching this video, I think that perhaps I had faint notions of a functional programming style. Which is nice.
I find your last points about OO being about modeling and FP being more mathy interesting. I've definitely done more OO than FP for work, but I find the FP paradigm far more intuitive, and to lead to better modeling than OO tends to. Yes in the trivial cases, OO makes for a nice `new Dog.bark()` experience, but anything complex leads to Factories and Providers and "Utility classes." I don't think those are good ways to model problems. We just need to get someone that can come up with better names and explanations for Monads and Functors and Applicatives etc. They are "mathy" in name, but I don't think they are in practice
Interesting. You may be right. What's really neat about a "semigroup" or a "functor" for example is that it's unambigous what laws it must obey. It's just a word at the end of the day. I think a lot of programmers (including me) get insecure and intimidated when we hear strange terms. As someone who doesn't like naming variables and procedures and systems and even hates discussion around naming, I celebrate the opportunity to expand my vocabulary with exact definitions.
There also just is not material out there to help an average programmer be successful in Haskell (for example). You have to have time to focus, and either know enough math jargon to digest academic literature, or be obsessively motivated. Compared to the wealth of accessible literature you can find on Java, Python, JavaScript, etc., there's almost nothing for functional languages
To me the biggest difference is that functional programming is much more implicit. In non-functional code you need to state everything step by step resulting in longer but simpler code, which may result in more repetition and bugs. Functional code tends to be shorter and less error prone, but every line may require much deeper knowledge of underlying principles because of which understanding or modifying of existing code may be a bigger challenge.
You are comparing functional programming with imperative programming when its perfectly possible and reasonable to work with OO systems in a more declarative and less imperative way. Stop treating this problem with these false dicotomies. We all agree that imperative programming is bad (good in some contexts but bad for bigger and more complex problems), but, not everything that is not functional MUST be imperative. That is wrong and rather foolish.
12:30 Absolutely agree and see this as a powerful argument for the functional approach. It forces me to understand what I’m trying to achieve with greater clarity and resolution. What a well thought out piece - thank you!
Few times I wrote code with "fancy" and short way. It worked for that moment, but after some time I had trouble and it take more time understand "what I tried here to do?" So i prefer bit longer, but more readable and understandable code.
9:41 polymorphism is not an exclusively OO idea. Most OO (in the "Object" sense) languages just happen to conflate polymorphism with inheritance, which is exclusive to that style.
Excellent lecture, I'll show this to my students as a way of backing up my 'chaotic paradigm switching' theories - I always tell 'em to switch freely and happily between the methods that work best.
This is intended as helpful criticism. 1) good job on the introductory history 2) each programmers mind works a bit differently. OOP works well for some, FUNCTIONAL for others. So what is the ratio? 3) if in paid employment, the choice of paradigm usually not an individual programmers. Just follow orders: you are being paid. 4) trade-offs: Which costs more to create? Which costs more to maintain. How big is the local pool of each type of programmer? Which generates higher performance? Which tends to have the fewest bugs? Which are easiest to train people in?
"OO programmers think of programming as modelling, Functional programmers think of programming as mathematics " I think the spanner in the works is that new age databases are shaping up to do the modelling part inside of them,leaving the mathematical part to the program running outside of it
Prevalence of OO thinking is by large the marketing Sun did with Java. It pushed it hard, schools and universities adopted it, and we are having what we are having now.
I think you're too young then. We were pushed OO in the early 90s with C++. Late 80s Objective-C came out as well with NextStep (now known as MacOS). OO was a huge push in things like CORBA. Java just came along and simplified it.
@@dmitryplatonov of course it was.. back then Windows programming was the big thing and C++ was the language to use for it along with the MFC framework.
@@acasualviewer5861 well, it was major paradigm for UI. But I feel that Java did try to cram everything, business logic specifically, into class hierarchy model. And they sponsored teaching generation of programmers how to do so.
Excellent video! I personally prefer languages that mixes both, OO and FP such as Scala. I am feeling that the more I gain expertise from each paradigm, the better I am coding using both approaches at the same time.
Yes, I agree, this shouldn't be about waring camps, ultimately it is about haveing access to a selection of tools that we can apply, as appropriate, to the job in-hand.
@@teeesen my dearest hope is for C/C++ compatible language which would basically be C++, but with better defaults (e.g. mutable instead of const, for both variables and methods, and for both definitions and call sites)
@@defeqel6537 One of Ric Holt’s language design principles is “usage shortens form”; for example in Turing it is easier to write an output statement that puts an newline at the end than one that doesn’t because the former is the more commonly used case. But there is a related principle “shortness forms usage”; make it easier to write correct code than incorrect.
@@defeqel6537 The problem is that C++ has deeper design flaws that can't be fixed by flipping defaults and similar superficial changes. For example, argument-dependent lookup is an incoherent hack, but enough of the rest of language depends on it that replacing it with sane namespace semantics would break compatibility.
Yes I think that it is at least very similar. It is a form of Actor model, when my team 'invented' a version of it for the exchange that we built, we did this at an architectural level, rather than a language level, but the ideas certainly hold. The other system that is like this is Akka from Lightbend.
Nicely done, simply explained. I would love to hear a conversation about how Java is moving towards functional concepts and creating something of a hybrid system.
Wow, I'm glad I warched to the end, the "message-passing" style is something I have just spent 3 months back-porting to my opus magnum (General-pupose all-singing ESP8266 / ESP32 asynchronous programming frame work - 10,000 lines C/C++) I call them "events" but thats EXACTLY how they work to overcome the sync / async timing boundary. The first training example app is called "EverythingIsAnEvent" to coax users gently into eaccepting that their own code becomes little more than a switch statement and a handful of small callbacks. I thought I had invented something quite clever ....after watching your vid, it turns out I have! It made my day :) PS Internally to that its a mix of 50/50 ish OO and functional, I use a LOT of C++ lambdas :)
@@fredrik751 well how do you sum numbers in your head you make a for loop or foreach loop you take first number you add second then third then forth that is basicly a loop
Several of things: 1. In my experience, the breakdown between functional vs OO is a matter of the problem domains a developer is used to dealing with. Some domains map more naturally to one or the other. If you haven't worked on a problem where the paradigm you like *doesn't* work, then you don't really understand the paradigm. And it seems like you just haven't had occasion to work on a problem where OO was a horrible fit and FP just flowed naturally. 2. What counts as "OO" differs widely depending on whether you are talking to someone who works in Java or Python or C++. You have a similar thing on the functional side between dynamically vs statically typed. But the difference is that the functional people have come up with a lot of careful terminology to communicate the specific intent behind the exact version of the paradigm they are using in any given library or system. I'm unaware of any comparably rigorous terminology on the OO side of the equation. 3. As others have mentioned, what you are talking about at the end is Erlang. What they left out is that this is how most soft-realtime systems are designed in practice regardless of language. For our purposes however, the important thing is that this design choice *forces* Erlang to be a dynamically typed pure functional language. That's the relevant mapping of the problem it is dealing with. 4. In any event, thinking in terms of paradigms obscures the real issue. A professional is going to use the paradigm that best fits the problem. But, however you are designing your code, the goal is do it in a way that lets your tooling automate as much of the work as possible and allows you to systematically rule out categories of behavior so that you can reduce your cognitive burden for the code you do have to write by hand. You *can* use any paradigm in any language, but what matters is the level of support you get from the language in actually doing it. It's a matter of "which tool is the best fit for my problem domain". The business case needs to be about productivity and cost, not about ideology and fads. We've been doing this long enough that we should be able to attach hard numbers to this stuff. The people in the comments complaining about managers not understanding need to learn how to make a business case for their preferences. Communicating effectively is at least half the job. 5. Math isn't exclusive to FP. Plenty of OO devs use dependently typed proof systems to validate their API designs before transcribing the proven code into a normal language as the basis for their API. You can do some amazingly advanced refactorings this way. 6. Finally, when it comes to the ease of understanding imperative vs functional code, you are just factually wrong. We've both been programming long enough that the imperative code *seems* natural to us. But we suffer from the curse of knowledge. People have done studies on what non-programmers find easier to understand and and experiments on what students find easier to learn. The evidence is very strongly in favor of functional code, to the point that the 2nd edition of _How to Design Programs_ dropped the chapter on imperative programming entirely (with the expectation that a subsequent class on OO would deal with it). Beyond that research, there are lots of additional intuitive data points. The most widely used programming language on the planet is Microsoft Excel -- a functional reactive programming system. Similarly, functional programming languages are overwhelmingly popular in cases where you have a design requirement that managers with no programming background must be able to do code review and audits. Non-programmers (and less experienced developers) do find functional code to be easier to understand. That doesn't mean it's the right approach for any given problem. But it does mean that experienced devs like you and I have a blind spot to this design consideration that we need to be aware of and factor into our decision making.
A well-thought, well-written, relevant comment that offers valuable insight and provides a counterpoint to the video? What has happened to the RUclips I know?
@@Orlandofurioso95 (Serious answer to non-serious question) Actually, that's not really an exception anymore, on educational channels. A lot od intelligent and qualified people write resopnses and additions inder well-made videos like this one. You can actually learn a lot from YT comments - though I still would only treat it as a tarting point, not real source.
@Max Hayden Chiz What fraction of people using Excel actually use it as a programming language? In my experience, it's almost always just adding columns together, if that. And yeah, maybe you could say that's programming... but I'm sceptical. But I don't really have any data, that's why I'm asking.
@@jakistam1000 I am currently writing my thesis for a Mathematics degree, and despite knowing C, Python, Zig, F#, Haskell and Matlab, half of my work is done in OpenOffice - it's just faster to shuffle data around and debug. Only the more hardcore computations are done in Matlab, where I have 100 lines of code to import a couple CSV exports of the Excel files, and three lines to solve a couple linear systems.
Agree on almost all points. I've programmed for the last 4 decades or so in everything from assembly to typescript and back again :) Years ago I thought I loved Smalltalk because it was pure OO, then I discovered functional and realized Smalltalk Blocks are just closures, so yeah, mixed paradigm is the ticket.
Dave, the framing around paradigms as constraint is really good. Regarding constraining synchronicity, your description sounded close to the actor model.
Doood... I soooo appreciated this talk. As a quarter-century dev, I've grown so tired of the "Holy Wars". And I really appreciate this more balanced, logical approach to programming paradigms. Thank you for this.
It is always frustrating when you talk to young programmers and they are like we are doing it the modern way! All the ways software was written before weren't right. You just don't get it. I laugh because decades of perfectly functional software have been written before they were born.
Very interesting points ! Also thanks for the history lesson 👍🏿 We underestimate too much the importance of it in the industry. That being said OO is not for me anymore. OO despite all of its qualities has failed, IMHO, to keep its promises of reusability and maintainability. At some point, when dealing with complex system, a formal method is an advantage. Yes FP is hard to get into but when you do, it does not betray you...
Readability is important however being easy to read, does not imply that it is understood enough so that people can maintain & evolve it down the line. My point is that a language like Haskell is hard to get into but you can be sure of the basic level of skills of a Haskell developer. You will never have this safety net in Java.
I’m not sure OOP truly has failed on the reusability. I’ve worked solo and found that with a disciplined approach I can get lots of reusability benefits in OOP languages. However, in larger teams I’ve found it happens to a much lesser degree. As a solo programmer, I’ve typically called the shots, but in a team there’s been constant compromises and in all honesty the quality has been far lower. I wonder if we underestimate the influence of the social elements of coding and team culture, and perhaps which behaviours are rewarded and which are not. I’m not sure the failures in reusability are so much because the languages don’t facilitate it, but because in a commercial environment people drive with their focus shortly ahead of the car bonnet, rarely looking further ahead. The pressure is always to get the immediately pressing results, not to invest in making future results more effortless and coherent. So in a commercial environment I’ve seen lots of reuse of third party libraries (appropriate or otherwise) but little emphasis on creating any kind of libraries tailored to the developer’s specific needs. Having said that, I work primarily in C# which in my view hinders reuse with it’s forcing everything into fully compiled DLLs - it’s just not fine grained enough.
He describes the Actor Model, which applies to the BEAM vm (Elixir, Erlang), but also to the Actor Model implementation to the JVM called Akka, and many other implementations
Thanks I am attending a Functional Programming course after a Object Oriented one And your comparison and explanations widen my understanding of the basic concepts behind them
@13:55 How is whether or not something is "more readable" or "clearer" not simply an artifact of education? I don't speak Chinese. To me, no different combinations of the symbols are going to make sense. Is Chinese therefore "unreadable?" "Unclear?"
"How can you have a conversation about programming constraints without mentioning design by contract?", says an Eiffel programmer. Eiffel of course, is the great exemplar of this innovation.
Ada/SPARK has taken design by contract to a new level in the 2012 release. To the point that you can formally prove your system. If design by contract is your thing, you owe it to yourself to check out SPARK. Nowadays the vendors offer open-source/free-to-use versions for personal use. The downside is that expressing your constraints in SPARK is a lot of work. The upside is that you need to do less Unit Testing.
Functional programming for me is a different way of thinking. I learnt Haskell recently and I think one of its strongest points is it's recursion. The easy functions in OO don't look easy in Haskell as you showed. However the easy recursive functions in Haskell look hard in OO. I also think that programming constantly in OO makes you forget what can be very confusing. Like the standard for loop in java takes a while to get what is actually going on. Like the standard function in Haskell takes a while to understand.
Every one can throw the word easy around until you give a total novice, someone without any programming background the task of understanding the different code styles. Then the truly easier solution will come to light.
Great shout out for good old polymorphism, Dave! One of my favourite things is seeing new team members "get" polymorphism after being taught OO is all about inheritance: "Oh, I see - we deal with things by what they do, not by what they are!" :D
Sometimes it is easier to ask your peers to make the design around the interfaces rather than the object. It is precisely the same thing but (sometimes) easier to understand.
Yes, it is such a fundamental idea these days, that we probably take it for granted, but it is certainly one that is at the heart of how I think about design.
Want to say I really appreciate your video and am going to be promoting your video on my channel! awesome discourse on the subject! Keep up the awesome work!
I really like this kind of thinking. I've seen both arguments strongly against OOP as there is for OOP for example, and I find both are too extreme, and in the end, what really matters is to get the job done in a sensible way, regardless of what tools you use. Ultimately close to any project, at least when reaching a considerable size, should probably include a bit of everything depending on your needs.
14:00 - FP looks convoluted in an OO language with functional features tacked on, what a surprise. 14:45 - you missed a " :: " between the name and the type signature. Were any functional programmers even involved in making this video?
Brilliantly presented, you have a new subscriber. The end comment of a new language paradigm is broadly described by mixing Event Driven and MicroService Architectures. This is now for a lot of developers, and an encouraged approach by AWS, Azure, GCP. For anyone interested in this, you need to be looking at Kafka (or other Stream oriented systems), and investigating Akka as this will give you a crash course in this area and cover a lot of the sub-architectural principals you need to understand (Event Sourcing, CRQS, Worker pattern). Also, the number of OO developers (and very senior ones at that) I've interviewed that do not understand polymorphism is painful. There's a reason there's an awful lot of bad OO code in the world - uneducated developers. Don't blame the language for stupid implementation.
Very interesting discussion. I'll add that I've encountered big issues onboarding teams of imperative style engineers with functional codebases. We've spent lots of time and money unwinding and rewriting code for this reason. In my experience, oo / imperative design is just more accessible, as you say, better aligns with human reasoning. I like a lot of what fp has to offer and _actively_ incorporate concepts, but it's often been an impediment to my work.
Yes, I did something early in my career thayt deeply ingrained that idea. I was involved in build a system that was deeply OO, but not at the language level, it was very enlightening.
Why not both? In college, in one of my Computer Science classes, we used Dylan, an object-oriented functional language (loosely based on Scheme). I found it to be a very elegant and enjoyable language to program in. Sadly, it's not a language that's much in use outside some academic and personal projects... :) Great video!
I agree with most of what your saying, and I believe that each OO and functional paradigms bring positives to any project. I've had a great experience using them both with the language Clojure. I don't think any other language lets you use these two paradigms in your own way.
I like both functional programming and object oriented programming. I think both are valuable in different situations. It’s also possible to do both at once, especially in Scala.
whichever system groups that which needs to be grouped, and separates that which needs to be separated in order to make maintenance and modification easier is the preferred system for certain things that's OOP, for others it's functional, for some it's AOP. for others, something else. whichever one satisfies the stated condition that makes the maintenance and modification easy is the right one for that project.
"Let's be clear, you can write crap code in any paradigm"
I see you're familiar with my work...
...sounds like you're setting yourself up for a couple of copyright infringement lawsuits. :P
shut up both of you. he meant MY work!
The only thing that determines the “quality” of your code is how much you (or your employer 😉) can get paid for it.
Shut up all of you, he's talking about MINE.
I’ve been telling people for years that I want this written on my headstone:
“It’s equally easy to write shitty code in all languages.” - Tom Mornini, 1999
"It's not about objects, it's about sending a message" :-)
Lol, nice
omfg winning
I think this is especially clear in Objective C. Messages are not method calls. The language is C with a smalltalkish layer upon, totally orthogonal to the language.
Understanding that OO is actually not about inheritance is an awesome moment of enlightenment I hope all programmers cherish reaching.
@@edincanada I don't have a lot of experience with OO programming(or programming in general), but for me using inheritance adds extra complexity for little to none benefit.. The way I see OO is kind of like c structs with methods that can act upon the data.. not sure if this is a reasonable approach, guess it depends on the language to use..
Non programmers: Oh programmers seem so smart, you have to be some kind of genius to understand code
Programmers: Unga bunga OOP tribe sucks
Scala programmers: let’s make a functional programming language with four new styles of classes
@@dexterantonio3070 "Let us increase class struggle"
Wait. Wrong topic, my bad...
Non-programmers: "I have 75 MBAs and get paid three billion dollars an hour. Scrum master, CEO, CEO, scrum master. What is a see-sharp? I am not concerned about the programming part, that gets itself done automatically. Sales are what matter."
Programmers: "One more day driving to the office, where I will take it up the ass by someone with an IQ 20 points lower than myself, who gets paid 3 million times as much and takes my job for granted."
@@DudeWatIsThis C# is terrible only java is worse, but point taken
@@Megalomaniakaal lol Class struggle
"You can write crap code in ANY paradigm" - You been looking over my shoulder ? :)
🤣
10:54 "let's be clear, you can write crap code in any paradigm!"
but particularly in oo
Nice, then I can just pick any paradigm
But the real question is: is the number of paradigms in which one can write crap code equal to the number of paradigms in which one can write good code? And is that question best phrased in OOP or functional code?
I can confirm this statement.
I write crap code and I can confirm this.
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.
Yeah, I mean, here's an idea that nobody seems to be having. Mix paradigms in your code, don't use just one, use them all when they make the most sense to use them. I dislike Java because it forces OOP. You don't need singletons in C++ because you can just "encapsulate" functions into a namespace, so it syntactically looks like OOP, but it's actually structured.
EDIT: I meant to say procedural.
The best approach is the one that makes future usage, development, and identification of errors simple. Cognitive load on one day is nothing compared the long term cost arising from the unnecessary demand to reduce cognitive load on that day.
Yep! It's best to write your code while keeping in mind the effort required to understand it by the next person who has to read it.
The first time I was told to rewrite code to make it simpler for the maintenance coders, I was pretty pissed because my code bloody worked! _Why should I rewrite something that works???_ 😮 But I was also very young and naive.
Now, decades later, I'm totally on board with writing simple code to make the lives of the code maintenance staff easier.
The simple fact is: If the maintenance coders can't reliably change the code, the system is never updated, and then it's pretty quickly replaced with something that they can actually handle.
Exactly.
But how do you decide which paradigm will induce less cognitive load beforehand?
"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".
That's worse than saying, "We've identified all the patterns that there are to find."
People don't give complexity enough credit.
That sounds like a story worth telling. Thanks for the rabbit hole.
EDIT: oh, its a myth.
640kb is all the memory anyone would need
Good that they didn't, as Einstein would have not been hired and could have not been so bored that he started to wonder about why time was so relative...
@@imrematajz1624 Wrong patent office. Einstein worked in one in Europe. The one that was to be shut down was in Washington, DC.
I feel like I'm in programmer church, listening to a sermon
That’s super accurate actually
Duco Darling Speaking of sermons, I believe that object oriented programming is one of the great deceptions.
I felt a bit wtf when I heard the ironic "I rest my case" to that short, concise and totally beautiful sum definition :). How is FP bad for modelling here when most OO languages miss half of expressive power by not supporting union types? How are we not "guided in our analysis by the problem" in FP or how is this guidance only bestowed on OO guys? Recursion is very readable, because it closely models decomposition of a problem into smaller problems, thats why its in most books before any mention of OO. Moreover, it a bridge between FP and structured world. I don't think FP folks are motivated by some hatred of OO to point out its flaws, but I think it's no coincidence, that a lot of good practices in OO are also very much FP practices (composition over inheritance, SOLID). And I say that as an everyday java guy, so I'd like to stay out of any strict labelling.
@@vladimirljubopytnov5193 rebased
edit: and f-pilled
@@flightrisk7566 f-pilled 😂😂😂😂😂😂 I'm going to start using that ASAP
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.
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.
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.
I think coding for so long gave you understanding so that you can see where you can improve. I started learning JS and a few weeks later been introduced to OOP not having a proper base knowledge. This lead to confusion and a year after I still don't know if I'm functional or OOP programmer which is embarrassing.
@@pawel7196 JS is a prototyping language. Only it's recent version started supporting Classes and even now those classes are really prototypes underneath. Prototypes are very similar to Classes and objects (in OOP), you should read more about it.
That said I still don't like programming in JS. Unless you follow some unwritten rules, the code you write is very hard to read and understand afterwards.
@@pawel7196 Javascript is a weird language, very malleable but weird indeed . You should go with typescript. And, what do you mean you're a functional or OOP programmer? as Iamcho00 pointed out, you can use prototyping to maskerade as classes. But, you've definitely never programmed anything under the functional paradigm. You're confusing things, maybe you should read about it. Languages like Lisp and Haskell, are functional. Haskell has the pure implementation of functional paradigm, or almost pure, if you don't include IO.
You can program following functional paradigm practices, using javascript, but i can guarantee you that you didn't do that.
Functional programming is all about not using changing-state and mutable data, which most programmers do using imperative or OOP paradigms.
wait… You wrote software for years without understanding recursion? Yeesh
@@pmarreck That was a bit loopy 🖖
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".
Yeah, the niceness is like an optimisation that is possible because of the lack of side effects.
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.
👍🏿
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.
@MP-mx9nf that is absolutely not true. Read about managed side effects feature that most of the functional languages and newer languages like rust have and you will understand why inherently writing tests in current OOP languages like java,c# will be harder and more error-prone.
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.
I just wish there was more info on FP. I am self taught and found that at least the problems I was dealing with were often better handled through FP. I had complained to some programmer friends that OOP is weirdly obtuse for the stuff I was doing and they kind of made me feel like I was a dumbass until I found that there's another paradigm. It made for TONS of friction and stress on my learning path. Even when I learned there was this FP thing it took me a while to grok anything about applying it because all the conversation is so saturated by ppl being dogmatic.
I think, depending on the kind of the problem you are solving you need 90-99.9% FP and 10-0.1% OOP, most of which can be handled relatively well in pure FP languages too (monads, IO-functions, etc), but there is a small remainder, which is so much harder to do well in pure FP languages, still tend to stick with basically programing FP as much as possible inside OOP language and use the freedom to mutate exclusively where it really helps performance or simplicity against correctness. In simple cases that never change even inheritance can be the simplest and best solution. You need lots of discipline to do it right, but it pays off and rewards good things of both worlds.
I know that OOP encompasses a wide range of languages, so my initial reaction might be misplaced here. But you did mention Java, and it is striking to me just how much my experience with it was the opposite of "bringing me closer to the problem" as opposed to functional programming.
The core idea of functional programming to me is composition. Because the functions are pure, you do not have to orchestrate them in a way that takes into account their side effects (as you would e.g. with imperatively creating a connection, imperatively committing it to a pool, imperatively checking if it is still open, imperatively disposing of it, etc). If a function does something in one context, you have a guarantee that it will do that exact same thing in any other context, which ultimately makes it cognitively cheaper to think on much higher levels of abstraction.
Maybe Java wins in the loop-sum example, but looking at it gave me flashbacks to the nightmares I created in the early days, summing various quantities simultaneously in inner and outer loops and trying to keep them all in sync. The imperative approach is not clearer here. Had I learned to express what I was doing in a functional style, the odds are good that I would have escaped that quagmire much faster (and maybe even realized that what I was doing was not actually necessary for the program).
I've heard it said before that object oriented programs let you use objects to model a problem. In my experience that has been a false promise. Objects create a layer in between you and the problem. Almost universally in programming, the problem is in the data: some input has to be turned into output. Functional programming is not short of ways to model that data and define transformations on it. What it avoids doing is handing the data off to a sovereign domain of control that might mutate it according to its own opaque rules. When functional programming works, it works because it links the program's input to its output in an unbroken chain. I have never seen anything comparable actually achieved in a Java program.
When it comes to polymorphism, it seems like this potential strength of OOP is unavoidably tied to what I see as its greatest weakness, which is that objects are opaque to the caller of a method. If one is careful with side effects, I do see how polymorphism can help build reusable code. I'll just add that many functional programming languages use duck typing to accomplish the same thing. Instead of defining a class or interface that future implementations must extend, one defines the contract of a function in terms of what is true of its type. In this system, things can interoperate by virtue of their common traits, regardless of whether they share the same explicit interface or abstract class. Of course this idea does have its drawbacks as well.
Ideally, interfaces in OO languages such as Java shouldn't be huge lists of things that needs to be implemented. When I'm creating interfaces in Java, I try to make them as small as possible, preferably a single method. Since classes in Java can implement more than one interface, and by having very small interfaces, you can come close to duck typing. You don't have to worry that a particular interface is implemented together with 20 other interfaces in one class, you're only interested in a tiny portion of a class' implementation.
You don't need duck typing to achieve polymorphism. Just generics and typeclasses.
Oh man, this functional folks always use the bad examples of other things to show their point...
It is PERFECTLY possible to work with composition using OO paradigm avoiding bloated inheritance.
It is PERFECTLY possible to work with functional programming and OO at the same time.
Just use the best of both worlds, it seems people have the NEED to be in a "club" and talk shit about other "clubs".
I still remember the early Ruby days, where every Ruby programmer felt like they were in the higher ground, talking shit about java, php, etc... and that ruby was the best language.
And now, is dying... Not because is bad but rather because competition is fierce and new generations have new tastes.
So please, step down from that ivory tower because things change, and change fast.
@@gustavoandrade58 I am a Typescript programmer.
Polymorphism is widely used in functional languages too, i.e. type classes in Haskell and row polymorphism in Elm.
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.
I once gave a presentation on why copy-paste is evil, so seeing "contrains" pop up over and over made me chuckle.
Not typos, undocumented features.
Another correction: Haskell's sum function should be:
sum :: [Int] -> Int
sum [] = []
sum (n : ns) = n + sum ns
@@mayabartolabac That gives my brain a TypeError, shouldn't it be
sum :: [Int] -> Int
sum [] = 0
sum (n : ns) = n + sum ns
?
@@dtkedtyjrtyj ooooohhhhh right thanks for letting me know
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.
This is where I'm at as well. After spending the first half of my career deeply plumbing the depths of OOP and trying to be a purist there, I got a job where I spent a lot of time with Clojure. I can't overstate how much driving into the functional paradigm and writing with a functional language was a game changer. These days I mostly write in python where I do what Dave mentioned, I chose my constraints based on the problem. Some things are best done as objects, some in a functional style. Python lets me do both, but has more support for making classes and objects.
@@markdewey6788 how long did it take for you to learn FP? And how long to really appreciate the concepts
@@breadman5048 6 months to a year? It's not that different from learning a new language. You get proficient in just a few months of study and practice, then keep ramping up as you go.
I find oo much easier to read, compnentdidmount is easier understand than usereffect... componentdidunmount is way easier to read than another usereffect... To me only more readable in functional is this. -writes. In functional you dont need to refer this.variable or function. How ever setting state is much more readable just write inside class: state = {yourAge: 36, yourStyle: blonde} where in functional you have to define each states by separate assignments. OO is way easier to read. Another topic is OO constructor but there is a way to simulate constructor in functional but again it looks like HACK and way much more harder to read.
In particular I'd dispute his point that functional programming isn't suited to intuitive modelling. Reading Scott Wlaschin's excellent book Domain Driven Modelling Made Functional opened my eyes to the potential of powerful FP type systems for expressing practical line-of-business domains.
I really really dislike OOP. It makes things so much more complicated. Without any necessity. In over 14 years of programming I needed inheritence exactly ONE time. You can do almost everything with functions. Use OOP only where it makes sense, everywhere else, use functions.
@@I_am_Raziel did you watch the video..? Maybe try to understand the bit around OO is really about the flexibility in messaging leveraging polymorphism not inheritance. It's a real shame how some see OO as inheritance and forget encapsulation and polymorphism as the benefit to building complex systems.
@@mattrenyard8712 Encapsulation is one of the features of OOO that I often use. Nevertheless it has been one more year since I wrote the initial message and still the same applies: you can do almost everything with functions. Most of the time (>98%) OOP in all of its complexity is not necessary.
Functional programming has polymorphism much more powerful than OO.
I do agree about everything said here. My only complain nowadays is the overcomplicated codes I find in OO around. Things you could easily solve with a script or a sql procedure are solved using a huge amount of things, using a lot of memory and processing.
You essentially described Erlang with that message passing example.
yeah its the Actor model which is a great way to code. can be hard to debug what happened in your system though the performance gains are great.
I only managed to write a "hello world" example in Erlang, but I definitely got that vibe too.
@@nwoDekaTsyawlA Try elixir it is a “modern” erlang and it is great
Erlang/Elixir also fit his criticism about copying values to maintain immutability. It's not that it's bad per say but it does come at a cost.
@@JohnDavidDunlap that’s right. On the other hand how should the suggested system work without copying?
That paradigm you explained at the end about multiple modules sending data between each other and otherwise being single threaded is pretty much exactly Communicating Sequential Processes (CSP) as described by Tony Hoare in 1978, and published in a book in 1985.
Nothing new under the sun! I'll have to add it to my reading list, sounds interesting.
That's pretty much exactly what I do with socketpair(), fork(), exec() and select() on Posix systems. I hate threads for anything other than, say, matrix manipulation or other such tasks where no signals need to be sent other than start_thread and thread_ended. So why has CSP never been widely implemented, while threads seem to be everwhere? IMO it's because the dominant OS, Windows, makes launching new processes painful and expensive, and has poor inter-process communications.
@@TigercatDesigns CSP is what go-lang uses. However, CSP is basically a somewhat broken version of the Actor model of concurrency. CSP is based on lambda calculus but Actor is based on physics in that it is capable of representing unbounded nondeterminism which lambda calculus cannot. Most famous example of the Actor model is Erlang which was designed to implement high availability high concurrency telephone switch operations. It's truly remarkable and about to undergo a Renaissance I think.
@@benjaminscherrey2479 Thanks for that! I've never come across the Actor model before in any of my design pattern books, although I have heard of Erlang. Looking at the Actor model stuff online, I agree it could/should undergo a Renaissance.
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.
True. On the other hand, a certain amount of _consistency_ is definitely needed for all the paradigms, to actually reap the benefits. No doubt one of the reasons for Java's success is that it was the first mainstream language which had enough OO-constraining built in _enforced_ so even teams of largely unexperienced programmers would produce quite robust applications in it. (That is, what-Java-calls-OO constraining.) I personally find that quite annoying when I have to write Java - but then again, you can of course employ other paradigms in it, only, this can require some verbose wrappers which make it obvious. That has the downside of feeling slow & clunky to develop compared with, say, Python, but the advantage that it's less likely that the project will devolve into a mess of incompatible conventions.
Likewise, even though Haskell is purely functional, it is quite possible to write imperative code in it - really imperative with in-place memory updates! - it just needs to be made explicit with a suitable monad. That way, you can again mix paradigms, but avoid bugs where one developer expects foo to be purely functional, but another decides to give it a side-effect that was not considered and breaks code elsewhere.
Word
Sounds good, specially if you work solo on projects, like I do. MCU firmware programer here - I know only the native assembler of two midrange family of MCU and a couple of directives native to vendor compilers mainly used to control data and code allocation.
What I would like to know: is this war on paradigms not a direct result of a clash of diferent company cultures inherited by programers working for them?
I feel it is. And that is why I liked the vid above and your remarks so much.
Most people working in institutions have their mindset made up by those same institutions. The bigger, the stronger.
They seem not to have the freedom to try a new thing.
As a final sociological remark: people in big institutions seldom know the ends they work towards. The means they are allowed to come by seem also over-normalised. Megachurch stuff, I bet.
Let me know your remarks.
@@SimonWoodburyForget I think our disagreement here can be summed up quite succinctly around your assertion that "the larger number of paradigms you follow, the higher the complexity of your code base". In general, this is true; it's easy to go too far in the other direction and jump between paradigms too much, creating issues and mess for yourself and your coworkers. However, you miss a key bit of nuance in that statement - there are times when forcing yourself to stick to the same paradigm, even in the face of a problem which that paradigm does not solve well, increases complexity as well. Not everything is easiest to think about in the same way! Switching paradigms is a tradeoff to be considered, not a sin to be avoided at all costs.
Take Haskell, for example. Haskell is _excellent_ at creating and connecting tiny functional building blocks that can be easily reasoned about in isolation, so you can build a larger whole more easily. It's terrible, however, at anything outside of that specific focus area - any time you need to touch the outside world of messy IO and unpredictable inputs, it becomes an absolute nightmare. The language restricts you, quite forcibly, to a single paradigm, and while that is in many respects a benefit, it is also a detriment in others. Were you able to switch paradigms away from that strict, purely functional dogma and the hacks and workarounds needed to break outside of it and do real work, in favor of a paradigm better suited for that environment, your code would benefit greatly from momentarily stepping beyond a restriction that, while beneficial in other areas, is doing you no favors in that one.
Programming is not a religious endeavor. There is no benefit to sticking so closely to a specific dogma that you refuse to part from it even for a moment. It's about _solving problems_, and preferably in a way that you can understand, replicate, extend, and maintain easily. When switching tools, like paradigms for example, makes things work more smoothly, the only thing you gain by refusing to do so is frustration.
@@klausehrhardt4481 I agree in general, though I think the heat of the discussion is exacerbated by internet outrage culture even more so than insular company cultures. People stick to the ideas and technologies that they know, and many people - especially in a culture that either reflects back those ideas as an echo chamber or screams at them that they're idiots for having those ideas - refuse to broaden their perspective beyond their first impressions.
I tried out functional programming but I think I like it more for what it taught me than for what it actually offered. The theory behind functional programming, particularly the idea of pure methods, has definitely made me think differently about the way I write OO code. But in the end, I still find it quicker and easier to read and write code in C#.
Look to SOLID
I think this is the best way to deal with it too. My two cents: OOP languages are still better supported all over the board and have more/better libraries and allow sometimes more control, even if doing the right thing requires a lot more discipline and some more code in most cases. I would always keep things as pure as possible and leave the part that needs mutability/IO centralized on the outside of the application (debug/log code is an exception here), but have the ability open the Pandora's box in these rare cases where it makes sense, eg. to use purpose specific pooling and custom memory/resource management. But if so, then only with a lot of care and caution taken. The little extra time invested to build such architecture, very soon starts to save time over the entire lifecycle.
Keeping code readable + maintainable to me is the hardest part no matter if you're using oop / functional paradigm. Good and bad code can be written in either they just help you out in different areas :)
there are many problems: dead line , time to market ...etc.
the more you do the more you learn because you are the one writing your own projects
Human readers are terrible code interpreters. They can only track about 7 items at a time, values and program flow can go out of scope for no reason, etc. So it helps for coding style to target the weakest architecture that will read it, other coders, in order to at least maintain correctness.
"...part oo, part functional, part structured..."
JavaScript: "Someone said my name?"
@@paulkanja the only thing 'functional' about javascript is it uses functions. 😁
The hardest part of reactive programming is convincing management, especially those who were once developers.
and they are not always wrong :)
@@ZigzauerLT Management who were once developers are actually the worse because they think they know sh*t. Often times they weren't even good developers and even if they were, most of their knowledge is now outdated and/or misplaced.
@@parlor3115 lol but they're not wrong. You're young and have no experience. When I grew in my experience I'm discovering that they're more right than wrong.
on the frontend, the hardest part is convincing people that reactivity isn't always good =)
@@parlor3115 You're a very naive grasshopper. Programming concepts have not changed much over the past 30 years. The names of things have changed, and many things have come full-circle. Functional programming was around long before OO. Kubernetes/Containers were around long ago, Agile programming books were around 25 years ago. A manager that still subscribes to the waterfall method has always been outdated and misplaced.
The mistake is to believe a single paradigm is the best approach to solving all problems.
@@LegendLength Scratch?
@@LegendLength i worry about dealing with merge conflicts / viewing a diff between version A of such a visual creation and version B
I strongly disagree with a notion of a perfect language. There's just too much complexity. It's impossible to get everything you might want in a single language - in some cases, it's mathematically impossible.
Also, please don't let it be a visual language. Those have all the design problems of regular languages, plus a million more introduced by the difficulty of mapping things to visual elements. There's a reason all existing visual language are either incredibly simple or "regular programming but you use unwieldy blocks instead of easy typing"
@@LegendLength I don't think there's an "ultimate" programming language, because all languages involve tradeoffs and different tasks require different tradeoffs. A real-time safety-critical system needs a language that is highly amenable to verification and validation and that supports a time-deterministic runtime (so no automatic garbage collection - and possibly no dynamic heap storage to *need* garbage collection). I usually see that done in a subset of Ada. But the program I needed to parse texts marked up in XML to determine linguistic characteristics of the text (in an academic context) had no such constraints; it didn't matter if it took a couple of minutes to produce results, testing gave adequate-for-the-purpose confidence in correctness, but I needed it soon, and cheap (in terms of my own time) so I used Python. I don't see how a language can enforce the constraints of the former and still allow the flexibility of the latter.
@@LegendLength If you depend on different back ends for GC and non-gc, you're getting into a world of pain with libraries - do they depend on GC or not? does the compiler protect you from calling a GC library from non-GC code? And do you have to go through all the detail of smart pointers, if it's going to be garbage collected anyway? Does the compiler protect you from using simple pointers if there's no GC? And other differences I mentioned - there's a reason bondage-and-discipline languages are preferred for safety-critical systems, because they force progammers to express their intent in more detail, which is known to reduce bugs. Do we enforce that on non-critical scripts, or do we make it a language feature that can be turned on and off? Hmm, it's starting to look like multiple languages, isn't it?
Awesome talk.
The last piece in this talk on the "pure message sending" idea, actually reminds me more about Erlang&OTP rather than smaltalk or ruby.
Thanks, yes, it is very like Erlang.
@@ContinuousDelivery Or if you want to go more mainstream with java or its more functional sister scala, you get this using akka. It's heavily inspired by Erlang and OTP.
Yes, I worked in Erlang for quite a while and I was thinking the same thing. It really does make coding complex distributed systems a lot easier. A feel that Go is a promising candidate for a fairly contemporary language which can do this, and also ticks a lot of other boxes in terms of the good parts of OO and functional.
It sounds to me very much like pi calculus. It's a bit like lambda calculus in how it's a mathematical model that keeps itself very simple in concept. But everything is passing messages. Computation itself is passing messages.
As far as I understood what he meant, I think he's talking about C. A. R. Hoare's [Communicating Sequential Processes](ora.ox.ac.uk/objects/uuid:e0143106-e414-4f02-bd3d-3f3f8db34e88/download_file?safe_filename=H77%252520-%252520Communicating.pdf&file_format=application%2Fpdf&type_of_work=General+item). And while I do agree with him that we are unlikely to have seen every programming paradigm that can ever be, we have certainly seen this one.
For anyone interested in this discussion, I suggest reading the paper "Why functional programming matters" by John Hughes, who takes the view that we shouldn't focus on what FP *doesn't* allow (no side effects, no flow of control) but what it does enable (modularity, through higher-order functions and lazy evaluation).
I think most programmers find functional programming because they never had to deal with it's constraints. Their brains are wired to write a different kind of code and that's why it looks harder.
If you want to compare the sum example, I think a better comparison would be a "map" vs a "for". Which one will be easier for someone that has never coded before?
Regarding the asynchronous modules that send messages to one another, that's what Erlang and Elixir do for many years and yes, this is really powerful and for me it seemed a lot easier to understand in a shorter amount of time than Python, JavaScript and C++ code in a professional setting.
Agreed, except I would say that is why it *is* harder - when you're used to a different paradigm. It's not about it being __inherently__ more difficult. Then again, many people say math is hard, and I think that too is mostly a misunderstanding. (Although there is very advanced mathematics that truly is hard, but I think this is true of basically any subject that has been studied much by mankind...)
This is absolutely true, I have worked with elixir in the professional scene for about 6 years now.
If we talk about developer efficiency, maintenance and overall product quality, beating elixir or erlang in the field of distributed, highly concurrent applications is something you will not be able to do with one of the alternative languages currently on the market be it go,java or python. Immutable code is easier to reason about, is thread safe by design, pure functions are easy to reason about in a big and complex codebase, easy to test and debug and inherently have less bugs by design.
It is argued that you can write functional code in most languages however that is not entirely true, languages like java were not designed for optimization of immutable structures, can't handle concurrency race-free on immutable structures, there are no managed side-effects. These things cannot be implemented as libraries, they need to be at the core of the language and runtime and impact directly the performance of the designed system.
The way concurrency and OO concepts were implemented in erlang are superior by years to any languages I've seen nowadays. I could literally show you 45 minute presentation on how concurrency works in the runtime and even a kid will understand it, as it doesn't involve any low-level crap like mutexes, threads, race conditions, locks as the runtime and language abstracts everything for you, providing you great abstractions to get things done, not to reinvent the wheel on how to handle concurrency. I've not even mentioned to this point about fault-tolerance, a killer feature exclusive to erlang, that takes the combination of all these concepts to the next level and allows parts of the system to fail and self-heal with zero downtimes.
As a fulltime C# developer, and spare-time Haskell developer, I must say, that the absolute elegance of 'sum = foldl (+) 0' was what won me over! There is a reason that mathematical notation is the way it is, and not like English. Once you know the symbols, it becomes hugely expressive.
Uh. Bad example. There is no such thing as standard mathematical notation. Maths papers usually carefully define the particular notation used throughout the paper for that reason.
Without proper context, a mathematical statement can mean pretty much anything: |A| can be the magnitude of a vector A, or the determinant of a matrix A, or the absolute value of an integer A, or the absolute value (aka modulus, aka magnitude) a complex value A...
C++ is guilty of this - an expression like auto x = y() tells you _nothing_ about the type of x or y and the operation performed. Could be anything from a ctor call, to a function call, to an operator call on a class instance. Horrible. It gets even worse if you add initializer lists when expressions like f({1, 2}) become impossible to decode without tooling or context ({1, 2} could be an initializer list, an implicit tuple, a std::pair, a ctor call to a class that accepts two arguments that can be implicitly converted from ints, etc.)...
I don't want my programming language to be like that. IMHO, expressiveness is overrated.
A developer spends far more time reading and contemplating code than writing code and clear code is always better than clever code when it comes to understanding.
Mathematical notation is a language. If you're not fluent in it at all, functional programming is hard. If you are, it's intuitive. Unfortunately, almost no one is fluent in it. Most people don't even realize there is something to be fluent in.
@@totalermist I agree with your last argument that clear code is better than clever code. However, I don't think code needs tons of boilerplate to be clear - in fact, I think boilerplate reduces the readability massively. In functional programming languages like Haskell, there are also clear ways vs. clever ways to implement something. I think the example he gave with "sum" is very clear to someone who is familiar with FP.
It basically comes down to this: Do we want something that is accessible or something that is elegant? I for one do not want to settle for the lowest common denominator. But that's just my take.
@@oShinobu Clear code doesn't have to mean lots of boilerplate either.
There are quite a few languages that strike a nice balance, such as Python, C# (though that suffered from feature creep as well), F#, Swift and even TypeScript or Ruby and Kotlin.
It's nice that you personally don't want to settle for less, but the vast majority of developers deal with rather mundane tasks and line of business apps.
Employers want to be able to hire staff that don't have a Master's degree or a PhD and would get bored rather quickly with LOB apps, UIs for interfacing databases and maintaining vast existing code bases written in "boring" languages like Java.
That's why Go was created and its success seems to support this observation. (not that I personally like or endorse Go, but I understand why it exists)
@@totalermist He did say “mathematical notation” rather than “standard mathematical notation” . Haskell has its own standard and any Haskell programmer will roughly know what foldl means. If they don’t, this definition of sum is a good motivation to learn. But I think foldl is a good example of where Haskell takes good ideas too far. The default definition of foldl is ` foldl f z t = appEndo (getDual (foldMap (Dual . Endo . flip f) t)) z`, where t is some foldable object. This is not easy for beginners to grasp and leads to some really confusing error messages when you make a type error. The good idea is type classes. It’s a wonderful idea. The problem is it’s such a good idea that there is no clear line which should not be crossed in applying it. I think they crossed a line, but I’m not sure where. Perhaps `foldl f z t = foldl f z . toList t` would have been a better default. Who’s to say?
only just realised I'm a functional programmer after watching this video. Keep it up!
Thanks
I think one of the strengths of an imperative style is also it's weakness. I can look at an imperative block of code and navigate through it, line by line "executing" it in my mind to figure out what it does. It allows me to figure things out bit by bit. This is also a weakness though; if I don't execute the code with different inputs, and if I don't execute it completely (i.e. I just skim through the code) I won't truly understand this. Never mind the fact that any time there is a branching statement, I have more execution paths to consider.
More functional code allows me to abstract away imperative logic to somewhere else. A sub-procedure means I don't have to concern myself with the details of a procedure, just what it's arguments are and it's return. In a pure functional style, I can rest assured that even if I don't understand the function fully, it won't mess with the state of anything else so I am less likely to get strange behavior in other parts of my program. However, and I think this is to your point, I NEED to understand whatever my function is doing right up front. I cannot execute and reason my way through the code. I either know what a "map().filter().reduce()" does, or I don't. Given the nature of how abstract those functions are, it can also be difficult as a beginner to fully grasp.
As a side note, I slightly disagree that the core concept of OO paradigms are polymorphism. Or rather I should say, I think a MORE core concept of OO is encapsulation. I often find closures and dynamic typing to be much more polymorphic than what the more strict OO languages provide.
The strength of the imperative style is that it's close to the hardware.
I think it's about the trade-off between the specification and the execution gaps of a programming language... Closer to hardware meaning easier to translate the program to machine-executable instructions hence lesser execution gap, whereas ease of translating a problem to a program in the language refers to the specification gap
Meaning that any language that allows for inheritance is not really a true OO-language, since inheritance also makes you inherit all the private fields/internal data.
Inheritance as a concept is more similar to using patch-files to describe modifications of code than anything else.
Rust is a more object-oriented language than Java, because it uses traits (which actually preserves encapsulation) and doesn't allow inheritance.
@@tobiasbergkvist4520 That's nonsense. You inherit an implementation, but you don't inherit the private data unless you use reflection to poke at them, which you explicitly aren't supposed to do.
@@Christobanistan What I mean is that you inherit the knowledge that these private fields exist, and get the ability to modify them.
This means that it can be dangerous to change the implementation details of a class in the future, in case someone that inherited from it relies on something that is not part of the public interface.
I write in C, and i've also started thinking more in terms of limiting side-effects of procedures, after learning of functional programming. This is a very good video. Thanks.
I like the focus on constraints. In a sense it is close to a way of thinking mathematically. I just think that computer science is beautiful and I simply enjoy learning it and working with it. I do feel sometimes people dislike something because you can not understand it immediately or without using more maths or logic. But many times once you learnt those things they become pretty simple and obvious (and readable!).
To be hones't i think people have a hard time understanding functional is just because they mostly started learning in oop.
I teached programming to a few people (with python) and introducing them to oop concepts was the last thing i did. They mostly where more confused by oop than by functional programming. All the side effects, encapsulation, inheritances etc. was overwhelming to them. While functional is relatively straight forward, there is your "box" -> "data" goes in -> new "data" comes out.
"... functional is the new kid in the block"
considering that lisp is inspired by lambda calculus, which is equivalent and contemporary to turing machines, the basis of computing, you can argue that in some sense functional programming came _before_ computers and programming, so yeah, thinking about functional as the new kid in the block is quite a mistake
how did we go from "we can argue that" to "you're wrong"? I think it isn't wrong to think of functional programming as rather new considering its popularity among new languages in the recent years, sure, it may have existed before but it was never a standard in the programming world as OO is, until now.
Fun fact: Lisp influenced the first OO languages.
@ཀཱ yeah, I didn't mean to say he was wrong, I was just adding to that statement
Why don’t you like async await? I’d love to hear more of your thoughts on that
Yeah I want to know too!
To be honest it's better than Kotlin's coroutine in term of syntax length
I think he meant that async/await ruins that constraint he was proposing - you write async code as synchronized with async/await and that's what he would like to avoid. Which means you basically hide concurrency from yourself by doing async/await. Good when there's no actual concurrency (e.g. when you await for database to return a query result), bad when there's actual concurrency happening. Not sure that "asynchronous only" constraint would lead to more readable code though. But definitely would make developers think about possible concurrency issues.
@@AntonMochalin I think the key was threading And him saying messaging passing by it’s nature does not rely on cpu tricks hiding the apparent multi threading from you like asynchronere wait.
I agree with him and use events and message passing between modules . If you need to scale just start up many of the same modules and use a queue group to load balance each being given work to do .
You can do this pattern inside a single binary of many processes or servers with no code change if you use good message passing patterns
Because it’s not deterministic, and can be memory unsafe.
@@airman122469
What the hell are you guys talking about? 😂
And why Arts student like me is in here?😂
Typing the fewest characters should not be a goal. It reduces readability and reduces the pool of developers that will correctly interpret the code.
The methodology described at the end of asynchronous message passing between modules is very nicely implemented in go(lang).
Alan Kay’s description of object orientation was very much described as asynchronous objects that process messages received and likely generate new asynchronous messages of their own.
His objects were much closer to Actors in today’s parlance: objects that do things rather than objects that are things…
Also in OTP directly from erlang or through elixir.
Watched this a few weeks ago, and let it sink. Then watched it again now, paused at many points and took some notes. Organised the arguments and key points, wrote them down in an .md file and put it among my personal notes and studies.
This is a brilliantly formatted line of thoughts one can bring up on a lecture, interview, or in a pub! Thank you very much, 10/10, would watch again, will seek out your other videos as well!
Thanks, I am pleased that you liked it.
I do agree with the sentiment that "paradigms" are just "tools" to "help" programmers make good, maintainable code. Good habits learnt during mastery of a paradigm is actually applicable across lots of programming languages.
Why the quotes?? Lol…
your quotes makes it sound like an inuendo, yeah those """paradigms""" really are just """"tools"""" to really """""help""""" programmers
@@thefakepie1126 maybe they're instructions for an esoteric language like RockstarLang, but you code everything through ambiguous sarcasm.
In the end off the video you got close to describing Erlang which is a functional language
Was just thinking that also :-P
Exactly, Erlang and/or Elixir, pretty close description :)
Combined with OTP, which is a lot like Alan Kay's vision of OOP, you get a very powerful system (and one that's very fun to code in).
I used erlang but now use golang with nats . Very similar patterns
What makes elixir so flexible are macros. That’s another dimension not mentioned in the Video. Code that generates code.
This video provides a good overview, I specifically enjoyed the brief history lesson at the start. However, I disagree with some points.
I don't fully buy the "functional programming = math" premise, and the "therefore, OO is easier to understand" argument. I consider it a straw man. I am not a mathematician, nor am I thinking like one, yet I am perfectly able to understand FP.
I don't agree that OO is better suited to modeling a problem domain. I can recommend the talk "domain modeling made functional" by Scott Wlaschin, and his book of a similar name. He demonstrates, how modeling a problem domain is very well suited to the functional paradigm. See the talk here: ruclips.net/video/PLFl95c-IiU/видео.html
Similarly, the comprehensibility examples are less "functional vs not functional", more "declarative vs imperative implementation". But that doesn't matter. What counts is the "public interface" (so to speak) of a function. All the examples are "pure" (as in: effect-free), and can be considered functional. In fact, the Java example is a pure function, who cares about the internal implementation details?
Overall, the issues expressed in this video with functional programming come from a place of inexperience with the paradigm, I believe.
That being said, FP does have many issues. Off the top of my head:
1. I recommend "The Death of Tagless Final" by John A. De Goes, who goes deep into issues with abstraction on the higher end of functional programming.
2. A high learning curve, especially for (arguably) necessary abstractions to build entire systems in FP.
3. Requires lots of support from the runtime or libraries to be efficient (e.g. persistent data structures, tail call optimization, etc.).
My introduction to programming in Python was mostly using the numpy library, so I inadvertently learned to code in more of a "functional paradigm" than not. When I started to look into Haskell I was struggling to find the difference between how to code in Haskell and how I was already coding in Python, funnily enough. Thankfully I think I learned in a way that exposed me to the best and the worst of both paradigms at the same time. It's really nice not having to subscribe to one "side" or the other, just use whatever makes the most sense for that use-case.
From another grey-headed programmer, well done. There is no silver bullet, just pragmatics.
You should definitely go more in depth on your idea at the end in future videos!
Will do, thanks.
Maybe something about Sending async messages = actors
Also maybe worth mentioning is that there are at least two languages that I know of that are working with interesting paradigms for sending messages between asynchronous modules: Golang and Elixir
And about this same subject of concurrency and paradigms, there is one very interest article I read recently that compares the conditions that lead to the advent structured programming with the current way we work with concurrency. And proposes an interesting way of restricting the creation of new threads in order to make the code more predictable and provable:
vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
@@viniciusgarcia3452 yes, and Erlang, though that is nearly the same thing as Elixir as I understand it.
I like the idea of taking the best bits from each, I think that probably makes more sense than going completely one way or the other.
Great and informative as always! What I find funny is that while I'm not a functional programmer by any stretch, I do try to write my code as declarative as possible and actually find the functional examples in the video *a lot* easier to read :)
Yes, I was surprised by some of them, though many examples that I looked through took a while to pore over to unpick. Good code is readable whatever the paradigm and bad code is not.
@@ContinuousDelivery Functional programming can be extremely abstract, but a "basic" example is actually easier to understand for a beginner who doesn't know anything about any programming language. Consider your "sum" example.
In functional programming, the code is pretty close to natural language: if there aren't any numbers, the sum is 0. If there are, the sum is the first number plus the sum of the rest.
In imperative programming, the code is more complicated. First you declare a counter and set it to zero, because you haven't added anything yet. Then, using a "for" loop, you need a counter to keep track of the index of the element you need to add next (it starts in zero, it's valid until you reach the number of elements in the array, and you add 1 to this index counter at each step). Think of it as your "finger" pointing to the list. Wow, okay... Then you need to access the value that it's in the list using its index and accumulate said value to the result counter you first initialized. Then return the value.
Sure, the imperative approach improves massively if you use a "foreach" loop, and it also resembles natural language: foreach element in the list, add it to the accumulator.
So what about sorting a list? Haskell's approach to this problem always blows my mind :-)
@@ContinuousDelivery One thing I am periodically and unexpectedly sidelined by is how what is readable changes, especially when working on teams with members who span generations or disciplines. I have had project managers be surprised when explaining that, no, just because we are all programmers doesn't mean we can somehow understand each other automatically.
The "limiting synchronicity" idea you described sounds a lot like Observables in the rxjs world. what would be interesting is if that were more common in desktop use cases, and if an observable response could be sent along a separate thread than it was initiated from
Dave, as someone who strongly prefers functional programming, I really appreciate your balanced perspective here. I am curious if you're familiar with material on modeling in FP, such as Scott Wlaschin's "Domain Modeling Made Functional" -- I feel that I model early and deeply in FP, so it's a little hard to agree that OO is "more" focused on modeling; it seems orthogonal to choice of paradigm.
That said, I mix and match OO and FP based on need (inasmuch as I try to limit and centralize mutable state as much as I can), so maybe I'm an outlier?
Thanks, I tend to use a mix of OO and FP too, though mine is certainly OO with bits of FP rather than the other way around. I was trying to play this with a straight bat. I try to highlight the points where I am aware that my own prejudice may be involved. Thanks for the reference to the Domain Modeling in FP stuff, that sounds like something I will enjoy.
A very interesting book in this context (in my opinion) is "Concepts, techniques, and models of computer programming" by Peter Van Roy.
Erlang very closely matches what you described in your reactive manifesto.
Yeap! And I was thinking of Elixir.
Yes, it does.
Do you know any source where I could learn how to make the thing in C#?
@@openroomxyz you can do erlang style programming in C# with Akka.NET and reactive programming with Rx.NET
@@AnupDhakalSharma but Elixir sucks because it is dynamicaly typed...
Good lord, this is the most cogent explanation of programming ive heard since ive been learning the subject the last 6 months.
I'd be interested to get your take on Rust that takes little bits of inspiration from all different kinds paradigms, including both OO and functional, but eschews embracing any particular one wholly, such as implementing polymorphism, closures, and immutability by default, but purposefully leaving out inheritance.
Rust is my number one programming language to develop with at the moment, but I wish they'd add an option for strict aliased types. The reason being that the borrow restriction almost always leads to structuring and manipulating your data by having bunch of structs inside a vector and another vector of usize values that has index values pointing to the real data vector. When your algorithms grow more complex, it becomes hard to make sense which usize value points to which vector of data. With strict aliased types you could alias the usize to have specific label for each specific data vector, and while doing so the compiler would prohibit you from using the wrong aliased type at wrong context.
At the moment if you make a function that accepts aliased usize as its argument, you can pass any aliased usize type to that function as well as a regular usize value. There should be way to make this more strict. You can achieve this in theory by creating a new struct that has only 1 usize member, but it adds too much friction since you need to name that usize and access it every time with the dot operator.
Of all those pros and cons mentioned, the ability to naturally run functional programs in parallel is the unique key reason that it became more popular than before. Functional languages existed long long ago but they were never been mainstream like those procedural / OO paradigm back then during the days most of our machines cpu were just single core. Many of these older FP languages like Scheme were more like a computer science / AI research language where you can auto generate programs genetically by view FP as trees and crossover with their nodes.
Thank you for this. I haven't done much software development, but I have done an awful lot of maintenance, mainly of a complex C++ project started in the 90s by some Fortran programmers who got to page of 4 of their C++ book and said "well, we don't know what we're trying to achieve, but we definitely need a big ol' class hierarchy". Later, when I had a medium-sized project of my very own, I went for: A lean class hierarchy, concise interfaces, minimal use of new, passing by const reference wherever possible, and RAII wherever appropriate. And it worked pretty well. After watching this video, I think that perhaps I had faint notions of a functional programming style. Which is nice.
I love your description of "well, we don't know what we're trying to achieve, but we definitely need a big ol' class hierarchy" that resonates 🤣
The argument about constraints is a nice refreshing view!
I find your last points about OO being about modeling and FP being more mathy interesting. I've definitely done more OO than FP for work, but I find the FP paradigm far more intuitive, and to lead to better modeling than OO tends to.
Yes in the trivial cases, OO makes for a nice `new Dog.bark()` experience, but anything complex leads to Factories and Providers and "Utility classes." I don't think those are good ways to model problems.
We just need to get someone that can come up with better names and explanations for Monads and Functors and Applicatives etc. They are "mathy" in name, but I don't think they are in practice
Interesting. You may be right. What's really neat about a "semigroup" or a "functor" for example is that it's unambigous what laws it must obey. It's just a word at the end of the day. I think a lot of programmers (including me) get insecure and intimidated when we hear strange terms. As someone who doesn't like naming variables and procedures and systems and even hates discussion around naming, I celebrate the opportunity to expand my vocabulary with exact definitions.
There also just is not material out there to help an average programmer be successful in Haskell (for example). You have to have time to focus, and either know enough math jargon to digest academic literature, or be obsessively motivated.
Compared to the wealth of accessible literature you can find on Java, Python, JavaScript, etc., there's almost nothing for functional languages
@@j-r-hill yes, you are completely right about that
Every single paradigm is wrong.
In college I spent some time learning how to unfold recursion. Now we are trying to fold it back together again.
To me the biggest difference is that functional programming is much more implicit. In non-functional code you need to state everything step by step resulting in longer but simpler code, which may result in more repetition and bugs. Functional code tends to be shorter and less error prone, but every line may require much deeper knowledge of underlying principles because of which understanding or modifying of existing code may be a bigger challenge.
You are comparing functional programming with imperative programming when its perfectly possible and reasonable to work with OO systems in a more declarative and less imperative way. Stop treating this problem with these false dicotomies. We all agree that imperative programming is bad (good in some contexts but bad for bigger and more complex problems), but, not everything that is not functional MUST be imperative. That is wrong and rather foolish.
@@gustavoandrade58 absolutely right!!!!
12:30 Absolutely agree and see this as a powerful argument for the functional approach. It forces me to understand what I’m trying to achieve with greater clarity and resolution. What a well thought out piece - thank you!
Few times I wrote code with "fancy" and short way. It worked for that moment, but after some time I had trouble and it take more time understand "what I tried here to do?"
So i prefer bit longer, but more readable and understandable code.
9:41 polymorphism is not an exclusively OO idea. Most OO (in the "Object" sense) languages just happen to conflate polymorphism with inheritance, which is exclusive to that style.
You can do polymorphism without inheritance. Reflection is using that.
For example, Haskell implements polymorphism using type classes, which constitute a very different approach from OO.
Excellent lecture, I'll show this to my students as a way of backing up my 'chaotic paradigm switching' theories - I always tell 'em to switch freely and happily between the methods that work best.
This is intended as helpful criticism. 1) good job on the introductory history 2) each programmers mind works a bit differently. OOP works well for some, FUNCTIONAL for others. So what is the ratio? 3) if in paid employment, the choice of paradigm usually not an individual programmers. Just follow orders: you are being paid. 4) trade-offs: Which costs more to create? Which costs more to maintain. How big is the local pool of each type of programmer? Which generates higher performance? Which tends to have the fewest bugs? Which are easiest to train people in?
"OO programmers think of programming as modelling,
Functional programmers think of programming as mathematics "
I think the spanner in the works is that new age databases are shaping up to do the modelling part inside of them,leaving the mathematical part to the program running outside of it
Prevalence of OO thinking is by large the marketing Sun did with Java. It pushed it hard, schools and universities adopted it, and we are having what we are having now.
I think you're too young then.
We were pushed OO in the early 90s with C++. Late 80s Objective-C came out as well with NextStep (now known as MacOS). OO was a huge push in things like CORBA.
Java just came along and simplified it.
Did C++ way before Java/C# came along.
@@sis1296 yes, but that time it was not prevalent paradigm.
@@dmitryplatonov of course it was.. back then Windows programming was the big thing and C++ was the language to use for it along with the MFC framework.
@@acasualviewer5861 well, it was major paradigm for UI. But I feel that Java did try to cram everything, business logic specifically, into class hierarchy model. And they sponsored teaching generation of programmers how to do so.
Excellent video! I personally prefer languages that mixes both, OO and FP such as Scala. I am feeling that the more I gain expertise from each paradigm, the better I am coding using both approaches at the same time.
Yes, I agree, this shouldn't be about waring camps, ultimately it is about haveing access to a selection of tools that we can apply, as appropriate, to the job in-hand.
More and more I’m doing OO with immutable objects. Scala is perfect for this, but it can be done in any OO language.
@@teeesen my dearest hope is for C/C++ compatible language which would basically be C++, but with better defaults (e.g. mutable instead of const, for both variables and methods, and for both definitions and call sites)
@@defeqel6537 One of Ric Holt’s language design principles is “usage shortens form”; for example in Turing it is easier to write an output statement that puts an newline at the end than one that doesn’t because the former is the more commonly used case. But there is a related principle “shortness forms usage”; make it easier to write correct code than incorrect.
@@defeqel6537 The problem is that C++ has deeper design flaws that can't be fixed by flipping defaults and similar superficial changes. For example, argument-dependent lookup is an incoherent hack, but enough of the rest of language depends on it that replacing it with sane namespace semantics would break compatibility.
great video! alternative paradigm mentioned on last minutes sounds me like erlang/elixir :)
Yes I think that it is at least very similar. It is a form of Actor model, when my team 'invented' a version of it for the exchange that we built, we did this at an architectural level, rather than a language level, but the ideas certainly hold. The other system that is like this is Akka from Lightbend.
@@ContinuousDelivery Don't you think that, in a way, actor models or erlang are closer to Alan Kay's OO than Java or C++ ?
@@kguentube Yes, I think that they might be.
Nicely done, simply explained. I would love to hear a conversation about how Java is moving towards functional concepts and creating something of a hybrid system.
Wow, I'm glad I warched to the end, the "message-passing" style is something I have just spent 3 months back-porting to my opus magnum (General-pupose all-singing ESP8266 / ESP32 asynchronous programming frame work - 10,000 lines C/C++) I call them "events" but thats EXACTLY how they work to overcome the sync / async timing boundary. The first training example app is called "EverythingIsAnEvent" to coax users gently into eaccepting that their own code becomes little more than a switch statement and a handful of small callbacks. I thought I had invented something quite clever ....after watching your vid, it turns out I have! It made my day :) PS Internally to that its a mix of 50/50 ish OO and functional, I use a LOT of C++ lambdas :)
Yes, you can write good code in any language
The issue is, whether others can READ your code 🖖
13:58 is an unfair comparison. FP solution should be: val x = someCollection.map(_.size).sum
Yes, sorry for the typo there is a correction pinned in the comments now. The code wasn't really original to me, I took if from an example FP program.
@@fredrik751 well how do you sum numbers in your head you make a for loop or foreach loop you take first number you add second then third then forth that is basicly a loop
Several of things:
1. In my experience, the breakdown between functional vs OO is a matter of the problem domains a developer is used to dealing with. Some domains map more naturally to one or the other. If you haven't worked on a problem where the paradigm you like *doesn't* work, then you don't really understand the paradigm. And it seems like you just haven't had occasion to work on a problem where OO was a horrible fit and FP just flowed naturally.
2. What counts as "OO" differs widely depending on whether you are talking to someone who works in Java or Python or C++. You have a similar thing on the functional side between dynamically vs statically typed. But the difference is that the functional people have come up with a lot of careful terminology to communicate the specific intent behind the exact version of the paradigm they are using in any given library or system. I'm unaware of any comparably rigorous terminology on the OO side of the equation.
3. As others have mentioned, what you are talking about at the end is Erlang. What they left out is that this is how most soft-realtime systems are designed in practice regardless of language. For our purposes however, the important thing is that this design choice *forces* Erlang to be a dynamically typed pure functional language. That's the relevant mapping of the problem it is dealing with.
4. In any event, thinking in terms of paradigms obscures the real issue. A professional is going to use the paradigm that best fits the problem. But, however you are designing your code, the goal is do it in a way that lets your tooling automate as much of the work as possible and allows you to systematically rule out categories of behavior so that you can reduce your cognitive burden for the code you do have to write by hand. You *can* use any paradigm in any language, but what matters is the level of support you get from the language in actually doing it. It's a matter of "which tool is the best fit for my problem domain". The business case needs to be about productivity and cost, not about ideology and fads.
We've been doing this long enough that we should be able to attach hard numbers to this stuff. The people in the comments complaining about managers not understanding need to learn how to make a business case for their preferences. Communicating effectively is at least half the job.
5. Math isn't exclusive to FP. Plenty of OO devs use dependently typed proof systems to validate their API designs before transcribing the proven code into a normal language as the basis for their API. You can do some amazingly advanced refactorings this way.
6. Finally, when it comes to the ease of understanding imperative vs functional code, you are just factually wrong. We've both been programming long enough that the imperative code *seems* natural to us. But we suffer from the curse of knowledge.
People have done studies on what non-programmers find easier to understand and and experiments on what students find easier to learn. The evidence is very strongly in favor of functional code, to the point that the 2nd edition of _How to Design Programs_ dropped the chapter on imperative programming entirely (with the expectation that a subsequent class on OO would deal with it).
Beyond that research, there are lots of additional intuitive data points. The most widely used programming language on the planet is Microsoft Excel -- a functional reactive programming system. Similarly, functional programming languages are overwhelmingly popular in cases where you have a design requirement that managers with no programming background must be able to do code review and audits.
Non-programmers (and less experienced developers) do find functional code to be easier to understand. That doesn't mean it's the right approach for any given problem. But it does mean that experienced devs like you and I have a blind spot to this design consideration that we need to be aware of and factor into our decision making.
A well-thought, well-written, relevant comment that offers valuable insight and provides a counterpoint to the video? What has happened to the RUclips I know?
@@Orlandofurioso95 (Serious answer to non-serious question) Actually, that's not really an exception anymore, on educational channels. A lot od intelligent and qualified people write resopnses and additions inder well-made videos like this one. You can actually learn a lot from YT comments - though I still would only treat it as a tarting point, not real source.
@Max Hayden Chiz What fraction of people using Excel actually use it as a programming language? In my experience, it's almost always just adding columns together, if that. And yeah, maybe you could say that's programming... but I'm sceptical. But I don't really have any data, that's why I'm asking.
@@jakistam1000 I am currently writing my thesis for a Mathematics degree, and despite knowing C, Python, Zig, F#, Haskell and Matlab, half of my work is done in OpenOffice - it's just faster to shuffle data around and debug. Only the more hardcore computations are done in Matlab, where I have 100 lines of code to import a couple CSV exports of the Excel files, and three lines to solve a couple linear systems.
The holy grail is a typed Excel (And I kinda wish I was joking), it would definitely solve the MARCH1 issue.
Agree on almost all points. I've programmed for the last 4 decades or so in everything from assembly to typescript and back again :) Years ago I thought I loved Smalltalk because it was pure OO, then I discovered functional and realized Smalltalk Blocks are just closures, so yeah, mixed paradigm is the ticket.
Dave, the framing around paradigms as constraint is really good. Regarding constraining synchronicity, your description sounded close to the actor model.
Yes it is very close, if not the same, as actor.
Doood... I soooo appreciated this talk. As a quarter-century dev, I've grown so tired of the "Holy Wars". And I really appreciate this more balanced, logical approach to programming paradigms. Thank you for this.
It is always frustrating when you talk to young programmers and they are like we are doing it the modern way! All the ways software was written before weren't right. You just don't get it. I laugh because decades of perfectly functional software have been written before they were born.
Very interesting points ! Also thanks for the history lesson 👍🏿 We underestimate too much the importance of it in the industry. That being said OO is not for me anymore. OO despite all of its qualities has failed, IMHO, to keep its promises of reusability and maintainability. At some point, when dealing with complex system, a formal method is an advantage. Yes FP is hard to get into but when you do, it does not betray you...
Readability is important however being easy to read, does not imply that it is understood enough so that people can maintain & evolve it down the line. My point is that a language like Haskell is hard to get into but you can be sure of the basic level of skills of a Haskell developer. You will never have this safety net in Java.
I’m not sure OOP truly has failed on the reusability. I’ve worked solo and found that with a disciplined approach I can get lots of reusability benefits in OOP languages. However, in larger teams I’ve found it happens to a much lesser degree. As a solo programmer, I’ve typically called the shots, but in a team there’s been constant compromises and in all honesty the quality has been far lower. I wonder if we underestimate the influence of the social elements of coding and team culture, and perhaps which behaviours are rewarded and which are not. I’m not sure the failures in reusability are so much because the languages don’t facilitate it, but because in a commercial environment people drive with their focus shortly ahead of the car bonnet, rarely looking further ahead. The pressure is always to get the immediately pressing results, not to invest in making future results more effortless and coherent. So in a commercial environment I’ve seen lots of reuse of third party libraries (appropriate or otherwise) but little emphasis on creating any kind of libraries tailored to the developer’s specific needs. Having said that, I work primarily in C# which in my view hinders reuse with it’s forcing everything into fully compiled DLLs - it’s just not fine grained enough.
You’ve just described Erlang and Elixir at the end. And I’m sure, sir, you’re very familiar with them :)
He describes the Actor Model, which applies to the BEAM vm (Elixir, Erlang), but also to the Actor Model implementation to the JVM called Akka, and many other implementations
Hadn’t heard of Akka… thanks for that!
Thanks
I am attending a Functional Programming course after a Object Oriented one
And your comparison and explanations widen my understanding of the basic concepts behind them
Glad it was helpful!
@13:55 How is whether or not something is "more readable" or "clearer" not simply an artifact of education? I don't speak Chinese. To me, no different combinations of the symbols are going to make sense. Is Chinese therefore "unreadable?" "Unclear?"
"How can you have a conversation about programming constraints without mentioning design by contract?", says an Eiffel programmer. Eiffel of course, is the great exemplar of this innovation.
Ada/SPARK has taken design by contract to a new level in the 2012 release. To the point that you can formally prove your system. If design by contract is your thing, you owe it to yourself to check out SPARK. Nowadays the vendors offer open-source/free-to-use versions for personal use.
The downside is that expressing your constraints in SPARK is a lot of work. The upside is that you need to do less Unit Testing.
Functional programming for me is a different way of thinking. I learnt Haskell recently and I think one of its strongest points is it's recursion. The easy functions in OO don't look easy in Haskell as you showed. However the easy recursive functions in Haskell look hard in OO.
I also think that programming constantly in OO makes you forget what can be very confusing. Like the standard for loop in java takes a while to get what is actually going on. Like the standard function in Haskell takes a while to understand.
Every one can throw the word easy around until you give a total novice, someone without any programming background the task of understanding the different code styles. Then the truly easier solution will come to light.
Great shout out for good old polymorphism, Dave! One of my favourite things is seeing new team members "get" polymorphism after being taught OO is all about inheritance: "Oh, I see - we deal with things by what they do, not by what they are!" :D
Sometimes it is easier to ask your peers to make the design around the interfaces rather than the object. It is precisely the same thing but (sometimes) easier to understand.
Yes, it is such a fundamental idea these days, that we probably take it for granted, but it is certainly one that is at the heart of how I think about design.
Want to say I really appreciate your video and am going to be promoting your video on my channel! awesome discourse on the subject! Keep up the awesome work!
Thank you for your support!
I love these kind of discussions. Not only claiming which is better but actually comparing and pointing at good and bad. Love it!
Thanks for the positive feedback!
I really like this kind of thinking. I've seen both arguments strongly against OOP as there is for OOP for example, and I find both are too extreme, and in the end, what really matters is to get the job done in a sensible way, regardless of what tools you use.
Ultimately close to any project, at least when reaching a considerable size, should probably include a bit of everything depending on your needs.
The hardest part of programming... A good idea, elegance and knowing when to stop.
Wait, I need this feature! Just one more!
Didn't Alan Turing say knowing when to stop was impossible?
@@NimhLabs wait... if I answer you, then... D'oh!
@@jonathanmoore5619 I may or may not have been purposely misconstruing The Halting Problem for the purpose of being funny
@@NimhLabs stop... Just stop... :)
14:00 - FP looks convoluted in an OO language with functional features tacked on, what a surprise.
14:45 - you missed a " :: " between the name and the type signature.
Were any functional programmers even involved in making this video?
clearly, no.
Brilliantly presented, you have a new subscriber.
The end comment of a new language paradigm is broadly described by mixing Event Driven and MicroService Architectures. This is now for a lot of developers, and an encouraged approach by AWS, Azure, GCP.
For anyone interested in this, you need to be looking at Kafka (or other Stream oriented systems), and investigating Akka as this will give you a crash course in this area and cover a lot of the sub-architectural principals you need to understand (Event Sourcing, CRQS, Worker pattern).
Also, the number of OO developers (and very senior ones at that) I've interviewed that do not understand polymorphism is painful. There's a reason there's an awful lot of bad OO code in the world - uneducated developers. Don't blame the language for stupid implementation.
Very interesting discussion. I'll add that I've encountered big issues onboarding teams of imperative style engineers with functional codebases. We've spent lots of time and money unwinding and rewriting code for this reason. In my experience, oo / imperative design is just more accessible, as you say, better aligns with human reasoning. I like a lot of what fp has to offer and _actively_ incorporate concepts, but it's often been an impediment to my work.
The last part of the video sounds like Erlang and Elixir (which is also based on Erlang and runs on Erlang VM).
The primary idea of OO being primarily about messaging was exactly how it was taught to me in college circa 1990.
Yes, I did something early in my career thayt deeply ingrained that idea. I was involved in build a system that was deeply OO, but not at the language level, it was very enlightening.
OOP is not about messaging. That came from Smalltalk and it's just not how people understand and use OOP today.
@@Christobanistan The butchered understanding of OOP today and what OOP was intended to be are two almost completely different things
@@warferton6429 It's not "butchered," it makes complete sense.
@@Christobanistan 7 levels of inheritance in some Java modules makes sense to no one.
The message based paradigm sounds like the actor model. Take a look at the Pony language. It also attempts to be mathematically rigorous.
@FichDich InDemArsch interesting. I have only read about it myself.
...or maybe Akka? granted, it's a library for the JVM but written in... Scala.
As a relatively newb to programming, this was really Insightful to me. I'm sure it'll allow me insights into the way I'm coding in the future. Thanks!
Why not both? In college, in one of my Computer Science classes, we used Dylan, an object-oriented functional language (loosely based on Scheme). I found it to be a very elegant and enjoyable language to program in. Sadly, it's not a language that's much in use outside some academic and personal projects... :)
Great video!
I agree with most of what your saying, and I believe that each OO and functional paradigms bring positives to any project.
I've had a great experience using them both with the language Clojure.
I don't think any other language lets you use these two paradigms in your own way.
I like both functional programming and object oriented programming. I think both are valuable in different situations. It’s also possible to do both at once, especially in Scala.
Yes, I think that is probably the most accurate description of my programming style too, but for me the FP part is probably kind of "FP-Lite".
really enjoyed this kind of content - a bit philosophy, a bit theory. really good stuff! thank you!
OOP was a game changer for me. When it finally dropped all my programming woes disappeared overnight. I just love my C#.
whichever system groups that which needs to be grouped, and separates that which needs to be separated in order to make maintenance and modification easier is the preferred system
for certain things that's OOP, for others it's functional, for some it's AOP. for others, something else.
whichever one satisfies the stated condition that makes the maintenance and modification easy is the right one for that project.