Asta [AMP]object oriented programming: there are 50 classes. they all have some overlap in their venn diagram. some of the overlap is in a third or fourth dimension that cannot be graphed with human brains. your eyes register nothing but a hideous, writhing mass when you try.
Cassandra is only carbon now@aud The problem with OOP in general, IMHO, is that it couples subtypes and typeclasses in a very confusing way.
@aud You can kind of deal with that by being very disciplined about keeping your inheritance tree to zero or one levels of depth, and using fully abstract classes (interfaces) to do the bit that looks more typeclass-y, but it's very hard to add new functionality to an existing design that way without breaking back compat... so folks tend to just poke holes in the design instead.
@aud To be a little more precise, a function like `void foo(Bar bar)` and one like `fn foo<T: Bar>(bar: T) -> ()` are morally quite similar, if extremely different in literal meaning. They're both ways of saying "this function takes a value of any type that's Bar-like," but the former *also* adds that any individual value of a Bar-like type can be referred to by a binding of type Bar.
That's a very heavy additional assumption, and places severe constraints on how you organize code.
this function takes a value of any type that's Bar-like,you know what's interesting, is I haven't really had to play too many object oriented struggle games in C/C++/C-style languages, thankfully, so I wasn't actually aware of this specific distinction. Usually I just watch the compilation fail, curse loudly, cast, and move on.
@aud Yeah, basically polymorphism says that there's no difference between a type T having U-like behavior, and T being a subtype of U. So then you get that in order to do U-like things with a value of type T, you need to be able to bind it to a variable or parameter of type U, which, fine... but that leads to a lot of nonlocal confusion down the road.
@aud Consider a function like `Addable add(Addable a, Addable b)`. The clear intent is that you can add two values together of the same type together, so long as that type is addition-y. But there's a missing constraint there, namely that the two parameters are the same subtype of T.
@aud So you can solve that with `T add<T>(T a, T b)`, but now you've lost the `Addable` constraint. The most common solution I've seen is to have `T add<T: Addable>(T a, T b)`.
But there's a word for "a collection of types that can be used to satisfy a constraint on valid type parameters." It's a typeclass, or in Rust terminology, a trait. Or in C++ terminology, a concept.
Jeremy Kahn
cthos š±@cthos @aud @trochee Yeah, I almost made that point with the original post in my thread, where you have two very different ways of doing the same nominal thing, "define a function that acts on a Bar-like value."
Which one *should* an AI code generator do? Which one will an LLM trained on O(GitHub) do when it rolls the 1dOOP dice? Who knows!
@cthos @aud @trochee Like, the whole act of programming is to take some poorly defined goal, make that goal precise, come up with a design that would accomplish that goal, and then implementing that design.
You can't just YOLO your way through taking an imprecise goal to a precise and actionable goal!
@cthos "AI, sort this list for me." Motherfucker, *how*? Merge sort? Introspection sort? Bubble sort?
We even have a way of making that precise, and the AI bros just... don't do that! One of the few things I actually like about C++ is that the STL specifies things like sort in terms of guaranteed algorithmic complexity, rather than a specific algorithm, so you have a precise definition of what properties you're guaranteed when you call the STL's sort function.
@cthos But with AI? Who knows! Is your list nearly sorted? Do you need to sort it in-place? Do you need your sort to be stable under equivalence of the sorting key? Do you care more about worst-case or average-case performance?
Aaaaaaaaaaaaaaaa
@xgranade Listen, I just need it to do JortSort on everything.