Richard's podcast is great for anyone interested in looking "under the hood' of programming languages and also just generally for thought-provoking conversations. Highly recommend!
Just a clarification about Java, the front end language (this can include Kotlin) is transformed into bytecode by javac, the JVM then runs the byte code and _COMPILES_ it to machine code, it has multiple different compilers but on hotspot it's C1 and C2, so no, it's not interpreted after this, what you were saying about JIT applies from here and is somewhat correct given the point about small loops and the compile threshold (which is configurable btw). Those very interested should look at OSR from the compiler, the whitebox to compile a method up front, GRAAL AOT compilation.
I was firmly uninterested in yet another functional programming language, but I'm now really looking forward to trying it. Seems like a great guy with a great attitude!
Some aspects are great from FP, like pure functions, first class functions, explicit inputs and outputs rather than internal class mutation. I find myself enjoying modular procedural programming the most. Go supports this fairly well, so can still use loops, re-assign variables and such, and its brilliant simple code. I like the first class function support in Go too it means you can simplify a lot of code which might have otherwise have used an interface and move towards simpler structs, can also give the function's type a name to make them easier to understand, so most of the benefits of an interface but a whole lot easier to use. I have previously used OOP and given that composition is preferred over inheritance it starts looking closer and closer to module driven development. Indeed a good module syntax has now come to C++ and exists in Go already, so can already use that as a unit of encapsulation and build simpler programs around that abstraction and prefer a simpler data store of a struct in most cases. Bring on module driven development MDD. :)
Just to point out that active record is considered an antipattern by many OO developers for the reasons you mentioned, and many other reasons concerning separation of concerns, etc. There are many better solutions to the data access problem. I think that we shouldn’t paint OO as bad because people have developed bad solutions using OO. If the tables were turned and FP had been the dominant paradigm of the last three or four decades, I think we’d now be talking about how much damage FP has wrought. And just one more point on performance: Ruby is slow, but there are many OO language implementations that are orders of magnitude faster than Ruby. Again I feel like we are painting OO as problematic because we can do bad things with OO. On the JIT subject - I am not sure what the actual criteria are for Java or CLR to decide when to compile a block of code, but if this is a concern both Java and dotnet can ahead-of-time compile to native code.
I disagree about FP, I think it's very hard to defend OO objectively compared to FP other than the fact that it has had more money dumped into it and more man-power into actual implementations. Sure we would be talking about the bad ideas in FP, but are those worse than OO bad ideas? Also, what else do we gain (we gain way more compared to OO)? It's extremely hard to make any case for OO, other than that it is more natural to explain? Although I'd toss that to manpower put into education and learning.
EXACTLY THIS ... yes sir... you got it right. I am tired of listening the usual idio... saying OO is bad, when in reality they haven't spent a good amount of time learning the patterns, and abstractions to deal with it succesfully.
Which language is the exception to the assertion at the start of the video that popular object-oriented languages would be better without the object-orientation?
23:27 Common Lisp is on the level of fast language and memory managed, is on par with Java & C# Ruy & Python are not fully Interpreted, they use bytecode. PERL5 is fully interpreted. Common Lisp can be interpreted or compiled to bytecode and has type inference and optimizing compiler and in some implementations you can even define a function in pure assembly language in other implementations like CLASP you have an interactive Common Lisp but also using FFI to C++ code.
Great episode! I’ve been on a watching streak through your channel and this particular one (also Casey and Prime ones) caused me to subscribe. Great thought-provoking discussions! Keep it up Lane 👏🏼 For anyone interested, Richard’s podcast is called Software Unscripted. Great content too.
Great interview! I'm excited about Roc. I use and love F# for financial modelling and welcome a functional language with high performance as a design goal.
29:52 for those JIT compilers, why aren’t the counters persisted? I’d imagine that each loop would have its own counter for the life of the application, if a threshold is reached, then the loop would be permanently compiled. So you may only loop a handful of times each time the loop is called, but many times over the life of the application.
Richard is spot-on about OO. It's a painful truth that can make one a pariah in commercial development, which is probably why we hear it voiced so rarely.
This was great, thanks. I was considering roc for advent of code this year, but kinda shied away from it since the lsp is still in development and it would be my first experience with a functional programming language. I love the idea behind it though, I should give it another shot. Cheers!
Totally agree on the OOP stuff but if some boss, told me that I couldn't use for loops and while loops anymore and had to use recursion instead, I would quit on the spot...
@@ravenecho2410 No matter what you think philosophically what it is, when you have to write code in a editor the diferences are huge and require different mental gymnastics. Take a pure OOP code base and a pure functional code base, doing the same thing, put them side by side and tell me there's "no diference" between them. Plus they compile and run at different speeds.
@@HoD999x If I want a while loop I will just use a real while loop. ;P Btw I have been coding for 7 years, only used recursion a handful of times, for very specific work. You can code a entire complex, real code base and only need to use recursion once or twice, that is how important recursion is, aka is mostly useless. So IMO people speak so much about it, because they want to show off, they know recursion requires more mental gymnastics than a for or a while loop, so they want to show off their "AAA programmer mind". Also "is cool to write a function that calls itself" yes is cool but is also hard to read and reason by fast looking at it, a for or while loop is, you look at it, bang you immediately know your doing a loop, good for your brain to save energy. ;)
Oop is a fun way to make a puzzle out of your code that people will have to decipher later. Complexity is the primary enemy of good software engineering and I’ve learned to avoid that whenever I can.
This is only true of extreme java-esque OOP codebases and not OOP inherently. OOP is fundamentally two things: the ability to group state with behavior into instances, and the ability to abstract over those instances as constructable classes of instances, expressed using subtype hierarchies. Some people find subtype hierarchies intuitive, lots of modular organization beneficial, polymorphism useful and easy to grok. Maybe you are not one of those people, and that is not a fault of OOP. The "simplest code" is not the best code; 150 lines of direct imperative code doing only exactly what you need currently is going to read worse and be less extensible and testable than if you were to split that up as a composition of many proper sub-functions with generalized interfaces; neither of which are difficult for lots of programmers. In a sense, that refactored code is even simpler, despite involving a lot more constructs in your code, since any given piece at a time is very easy to understand even if there are many more pieces now. But, there are some programmers who somehow prefer the 150 loc zero abstraction (and zero extensibility) version because it's "simpler" (to them only). Maybe you're in that category. Brain difference mostly. Some people are wired for OOP and others are wired against it. Another way to word it; whether or not you find "separation of concerns" correct and beneficial in software will depend on how good your brain is at switching between many separate concerns and levels of abstraction at a time while navigating your codebase. If you're bad at that, you're going to hate OOP. I'm sure that if we devised a sort of IQ test that asked questions like "An X category is a subcategory of Y which relates to a Z category structurally in Q way which ...." some programmers would excel at tracking this while others would find it as difficult to follow immediately, and that is exactly the skill you need for OOP. Analogous to how some people excel at recursion while others struggle with it. It looks like some people have higher RAM in their brain for absorbing large category hierarchies and a higher ability to philosophize about abstractions in their codebase, and those people feel drawn to OOP. The people who don't will whince when they see it and want their codebases to instead have nearly zero conceptual scaffolding (because they find it complex and hard to follow and fail to see how it immediately relates to the problem)
“What functional principles do you use when coding in an OOP language?” is a really interesting question and I’m disappointed that Richard didn’t answer it but instead talked more about the benefits of functional languages. It’s even a question that has useful answers that would help bridge the gap for coders to whom he’s trying to reach out.
Probably neither since Elixir isn't statically typed, not controlled for side-effects and isn't that quick (if you're shooting for "most of the time less than 5 times slower than C")
Nothing wrong with it. 99% of the software is written in oop style. Learn it and understand how to not overdo it. There is a reason a lot of software is written this way.
Everyone need to learn it well .. even if he ended quite hating it, still you cant really call yourself programmer if you dont understand it. Functional programmers need to understand it really well so they may spit on it! 😂 I also prefer functional style.
35:30 - Python is s dynamically typed language - this is why there's a whole bunch of conditionals - since it needs to divine how to invoke the operand based on the left and right types - this applies to every dynamically typed language - c is a statically typed language - this is why it's faster. This is a completely different paradigm and nothing do with functional vs. OO vs. imperative.
Whenever you say everyone else is wrong and you are right it usually means you are wrong. I am an FP fanboy, but there is great value in OOP if used responsibly. An example is if you have a stack or any subject, you would want to call it like this: stack.push(element). However, if there is no clear subject, it should be called in a way where all argument as treated equal like this: Vector.intersection(vector1, vector2). Having the intersection function inside a module gives you the intellisense that you get when you use objects. Objects where there is a clear subject, procedural when it's not. That is my approach. Also preferring structural typing so that dynamic dispatch is avoided. Interfaces are still very valuable though.
'OOP is not suitable for what I do therefore is it bad and no one should be allowed to use it' Right... As a game dev I'll be keeping my objects and OOP languages.
I don't know why it seems to be a common understanding that OOP is good for game dev. There are many people who advocate against this and advocate instead for so-called "data-oriented design". Admittedly, while I don't think OOP is particularly suitable for game dev, FP is completely unsuitable (though Naughty Dog apparently pulled it off for a while). C++ likely still reigns king, but can be leveraged in a way that is more akin to "structs with constructors/destructors" than to traditional OOP practices.
You might want to look a bit into Jonathan Blow and Casey Muratori's stuff. They're both successful programmers in the game industry who advocate against OOP.
@darwinschuppan8624 Advocating against OOP in game dev is one thing, and possibly reasonable, but replacing it with functional... that's a whole different rabbit hole, and not a pleasant one.
ruclips.net/video/LC1yxlicWUs/видео.html go fmt is such that out team has to settle on a max line length for the codebases we do, and that's been 2 years of folks being dissatisfied with the decision on something you CAN argue over, cause the go formatter does not care. you can break your function signatures, first and foremost, in a whole bunch of places. so what's the max line length on Roc? All's I'm saying is that if you claim to have an all-things-included formatter, great. Just make it all things.
@@sacredgeometry objects are a tool to use when developing when they fit and are useful. Some developers will try to fit every aspect of their code into an object hierarchy when it isn't needed or useful
Give a junior programmer a large OO codebase and they will be probably able to reason about it; give them a large functional codebase and they probably will not. Since the number of developers has for ever been increasing, it means there are always a lot of junior devs. It becomes a case of economics.
I am just started the video, but already cannot agree more, and I am not even a fan of functional programming . I got my start ~20 years ago with Ruby and C#. and it took time to break out that mindset when approaching new languages. Even though a language wasn't OOP, I wanted it to be, and often attempted to use it as such, which is typically not idiomatic nor advantageous for languages that aren't supposed to be OOP. I have come to love the style used by Zig, Go, etc., where you can associate functions with structs, but it is merely syntatic sugar, with no polymorphism or inheritance garbage.
All the things people hate about pgrogramming languages, inheritance, singletons, OOP, apple uses them all as the basis for their entire ecosystem and it runs better because they do it that way.
In my opinion, use what works best instead of being locked into an ideology such as functional or oop. I don't see how functional languages can be considered general-purpose.
That's way too simplistic. It's better to use everything in moderation. Pure OOP sucks, as does pure functional. But a small amount of OOP mixed with procedural programming can be a very useful abstraction or a way to control scope. Lisp was a lot of fun but totally impractical for developing a Windows GUI application.
Too long didn’t watch but just based on the intro this guy is just wrong. Functional programming is great for smaller projects where you are the only developer. When it comes to larger projects with multiple developers it becomes way too easy to write stuff that is completely incomprehensible. Readability and maintainability are way more important than any benefit you get from functional programming over OOP.
Maybe, just maybe, if you didn’t listen to the full argument it’s worth refraining from posting the comment that says “it’s just wrong”. Food for thought.
@@idonthavefantazy nah. I’m just skeptical of people that claim one paradigm is flat out better than another. It shows a lack of maturity. There are trade offs to everything.
@@Didymus888 he didn’t though. If you watched the whole video you would hear his answer what type of problems he would not pick FP for 🤷♂️ As for your argument re. readability: readability is to the large extent the matter of habit/familiarity. Functional code is no less readable than OOP code, once you get used to it.
WTF !! golang has nothing to do with functional paradigm, functional paradigm is declarative and golang is an imperative language. So many bootcamp plebs
OOP is almost always manages the memory and this is why it is used. It is a lazy way to do it. This is why it was adopted, I guess. Anyway ECS is better and basically utilizes functions, data and OOP to some extend.
Use time codes please. They are not hard. Also maybe refrain from clickbaity cover art. I am 30 min in and still nothing about “OOP damage”. So i’m less likely to trust the next vid with baity cover and no time codes…
what the actual ... OO didn't cause issues to the industry. Programmers that used OO did. The same can happen with any other paradigm. What a load of it.
Yep. Some people really are a bit slow though, I bet once they manage to do enough programming in the paradigm they claim to fix all the problems and find the problems everyone else already knew existed they still wont get it but will just move round the circle of stupidity trying to catch a clue that they are the problem not the language or paradigm.
roc's faq says that it doesn't support higher kinded types because some devs don't know what they are lmao. As good of a speaker as he is, he's a terrible language designer if that's how he thinks. Developers should want to learn things, instead you're dumbing down a language to not scare about the bootcamp kids? Ok lol good luck with that, i don't know who your target audience is then
Dude how do you people not understand what a general purpose programming language is.. Rust is not one and never will be, it's for systems which almost nobody who talks about actually works in lol
Richard's podcast is great for anyone interested in looking "under the hood' of programming languages and also just generally for thought-provoking conversations. Highly recommend!
Where can I find it?
@@ianliu88Software Unscripted. Apple podcast is where I found it
Roc made in Rust! Very wokey!
@@ianliu88 It’s called Software Unscripted, available on most podcasting platforms I believe!
Richard explains things so clearly I feel smarter after watching this.
Really great.
Thanks!
It's always such a pleasure to listen to Richard talk, his passion is remarkable!
53:00 Smalltalk philosphy of OO perhaps best realized in Elixir/Erlang, which is ironically a functional language, and criminally underused. ;)
And reinvented as the actor model in various libraries
Just a clarification about Java, the front end language (this can include Kotlin) is transformed into bytecode by javac, the JVM then runs the byte code and _COMPILES_ it to machine code, it has multiple different compilers but on hotspot it's C1 and C2, so no, it's not interpreted after this, what you were saying about JIT applies from here and is somewhat correct given the point about small loops and the compile threshold (which is configurable btw). Those very interested should look at OSR from the compiler, the whitebox to compile a method up front, GRAAL AOT compilation.
C# has ways to completly avoid heap allocations and can also be compiled to machine code
I was firmly uninterested in yet another functional programming language, but I'm now really looking forward to trying it. Seems like a great guy with a great attitude!
Great episode!!! I really enjoyed the questions you made. This is my first episode, and I gotta say: I hope for many more!!😊
Some aspects are great from FP, like pure functions, first class functions, explicit inputs and outputs rather than internal class mutation. I find myself enjoying modular procedural programming the most. Go supports this fairly well, so can still use loops, re-assign variables and such, and its brilliant simple code.
I like the first class function support in Go too it means you can simplify a lot of code which might have otherwise have used an interface and move towards simpler structs, can also give the function's type a name to make them easier to understand, so most of the benefits of an interface but a whole lot easier to use.
I have previously used OOP and given that composition is preferred over inheritance it starts looking closer and closer to module driven development. Indeed a good module syntax has now come to C++ and exists in Go already, so can already use that as a unit of encapsulation and build simpler programs around that abstraction and prefer a simpler data store of a struct in most cases.
Bring on module driven development MDD. :)
21:56 C# can compile AOT just like Go. It’s baked in the tooling.
but it's not the default
Just to point out that active record is considered an antipattern by many OO developers for the reasons you mentioned, and many other reasons concerning separation of concerns, etc. There are many better solutions to the data access problem.
I think that we shouldn’t paint OO as bad because people have developed bad solutions using OO. If the tables were turned and FP had been the dominant paradigm of the last three or four decades, I think we’d now be talking about how much damage FP has wrought.
And just one more point on performance: Ruby is slow, but there are many OO language implementations that are orders of magnitude faster than Ruby. Again I feel like we are painting OO as problematic because we can do bad things with OO.
On the JIT subject - I am not sure what the actual criteria are for Java or CLR to decide when to compile a block of code, but if this is a concern both Java and dotnet can ahead-of-time compile to native code.
one hundo agree.
What is OO to you? Would you consider Rust structs and functions in the struct namespace, OO?
I disagree about FP, I think it's very hard to defend OO objectively compared to FP other than the fact that it has had more money dumped into it and more man-power into actual implementations. Sure we would be talking about the bad ideas in FP, but are those worse than OO bad ideas? Also, what else do we gain (we gain way more compared to OO)? It's extremely hard to make any case for OO, other than that it is more natural to explain? Although I'd toss that to manpower put into education and learning.
EXACTLY THIS ... yes sir... you got it right. I am tired of listening the usual idio... saying OO is bad, when in reality they haven't spent a good amount of time learning the patterns, and abstractions to deal with it succesfully.
Thats because OO is bad, there are better solutions in every case, depending on what you mean by OO@@ldandco
Which language is the exception to the assertion at the start of the video that popular object-oriented languages would be better without the object-orientation?
23:27 Common Lisp is on the level of fast language and memory managed, is on par with Java & C#
Ruy & Python are not fully Interpreted, they use bytecode. PERL5 is fully interpreted. Common Lisp can be interpreted or compiled to bytecode and has type inference and optimizing compiler and in some implementations you can even define a function in pure assembly language in other implementations like CLASP you have an interactive Common Lisp but also using FFI to C++ code.
Quite a serious contender for the title of Best LLVM Language Ever!
I've been waiting for Roc to become available. Cheers to Richard Feldman!
Great episode! I’ve been on a watching streak through your channel and this particular one (also Casey and Prime ones) caused me to subscribe. Great thought-provoking discussions! Keep it up Lane 👏🏼
For anyone interested, Richard’s podcast is called Software Unscripted. Great content too.
Great interview! I'm excited about Roc. I use and love F# for financial modelling and welcome a functional language with high performance as a design goal.
29:52 for those JIT compilers, why aren’t the counters persisted? I’d imagine that each loop would have its own counter for the life of the application, if a threshold is reached, then the loop would be permanently compiled. So you may only loop a handful of times each time the loop is called, but many times over the life of the application.
Richard is spot-on about OO. It's a painful truth that can make one a pariah in commercial development, which is probably why we hear it voiced so rarely.
I love videos like this. I must admit from the title I was skeptical, but I learnt a lot from this discussion, so thanks
so glad to hear :)
This was great, thanks. I was considering roc for advent of code this year, but kinda shied away from it since the lsp is still in development and it would be my first experience with a functional programming language. I love the idea behind it though, I should give it another shot. Cheers!
Totally agree on the OOP stuff but if some boss, told me that I couldn't use for loops and while loops anymore and had to use recursion instead, I would quit on the spot...
Hmmm i disagree that there is anything meaningfully different in any programming language, object, functional, imperitive are all just interfaces
you could just implement a while loop with recursion
@@ravenecho2410
No matter what you think philosophically what it is, when you have to write code in a editor the diferences are huge and require different mental gymnastics.
Take a pure OOP code base and a pure functional code base, doing the same thing, put them side by side and tell me there's "no diference" between them.
Plus they compile and run at different speeds.
@@HoD999x If I want a while loop I will just use a real while loop. ;P
Btw I have been coding for 7 years, only used recursion a handful of times, for very specific work.
You can code a entire complex, real code base and only need to use recursion once or twice, that is how important recursion is, aka is mostly useless.
So IMO people speak so much about it, because they want to show off, they know recursion requires more mental gymnastics than a for or a while loop, so they want to show off their "AAA programmer mind".
Also "is cool to write a function that calls itself" yes is cool but is also hard to read and reason by fast looking at it, a for or while loop is, you look at it, bang you immediately know your doing a loop, good for your brain to save energy. ;)
I love functional programming, but I’m with you on this one. I’d love to see a language with loops in its type system. Recursion sucks!
Lane doing awesome work, thanks sharing great stuff!
Oop is a fun way to make a puzzle out of your code that people will have to decipher later. Complexity is the primary enemy of good software engineering and I’ve learned to avoid that whenever I can.
OOP makes your code easier to understand and manage. What world do you live in?
This is only true of extreme java-esque OOP codebases and not OOP inherently. OOP is fundamentally two things: the ability to group state with behavior into instances, and the ability to abstract over those instances as constructable classes of instances, expressed using subtype hierarchies. Some people find subtype hierarchies intuitive, lots of modular organization beneficial, polymorphism useful and easy to grok. Maybe you are not one of those people, and that is not a fault of OOP. The "simplest code" is not the best code; 150 lines of direct imperative code doing only exactly what you need currently is going to read worse and be less extensible and testable than if you were to split that up as a composition of many proper sub-functions with generalized interfaces; neither of which are difficult for lots of programmers. In a sense, that refactored code is even simpler, despite involving a lot more constructs in your code, since any given piece at a time is very easy to understand even if there are many more pieces now. But, there are some programmers who somehow prefer the 150 loc zero abstraction (and zero extensibility) version because it's "simpler" (to them only). Maybe you're in that category. Brain difference mostly. Some people are wired for OOP and others are wired against it.
Another way to word it; whether or not you find "separation of concerns" correct and beneficial in software will depend on how good your brain is at switching between many separate concerns and levels of abstraction at a time while navigating your codebase. If you're bad at that, you're going to hate OOP. I'm sure that if we devised a sort of IQ test that asked questions like "An X category is a subcategory of Y which relates to a Z category structurally in Q way which ...." some programmers would excel at tracking this while others would find it as difficult to follow immediately, and that is exactly the skill you need for OOP. Analogous to how some people excel at recursion while others struggle with it. It looks like some people have higher RAM in their brain for absorbing large category hierarchies and a higher ability to philosophize about abstractions in their codebase, and those people feel drawn to OOP. The people who don't will whince when they see it and want their codebases to instead have nearly zero conceptual scaffolding (because they find it complex and hard to follow and fail to see how it immediately relates to the problem)
12:38 it depends on the scope of the project. If it is an asm-level-optimized code or very metaprogramming-intensive one, FP would be sort of bad.
“What functional principles do you use when coding in an OOP language?” is a really interesting question and I’m disappointed that Richard didn’t answer it but instead talked more about the benefits of functional languages.
It’s even a question that has useful answers that would help bridge the gap for coders to whom he’s trying to reach out.
Roc is interesting but did Elixr not fit the bill for the experience or performance?
Probably neither since Elixir isn't statically typed, not controlled for side-effects and isn't that quick (if you're shooting for "most of the time less than 5 times slower than C")
im in the middle of learning more of OOP 😅
Nothing wrong with it. 99% of the software is written in oop style. Learn it and understand how to not overdo it. There is a reason a lot of software is written this way.
Everyone need to learn it well .. even if he ended quite hating it, still you cant really call yourself programmer if you dont understand it. Functional programmers need to understand it really well so they may spit on it! 😂 I also prefer functional style.
I'd like this video but the audio is just so quiet that I had to tune everything else down just to understand things. Please fix!
Haskéll at 7:12 I guess that's the French version? 🙂
35:30 - Python is s dynamically typed language - this is why there's a whole bunch of conditionals - since it needs to divine how to invoke the operand based on the left and right types - this applies to every dynamically typed language - c is a statically typed language - this is why it's faster. This is a completely different paradigm and nothing do with functional vs. OO vs. imperative.
3:18 - Pico bytes of data? I’ve never heard anyone say that. Is that 10^-15 bytes of data? Thats extraordinary 😂 Perhaps he meant petabyte.
Hot code loading was happening on Lisp machines in the 80s. So maybe not the first.
How is caching a problem of the underlying system that produces the output, IN ANY f way ?
Whenever you say everyone else is wrong and you are right it usually means you are wrong. I am an FP fanboy, but there is great value in OOP if used responsibly. An example is if you have a stack or any subject, you would want to call it like this: stack.push(element). However, if there is no clear subject, it should be called in a way where all argument as treated equal like this: Vector.intersection(vector1, vector2). Having the intersection function inside a module gives you the intellisense that you get when you use objects. Objects where there is a clear subject, procedural when it's not. That is my approach. Also preferring structural typing so that dynamic dispatch is avoided. Interfaces are still very valuable though.
no.
That is using objects, rather than doing object orientation. May seem like a small difference, but it's VERY impactful.
@@Akronymus_ Yes, I actually meant Object Programming and not Object oriented programming. So you are correct!
How did they change their Ruby ActiveRecord models to a functional style?
Typo in Richard’s last name in the intro btw.
00:40 the man has field in his name we should listen to him
I swear people think c# still exists in 2014 and earlier.
great talk thanks you.
Please add timestamp to long videos… thanks
47:36 crying in Erlang that had live code reloading in production since 1986
Not me getting frustrated and giving up because I couldn't find the "Software Unsubscribed" podcast.
I think the podcast is called Software Unscripted.
Thanks. I watched this video again just to get the name of the podcast.@@adolfosilva3883
'OOP is not suitable for what I do therefore is it bad and no one should be allowed to use it'
Right...
As a game dev I'll be keeping my objects and OOP languages.
I don't know why it seems to be a common understanding that OOP is good for game dev. There are many people who advocate against this and advocate instead for so-called "data-oriented design". Admittedly, while I don't think OOP is particularly suitable for game dev, FP is completely unsuitable (though Naughty Dog apparently pulled it off for a while). C++ likely still reigns king, but can be leveraged in a way that is more akin to "structs with constructors/destructors" than to traditional OOP practices.
You might want to look a bit into Jonathan Blow and Casey Muratori's stuff. They're both successful programmers in the game industry who advocate against OOP.
ECS enters the chat.
@@darwinschuppan8624bunch of contrarian blowhards who have experience in one niche of the industry but make wide ranging all encompassing statements
@darwinschuppan8624 Advocating against OOP in game dev is one thing, and possibly reasonable, but replacing it with functional... that's a whole different rabbit hole, and not a pleasant one.
MMA OF SOFTWARE ENGINEERING
ruclips.net/video/LC1yxlicWUs/видео.html go fmt is such that out team has to settle on a max line length for the codebases we do, and that's been 2 years of folks being dissatisfied with the decision on something you CAN argue over, cause the go formatter does not care. you can break your function signatures, first and foremost, in a whole bunch of places. so what's the max line length on Roc? All's I'm saying is that if you claim to have an all-things-included formatter, great. Just make it all things.
RE: Functional being harder for beginners, this is only true if you are taught OO first.
I always say the problem with "Object Oriented" isn't the "Object", its the "Oriented".
What does that mean?
@@sacredgeometry objects are a tool to use when developing when they fit and are useful. Some developers will try to fit every aspect of their code into an object hierarchy when it isn't needed or useful
@@RayAndrewsDevWhat professional developer with any amount of experience doing Object Oriented Programming works like that?
So none of you know swift huh?
Give a junior programmer a large OO codebase and they will be probably able to reason about it; give them a large functional codebase and they probably will not. Since the number of developers has for ever been increasing, it means there are always a lot of junior devs. It becomes a case of economics.
I am just started the video, but already cannot agree more, and I am not even a fan of functional programming . I got my start ~20 years ago with Ruby and C#. and it took time to break out that mindset when approaching new languages. Even though a language wasn't OOP, I wanted it to be, and often attempted to use it as such, which is typically not idiomatic nor advantageous for languages that aren't supposed to be OOP.
I have come to love the style used by Zig, Go, etc., where you can associate functions with structs, but it is merely syntatic sugar, with no polymorphism or inheritance garbage.
All the things people hate about pgrogramming languages, inheritance, singletons, OOP, apple uses them all as the basis for their entire ecosystem and it runs better because they do it that way.
In my opinion, use what works best instead of being locked into an ideology such as functional or oop. I don't see how functional languages can be considered general-purpose.
Love Louis CK!
i'm with u buddy, OO sucks and its a mistake the world of programmig would be better off without it
That's way too simplistic. It's better to use everything in moderation. Pure OOP sucks, as does pure functional. But a small amount of OOP mixed with procedural programming can be a very useful abstraction or a way to control scope. Lisp was a lot of fun but totally impractical for developing a Windows GUI application.
Too long didn’t watch but just based on the intro this guy is just wrong. Functional programming is great for smaller projects where you are the only developer. When it comes to larger projects with multiple developers it becomes way too easy to write stuff that is completely incomprehensible. Readability and maintainability are way more important than any benefit you get from functional programming over OOP.
Maybe, just maybe, if you didn’t listen to the full argument it’s worth refraining from posting the comment that says “it’s just wrong”.
Food for thought.
@@idonthavefantazy nah. I’m just skeptical of people that claim one paradigm is flat out better than another. It shows a lack of maturity. There are trade offs to everything.
@@Didymus888 he didn’t though. If you watched the whole video you would hear his answer what type of problems he would not pick FP for 🤷♂️
As for your argument re. readability: readability is to the large extent the matter of habit/familiarity.
Functional code is no less readable than OOP code, once you get used to it.
WTF !! golang has nothing to do with functional paradigm, functional paradigm is declarative and golang is an imperative language. So many bootcamp plebs
OOP is almost always manages the memory and this is why it is used. It is a lazy way to do it. This is why it was adopted, I guess. Anyway ECS is better and basically utilizes functions, data and OOP to some extend.
Use time codes please. They are not hard. Also maybe refrain from clickbaity cover art. I am 30 min in and still nothing about “OOP damage”. So i’m less likely to trust the next vid with baity cover and no time codes…
Exactly disliked and clicked on don't recommend this channel so this channel gets shadow banned.
@@recursion.you two seem like whiny little babies.
It’s literally two minutes in…
Fair point. At the same time, someone's gotta pay the bills!
I've been enjoying the podcast so far regardless!😊
what the actual ... OO didn't cause issues to the industry. Programmers that used OO did. The same can happen with any other paradigm. What a load of it.
Yep. Some people really are a bit slow though, I bet once they manage to do enough programming in the paradigm they claim to fix all the problems and find the problems everyone else already knew existed they still wont get it but will just move round the circle of stupidity trying to catch a clue that they are the problem not the language or paradigm.
roc's faq says that it doesn't support higher kinded types because some devs don't know what they are lmao. As good of a speaker as he is, he's a terrible language designer if that's how he thinks. Developers should want to learn things, instead you're dumbing down a language to not scare about the bootcamp kids? Ok lol good luck with that, i don't know who your target audience is then
WTF! People waiting for Roc when we have Rust!
I feel sorry for the influence of the influencers on the influenced. This is the end.
no lifetimes? :P
Dude how do you people not understand what a general purpose programming language is.. Rust is not one and never will be, it's for systems which almost nobody who talks about actually works in lol
This is it. The worst comment I've ever read. Oh My God.
@@angelcaru The Rustaceans have a gift for this kind of thing
@@not_everas expected from the 41% crowd