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.
It's because he's a programmer. They have no idea how a computer or their algorithms actually work under the hood. This is why 90% of his channel is unintentionally comedic videos about programmer arguments. It's also why if you ask a modern programmer to land a calculator on the moon, they will blow it up more times than the Apollo program ever did.
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 ♥
"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.
One of the real problems lately are "rockstar programmers" who overuse generics, and factory patterns and "book programming". Which makes stateless seem like a wonderful thing. Like imagine an e-commerce website is throwing an error because one line says a price of a product isn't a valid number. Easy to trace right? You look at the function. The function takes in a and just shows its price, that's atomic, should be fine. You're trying not to add a log to spit out a value because building a whole app and doing a whole test checkout for one atomic check is what babies do. So WTF is a CommerceObject? You look it up and where it's called, all it's doing, is stuffing a into a . Okay what the hell is that. So you track down where that gets stuffed, and it's taking a and jamming it into the slot. You haven't even found actual code yet. But do you think cramming these objects into different types could have caused a problem by itself? How would you even know!? So you have to look up all these objects, and sure enough, holds the price inside a which was in turn built out of a and now we have exponentially many problem vectors just from how these all convert into each other! We haven't even gotten to actual code problems yet! This is just plumbing! It's going to take you a week just to discover where the hell the price ACTUALLY comes from before you can even find where the problem is most likely to occur! Or... You add logs and run the test like a first year programming student. And maybe that turns out to be the best thing. Who knows.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
"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'
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.
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.
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.
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.
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".
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
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.
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.
Maybe a clear difference between programming paradigms is how state is handled. OOP has state in objects, has state in the procedure itself, and FP has state only inside of functions
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.
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.
"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.
I think the only real significant way you can differentiate what is "object oriented" and "functional" is by how the underlying memory works in whatever respective language. Like what Chris Lattner stated in a recent interview with Primeagen, in a purely function language you have no "in place mutation". Which is why this distinction between functional/declarative vs /procedural/imperative on languages that are multi-paradigm ultimately and let you manage mutable state is kind of dumb and a nonstarter imo. Just use the thing to get stuff done. Thank you functional languages for coming up with some useful patterns and concepts but at the end of the day I don't want to have to copy an entire thing again to do stuff in a "practical" sense. Because performance matters in most applications. If you've ever programmed in Prolog you'll get what this means right away. In Prolog you declare facts and rules and you state declarative cases that occur as queries that unfold given your facts and rules. At no point do you have control of the "how" in how things unfold once they do in the memory sense. And by design that relieves you of any concern for how state is managed. If the problem allows you not to have to concern yourself with that then there is a simplicity as well as a consistency that is nice. The input-output mapping is set it stone as it were. It works every time according to the rules of this little "universe" you created. A concrete example is that I had a math professor use Prolog as a way to automate proving theorems for a class. If a theorem was bunk then the rules and facts would show it to be so. And sure he could have wrote this program in a "object oriented" language and way. But why when he can do it faster and more elegantly in Prolog cause this problem of validating proofs lends itself to the "functional" design of the language? And he works in academia. He doesn't give af if it takes like 15 minutes to run. He'll just takes his 4th coffee break or something. Prolog is really useful as a learning tool and I imagine it has it's place academically for research as well. So really no point in splitting hairs of whether something is really functional or OO in languages that ultimately concerns itself with performance by allowing you to do things like mutate things in place. That is state management and whatever functional/declarative design thing you can invoke is just an abstraction around how memory fundamentally works in a given language. Style arguments can be stupid. And this is one of those times where it is. It can just be a lambda. You can just know how lambdas work. Lambdas, anonymous functions, callbacks, first class functions, whatever the fuck you want to call them, if they are in a language like java or javascript where everything is an object the question of is it really functional kind of becomes a nothing burger of a question. Cause no it isn't. It isn't functional in the only way it actually matters. It has a refcount and is maintaining whatever other state. Is how it "look" functional? Sure like in a lineage sense yeah. It's a nice little thing that was yoinked for a richer semantics and adds to the language complexity. But functional languages are functional cause they don't concern themselves with state at all (or as little as possible) which allows for a simplicity and level of expressiveness in way fewer lines of code than any multi-paradigm including OO. You can't declare an array and give it a name to reuse in Prolog. But you can say there is an array and this array has to contain these elements after a series of operations and if it doesn't then resolve to false in fewer lines than if you had to do all the typical programming plumbing of declaring and managing state. Math people seem to like it so that has to be something. It's neat knowing little factoids about the lineage of programming patterns/language features and how functional languages gave us these things but just do things in a way where the next person that has to read your thing doesn't want to kick your teeth in. Use whatever to facilitate that. And I feel the video and ultimately this reaction to it also doesn't help anyone keep their teeth. Cause I don't even know what to take away from this other than even calling most modern languages nowadays even partly "functional" for yoinking a few patterns is a mistake.
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.
16:37 This was the case in Python2, where `print` was a statement, in Python3, they turned `print` into a regular function that you can use in lambdas. Even though Python3 has been around since 2008, Python2 wasn't fully deprecated until 2020, so I guess it's understandable. Tho real ones would use sys.stdout.write instead, which has always been a function.
Always having good laughs watching you interacting with chat, for e.g. "is OOP alot like FP when done right?" chat: "yes", "no", "ofc" "nono". Somewhat contradictory/confusing statements (mb just for me). Also "never make generalized statements": "inheritance is always bad" or "UML is BS" vs "i always use pen and paper to write/model things down" (guess this was about inheritance). Anyways very funny
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.
That throwaway "almost never the case" parallelisation argument is hilarious to me. I work in analytics, mainly using R, and I wrote some functions for hitting up and processing results from an API earlier this year. First iteration of the code was not parallelised, and it was taking 40 minutes to process the results of a full-size dataset (~ 30k requests). Switched to parallelised functions and tested with 4 cores: went down to 10 minutes.
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?”
@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.
one key difference between functional and object-oriented programming is how it handles state. In object-oriented programming, you have a set of objects representing the state, and functions mutate those objects to change the state. State, and the functionality related to a class of state, is inherently structured and usually long-term. In (pure) functional programming, there is no state in the same way, just functions that map input values to output values most "functional" programming languages usually strike some form of middle ground, where there is some form of long-term, usually structured, mutable state, and functions are used to determine the correct way to mutate the state
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
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 :)
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.
Having been professionally using a functional language for a year, I can safely say... its annoying. I would really say that the difference between functional and oop is what level are your objects at. In functional programming, you just only have one object, only one path to follow through the program instead of running everything by handlers and you never get to set aside what your current problem is inside a given program. If you need multiple paths you have multiple programs. But really, that just means you, the human, are the handler, manually doing what you could have programmed into an object oriented program that handles multiple tools.
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
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.
I have pretty much fallen out of love with OOP. I find that it is almost always the wrong abstraction. Some form of type-classes works far better in practice IMHO. The real-world benefits of functional programming for actual people rather than for computing science researchers seems to always boil down to abstraction through type-classes. This is what Rust took from Haskel that makes Rust work, for example.
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.
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
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
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.
Hey @theprimeagen, big fan here! just wanted to point out that immutable collections in many implementations across languages/runtimes do not copy when they get changed, they are usually implemented by height balanced trees, and only the node that is changed will be modified and the rebalance will be done after that depending on the operation. If you however take the mutable data structures under multiple readers/writers, then they have to be copied for the current readers before they get modified which is way costlier than immutable collections modification under concurrency. You might already know all of this, just curious
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.
@@mehow357 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.
@@mehow357 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?
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.
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.
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!
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
FP has polymorphic methods (and sometimes objects) and OO has polymorphic objects (only). Therefore, in FP you are able to add functionality to existing classes without modifying the class itself.
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.
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.
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 :)
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.
Watching these videos together with Prime makes me understand just how much I don't know. I need to dive into low level one day to satisfy my curiosity.
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.
Situations where you might think more than type: 1. You're implementing an algorithm for some acoustics or physics application and need to understand what each quantity means and organize things to make it readable. 2. You have a serial computation and need to tweak both the implementation and the API to make it available for parallelization. 3. You're designing a large and complicated system. After doing your POC, you need to sit down and figure out how to split up and reorganize everything, possibly into different services if you're into that.
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.
my code was written using OOP and was inherently trash, then i rewrote everything using FP and now it's functionally garbage
proper
perfection
Coding poetry
It's objectively garbage first then it's functionally garbage LOL
@@afterschool2594 inheritence
I always follow money oriented programming. whatever the fuck my boss tells me to do.
classic
A truly top-tier engineer answer.
Thanks, you made my day
🤣@@tsalVlog
Kkkkkkkk 😂
After a decade of programming, I've realized that no paradigm will cure my stupidity.
this
Use (void *)() ... it's good enough for your computer.
us
period
rust 😯☝🏽
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
I know Tim Rentsch! He and I used to talk every week for a few hours. I never realized that he said that!
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.
@@xdarrenx very insightful observation 🙏👊
It's classes though right?
Hey, kinda like every product having "AI" in it (freshly squeezed, I guess).
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.
It's because he's a programmer. They have no idea how a computer or their algorithms actually work under the hood. This is why 90% of his channel is unintentionally comedic videos about programmer arguments. It's also why if you ask a modern programmer to land a calculator on the moon, they will blow it up more times than the Apollo program ever did.
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 ♥
Maybe it's ugly and unmaintainable, but it's MY ugly and unmaintainable!
hansen brothers always code in the MBOP paradigm
I usually just emulate dc via subleq.
"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.
@@KennethBonethI love how you call him continuous delivery lmao. Not bagging on you, it's just funny to see
@@duartey8241 haha I forgot his name. I think its like Dave.
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.
it dependeds , i think global state should exsist but should also be minimal and immutble
I just pass around a huge struct named "globals" instead.
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.
One of the real problems lately are "rockstar programmers" who overuse generics, and factory patterns and "book programming". Which makes stateless seem like a wonderful thing.
Like imagine an e-commerce website is throwing an error because one line says a price of a product isn't a valid number. Easy to trace right? You look at the function. The function takes in a and just shows its price, that's atomic, should be fine. You're trying not to add a log to spit out a value because building a whole app and doing a whole test checkout for one atomic check is what babies do. So WTF is a CommerceObject? You look it up and where it's called, all it's doing, is stuffing a into a . Okay what the hell is that. So you track down where that gets stuffed, and it's taking a and jamming it into the slot. You haven't even found actual code yet. But do you think cramming these objects into different types could have caused a problem by itself? How would you even know!? So you have to look up all these objects, and sure enough, holds the price inside a which was in turn built out of a and now we have exponentially many problem vectors just from how these all convert into each other! We haven't even gotten to actual code problems yet! This is just plumbing! It's going to take you a week just to discover where the hell the price ACTUALLY comes from before you can even find where the problem is most likely to occur!
Or... You add logs and run the test like a first year programming student. And maybe that turns out to be the best thing. Who knows.
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.
i will purchase this take
I agree. With the caveat FP has less footguns.
@@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.
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.
Nah ASM is better than rust
I would say that Rust is a mix between functional and OOP and can't be entirely put into one camp.
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.
Most devs have less than 5 years of experience
Product managers even less
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.
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.
good rule of thumb here
“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".
@@u9vata Like summing a million or some numbers together?
@@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.
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
Well said and true. Doing FP without tail recursion optimization and immutable data structures is painful.
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.
@@SimGunther procedural is a subset of imperative
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.
Not true. Lisp matches what Lsip machines actually execute (as they have CPUs made to run Lisp natively at the die level).
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.
Well said. The OOP pillars don't even belong exclusively to OOP (other than inheritance which is bad).
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.
Yeah the whole video just feels like a guy having vague over-generalised thoughts about ill- or un-defined concepts
the point is that Haskell doesn't have side effects, only effects, which are explicit in the type system
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.
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.
what is UML?
@@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.
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.
@@Asto508 Yeah, but I'm not arguing what it was originally designed for. I'm talking about what it ends up actually useful as.
the best use case for UML is throwing it into the bin
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.
And dyn trait objects for runtime polymorphism
@@_Aarius_ yes exactly.
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.
But do we need to associate functions with specific object exclusively? What is the benefit?
@@viktorshinkevich3169 If the function only interacts with a particular class it's more convenient to have it inside of the class scope.
Even FP associates functions with objects to a degree.
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.
@@NathanHedglin Yes, but with OOP it's a single thing you associate it with. A function may have multiple parameters that may be considered objects.
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.
@@Jabberwockybird I think the opposite. The British guy does NOT say they are exclusive.
I think that's why they say that OOP is similar to FP when done right.
@@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.
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.
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 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.
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.
The best langage is the one that helps you keep complexity at bay and not shoot yourself in the foot repeatedly
Prime: "You need to be careful with those bold statements"
Also Prime: "Whiteboarding is bull SHIT, bull SH**!!"
It is not a bold statement. It is obvious.
Not a bold statement, everyone with more than 2 half functioning neurons can tell.
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.
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.
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.
ocaml has oop too (thats what the 'o' stands for)
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.
"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'
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.
"very intelligent" lmao
The dude is a book salesman. Ignore.
I've never felt he has had any useful or new takes, just gave up on him after something like 3 videos
"even a struct with some private data and some functions, is that OO?"
Yes. Yes it is.
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.
OO is when you have a link between data and behavior, and functional is when functions are pure (given the same input, you always get the same output)
You can do the same thing with categories in functional programming. That's what monads are.
why did prime just take a laxative shot in the first 3 minutes
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.
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.
totally agreed, once you see haskell, you can’t unsee it, and typescript/etc just don’t cut it
@@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.
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".
You are so lucky that you are working on actual good codebases and greenfielding a lot.
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
Thats why i love Kotlin. Just staying OOP where it has sense, taking only the good parts of FP, without any stupid dogma
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.
that olive oil shot is gonna blow your guts out, hope you have a strong throne room.
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.
Compare impls to Haskell typeclasses
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.
@@duncanw9901 typeclasses compare better with traits. Struct impls are just syntactic sugar
“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.
Maybe a clear difference between programming paradigms is how state is handled. OOP has state in objects, has state in the procedure itself, and FP has state only inside of functions
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.
It almost never matters if most arrays don't have a ton of elements in them.
really depends on what your trying to accomplish. good code/bad code can be written in either style.
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.
"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.
OOP is good for simulation. Outside that it's needless complexity.
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.
@@jboss1073 pretty sure the language was simula
I think the only real significant way you can differentiate what is "object oriented" and "functional" is by how the underlying memory works in whatever respective language. Like what Chris Lattner stated in a recent interview with Primeagen, in a purely function language you have no "in place mutation". Which is why this distinction between functional/declarative vs /procedural/imperative on languages that are multi-paradigm ultimately and let you manage mutable state is kind of dumb and a nonstarter imo.
Just use the thing to get stuff done. Thank you functional languages for coming up with some useful patterns and concepts but at the end of the day I don't want to have to copy an entire thing again to do stuff in a "practical" sense. Because performance matters in most applications.
If you've ever programmed in Prolog you'll get what this means right away. In Prolog you declare facts and rules and you state declarative cases that occur as queries that unfold given your facts and rules. At no point do you have control of the "how" in how things unfold once they do in the memory sense. And by design that relieves you of any concern for how state is managed. If the problem allows you not to have to concern yourself with that then there is a simplicity as well as a consistency that is nice. The input-output mapping is set it stone as it were. It works every time according to the rules of this little "universe" you created.
A concrete example is that I had a math professor use Prolog as a way to automate proving theorems for a class. If a theorem was bunk then the rules and facts would show it to be so. And sure he could have wrote this program in a "object oriented" language and way. But why when he can do it faster and more elegantly in Prolog cause this problem of validating proofs lends itself to the "functional" design of the language? And he works in academia. He doesn't give af if it takes like 15 minutes to run. He'll just takes his 4th coffee break or something.
Prolog is really useful as a learning tool and I imagine it has it's place academically for research as well. So really no point in splitting hairs of whether something is really functional or OO in languages that ultimately concerns itself with performance by allowing you to do things like mutate things in place. That is state management and whatever functional/declarative design thing you can invoke is just an abstraction around how memory fundamentally works in a given language.
Style arguments can be stupid. And this is one of those times where it is. It can just be a lambda. You can just know how lambdas work. Lambdas, anonymous functions, callbacks, first class functions, whatever the fuck you want to call them, if they are in a language like java or javascript where everything is an object the question of is it really functional kind of becomes a nothing burger of a question. Cause no it isn't. It isn't functional in the only way it actually matters. It has a refcount and is maintaining whatever other state. Is how it "look" functional? Sure like in a lineage sense yeah. It's a nice little thing that was yoinked for a richer semantics and adds to the language complexity.
But functional languages are functional cause they don't concern themselves with state at all (or as little as possible) which allows for a simplicity and level of expressiveness in way fewer lines of code than any multi-paradigm including OO. You can't declare an array and give it a name to reuse in Prolog. But you can say there is an array and this array has to contain these elements after a series of operations and if it doesn't then resolve to false in fewer lines than if you had to do all the typical programming plumbing of declaring and managing state.
Math people seem to like it so that has to be something. It's neat knowing little factoids about the lineage of programming patterns/language features and how functional languages gave us these things but just do things in a way where the next person that has to read your thing doesn't want to kick your teeth in. Use whatever to facilitate that. And I feel the video and ultimately this reaction to it also doesn't help anyone keep their teeth. Cause I don't even know what to take away from this other than even calling most modern languages nowadays even partly "functional" for yoinking a few patterns is a mistake.
you know it's gonna be good when it's almost an hour and Dave's on the thumbnail
lets go!
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.
16:37 This was the case in Python2, where `print` was a statement, in Python3, they turned `print` into a regular function that you can use in lambdas.
Even though Python3 has been around since 2008, Python2 wasn't fully deprecated until 2020, so I guess it's understandable. Tho real ones would use sys.stdout.write instead, which has always been a function.
Always having good laughs watching you interacting with chat, for e.g. "is OOP alot like FP when done right?" chat: "yes", "no", "ofc" "nono". Somewhat contradictory/confusing statements (mb just for me). Also "never make generalized statements": "inheritance is always bad" or "UML is BS" vs "i always use pen and paper to write/model things down" (guess this was about inheritance). Anyways very funny
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.
"UML diagrams are full of shit"
*italian chef hand emoji*
this doesnt mean dont design, but this does mean update documentation regularly
When I see OOP I think "oops"
that's what the people using OOP for anything and everything should say
That is the full acronym sometimes 😂. Object-Oriented Programming System
That throwaway "almost never the case" parallelisation argument is hilarious to me. I work in analytics, mainly using R, and I wrote some functions for hitting up and processing results from an API earlier this year. First iteration of the code was not parallelised, and it was taking 40 minutes to process the results of a full-size dataset (~ 30k requests). Switched to parallelised functions and tested with 4 cores: went down to 10 minutes.
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
And data oriented is still an abstraction, except it's a good abstraction. OOP is a horrible abstraction and total garbage.
@@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?”
4:40 OOP is when your objects have functions, FP is when your functions have objects.
"Set" is not a subclass of "Vector" in Java. "Stack" is the only one and it just adds a convenience method to pop the last element.
Why not just add it to vector 😅
@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.
one key difference between functional and object-oriented programming is how it handles state.
In object-oriented programming, you have a set of objects representing the state, and functions mutate those objects to change the state. State, and the functionality related to a class of state, is inherently structured and usually long-term.
In (pure) functional programming, there is no state in the same way, just functions that map input values to output values
most "functional" programming languages usually strike some form of middle ground, where there is some form of long-term, usually structured, mutable state, and functions are used to determine the correct way to mutate the state
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
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 :)
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.
Having been professionally using a functional language for a year, I can safely say... its annoying. I would really say that the difference between functional and oop is what level are your objects at. In functional programming, you just only have one object, only one path to follow through the program instead of running everything by handlers and you never get to set aside what your current problem is inside a given program. If you need multiple paths you have multiple programs.
But really, that just means you, the human, are the handler, manually doing what you could have programmed into an object oriented program that handles multiple tools.
Only Prime can make a react video 2x longer than the 2x speed actual vid
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
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.
I have pretty much fallen out of love with OOP. I find that it is almost always the wrong abstraction. Some form of type-classes works far better in practice IMHO. The real-world benefits of functional programming for actual people rather than for computing science researchers seems to always boil down to abstraction through type-classes. This is what Rust took from Haskel that makes Rust work, for example.
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.
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
forget about oop and functional, did you just said "yerba mate"? 👀
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
You don't use Rust, I assume?
Concurrency is just an illusion of parallelism
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.
@@Borgilian these things have an actual formal definition. A persistent data structure has requirements to be considered so.
Hey @theprimeagen, big fan here! just wanted to point out that immutable collections in many implementations across languages/runtimes do not copy when they get changed, they are usually implemented by height balanced trees, and only the node that is changed will be modified and the rebalance will be done after that depending on the operation. If you however take the mutable data structures under multiple readers/writers, then they have to be copied for the current readers before they get modified which is way costlier than immutable collections modification under concurrency. You might already know all of this, just curious
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.
@@mehow357 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.
@@mehow357 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?
Rust isn't functional, or at least not _fully_ functional. I think those languages are somewhat rare. Haskell comes to mind.
I agree, programming paradime is a tool, i.e. if you don't need classes use procedural paradigm.
This is therapy for me, this guy @ThePrimeTime is yelling basically everything I have seen go wrong in various environments in my programming career.
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.
Glad someone else spotted this.
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.
Liking this video just for the anabolic steroids!
appreciate it
@@ThePrimeTimeagen however this is the guy who insists on pushing straight to master, so I'm just waiting for the car crash moment!
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!
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
FP has polymorphic methods (and sometimes objects) and OO has polymorphic objects (only). Therefore, in FP you are able to add functionality to existing classes without modifying the class itself.
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.
The way other languages can do this is via reflection (which is very unperformant)
@@Luxalpa Is there any framework I can look into (for any language) ?
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.
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 .
lol every some comments, i see a comment like this, and i just hope there would be more of this haha! learn haskell, prime!
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 :)
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.
Procedural chads rise up
Watching these videos together with Prime makes me understand just how much I don't know. I need to dive into low level one day to satisfy my curiosity.
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.
35:38 "Object oriented programming looks a lot like functional programming when it's done right". Is this supposed to be an argument for OOP or FP?
10:40 pointless code, you didn't have to map to add /n when you use println... lol
Situations where you might think more than type:
1. You're implementing an algorithm for some acoustics or physics application and need to understand what each quantity means and organize things to make it readable.
2. You have a serial computation and need to tweak both the implementation and the API to make it available for parallelization.
3. You're designing a large and complicated system. After doing your POC, you need to sit down and figure out how to split up and reorganize everything, possibly into different services if you're into that.
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.
Off topic but thanks you prime! you've helped me out of my coding rut! IOU