Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

Obviously I realize we can prove theorems. If I didn't realize it was possible to prove things I wouldn't claim things were provable. This is false by contradiction with my previous statements. Your worldview of me isn't consistent.

> You also failed to address the gazillions of abstractions that don't have errors, some of which I have listed along with linear algebra.

Why should I have to prove that abstractions without error don't exist? They do. I never claimed they didn't. My point was that abstractions with error reduce computational complexity. This gives them room to outcompete perfect abstraction for sufficiently complex problems. It honestly seems insane to me to not believe what I'm saying is true, because it is true. I can't fathom how the concept would be impossible to grasp. Showing that we regularly use error filled abstractions is more important than demonstrating something I don't intend to show.

> The OP was not discussing learning at all.

I literally quoted him saying there was never a reason to teach bad abstractions. Teaching is related to learning. Abstractions are related to abstractions. So abstraction and learning were a topic of discussion. Even the original post we're under is about teaching programming technique. Which is about learning, because of the relationship between teaching and learning. It is also about abstraction, because problem modeling is very related to abstraction.

> "all abstractions have errors"

Ctrl + F shows no instance of this except for you saying it. What do you think I'm claiming? I'm really confused? You seem to think I'm saying something I'm definitely not saying.

Notice how when I said it I put parantheses and explained my reasoning as to why I felt your claim was your claim? You meanwhile misquote me. Strict quotes imply actual attribution, but I never said what you claimed I said.

I don't want to talk to you anymore. I very much don't appreciate your comparison to someone who just makes stuff up. I found that very rude and insulting. A kind person would help correct me if my reasoning was wrong and I would appreciate it, but you haven't done that. When you quoted me, it wasn't even something I said or tried to argue. If you were trying to make someone have a worse day, congratulations, you did.

I despise that you lied about whether we were talking about learning and abstraction. I don't like talking with people who blatantly lie. I consider lying bad.

I also dislike that you misquoted me. You put quotes around words I didn't say. I didn't do that to you. You say that I did. You lie when you say that. I gave you my interpretation of what I felt you were claiming. I even explained why I felt you claimed that. This wasn't under the quote symbol. Yours was inside quotes. Yours was a lie. Mine had your original quote, unaltered, with my interpretation below it. I was in error. I admit that. I was trying to get at the heart of my point - that erroneous abstractions aren't inherently bad. Outcome error is much more important than input error.

I don't agree that you've taught me anything - you just try to call me incoherent because what I'm saying is true but you employ motivated reasoning to avoid having to refute it. If you actually understood what I'm saying - which obviously you don't, which is a big part of the problem here, you would agree with me. Or at least, I think you would.

That simple problems are easier to solve and sometimes an actual solution is better than no solution really isn't that complicated a thing. Or controversial. I'm sure plenty of people understand it.

There are so many times in life where my point holds. The use of floating point is one. Perhaps you didn't notice that ML engineers frequently choose to move from float64 to float32 to float16 to float8? Perhaps you didn't notice that services all throughout the computing industry choose to meet an SLA, minimizing latency sometimes at the cost of optimal solutions whose computation isn't realistic given their computing budget. I don't know. But you're definitely not actually teaching me anything. Your just not understanding me. So this conversation is pointless.

I'm still just as convinced of the truth of the idea that it can be very wise to accept a bad abstraction, one that has error, rather than a perfect abstraction. I can't even fathom how to go about the opposite. How would a child go from knowing nothing to knowing everything perfectly without moving through areas of bad abstraction along the way?

I feel you are mean. I'd rather we stop talking about this together if we're not going to actually engage with each other on the topic under discussion.

- When we tried to solve chess we couldn't, the branching factor was too much.

- Go, it was horrendous there too.

- Poker, terrible there too.

But you want to dismiss me on the basis of jargon right? So here you go. Bellman coined the term curse of dimensionality. Combinatorial explosions happen because of branching factors in game graphs. Computational complexity for algorithms are defined with respect to this graph in both time and space for many learning algorithms. Because the games get so big the curse of dimensionality forces problem relaxation. I used ~words~. I must be an idiot. Feel free to dismiss me, I guess. I heard you heard someone else use words once and they were ~wrong~.

Hey wait a second. You're using words too. Does that mean everything you say is wrong?

Or with a record you just explicitly implement typeclass methods in reference to the contained data.

If you mean doing it without doing a typeclass, well the functions need to have different names. If that’s exactly what you want. In order to have the same function name you need a typeclass.