Recorded live on twitch, GET IN / theprimeagen Original: • Functional Programming... Author: / @continuousdelivery MY MAIN YT CHANNEL: Has well edited engineering videos / theprimeagen Discord / discord
This is from an article written in the 80s. It was pretty on point. "What is object oriented programming? My guess is that object oriented programming will be in the 1980's what structured programming was in the 1970's. Everyone will be in favor of it. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is" - Tim Rentsch
The problem is, that humans are "not dumb" . Code syntax is "fake", map and for loop returning the same physical electron through transistor sequence, the only reality is the movement of the electrons, the rest is just speech. The problem is, that between procedural code and declartive code, some code will line up with direct logic, and some will be abstract. To the uniniated this creates confusion, especially people that are smart and logically minded, they must understand that a coding language depends on subjective notational choices made by the language creator, and this naturally moves through into abstractions, paradigms and frameworks.
It's funny to watch you interpret everything Dave says completely differently than me. Like, when he said 'model your problem', I didn't even for a moment think he meant 'ahead of time' or 'at a white board', but rather just that object models align to real world models very nicely in some domains (e.g., user interfaces). Similarly when he said that mapping is almost always slower -- I agree. You have to measure. If you map everything by default and try to parallelize it all, you are likely spending more time in joins. The exceptions are important performance cases but you have to measure. Always measure.
This guy doesn't understand what he's talking about, when he mentions side effects in haskell or closure. Side effects aren't the point. Of course there is io in haskell and closure, the point about side effects is that your functions will always return the same out put given the same input, and that always happens (at least in haskell) unless there is some sort of bug in the compiler. Of course you can get side effects if you start doing shit like calling unsafeio, but that's missing the point. Of course you can get the job done however you want using oop or fp, but again that is missing the point. Its also missing the point to say which is better oop or fp. This is an argument purely about style. Honestly, however, I wouldn't even make the comparison between oop and fp. OOP is an amorphous concept, where fp has a clear definition--you're attempting to get as close as you can to lamba calculus in a programming language. OOP is way more amorphous, vague, and too many people disagree about what it means. The real distinction here, in my opinion is an imperative programming versus declarative programming. That's a much more sensible topic talk about.
Introducing side effects in Clojure is super easy. Clojure is an impure functional programming language. I agree the CD guy just goes on without much knowledge.
I usually stop watching any video on FP when they never mention how much experience they have doing FP. It’s always an OOP user describing what he thinks FP is rather than knowing what FP actually is.
18:00 "Proof of concept, learning from it, and building the final product". Open a 50 year old book (Mythical Man Month) and you have a full chapter about it called "Plan to Throw One Away". It is always crazy to read old things like that and see how most of software managers have not learnt anything.
Software managers learn with experience. The problem is that they inevitably get replaced with more inexperienced software managers when they become older.
I've been developing for over 30 years, and you would be surprised how many times old ideas come around with new names, as if no prior art existed. Usually, they suffer the same pitfalls too. I'm also suprised how few devs bother reading some of the classics of the field.
MBOP (Mudball Oriented Programming) is the best. Because in your heart of hearts you all know that is what you have to maintain... so may as well love it ♥
When I did parallel computing for uni, I was taught that parallelising is almost always faster given a large enough dataset. An array with 1k elements, it would be faster on a single core utilising the L caches. 1bil elements, it would likely be faster if it was split to the number of cores. And if you have to search, you might as well search in the parallelised code as well, why wait until it's joined up again.
“Our goal is that applications run 0.75 x N times faster on an N-core computer. In this talk I'll explain how we do this.” Joe Armstrong: How we program multicores (2016)
I actually wanted to blog down this, but there are sub-linear cases where parallelization is really not helping. Not because of the semaphors and overheads, but because there "divide and conquer" starts to be worse than "unite and conquer".
@@SimGunther Not only limiting to like 2 numbers instead of a million (albeit bitwise you can still parallelize, but lets suppose addition is atomic) - But for starters try to parallelize logarithmic search efficiently ;-). There are borderline existing ways to do that efficiently because it is sublinear. I choose this for the simplicity. Think about the following: If you have 1024 elements to search between, you get your result in 10 steps (at most). How long it takes to search the element in the top 512 part of the array? 9 steps. So if you "divide and conquer" the algorithm and do it (non-parallel) how many steps you should do on the lower and upper half added together? 9+9 = 18. This is counter intuitive. Usually divide and conquer (block processing) like that even makes your algorithm faster even without multiple cores. For example if you take an O(n*log(n)) solution to some problem. You could save time if you could reduce your problem to two smaller calls and somehow (in smaller time) merging or choosing the result... That would give instead of 1024*10 (10k) a solution in 512*9+512*9 steps which is around 10% gain even on a single core. Also you likely see that you can parallelize and do the halves on separate cores.which adds an extra halving of the runtime. The worse the problem away from linear, you get more speedup even by simply doing the divide-and-conquer even on a single core like it is really measurable in O(n^2) cases. Okay... Now back to parallelizing the binary search.. - As you have seen above, running binary search on smaller blocks (on single thread) takes not really so much smaller time. Compared to 10 steps, you still need 9 steps here when making a smaller working set from 1024 to 512 elements. - As you have seen if we do not start two threads, the whole operation now takes 18 steps instead of the original (at most) 10! - Now here comes the issue: the two threads you start on the data would in theory only make a 2x speedup if there is no communication or any overhead whatsoever... nothing whatsoever! Basically this means that in practice you would be nearly the same amount slow - or very tiny bit faster... at the cost of cores and stuff. You might think "hey, but why not add more cores?" then you should realize that those cores also need to work on smaller sets, then collect the result - so in that case you end up - lets say there is 4 cores - at 256 element arrays to search your key and 4 of them with 4 processors. The logarithmic / binary search on each processor again takes 8 steps: that would be 8+8+8+8 = 32 if done on a single core... the 4 core speedup gains a theoretical 4x speedup to you so you get like 32/40 runtime of the original IN THEORY. Now this is O(log(n)) surely this not work for O(1) tasks so well (but I really hope you do not want to start threads for a lot of O(1) tasks) and there are other sublinear runtimes like O(log(log(n))) and stuff which becomes really hard to parallelize. In my experience, the "practically somewhat still parallelizable" lies somewhere exactly at O(log(n)) sublinear but anything more faster single threaded algorithm is basically impossible. And to be honest anything that is sublinear is usually very bad anyways and a better algorithm is needed in order to parallelize. Oh... and if you have some tasks that you can do in "some part, then some part, then unify/found end result using the sub-oprations" (that is it is divided) - then you better "Unite and conquer". The rule of thumb is: - Simple ones: unite them and conquer - Complex ones: divide them and conquer Most people only know the latter.
"Academic masturbation" is such a great term for this unquestioning acceptance of a few research papers on hard to measure topics. I was especially peeved when he kept using some research papers to conclude that pair programming is objectively the best way to code.
the masturbation can be 50/50 the academic papers have proven that scaling agile is difficult and have also shown that a more planned approach or waterfall approach is better.
What confuses me is how unquestioning rejection of those same papers is any better than "unquestioning acceptance", when the only counter being offered is a vague "oh this thing is so arcane and complex that nobody could possibly reliably measure anything about it". Using "some research papers" to conclude what the best course of action might be in any given scenario, seems to me a more substantive method than unverifiable anecdotes.
@@robertgray4961I think taking "anecdote" from a pool of accomplished people is better data than most of these papers. You literally have continuous delivery trying to cite a paper where the majority of participants are junior devs (even students!) working on simple projects. Also, you can find other research papers on functional programming that indicate there are fewer bugs... should continuous delivery see that study and just say "well I guess I was wrong!". Obviously not. A non-replicated, small study should not be weighted above expert opinion.
Stateless functions are good because it's easy to check for errors, find bugs and overall understand what a function is doing. Function that accesses global or even instance variables can be much more difficult to understand.
That's hard. You can make FP much easier by wielding globals/lists/mutability. 🤣 OOP is when people took that route rather than learning. Inheritance is when people took the easy route of OOP. And then keep abstracting until the confusion from the current way of doing things far outweighs the cost in learning a better way.
Depends. In my Rust backends for web, I use a global static to represent a thread-safe database connection instead of using a pool (which btw would also need to be initialised somewhere). So no, making static variables like that can actually make it easier to write your code, and also read it. But that's not OOP.
I agree with the overall take, FP is no better than OOP. However, a language which does not support functions as first class citizens is a bad language.
@@mynameisnotyours Recursive functions are not massive footguns? Decorator functions to extend functionality aren't footguns? The way I see it, they have the same footguns, just different syntax.
You can decorate class methods in languages with decorators. (In JS, you can only decorate class methods. (For now.)) You can write recursive class methods. All footguns, to be sure. No this pointer reference: -1 footgun Can't inherit functionality automatically: -1 footgun Don't have to overwrite inherited functionality for custom functionality: -1 footgun That's 3 less footguns in seconds of thought. @@CottidaeSEA
@@mynameisnotyours Functionality is inherited by function composition, literally one of the core components of functional programming, is also far less restrictive and volatile than extending a class. Function composition is also the same thing as decorating, that's what decorators are. So again, that's just something that exists by the very nature of how functional programming works. For custom functionality you would use an interface or an abstract method in OOP in which case there would either be no standard implementation or a barebones one just to not break shit. So that sounds like a skill issue and a lack of understanding of your available tools. Also, functional programming once again solves this by function composition. So in a way there are fewer footguns, but instead of a pistol you have a shotgun.
Procedural is the only paradigm which matches what the machine actually executes. OOP and Functional are just abstractions above procedural and are up to the compiler in how they're implemented and their expected performance
If-Then-Else and functions are just an abstraction on call/jump/branch/ret instructions in assembly code. What you might be referring to is imperative programming.
C & Rust are closer to Java & Python than they are to assembly. It's all abstractions. The only time there's a close mapping between what you write and what machines actually execute is when you've compiled it with `-O0`, i.e. your procedural code is still ass if you don't let your compiler turn it into something incomprehensible that somehow runs 50 times faster.
Rust's traits are very similar to Haskell's type classes, which is considered a functional programming language. Rust's algebraic data types are very similar to those found in the ML family of languages, which are considered functional programming languages. With these features Rust leans towards the functional programming languages. However, the idiomatic style of programming in Rust is mostly procedural. It is common in Rust to express how a certain algorithm should be executed, while the ideal for functional programming languages like Haskell is to express what the algorithm should accomplish. The emphasis in Rust is also to safely mutate state, while in functional programming the emphasis is on immutable state.
I would definitively say that Rust is FP because it doesn't glue code into data. OO basically glues code into data, even thou it originally was supposed to be about dynamic dispatching (message passing). Another good thing about not being OO is that you don't pay excessive double-jmps and VTables, (unless you used too much closures, but compilers like closures, they can easily inline them, you can't inline an object) Ironically its OO that makes Java and C# not be as fast as C++, its not the JIT compiler, and its not the Garbage Collector, no, its excessive dynamic dispatching. People have this wrong idea that GCs are slow, they aren't, its just that OO makes you allocate thousands of objects, even if you manually allocated them (and leaked most of them, lol), it would still be slow.
@@monad_tcp Interesting points. If not "glueing code into data" makes a language "functional", then by that definition, COBOL is a functional language. None of the languages that came about in the last 25 years has strictly adhered to one paradigm, and that makes sense. If you want a purely procedural language, why use anything other than ALGOL-68 (or one of its immediate derrivatives like PASCAL or MODULA-2), If you want a purely functional language, why use anything other than ML, or Haskell (if you prefer lazy evaluation by default). If you want a purely OO language, why stray from Smalltalk? All modern languages, and additions to existing languages have a multi-paradigm flavor. Rust can do dynamic dispatch like OO languages. It supports higher order functions like functional languages. It also support ADT's, which is also present in purely functional languages. However, it does have control flow (if, while, for) that puts it squarely in the procedural corner, and it doesn't (yet) have tail call optimization as a first class citizen, making recursive programming not a first choice, like it would have been in ML or Haskell. What the last 25 years has shown us, is that a good balance of various features is preferable over paradigmatic purity. The only stepchild that has not yet been fully integrated in most languages is logical programming. There are prolog-like libraries for many languages, but apart from Oz/Mozart (which is very much a niche language), it hasn't found a strong foothold in multi-paradigm languages.
@@nielshoogev1 Even Haskell isn't actually completely pure in practice. Simon Peyton Jones has described it as the most beautiful procedural language, due to the specificity of where side effects/mutation can occur.
I just wanted to add that UML diagrams aren't great for building code, but can be good at summarizing code. I wouldn't want to plan out my code with UML, but if I'm asked to create a visual representation of my project, UML isn't a bad way to do it.
@@basilfeitknecht6430 It stands for "unified modeling language". It's a notation for expressing classes and the relationships between them. You could almost think of it as pseudo-software.
UML is agnostic towards how you implement what you describe. That's why you won't find any translation from UML to any programming language. It's really, as the name says, just for modeling towards human brains to understand.
if asked to create a visual representation of your product you are either a) in university being taught by fossils b) taking to the product level of the team and really what they want is a user flow diagram. UML is pure trash for anything.
@@Friskni Neither but pseudo (a). Most common case is for academic papers. I would say that a lot of the downsides to UML don't apply as much to academic papers, which is why it's still used there.
I kinda feel as if the line where you're veering into OO territory is usually when you start associating functions with objects exclusively, as in "this function is specifically just a thing this one object does". At that point, you have essentially "oriented" the logical module around the object rather than the function existing purely as its own machine with specified inputs and outputs.
I do like this definition. I would broaden it a bit, to not use the term "object", but thing. That thing can also be a trait in my mind. Yeah that goes against the often quoted definition, I don't care.
Rust is multiparadigm. You can do OO for the most part, but it doesn't have inheritance (which to me is a blessing). Structs + impl can somewhat act like a class, and traits are somewhat equivalent to interfaces. Of course they're not exactly the same, but I would still consider Rust to be mostly capable of OO.
Just wanna put it out there, my company spends about 6 months in writing UML with plantUML and when we finish designing the UML, the requirements usually change and we throw everything we did in UML and start writing code.
I think advance planning (e.g. DDD) and diagramming (e.g. C4 modeling w/ UML) are best used when building a _replacement for a legacy system_ with a stable and well-understood domain & scope. Solving a _new_ problem is a different story. Lots of people here are only thinking about these questions from the perspective of building new systems. I think we need to hold this type of bias in our field of view when discussing sweeping ideas of how software design ought to take place.
@@tantalus_complex 100% Agree! We are currently replacing a decade-old legacy system and none of the original Devs are around. Whiteboarding as we read through the code, talk to different departments, run though the system, and testing new code has proven to be a time-saving approach for us. This method has not only streamlined the process but has also unearthed numerous gaps in our understanding of the software and its ultimate goals. In addition, the original team decided to transfer the SQL DB to a NoSQL DB without changing the data structure, which over time has crippled the performance of the software. Whiteboarding all the relevant tables and stitching together new and improved NoSql Document Collections has been quite the undertaking. With all that said whiteboarding can be simple or complex/detailed (UML tends to get too granular). I would try to stay away from complex/detailed as often as possible, due to inevitable changes but keeping things simple, taking 10 minutes to jot down notes, and if needed doodling the basic flow has been helpful for my team's communication. @sortof3337 6 months! that's ridiculous! It sounds like your company is using the Waterfall Method version of whiteboarding! they should move to a more Agile Approach.
I like to put spaces in between my arguments AND before the parenthesis! its a little known fact, but function arguments can and do experience claustrophobia just like we do, and I believe it is unethical to force them into such confined spaces. They have evolved for life in wide open pastures , where they can use their wide-angle vision to detect and respond to predators. When we don't give them enough room they become anxious and this can lead to unexpected null references.
18:13 I think the best use case for UML is after the project has been made. It's useful as documentation of how a project is structured for helping new employees/contributors. Solving the problem itself? No, I'm with you on that one
UML is what you invent if you need to draw the structure of what you design in your mind in the first place. It can be a nice tool for more complex structures that you can't keep in your head for long. It can also help in solving certain problems that require a more system view on the design. For documentation purposes, it may be helpful for others, but it's not really the what it's supposed to be used for.
I'd love to see you try out F# (or OCaml). F# is very similar to OCaml but does bring a lot of OO functionality with it from being a dotnet language, which can make it easier to give the whole functional thing a try without having to dive in too deep immediately.
Can't speak for F# or OCaml, but at least with Scala I feel like combination between FP and OO and the JVM is pretty awkward. Still an improvement over Java, but it feels way more like Python but with types than less compromising functional languages like Haskell, Scheme and Erlang.
I stayed with F# for the FP, but I like its approach to OO way better than any other language I've tried. In my experience, you can get the best of both worlds in F# by using classes for small-ish objects while using FP for the actual workhorse code.
6:54 you could probably do currying with anonymous classes. It looks like local variables in scope can also be returned, so it’s basically a closure too. But just generally, creating a class or stuct is creating a closure over its field/properties, the benefit though is that classes and structs can have more methods, where as what people traditionally think of as a close is just a single method.
Side effects are definitely done in functional languages, just that they are done at the edge of your program execution(the main function). You do declarative programming dealing with immutable, composable data structures most of the time which keep your mental overhead low. It's just a matter of how easy a functional language makes you do side effects. Scala's ZIO framework has made that happen.
There is absolutely 0 evidence that immutable, composable data structures keeps mental overhead low. This is just a claim that FP advocates keep repeating over and over again. This is just argument ad infinitum. So on a rudimentary examination of the claim: If a paradigm is "low mental overhead", then an emergent property of that is that we should observe fewer bugs in programs built in that paradigm. And yet, the measurements all show that this is not the case.Programs written in pure functional programming languages tend to have the exact same, or **more bugs** than programs written in any other procedural or OO managed language. Reality is at odds with the claim.
Rust's struct methods ARE functional, because Rust impls are just a convenient way to access functions that happen to take the struct as the first argument. that's why you put "self", or "&self", or "&mut self" as the first argument in a method. you can call any method as foo.themethod(), but also Foo::themethod(foo) The thing that makes Rust less functional than a pure functional language is being able to mutate values.
Immutable data is the entire point of functional, in the same way that the entire point of OO is data encapsulation. The difference between the two is really how they handle state and make state simple. Rust is really just a pragmatic language. I jumped in as a mostly functional programmer and very quickly found myself writing very OO code because it was the simplest way to get the job done.
“Rust is influenced by many programming paradigms, including «OOP»; for example, we explored the features that came from «functional» programming in Chapter 13.” The Rust Programming Language (Chapter 17) At the core Rust is an imperative programming language. However through clever language design a lot of idioms typically used with functional languages can be leveraged in Rust. In Rust the concept of ownership fills the role that immutability has in functional languages.
For the EventEmitter example, remember, replace inheritance with composition. Just have an Event type that wraps a listener list, then expose that on your type: struct Rectangle { pub resized: Event, ... } I've both done this and seen this in other's code in JavaScript, which already has (two!) event base classes. In Rust, I don't know how you would have typed arguments without doing it this way without some terrifying type id hackery, which doesn't seem worth saving the pointer per event.
I write with an OOP approach and i support my classes worth pure functions as defined by functional programming, I do both. This better or worse approach to the entire concept to me is extremist madness. You can code in both at the same time.
I think that's the biggest difficulty of the question. They are not mutually exclusive, but the British guy is debating (attempting to) as if they are.
@@g3ff01 yeah he completely misinterpreted what the guy said. Godot is a perfect example of what he is saying. Scenes and Nodes in Godot are essentially analogous to pure functions if you design them correctly. It's such a robust system that combines declarative, functional, and OO programming in one package.
Obviously, when it comes to writing code, both OOP and Functional try to solve essentially the same problem, you can do everything in assembly, design however is different than actual purpose that the code serves. My take is that when it comes to design there cannot be one best option, there can be options that are better than others, but we cannot find the best one. So now I can say that the paradigm is a tool, Functional and OOP are there so you can use them to design your applications and libraries, when it comes to choosing which paradigm you should use, maybe instead of asking which one is better objectively, you should look at which one will serve better in terms of designing the application/library you're working on. And yes there's stuff that monads just cannot express as good(key part: AS GOOD) as classes, and I think that's fine. When it comes to putting the line between what is considered OOP and what isn't, I don't necessarily have a strong opinion on that matter, and in fact C can achieve much of what classes generally do(inheritance being a bit more challenging). There's a lot of "GOOD" design in OOP and there's a lot of "GOOD" design in functional.
The EventEmitter thing could easily be solved in Rust by using a trait and only having a `get_the_thing` required function, this is generally what you would do if you "need" a property inside a trait, just require a getter and maybe make that trait derivable if you don't want to type out the getter.
To address the video, why not just put your type in an EventEmitter box? There's no point in pretending that the data structure itself is the emitter. Generally favouring parametric polymorphism over subtype polymorphism. I'm not particularly familiar with rust traits so I don't know what kind of polymorphism that achieves.
On the note about UML diagrams (and similar), my experience has always been that programmers are shit at drawing up diagrams because they're shit at explaining things, but I have (after having done it several times) found that with practice and a good understanding it's definitely possible to draw up diagrams which are useful in some way, usually for really high level things like documenting the overall processes in a system or the overarching database architecture. I've made these diagrams before and shown them to people and they absolutely love them because it really helps understand the big picture. And then I see other people try to make these diagrams and I'm like "this is complete shit, it's like that high school essay where you just incoherently wrote down everything just to satisfy the requirements". Having said all of that, I still think of all of the diagrams, UML diagrams are still one of the most shittiest. Way too much detail in them for high level explanations. Dependency models are way better for covering the important part which is the model dependencies while keeping every high level with the business logic.
UML doesn't require anyone to provide more information about (say) a class than its name. Other details are entirely optional. Even the lines drawn to show relationships between system components don't have to show anything more than mere correlation. A single named box is a valid UML diagram - even without a second box or a line of any other detail inside the box. And any line you do have can be as unspecific as the vaguest correlation. Like computer displays, diagrams have a "resolution." The higher the resolution, the higher the detail. Rarely will a team have a diagram at hand with just the right resolution for every need. So not only do most teams not create several resolutions of the same system (no judgement here), many questions are going to be far more narrow in scope than a common diagram. So it is no wonder that we often feel that they are "a lot to take in." But this is partly a problem with human psychology, because we don't raise a similar complaint about documentation (as often). And diagrams are just another form of documentation.
Yes, its a tool. Languages are tools to express and communicate. Methodologies are tools to solve problems. Some problems naturally lend themselves to be easier or faster in one particular methodology or the other. Odds are like most programmers you are multi-method and at your level you implicitly know certain areas where you use them. For instance, an iterator (particularly the notion of method chaining) is functional methodology, and it suits itself well towards aggregation and transformation tasks, its a tool for providing you you reusable and composable transformers. Traits (rust) Objects (js), Classes/Interfaces (c's) are object oriented, and is a tool for giving give you reusable and composable object behaviors. And imperative is generally glue code, because either a functional or object orientated language requires an imposed structure to have any effects.
My problem with the 13:06 functional style code is that, we have to understand the internal of the map function to understand if it is 1) just a rewriting of a loop or 2) a parallelized version of the loop. This makes huge different as in the example, where the mapped function has a printing side effect. And for printing, the ordering matters. We don't know whether the order is guaranteed or not.
12:00 I think, you completely missed the point in the video by replaying a tiny part of it. He is talking specifically about automatic parallelization, that only is possible in PURE FP languages. Immutable data + no side effects in FP languages means that you can (for example) compute multiple arguments concurrently, so add(foo(...), bar(...)) can automatically compute foo and bar in parallel. This kind of parallelization genuinely doesn't work well in most cases because it is too fine-grained. You end up spending almost all time on "deciding what to do next", context switching, waiting for stuff etc etc. This is in contrast with "structured parallelism" where you manually/heuristically determine a few specific places in your code that are especially suited for parallel computations (often, this is done ahead of time) and only use parallelism in those places.
Honestly Prime, as long as you haven't even picked up learning a language like Haskell or ML, I can't take take your opinion too seriously about functional programming. "Functional programming" in languages like Typescript, Rust, anything not designed as legit functional.... just doesn't cut it.
What does "True Functional" mean to you? Does it have to be immutable everywhere? Does it have to have a strong type system? For me, for example, Lisp is just "toy functional", even though historically it's one of the foundational functional languages.
@@rogergalindo7318 What's so special about Haskell? My personal problem with Haskell is that the so-called denotational semantics is more like operational-in-disguise. You constantly need to think "But which way will it reduce?" if you want your program to terminate in reasonable time. I would rather specify all the computation steps myself, imperatively, while having a strong type system check my conclusions - like in F# or in Typescript.
I was traumatized in uni having to write a non-trivial program in Haskell. It takes a certain kind of person to enjoy writing code like that. Rust just takes some functional concepts without sacrificing on practicality. Argue all you want about the beauty and different style of thinking etc, never clicked for me personally, the language was difficult without solving any useful pain points for me.
@@moodynoobuse it to solve a maths problem maybe it might stick then. Trying to find Pythagorean triples between 1 and 10 in Haskell is one line that I can write the set builder notation for. Trying to do it in any other language is a hassle.
Haven't seen the whole video, but pure functional programming languages are way better for some usecases, like fomal code verification and correctness. It derives from lambda-calculus and you can't express computationally the "category theory" principles using OOP. Or at least not in clear way. PS: Prime, learn Haskell please, i agree you're lacking the knowledge of using a pure functional programming language like others stated. You can even peer into category theory to see why its fantastic to express mathematical reasoning and come up with much more reliable programs in terms of what they should do .
as a sidenote, you don't really need (and probably don't want for your own good) to learn category theory in order to learn haskell. the basic "mathematical" mindset is more than enough (mainly being able to reason about what your program does & proving that your monad instance is a true monad lol)
@@kalamasin i think meant that one thing you can do with functional program is to translate formal methods' requirements to a computational representation, which is impossible with OOP, so it doesn't make much sense to say FP is worse than OOP.
@@kalamasin i was explaining why i think there's a special place for FP, and why it doesn't make much sense to compare with OOP, not saying one shall learn first category theory. Monads are in my opinion easy to understand once one deals with functors for example. But yes, you don't need cat. theory. But i think its awesome though :)
Stumbled on your videos, you've got a great attitude and takes on things. So thought I'd weigh in with a few opinions, having experience with both OO and Functional programming. I've been doing a lot of functional programming in the Scala programming language for the last few years. Originally having learnt C at university and doing a lot of both Java and (pre-JQuery) Javascript work since 2012. Scala is a language with all the bells and whistles, it's got OO but functional code is first class, and its type system encourages composition over inheritance. I struggled at first switching to the functional paradigm but it really does help with a lot of the problems I deal with as a Data Engineer. The more OO aspects of it are what makes testable, and more maintainable code however. Even then, larger code bases still suffer from the same old issues with refactoring (there's no panacea for this from my experience). And an issue with Scala (and other functional languages and frameworks) is the obsession with super terse code. This isn't a big issue in plain Scala but it is much more of one in many of the frameworks written for it, that is: employing all sorts of weird symbols to mean various things. This has led me to the belief that operator overloading should be used sparingly in any language to avoid the hell of figuring out what all the different combinations of >| |< >>
The funny thing is this is the point the video was trying to make. It is a false dichotomy between the two but he seemed to miss it because the guy said he had less experience in functional.
On vectors, sets, etc... all one needs, is a starting address, a type and its size, an array, the size of the array, and index into the array, and an offset to the data within that array. With that there isn't much that you cannot do, now if you don't know the size of the array then it becomes required to create it dynamically and this becomes a vector or a set. If you don't know the type and its size then this is when it is required to have the ability to have generic programming. As for the index and the offsets, these can be abstracted out with the concepts of basic iterators. This is why C++ std library is so powerful with its template features. #include std::vector my_vector_of_ints { 1,2,3,4 }; std::vector my_vector_chars{ 'a', 'c', 'e' }; for (auto i : my_vector_of_ints) { // do something } for (auto c : my_vector_chars) { // do something } Without templates for creating generics and abstracting iterators out of the class container these structures would look like this: class my_ints { int* data; size_t size = sizeof(int); size_t index; size_t count; // member functions here }; class my_chars { char* data; size_t size = sizeof(char); size_t index; size_t count; /// member functions here }; for (int i = 0; i < my_ints.count; i++) { // do something } for (int i = 0; i < my_chars.count; i++) { // do something } This is why I like C++. It is multi paradigm where you can borrow concepts of Object Oriented Programming along with Generic Programming to give you the versatile STL all while maintaining the core concepts of being a very efficient language (you only pay for what you use) with its strongly typed compiled ecosystem which at runtime is still considered a procedural language. So there are benefits of Object Oriented Programming as well as Generic Programming when done properly and I think the STL within C++ illustrates this. We don't have to create the same kind of container for each of our objects or types everytime we want a collection of them. We can just simply use the template libraries that will work on any type. And the way the STL is implemented, iterators themselves are abstracted away from the containers but will work with any container that provides a begin and end pointer or iterator. This is why I like multi paradigm languages. You're not bound to one specific methodology of solving a particular problem. You have options to be creative!
One line you can distinguish between object oriented by the c# crowd is that you are mixing data and behaviour inside a single instance or I should say a class. Methods are functions that are inside a class in classes also contain data types. You can call on methods to do operations within that class. At the same time there is no pure Functional programming that is practical. You cannot have pure functions because functions that do something useful have side effects. If the language is pushing you to use objects and pushing you to use instances and also the requirement to use singletons like that is something special then I think that is an object-oriented language. Another defining feature of object oriented languages is that they want to abstract multiple layers, As we have seen by the fizz buzz enterprise edition
Please do more reacts to this channel. He's a very senior dev with an incredible amount of experience, and he's obviously very intelligent, but I often find myself(much more junior at 11 years now of prof experience) disagreeing with his opinions. I'm genuinely curious to hear your opinion on more of his takes.
Please disregard most of what that guy says. He is an old-school guy who repeats what he was told. He could not properly define OOP if you asked him. I doubt he knows who Luca Cardelli is.
I use inheritance by extending an abstract class that implements an interface. The abstract class can be used to have some default implementations / helper methods.
43:16 i wonder everytime in my final git commit how i wrote only two lines of code at the end. while the process there was creating bunch of files, removing code and moving files around. so if you do not commit every change and only the final working part, you might look like you do more work with thinking rather than coding. since the final part of code is acutally not that high
Rust is a bit special, but I think it has more functional than oo components. I heard from Haskell programmers that they easily adopt the concept of Rust, while imperative/oo programmers usually have massive problems to learn Rust.
35:45 - No? I've been programming in Haskell for some time and that statement is just naive and missing the whole point of functional programming. As the software grows year by year, the code design and principles can change, people come and go and the code rots. When you've got something in the compiler which makes the whole principles mandatory (otherwise it doesn't compile) the core code design pretty much stays the same. There are also so many things where OO programming languages copy from functional languages like pattern matching, first class functions and high order functions. I love functional code because it has many features which OO can't even dream of (MoNaDs,Arrows, Liquid Haskell, Strong Type Checking, Template Haskell - like macros but type checked at compile time + intellisense support). The biggest downfall of FP is insane learning curve.
43:10 The days or even weeks I'm spending in state "I'm thinking more than writing the code" is when there are no good solutions given the existing infrastructure and the task at hand. Only multiple options to proceed but each with various obvious con-sides. In practice, in that case "thinking" is about going through existing programs (searching for something similar and looking for results with pros and cons any given solution had), implementations (typically reading code of some open source libraries to understand how they handle the problematic edge cases), research papers, writing some test code etc. That's the "research" in R&D. I have trouble imagining a coder that just sits there meditating and coming up with a good solution they will finally write. Some call this maintaining a legacy system but I think it also covers making any complex changes to any *big* system, not matter how old or new the code is. Legacy systems are just typically bigger than newly created (toy?) projects. And you get old hairy legacy systems as a result if you repeatedly try to skip the thinking and research part and always go for the most simple solution you can think of without thinking about the con-sides. Basically: how much technical debt your next change is creating to the whole system? If you ignore the debt, making changes is faster but it will bite your ass later for sure. On the other hand, you don't want to waste time trying to create perfect solution either because perfect is enemy of good and it requires insane amounts of time to create perfect solutions.
Hey Prime, can you check Bevy Engine's systems work ? You write a function and put in any argument of any type in any order. Then add the function as-is to App and the bevy runtime automatically knows what arguments to supply it to. Can this pattern be repeated in other languages.
"anything you can do in OOP you can do in FP and vice-versa" is just a fancy way of saying: 'You can do everything in assembly, therefore paradigms don't matter'
22:00 Encapsulation has always been weird for me. Like if I make a js module that exports something, anything not exported is "private". I'm encapsulating data/behavior without getting near OOP. In a recent code review my tech lead said "why is that function outside the return statement (of the module in review)", I said "because I don't want to return it" and it got approved lol. Like why would I return an auxiliary function only relevant in the context of this module internals?
Immutable data structures, when properly designed need not do a fully copy of the whole data stucture. These kinds of data structures are called persistent data structures. In Scala, val list1 = List(1, 2, 3, 4) val list2 = 0 :: list1 We created a list1 and created another list by appending 0 at the head. The second list is not a copy of the first list. There are just two pointers maintained, one pointing to 1 and another pointing to 0. This is a simple example, but can be extended to complex data structures like trees. And using immutable data structures surely help you reason about the code, since your peanut brain doesn't need to track mentally what changes happened to that data structure. Scala, tho, offers you both sort of data structures, mutable and immutable.
"immutable data structures / persistent data structures"... no, they are, just like you briefly mentioned, just two pointers pointing to the same memory location. Nothing more nothing else. I find it fascinating how you people feel the need to rename simple concepts invented multiple decades ago and make them sound like some fancy out of this world thing.
for me, the real comparison is OOP vs Data oriented makes more sense.. I find it makes more sense to reason about your code and design oriented around your data, and how you manipulate and deal with your data rather than trying to force your architecture and design into poor abstractions of real world like objects. I just naturally end up almost never using classes or object oriented ideas simply because most of the time what I want to do is to have data structures that accurately model the actual data, instead of forcing the data into an abstraction, and my functions and methods is all about manipulating, reading and storing the given data I'm dealing with.
Data oriented is literally the best for performance. It's just the class of engineer required for it makes businesses think that have 5x engineers that OOP is cheaper
@@adama7752 They're not talking about the same data oriented you are. Functional Programmers are attempting to co-opt the term for themselves. You are talking about how you structure data in memory, Alexander is talking about managing data transformations by invalidating your cache and doing everything your computer doesn't want you to do for performance.
@@phazechange3345 I am? Im surprised thats what you got from my post. I'm not a functional programmer in the sense of someone that is dogmatic to only using pure functions etc. I was just arguing for the fact that we should probably look at OOP vs Data oriented design instead of OOP vs Functional, especially in the context of debating whether OOP is good to use or not. Since OOP is the dominant paradigm in the industry that's usually what we are really doing anyways.
@@apresthus87 “Data Oriented Design“ was claimed way back in 2009 by the article “Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP)“ by Noel Llopis. Have a look for the “Data Oriented Design“ Resources repo by dbartolini. According to Richard Fabian's Data-Oriented Design book it aims to arrive at an optimal machine representation as opposed to an optimal human-oriented representation of a solution. In the gaming industry this gave rise to the ECS architecture (Entity Component System). Since about 2020 Yehonathan Sharvit has tried to claim the “Data-Oriented Programming“ moniker for Clojure Programming, probably piggybacked on Rich Hickey's notion of “The Values of Values“ : Imperative programming describes the "flow of control" (think flowcharts) where program execution moves computation forward by manipulating values in place (PLOP - Place-Oriented Programming) Functional programming advances computation by creating new values through the transformation of existing values (value-oriented programming). A functional program's description focuses on the “flow of values“ (not to be confused with dataflow programming) rather than the “flow of control“ . Your use of “Data Oriented“ seems to just refer to: “Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious.“ Fred Brooks, The Mythical Man Month (1975) Which is one part that hasn't aged particularly well about that book. Sam Newman (2015): These capabilities may require the interchange of information - shared models - but I have seen too often that thinking about data leads to anemic, CRUD-based (create, read, update, delete) services. So ask «first» “What «does» this context do?”, and «then» “So what «data» does it need to do that?”
Re when to just think and not writing code: I tend to do this when I want to change a core business logic in a system which got different requirements (brownfield). I'm trying to figure out a way to create a minimal diff to transform a code to the new requirements while also making sure no dead code or unnecessary complexity is left there. I could try to immediately transform the code first, but in my experience that results in a larger diff which is harder to review and reason about. So I tend to make a plan first in my mind, then start executing it. This usually just takes a few minutes (or a few tens of minutes) though.
I'd say Rust is a mixture of functional (first class functions) and procedural with a sprinkle of object orientation syntax. Haskell also has traits similar to Rust (they call it type classes), but its not `object.method(arg)` syntax, but just `method object arg` as with normal function calls. Otherwise I think they pretty much work the same. (It's a long time since I used Haskell in two university courses.) I don't think traits and dynamic dispatch are enough for it to be object orientated, it needs to have sub-typing of actual types, not just between interfaces/traits. Also note its sub-typing, not necessarily inheritance, but the two usually come together. But that is just my take on things. Don't know what textbooks say on that matter.
I think broader design principles matter more overall and to that end its worth looking at a range of paradigms. Sometimes, objects (or at least structs) are great! But I really tend to be quite sparing with their use.
This 100%. I disagree with him that "paradigms aren't tools" that's literally all they are. They're approaches to solving problems. You can do it the FP way, the OO way, the Data-oriented way, etc. There is no "best paradigm" because there is no "best tool". Even for procedural I can come up with problems that aren't well suited to procedural methods and are easily handled with Objects, for example.
7:00 no, the guy in the video is correct. As long as a language is turing complete, it can do anything any other turing complete language can do. It may be exponentially harder to do certain things, but they must be possible.
Interrupts are very distinct from events because interrupts interrupt the existing flow. They have to do all kinds of things to be very careful about disturbing state that the program they're interrupting might be depending on. Event handlers are part of the normal control flow of the program. I would argue that this is qualitatively different. And I would also argue that while there may have been systems that sort of operated like this, the idea of an event handler as a discreet thing didn't crop up until GUIs became a big deal, and OO and GUIs are very linked ideas. Unix signals are modeled after interrupts and have the same kinds of requirements with regards to disturbing program state.
@Gennady M These classes are really, really old. Stack actually adds more than one method, but they have later been added to the Collection interface under slightly different names. Nobody uses these classes anyway because their methods are thread-safe. Nowadays ArrayList or ArrayDeque are used with external locking if needed.
if you have a template or generic function that that is bounded to compile time. the type must have desired set of properties / method defined by either a trait in rust, concept in c++ or interface in C# / java. The rust method / c++ method is nicer as you dont have intrusive inheritance if you do it right
The way it was explained back in the early 90's, when Java started rearing it's ugly head, was that an object in programming is basically a data structure that can also embed it's own functionality. In the beginning this was user implemented in C the way you mentioned around 22:00, creating a struct that included pointers to trigger each of the functions to manipulate it's elements, but it was not yet called an "object".
1) Since you asked, in at least one language, R, the mapping functions are vectorized to native code and do not allocate. But a for loop will almost always allocate and hence generally be slower, on top of running in byte code. In that language, you always vectorize where you can. 2) For "object oriented", the definition in practice tends to be "dynamic dispatch". Specifically, object oriented code is very good at open recursion problems. But, outside of GUI design, it seems to be a pretty rare design necessity. All the bad OOP code I've seen in the wild is bad because the system ended up designed around using this language feature despite it having nothing to do with the actual problem that needed to be solved. 3) UML is a useless cult, but you *can* usually rule out portions of the design space with some up front back of the book calculations. This is how engineers use physics: there are things that definitely can't solve the problem and avenues that are certainly non-productive. 4) FP "having fewer bugs" is confusing cause and effect. FP gets used most extensively in systems where bugs are extremely expensive because complex object oriented type systems are much harder to combine with elaborate compile time type checkers and similar tools. At the same time, functional programming style makes it easier to use those tools and to encode more elaborate constraints into the type system. I can't speak to the cost of change for a more normal code base, but when certain kinds of bugs are absolutely not acceptable, then you will want to use functional programming. That's what allows you to change the code *at all* without things breaking. I'm as curious as you are to see if those benefits carry over to more general coding situations like web development or if this is an added design cost that is only occasionally worth it. I think it will carry over, but that's just an educated guess. 5) Re: time thinking vs time typing. I think that comes from people who don't *primarily* code. That's probably most people who know how to code even though it isn't true for full time software developers. E.g., it's a lot harder to come up with a creative, novel statistical analysis than it is to code it up.
All you wrote starting from point #2 is total BS and biased opinion. I am not evaluating #1 as I'm not using R. As it goes with every tool - you're doing crap job if you're using your tool wrong. PS. I'm an architect with close to 25y extremely intense exp. who wrote quite interesting stuff 😉 As an example: at one point around 80% of any bank transfers in my country (central europe) were going through my code, as the system hass proven itself and was deployed in many banks (also outside my country). UML is necessity, unless you're working on some nish crap that noone cares. State, sequence and component diagrams are the fundamentals for every useful documentation. Documentation is necessity for any big and critical system. You can't afford loosing knowledge when the programmer gets a sick leave or leaves the company. You can't spend months on "I need to track the code to get know how the whole process goes". It's cheaper and more reliable to grab the sequence diagram and see the flow and involved systems. I can partially agree to your statement only on one condition: you're working on the system that relatively almost noone cares.
@@mehow9521 Okay. I'll bite. Give me a good example of where UML would be great tool that solves a problem in a way that makes the overall project more productive.
@@MaxHaydenChiz defining patterns that most integrations should follow, instead of reinventing the wheel by all devs (class/component diagrams). Documenting/designing the flow (sequence diagram). Definig needed hardware (deployment diagram). Please, keep in mind that I'm referring to big(ish) projects, where at least tens or hundreds devs are involved. As an example, my prev project: I did my job - I have designed majority of stuff. For over 5y there were 0 (ZERO) production bugs (over 100 devs involved out of ~400 people on the project). Everything was going smoothly like from production line. Project was conducted in northern europe (Finland) - we were exchanging core systems for the biggest insurance company there, also changing business processes and making the company ready for technological shift (on the company lvl). Without proper documentation you can't do serious projects, you can't run it "verbally" when different people are imagining different stuff when they hear the same thing. Lawyers have their own language to precisely communicate legal stuff, doctors have their own language when they talk about Healthcare, it has its own language as well - UML. How do you communicate when you describe how the system works? Do you only wave hands and talk? It's a kindergarten. I did that 25y ago and I don't want to go back to those times 🤣
@@MaxHaydenChiz to heat it up a bit i have controversial statement 😉 The role of good architect and architecture is to make the project boring 🙃 When I do my job - everyone knows how every piece of software works. There is zero effort to jump between different systems or parts of the system, the dev knows what to expect and can right away work on that part of system or write new part with confidence that it will fit well. It is the job to do, the job we are paid to do well. Do you go to the doctor and expect that he will experiment on you? Devs do like fun and experiments, but 200M of $ is on the stake and the client does not want your experiment, just to provide you with the fun, when his core of the business is on the stake. PS. To have fun, few years ago I started building by human-size and shape robot. That's the place where I have fun and my experiments - not the job. The job must be done professionally.
@@mehow9521 None of the benefits you are talking about are specific to UML. I agree that you need good documentation. You need to figure out the correct cut points for sub-parts of the team split on. Etc. But I don't see how UML helps with any of this. UML also doesn't automatically sync with the code. It doesn't break when someone doesn't do what the spec says. And it doesn't feed into a formal verification pipeline like many other tools do. So, I don't see the point. If I have a high assurance project, UML isn't good enough. For any other project, the main issue is understanding the problem and conducting reasonable design experiments to figure things out. If I already knew enough about the problem to write out a UML spec, then it wouldn't be a problem to begin with. Getting that understanding right is where the bulk of the work is. Moreover, I don't see how UML is a *good* vocabulary. It explains how this one particular solution to this one specific instance of this problem was implemented. It doesn't help you understand the problem space, the types of things that are acceptable solutions, why other things that look like solutions aren't, etc. I've never looked at a UML diagram and said "oh, this is a distributed non-convex optimization problem". But I can get that from a well written comment that tells me the intent of the code. So, where am I getting a benefit? How is a project different for using UML over something more rigorous like TLA+? How is the project different by using UML instead of an executable spec + test suite? From having really well written prose documentation? From encoding key design constraints into the the type system and getting compiler guarantees about them?
"Procedural programming is greater than anything else" - finally someone that understands me! OOP is needlessly rigid and complex, and functional can get a mess like cable mismanagement on a server room.
I know what you mean here, but after some thought, this almost seems like the same thing as saying "Generic cars are better than anything else; Mercedes are too expensive, and Fords are messy"; while they aren't the same thing, OOP and FP may not have ever existed without Procedural Programming. In the sense that, "I hate this thing, so I'm gonna make a better thing that has NOTHING IN COMMON WITH IT, in context."
@@tsalVlog overall, the biggest issue probably lies on the companies that end up adopting concepts and methodologies without really understanding them. Several years after generations of different development philosophies and bad coding practices, the code you end up working with is just bad.
@@carlsjr7975 Exactly that. Few know this. OOP was created strictly for simulation. It was not ever meant for "general purpose". Of course this guy (the old guy) doesn't know this or care.
UML diagrams depends. Complex system having seqence diagrams showing the overall flow, maybe a few enitity diagrams to explain some abstract areas that are difficult. I think UML has a place where new staff wanna see whats going on quickly. especially in bnadly written codebases where reading the code is more costly than reading the uml
18:13 the only UML diagram I've found useful is the component diagram: you can model each module in a black-box implementation-independent way, and express which interfaces were meant to interact with other modules. These modules can then be implemented with FP, PP, or OOP styles in a way that works best for each module. In a sense, it breaks down a problem into smaller chunks and does not narrow down how you have to implement your solution.
Michael Feathers has a great book on refactoring legacy codebases. "OO looks like FP when it's done right" statement is essentially that method calls don't mutate `this`, but rather copy on write. Methods are for creating new data, rather than mutating themselves. It ends up being declarative in the final interface. Like... the original Java date library was not thread-safe, because the class instances were mutative. This caused some massive issues for companies once multiple cores landed in hardware; especially in handhelds (PDAs / Cell Phones / etc), before x86 systems caught up. When your code is declarative, it takes inputs, it provides outputs, there are no other surprises buried inside. That makes it really easy to pick up any piece of code, no matter how big or small, and replace it with another piece of code that does the same thing, but faster, or simpler, as the situation might warrant.
Not home so I haven't watched yet, but I remember the video in question had some severe unawareness of functional languages Functional style in Java | Python or avoiding mutation is just not the same thing
This video made me realize that I no way less about programming than I initially thought. Can't wait to come back to this video in a couple years and be able to follow the conversation completely. I'm excited for that :)
Abstractions are awesome! You solve the problem on higher level then everything fits together on your concerete implementation! In Rust, for example, you can implement one of the base langauge traits (say, Iterator), then you must implement the next() method. Once you do, the rest of the automatic methods of the traits, line up to your next() implementation
Immutable Data Types have a point, for example if they are very optimized to be clearly faster compared to mutable types (for example the immutable/readonly lists that are slowly coming into c#) If you know, that the list you are returning won't be mutated ever, then you can get the performance boost of immutable lists
16:40 This is incorrect - maps in Python are lazily evaluated (which I see as a good thing) leading to the print not being called. If you convert the map to a list all the values will be evaluated and thus printed. E.g. list(map(lambda x: print(x + "\:n"), WORDS)) works.
that is what a react video should always be, i hate minimal reaction videos that are basically a couple of sentences on top of the original... you either only include parts of the original to complement your commentary, or you add a ton of stuff on top
Towards the beginning you asked what’s the difference between OOP and FP? I always just thought OOP is typically imperative (having an effect on memory) while FP shouldn’t mutate any memory. It also shouldn’t be sequential like OOP is, the code just runs all together in no particular order, unless you specify it (like how scheme has let*). Functions should just be treated as part of both paradigms. Wish I was part of the twitch stream as the concepts of both FP/OOP are still fresh on my mind and I could’ve joined the convo. Rust of course is imperative but has themes of FP, like the pattern matching.
The difference between OOP and FP is not really anything technical like no mutations or pattern matching. The difference is simple how you organize your project. Are you organizing your project around objects or are you organizing around functions. There is nothing stopping you from having no mutations or using pattern matching in OOP, just like you can use abstractions and polymorphism in FP.
Here is my hot takes on where to put the line between functional programming and not. If the languages execution semantics is defined by evaluation rules regarding expressions then it's functional (for instance, lisp is fp becausr it primarily executes by changing ((lamda x e) y) with e_y which is the the expression e with x changed to y, and c is not fp because it primarily evaluates statements one after another).
Inheritance can be good, if done properly. If 2 classes are quite similar, but have a few minor differences, then it can be good to have a parent class that both inherit from, rather than having 2 classes which start off identically, with large amount of code duplication which then needs to be maintained and updated making sure you get both. It can also be good for when you have a class and want to make a similar one which has some variations, which you don't want to modify the original class.
First C++ compiler was just a translator which converted your C++ code to C code, passing to the methods the address of the struct implicitly as the 'this' argument, and adding a table of addresses of the virtual methods in the beginning of the struct, to support polymorphism. You can do OO in a procedural language if it supports pointers. His example on 13:20 is valid because the second code makes lots of nested and looped function calls, like stream(), map(), lambda function inside map(), forEach(), lambda function and println() inside forEach(), which degrades performance, whereas the first code does only println() inside a loop. Event handling is not an OO idea, I used to write interrupt handlers to use the mouse and other external devices in MSDOS in old times, interrupt is an event handler in assembly. GUI operating systems renamed interrupts to event handlers, turned the mouse interrupt into MouseMoved, MouseClicked events. OO done right (SOLID) turns OO closer to functional programming, a lambda function is a one method interface (SRP and IS in SOLID), then you can pass this interface as a lambda function and compose on top of them, keeping objects small (SRP) also aids in less mutable state. But, pure functional programming (LISP) is hard to grasp for me, there is too many wired up code, thinking in objects are more natural and easier and more productive for most daily work. If you ever worked in a finance system, you would know how valid the account balance update problem is, it is stateful and OO. And in a real finance system, you never do it that way, you insert immutable money transactions and the account balance is a side effect, you sum up the money transactions at the end of the day and update the balance, but to get the real balance at runtime, you get yesterday's balance and add up the current money transactions on top. This is a functional way, transactions are the source of truth, you don't update account balance, you don't delete a transaction, you can do reverse transaction if something is wrong in real life. His example on 41:22 is also valid, if you've done refactoring on a procedural code base where functions have too many arguments, you group the recurring group of arguments and turn it into an object and make those functions a method on the object with much less arguments. When a programmer is thinking a lot, it is usually a project management smell, there are gaps in the analysis and there needs to be a conversations going on with the clients or other stakeholders to solve the issue. If you don't trust this guy, see what Uncle Bob (Robert Martin) says, he's done everything, functional, OO, patterns and principles, Closure, C, C++, Java, C#, assembly,...
You used to write event handlers for MSDOS (first released in 1981). That’s your evidence that event handlers aren’t an OO concept? But Smalltalk was first released in 1972. 🤔 TBC I’m not saying there isn’t an event handler concept that predates OO. I’m saying your example isn’t it.
About the immutable data structures argument, that it hurts memory performance because of copy, I think that indeed if you need to copy the whole data struct it defeats the purpose. My approach is generally that I make an immutable data struct, let's say "PlayerData" And then if I need to change some things at runtime, I create a PlayerInstance that contains a reference to the immutable PlayerData as long as all the "overriden" fields Let's say if PlayerData contains a float speed that I need to override, PlayerInstance will then also contains a speedOverride variable. This way I can control precisely what data needs to be copied, fine-tuning memory usage, at the cost of some boilerplate What do you guys think of this approach ?
Sounds like a plan, depending on how you actually set those variables. If you put the function to change the variable within the struct itself, the data for the mutable data structure would be extremely tiny and efficient. Does it take more boilerplate though? Doing it the way you said could still result in a one-line "playerInstance.speed(float)" or even playerInstance.move() function that gets the speed from your mut, but even if you used a fully mutable data structure through the whole thing, you still have to have a function that sets/changes the speed, you still have to create all the playerdata, and you still have to access those datastructures. As long as you only act on your mutable data structure from functions within playerinstance, I don't see why you'd need anything extra.
i like how oldschool programmers made certain code in the languages they were comfortable with, and then made modules out of more performant languages in order to keep as much of the functionality familiar as possible, without sacrificing a feature or performance for the other theres also "pseudo compilers" for interpreted languages that basically converts the program into another form that may not be as performant as if it were made that way from scratch, but allows you to program in a familiar way, but then gain all of the performance benefits as possible from what it gets "compiled" into the idea behind such methods is that you have to have the computer know what to do somehow, so just bake the instructions as much as you can, into a form that doesnt need to basically read the text, figure out what it does, and then do it, it already knows what it does, so just do it i ultimately do not know what i am saying, but at least im trying
The most important thing with functional is that it's declarative. IMO future will be declarative only, eventually. Compiler will (and in many cases already does) do better and smarter optimizations than most, or all humans. And when code is declarative, compiler has way way more freedom to do it's magic, simply because code is much more easy to reason about. SQL for the moust part, is purely declarative (not even functional), and it is f* amazing tool. And what about even more advanced things like logic/non deterministic programming? If you look at that shit, you'll realize how much simpler some things can be written in that way, it's not even funny. IMO everyone should look into prolog, for some serious mind bending. Had some mind bendiness when learned haskell long ago, but that's nothing to what prolog does to your brain! I have more hot takes :)
I did some prolog this past semester! It’s amazing with how powerful it is with its query system. That’s a whole separate paradigm from FP and OOP aka logical programming! I used SWI Prolog
I dislike continuous delivery because he insists on talking about things he clearly has no idea about as we can see per this video. If you're going to talk about OO vs FP please at least make sure you've actually worked with a functional language long enough to grasp the concepts. And even then functional langauges and community vary quite a bit in what they do and how they view FP. The idea that "no loops" is one of the core ideas of functional programming is ridiculous. Also, not bringing up at least one of: union types, currying, partial application, pattern matching, correctness, functional totality, applicatives, monads or algebraic effects just shows how much he knows what he's talking about.
18:18 I think UML diagrams are one option for *visualization* of the code you already have. I have never ever seen a case where it has been a good idea to first create UML diagrams first and then generated code based on those diagrams. Whenever somebody asks me to create an UML diagram, I always generate it from code, even if I had to write the code just to generate the diagram.
In the parallel programming my guess he mixed up parallel threads running on single core or discounting the effect of modern CPUs with a big number of physical cores to take you into true multi core (true parallel) processing. Also, your talk about concurrency is generalizing. Concurrency can be fluid. For example, concurrent queries on DB engine means simultaneous calls but when it comes to APIs even though you send the call concurrently (simultaneously) the service bus will hold you back protecting the endpoint. Thank you for the great content btw, I've learned many languages on my own and I appreciate all paradigms for what they're designed to do. I'm making a comeback thanks to your content.
Remember that functional programming is like object oriented programming minus classes. In C# all that is needed is to create a static class and create static methods. However, functional programming is in general more performant. C++ is a weird compromise - it has the performance of C and it has OO, but it's hard to code in it.
Re: methods. Clojure has multi-methods, and Clojure is definitely functional, so "methods" don't seem exclusively relating to OO... although I believe Clojure inherited this feature from Common Lisp / CLOS. Not sure entirely sure, though. As an aside, I've found Dave Farley's / Continuous Delivery's content incredibly useful. It would be neat to see an episode of you both talking shop and debating some of these points.
Even a simple common pattern of fetching x results in parallel from multiple servers (yes the js bit is concurrent, but the wait time over the wire and retrieval on the servers is parallel) the total time becomes the slowest server instead of sequential sum of each request. Almost always it is many times faster.
A lot of these debates started when there was a clearer distinction between OOP, FP and PP at a language level. Since then, stuff like Rust is primarily procedural but borrows the good stuff from OOP (encapsulation, inheritance via traits, polymorphism) and FP (pattern matching, option and result monads, bias toward immutability). Go has interfaces as in OOP but not inheritance. Java has HOFs, lambdas, the Streams API, immutable collections. C# and LINQ, JavaScript and first-class classes, etc. It’s more of a blend now than ever. That’s mostly been a good thing, and I think the right answer is that OOP and FP both have good ideas that can be selected without committing to the entire paradigms dogmatically.
There is a talk by James Coplien - has a video 'The Dehumanisation of Agile and Objects'. It has a lot of insights in it about what OO was meant to be.
