You must log in or register to comment.
The day I learned that Linus shares my disdain for all things OOP was such a good day for me.
Me, when Linus’ opinion is different to mine: “Linus has such weirdly strong opinions about this”
Me when Linus’ opinion is the same as mine: VINDICATION
I feel the OOP debate got a bit out of hand. I hate OOP as well, as a paradigm.
But I love objects. An object is just a struct that can perform operations on itself. It’s super useful. So many problems lend themselves to the use of objects.
I’ve been writing a mix of C and C++ for so long I don’t even know where the line is supposed to be. It’s “C with objects”. I probably use only 1% of the functionality of C++, but that 1% is a huge upgrade from bare C IMO.
Agreed. Objects are nice and a great way to program. Composition is great. Traits/interfaces are great. Namespaces are great. Objects are a really nice way to reap the benefits of principles like these.
But then there are aspects of OOP that absolutely suck, like inheritance. I hate inheritance. The rules get very confusing very quickly. For example, try understanding overriding of methods. Do I need to call the superclass method or not? If not, does it get called automatically? If so, in what order? How do these rules change for the constructor? Now repeat this exercise for every OOP language you use and try not to mix them up… Java, C++, Python, etc.
Fortunately, it feels like we rely on inheritance less and less these days. As an example, I really like how Java allows you to implement
Runnablethese days. Before, if you wanted to run a thread, you needed a separate object that inheritedThread. And what if that object needs to inherit from another one too? Things would get out of hand quickly. (This is a very old example, but with lambdas and other new features, things are getting even better now.)Anyway, long story short, I think OOP is a complicated way to achieve good principles, and there are simpler ways to achieve those principles than a full OOP implementation.
I’ve seen this thing where people dislike inheritance a lot, and I have to admit that I kind of struggle with seeing the issue when it’s used appropriately. I write a bunch of models that all share a large amount of core functionality, so of course I write an abstract base class in which a couple methods are overridden by derived models. I think it’s beautiful in the way that I can say “This model will do X, Y, Z, as long as there exists an implementation of methods A, B, C, which have these signatures”, then I can inherit that base class and implement A, B, and C for a bunch of different cases. In short, I think it’s a very useful way to express the purpose of the code, without focusing on the implementation of specific details, and a very natural way of expressing that two classes are closely related models, with the same functionality, as expressed by the base class.
I honestly have a hard time seeing how not using inheritance would make such a code base cleaner, but please tell me, I would love to learn.
What you’re describing is an interface. An interface is a contract that ensures you can do something, but doesn’t care how.
Abstract classes can have abstract functions. When you do this, you’re basically just creating a base class with an interface on top; you’re saying “all my children must implement this interface of mine” without having to actually make a separate interface.
Abstract classes also offer additional functionality though, such as the ability to define properties, and default implementations of methods. You can even utilize the base class implementation of the method in your child class, in order to perform extra steps or format your input before you do whatever it is you were doing in the first place.
So, an interface is a contract that allows you to call a method, without having to know the specific class or implementation.
Inheritance is more like “it does everything that X does, but it also does Y and Z.” If you’re ever finding yourself writing an abstract class with purely abstract methods, you probably want to write an interface instead. That way, you get all the same functionality, but it’s more loosely coupled
Epecially when you think in “real” OOP terms:
Abstract classes are “child is a parent”, fx “duck is a bird”. Bird describes all the traits that all birds have in common. But not all birds fly, so flight must come from an interface. This interface can be passed around to any number of objects, and they’re not as tightly coupled because unlike an abstract class, an interface doesnt imply that “duck is a flight”. The interface is just something we know the duck can do.
As you can probably tell, I work with OOP on a daily basis and have for years. There are a lot of valid criticisms of the OOP philosophy, and I have heard a lot of good points for the record. I am just educating on the OOP principles because you said you were interested and to clear up any misconceptions.
Is there some lore about this I don’t know?
There is no C++ allowed in the Linux kernel and Linus has gone on several major rants about how terrible a language it is.
Is it all C?
Lots of core UNIX and Linux projects are. C++ is not liked by a lot of low level FOSS community. I think Rust is going to get further into these areas. I know C++ well but prefer C. I know plenty of others who feel the same.
I’ve read that they are writing parts of the kernel in Rust
Yes, I think Rust is a better C++ and will replace it in many places. Though all three will be around for ever to be honest.
Yes, first Rust code was released in 6.6 I think and MS also started implementing Rust code in the Windows kernel.
Rust is certainly interesting. I think it’s the C++ we need.
According to the github analysis, the kernel repository is:
- C 98.3%
- Assembly 0.7%
- Shell 0.4%
- Makefile 0.2%
- Python 0.2%
- Perl 0.1%
- Other 0.1%
So yeah, its basically all C, plus a tiny bit of assembly for very low level bootstrapping and some helper scripts.
There’s assembly and makefiles too
Less of a joke answer, there has been work to allow Rust bindings for drivers.
”C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.”
Torvalds just really dislikes C++. He’s gone on the record saying that he thinks it’s just not a good language. In his own words “C++ is just a waste, there is no design at all, just adding some scum on top of C.”
he’s not wrong
In the specific use case of kernel programming, maybe. But the Standard Template Library is awesome.
The STD is maybe the only good thing C++ has over C, and even that is awful compared to other language’s standard libraries.
I can’t name another good thing C++ has. Maybe templates. C++’s reliance on inheritance for polymorphism is awful (should’ve gone with interfaces/traits).
Not to mention the mess with all the different types of constructors that must always be implemented.
It’s just a bunch of bad design choices added on top of an old outdated language.
Linus is a C advocate btw, which make him even more goated
