Due to potential new direction of D, I’m looking for some escape route just in case. I’m primarily a gamedev, so no functional programming languages like Rust or Haskell. Also one of the features I dislike the most in C/C++ is the super slow and super obsolete precompiler with its header files, so no zig, I don’t want to open two files for editing the same class/struct. Memory safety is nice to have, but not a requirement, at worst case scenario I’ll just create struct SafeArray<Type>. Also I need optional OOP features instead of reinventing OOP with all kinds of hacks many do when I would need it.
Yes I know about OpenD, and could be a candidate for such things, just looking into alternatives.
have you tried GoLang? It’s big for game dev as of late
It has no classes
Because classes kind of suck.
It amuses me that someone downvoted
classes suck.It’s an objectively true fact.
Classes can be useful for abstraction. Just because they often overused doesn’t mean they’re bad.
Without an explicit class, I would either:
doStuff(cast(void*)&localstate, values)vslocalstate.doStuff(values)).While structured programming was a godsend to the chaos preceding it, newer programming paradigms should have been instead seen as tools rather than the next dogma. OOP got its bad name from languages that disallowed its users to develop without classes, and enterprise settings making its devs to implement things that could have been simple functions as classes, sometimes complete with factories.
Same is with functional programming. There’s clearly a usecase for it, but isn’t a Swiss-army knife solution for all problems of programming.
Well said.
Here I am trying to wind people up and you’re responding with thoughtful nuanced consideration.
You make some great points.
I’ll add - for folks reading along - I do think a class is still almost always an anti-pattern, even with all the OOP class function and factory pattern stuff removed.
I also feel (as you referenced):
And also:
State data is a necessary evil in most programs.
I’ve found that most advanced
class objectimplementations treat program state data more like a pet than a threat.Sorry for the long response - I know you don’t need it - you know what kind of tool you’re looking for.
I figure they extra detail above might provide food for thought for folks reading along who are surprised there’s even contrasting opinions on classes.
(And I feel a little bad for not really posting anything very useful earlier in the thread.)
I’ve always hated factory patterns because I find them unintuitive, but I couldn’t articulate why I find them that way or even organize the reasons why in my head. I just recognized them as a frequent source of annoying debug sessions. I envy your ability to concisely convey something like this.
You don’t need to do any of those things with Go or Rust. Interfaces/traits provide the capability for dynamic dispatch.
The problem with classes is inheritance. Inheritance is just a bad idea and a bad way to structure stuff if you ask me.
Rust fixes this neatly with traits that basically provide the same benefits as classes without any of the downsides.
Today I learned GoLang has no
class.Neat! Thanks. Sincerely.
I’ve been coding casually in GoLang for years without noticing. (I don’t use classes, because classes suck.)
Apparently GoLang doesat least have
interfaces, which are likeclassesthat don’t suck. That’s probably why I didn’t notice.https://www.geeksforgeeks.org/class-and-object-in-golang/#
Interfaces (traits in rust) are the best imo. Way better than raw structs in C or the mess that is inheritance.
What I don’t like about go’s interfaces is that they’re implemented implicitly. I much prefer java’s and Rust’s way to implicitly say which classes/structs extend/implement which interfaces.
These are extremely superficial observations. You should learn more about each of these languages before dismissing them; Go is especially easy to learn.
(I quite dislike Go, actually, but “it has no classes” is nowhere near a valid reason not to learn a language.)