I added this language to my watch list some time ago and forgot about it, until I got a notification about a new release (0.15) yesterday.
I’m someone who is familiar with system languages (C, Rust) and shell languages (Bash, Zsh, …). But don’t have much experience, at a proficient level, with any languages setting in between.
So I gave Koto’s language guide a read, and found it to be very well-written, and the premise of the language in general to be interesting. I only got annoyed near the end when I got to @base, because I’m an anti-OOP diehard 😉
I hope this one well start to enjoy some adoption.
I can’t tell if we are miscommunicating here, or if my leg is being pulled.
You are not aware of staunchly anti-OOP (object oriented programming) people existing? Anti-OOP is a majority position now (always was in my circles). And the holdout proponents would usually only defend one (limited or revisionist) way of doing it, usually referring to some specific language implementation. Long gone is the quintessential list of OOP talking points presented in C++/Java classes in the 90’s.
For people new to this, a quick search should lead to an endless stream of results. I found this one immediately which looks decent and covers good ground.
Would unfettered inheritance finally be gone for good?
Alright, then. I’ve read, like, a few Python tutorials. I thought OOP was more of a way to do things if it makes sense to. Like using a for loop vs a while loop, just on like, a language and code structure level. I didn’t realize most people didn’t like it? I hardly even know what it is lol. It’s just that I’ve not heard someone explicitly be against it. I didn’t even consider it a thing people would be pro- or anti- lmao
The context you are missing is that, for a lot of people, OOP was taught as the be-all and end-all of abstraction. I personally have seen some of my less experienced colleagues start to write code to solve a problem and immediately reach for OOP over and over again, even when this made things a lot messier (which ultimately I had to deal with…), because that is how they were told at one point was the “correct” way to do it, so I can completely sympathize with anti-OOP sentiment. On the other hand, I am not personally vehemently anti-OOP because I think that (as you have correctly observed) OOP is a perfectly fine pattern when it fits, and arguably the root problem that my colleagues had was not so much that they used OOP everywhere but that there was a tendency to not think through the consequences of their design choices.
One can be pro- or anti- any concept or thing, some options just make more sense
In my experience, nobody really knows what OOP is, everyone has a different definition.
Most of the “OOP” features are implemented in languages that are not OOP. The only one that is to me an OOP-exclusive feature is class-inheritance. So IMO OOP=class inheritance.
There is plenty of criticism about inheritance, specially among rust lovers. Since rust implements other features associated with classes, except class inheritance. Such as: methods (and self keyword), interfaces (traits), default interface method implementation.
Anti-OOPs usually argue that encapsulation and interface is a much better alternative to class inheritance.
Some things class inheritance is criticized for:
Diamond inheritance problem: If there is class A. B and C inherit from A and override its methods. D inherits B and C without overriding them. What implementation should D inherit? B or C? Same happens if only B or C overrides.
Encourages having multiple layers of abstraction: it’s not uncommon to see huge inheritance chains. MyCustomList -> OrderedVector -> OrderedList and Vector -> List -> Collection -> Iterator. Just by looking at MyCustomList, you don’t know the entire chain, you just see “OrderedVector”. You have to follow many nested links until you can know it all, and then you have to retain that knowledge along with tens of other inheritance chains.
Not ideal for performance: Inheritance encourages designs where the compiler will need to add a v-table to classes. These tables make implementation of OOP patterns much easier, but they require additional overhead when calling methods. Note that v-tables are not OOP specific, rust needs them also for trait objects. However, rust encourages designs with small amount of trait objects.
Not as intuitive as claimed: People are taught OOP with simple examples involving real-world objects like: car -> vehicle -> object. However, these situations are rare except in some specific cases like UIs, video games, simulations. In most other cases, you are dealing with concepts rather than objects. And even when you’re dealing with objects, it’s not a clear cut. Sometimes it might happen that bicycle -> car. Even though not intuitive, in some situations this may be a useful inheritance. But when bicycle inherits car, it no longer resembles the inheritance-chain of the real world, so that’s extra work for the brain.