object orientated programming is the wrong idiom for almost all problems, and even in the few cases where it makes sense, you have to be very careful or it’ll hurt you
Idk. Maybe it’s because I learned OOP first that it makes more sense to me; but OOP is a good way to break down complex problems and encapsulate them into easily understable modules. Languages like Java almost force everyone on the project to use similar paradigms and styles, so it’s easier for everyone to understand the code base. Whenever I’ve worked on large non-OOP projects, it was a hard-to-maintain mess. I’ve never worked on projects such as the Linux kernel, and I’m hoping it’s not an unmaintainable mess, so I’m pretty sure it’s possible to not use OOP on large projects and still be maintainable. I am curious if they still use OOP concepts, even though they are not using strictly OOP.
I also like procedural python for quick small scripts. And although Rust isn’t strictly OOP, it obviously borrows heavily from it. Haskell is neat, but I haven’t used it enough to be proficient or develop good sense of application architecture.
I’ve done production work in C, but still used largely OOP concepts; and the code looks much different than code I’ve seen that was written before C++ was popular.
The Linux kernel actually uses quite a bit of OOP ideas. You have modules that are supposed to have a clear interface with the rest of the world, and they (ab)use structs to basically work like objects. If you try hard enough, you can even do “inheritance” with them, like with their struct kobject. It is actually somewhat well-thought-out, imo. No need to go full OOP, just pick some of the good parts, and avoid the MappingModelFactoryServiceImpl hell or the madness that is C++.
object orientated programming is the wrong idiom for almost all problems, and even in the few cases where it makes sense, you have to be very careful or it’ll hurt you
Idk. Maybe it’s because I learned OOP first that it makes more sense to me; but OOP is a good way to break down complex problems and encapsulate them into easily understable modules. Languages like Java almost force everyone on the project to use similar paradigms and styles, so it’s easier for everyone to understand the code base. Whenever I’ve worked on large non-OOP projects, it was a hard-to-maintain mess. I’ve never worked on projects such as the Linux kernel, and I’m hoping it’s not an unmaintainable mess, so I’m pretty sure it’s possible to not use OOP on large projects and still be maintainable. I am curious if they still use OOP concepts, even though they are not using strictly OOP.
I also like procedural python for quick small scripts. And although Rust isn’t strictly OOP, it obviously borrows heavily from it. Haskell is neat, but I haven’t used it enough to be proficient or develop good sense of application architecture.
I’ve done production work in C, but still used largely OOP concepts; and the code looks much different than code I’ve seen that was written before C++ was popular.
The Linux kernel actually uses quite a bit of OOP ideas. You have modules that are supposed to have a clear interface with the rest of the world, and they (ab)use structs to basically work like objects. If you try hard enough, you can even do “inheritance” with them, like with their struct kobject. It is actually somewhat well-thought-out, imo. No need to go full OOP, just pick some of the good parts, and avoid the MappingModelFactoryServiceImpl hell or the madness that is C++.