@_supervolcano
I like listening to Casey, incredibly intelligent and thoughtful person.
@ForeverZer0
OOP is a great paradigm for humans to conceptualize ideas, but is bad for how machine code actually executes. I started with Ruby and then C# (both strong OOP) when they were each the "hot" language of the era, and it wasn't until I moved onto to C and other systems-level languages that I realized OOP is not the ideal way to program. It was a great for me from a learning perspective, but it took time to break myself of OOP practices when learning other languages.
@Terrensino
I love C++ for freedom of being able to use various high-level concepts and being able not to use them sticking to what C core of C++ already provides a programmer with.
N/A
Sounds like Casey would like Rust quite a bit. No object inheritance, static dispatch preferred, has operator overloading, has widely-used built-in suppirt for tagged unions, has much fewer problems with generics than C++ templates.
@musicaeclectica
OOP is just the singular form of oops, think about that...
@jimkerak6404
I never thought of OOP as being a tool to reach for when integrating systems.
@KoenZyxYssel
People keep blaming the theory for other peoples bad practice. Different problems require different solutions, but you're still going to have a single function/operator for adding integers, even though 0+1 differs (as a problem) from 10+1. We use abstractions (like the concept of integer addition (thanks for the help maths bros)) to define what is and what isn't "different". That's part of why generics are actually good: they help us to make abstract what needs to be abstract in order for our code to reflect our/your idea of "difference". I mostly use OOP to write the most abstract parts of my code (like an object with an int you can only read, extended with an int you can also set) and because there's little to no wiggle room in that scope I can say that if it doesn't do what I want it to do I've simply got the wrong object. It's fair to say this is also data oriented, but then what (useful code) isn't? If it works it works, who cares what it's called.
@frozenbacon
After all of these years of arguing about programming paradigms you would think there would be at least one group of people who make a project using both that can act as a definitive study so people just stop spouting what is "better" based off of vibes. Its crazy people would write a whole ass book on this stuff with the vague concept of "best based on my experience" and have zero actual examples with full context to actually point to.
@asconblake
Thanks for having Casey in this talk - I really enjoyed it. Im having an issue with my side project right now that pointed me to moving away from the object oriented idea for structuring my classes, modelling elements of the system. Yet I feel more and more that I have to redesign the whole system because of some visibility problem I soley got from this approach. It sure has its place but right now I feel like trying to jump a hoop (like in circus) only because of some OOP paranoia I was taught. Keep on going, thanks!
@Nellak2011
Based take
@fyodorx5428
I have to deal with a legacy application, ACTUAL legacy, not like "legacy from 2005", some parts date back to the mid-1970s, so they had no chance to be infested with "OOP". It's completely un-encapsulated: all the state is just nicely laid out as a global struct that anchors everything else that's important: user input, actual data, all sorts of buffers and intermediate structures, presentation data. And guess what? It has not caused any problems! The codebase is imperfect and has various problems, but the lack of "encapsulation" just isn't one of them. In fact, it makes things very simple: if a module needs access to some data, it's just there! You don't have to worry about adding it as an argument to 10 methods and as a field to 10 classes and their constructors, all of which will just receive it and pass it on until it reaches the place where it's needed. The overall coherence of the various stages of global state transformation that happen in response to certain events is a matter of good design: rules like "this thing shouldn't touch raw user input after it's been parsed" are still followed, and "encapsulation" wouldn't really help here.
@jean-michelgilbert8136
Oh man, I learned C64 BASIC and Pascal as a child. Afterwards, I learned assembly then C and finally C++.
@MagpieMcGraw
You can replicate inheritance very cleanly in C. You just put a struct inside another struct. I put an Obj struct inside my Camera struct. And thus my camera gets all the functionality of Object. I can call object_move(camera.obj) or object_update(camera.obj), and these would do the same thing as camera.move() and camera.update() in OOP languages.
@rogo7330
Methods for types that could just be copied by compiler to inherited types would be cool. For `is_valid` example, by default int have no invalid state, except when you care about it not overflowing. That's when you introduce a new integer type that does not overflow and can be checked at some point in the code that it still `is_valid`. You just bolt-in this `is_valid` method to it and that's it. It does not need to be a literall at runtime, it just needs to be a compiler command that asserts that at this point this object of this type should fullfill whatever you want with this `is_valid` method. Most of things in programs should not be exported to runtime and almost never should be visible literally in binary - that just adds more failure points in runtime.
@airman122469
Template programming can be fine. OOP… I have never been able to make good OOP. Internally things can be OOP, mostly. But anything public facing… I’ve never gotten it to be good. Ever.
@gsestream
modular, even when using oop or procedural code, c and c++ are both still viable languages, asm and java, etc.
@skaruts
I wonder what his opinion would be about Odin, which doesn't have operator overloading, but has array arithmetic.
@easyBob100
I'd have to disagree with some of what he's saying. It does depend on what you're doing. I've written a c++ abstraction to CUDNN, it uses both templates and inheritance. The templates are dealt with at compile time (you don't want to be testing for types at run time/training time, cudnn uses A LOT of void pointers), and the inheritance creates clear separation of functionality. For example, the function in cudnn that let's you do basic add/multiply/etc is all one function in C. You set a flag to change the function in what they call a descriptor to tell it what operation to do. Instead, you can just have a base class that calls that function while the child classes pass the flag in during construction. As long as there are not virtual functions (I agree vtable=bad/slow) you'll be good. IMHO.
@geriatricprogrammer4364
If OOP is so fantastic, why does the verb cheat exist in C++ to allow you to reference methods of objects have not inherited?
@mkwpaul