OOP is TRWTF

[topspin]

@boomzilla said in OOP is TRWTF:

@Carnage said in OOP is TRWTF:

@Dragoon said in OOP is TRWTF:

Since this is now the Haskell thread:
https://insights.dice.com/2019/07/29/5-programming-languages-probably-doomed/

Note: The article is utter trash

This comment...

We need to do more with object-oriented classes. Programming needs to become simpler – not harder. It needs to make objects do the nitty-gritty work. It needs to de-geek itself and become user-friendly in the extreme. It needs to do away with the acronyms. It should be more like BASIC, with objects that extend its usefulness to the max. Saving, opening, reading and resaving any file should be built in. Access to changing pixels and saving them in any lossless format (and every format should be lossless) should be easy. Pixel colors should be assigned numbers with a base of 256 in which to both read them and write them with. Going to a specific address, to use the data there, should instead take the form of nesting data in arrays.

It's like a 12-year-old-blakey blakeyrant.

Damn it, I wanted to post that.

Sounds like it’s from the free-for-all wishful thinking school of language design.

[Gąska]

@topspin when switching from a == b to a.field1 == b.field1 && a.field2 == b.field2 && a.field3 == b.field3 yields a 10x speedup (YES I DID ACTUALLY MEASURE IT WITH PROFILER), something is very wrong with that equality operator. And I know it's reflections because I actually researched this particular thing and I did find multiple independent anonymous sources talking about how the default == on structs does something with reflections so any serious C# code absolutely must provide a custom overload if they want performance. Also, tuples have the same problem, but in their case you can't do anything about it.

[mott555]

@Gąska Makes sense to me, if the struct author doesn't provide an override of .Equals(), then reflection is the only option left by the runtime.

[topspin]

@Gąska The wasn’t directed at you.

@mott555 said in OOP is TRWTF:

@Gąska Makes sense to me, if the struct author doesn't provide an override of .Equals(), then reflection is the only option left by the runtime.

It could just provide a default implementation that does the sane thing without reflection.
Or is that not possible because of partial classes?

[mott555]

@topspin said in OOP is TRWTF:

@Gąska The wasn’t directed at you.

@mott555 said in OOP is TRWTF:

@Gąska Makes sense to me, if the struct author doesn't provide an override of .Equals(), then reflection is the only option left by the runtime.

It could just provide a default implementation that does the sane thing without reflection.
Or is that not possible because of partial classes?

How can the default implementation look up its members without using reflection? As far as I understand, the only way to discover fields at runtime is via reflection, and the only way around this is for the struct definition to handle .Equals() or == itself.

(Also, in C#--and this is a implementation detail and not a contract--structs are allocated on the stack and copied by value instead of passing references around. So taking a shortcut and checking the memory address to see if two objects are the same, like some classes might do, will never work with structs under the current implementation.)

[Gąska]

@topspin said in OOP is TRWTF:

@Gąska The wasn’t directed at you.

Oh, okay then. Sorry for the outburst.

@mott555 said in OOP is TRWTF:

@Gąska Makes sense to me, if the struct author doesn't provide an override of .Equals(), then reflection is the only option left by the runtime.

Yeah, it's not like the language designers coming up with the original design for C# 1.0 had any power to specify semantics of a language construct that the sole purpose of was to provide maximum performance. No, it was entirely outside of Microsoft's control.

[Gąska]

@mott555 said in OOP is TRWTF:

@topspin said in OOP is TRWTF:

@Gąska The wasn’t directed at you.

@mott555 said in OOP is TRWTF:

@Gąska Makes sense to me, if the struct author doesn't provide an override of .Equals(), then reflection is the only option left by the runtime.

It could just provide a default implementation that does the sane thing without reflection.
Or is that not possible because of partial classes?

How can the default implementation look up its members without using reflection?

C++ does have default implementations of == for all structs and it does not use reflection.

[topspin]

@Gąska said in OOP is TRWTF:

@mott555 said in OOP is TRWTF:

@topspin said in OOP is TRWTF:

@Gąska The wasn’t directed at you.

@mott555 said in OOP is TRWTF:

@Gąska Makes sense to me, if the struct author doesn't provide an override of .Equals(), then reflection is the only option left by the runtime.

It could just provide a default implementation that does the sane thing without reflection.
Or is that not possible because of partial classes?

How can the default implementation look up its members without using reflection?

C++ does have default implementations of == for all structs and it does not use reflection.

It doesn’t afaik (I think it’s scheduled for C++20, but I’m not up to date). But yeah, that was the idea behind my remark. It provides default implementations for other things (destructor etc.). Also, tuple has ==.

So the C# compiler should just go ahead and at compile time create an implementation that does member-wise compare instead of doing the same at runtime with reflection.

I mean, even getting a compiler error would be more useful than this, so at least you’d be forced to provide a sane implementation.

[error]

Is this really a problem you encounter frequently? The only time I can think where I compare structs or objects by-value is when they're actually a tuple of some kind (but then System.Tuple has you covered).

[Gąska]

@topspin said in OOP is TRWTF:

@Gąska said in OOP is TRWTF:

@mott555 said in OOP is TRWTF:

@topspin said in OOP is TRWTF:

@Gąska The wasn’t directed at you.

@mott555 said in OOP is TRWTF:

@Gąska Makes sense to me, if the struct author doesn't provide an override of .Equals(), then reflection is the only option left by the runtime.

It could just provide a default implementation that does the sane thing without reflection.
Or is that not possible because of partial classes?

How can the default implementation look up its members without using reflection?

C++ does have default implementations of == for all structs and it does not use reflection.

It doesn’t afaik

Right, sorry. I haven't written C++ in a very long time and got some details mixed up.

So the C# compiler should just go ahead and at compile time create an implementation that does member-wise compare instead of doing the same at runtime with reflection.

I mean, even getting a compiler error would be more useful than this, so at least you’d be forced to provide a sane implementation.

+1

[Gąska]

@error said in OOP is TRWTF:

Is this really a problem you encounter frequently?

No, because I learned my lesson and avoid it like fire now. Like iostream library in C++ - I don't experience any problems with it because I've switched completely to cstdio.

[mott555]

C# structs are pretty rare, and they're odd enough that you shouldn't pick structs over classes unless you know their quirks, have a compelling reason, and are willing to do things like override .Equals(). It's also possible there are a bunch of calculated properties with no backing variable, or that provide different views of the same field or something, and a naive memberwise check would end up checking a bunch of potentially-slow properties that a custom .Equals() would skip.

In short, C# structs are really weird.

[powerlord]

@mott555 said in OOP is TRWTF:

C# structs are pretty rare, and they're odd enough that you shouldn't pick structs over classes unless you know their quirks, have a compelling reason, and are willing to do things like override .Equals(). It's also possible there are a bunch of calculated properties with no backing variable, or that provide different views of the same field or something, and a naive memberwise check would end up checking a bunch of potentially-slow properties that a custom .Equals() would skip.

In short, C# structs are really weird.

For any data class, not overriding Equals is a wtf.

[mott555]

@powerlord said in OOP is TRWTF:

For any data class, not overriding Equals is a wtf.

I've overridden .Equals() maybe once or twice, ever. It's not something I worry about unless it's needed.

[_P_]

Wait, does anyone use struct at all in C# except for Vectors (which is used a lot because of Unity)? It seems to me that they cause nothing but lots of confusion whenever they're used because nobody bothers to understand how they work, unless you really need that performance, but you'd be implementing it yourself by then.

[Parody]

@_P_ said in OOP is TRWTF:

Wait, does anyone use struct at all in C#...?

I've used them for interop calling into C libraries, but not outside of that.

[WPT]

@_P_
I have used them for custom messaging systems, where I do not want users to override the underlying data. So instead of passing by reference, I chose passing by copy. But still, C# struct still has its limited use-cases. Unless one is absolutely sure of what he/she is implementing/designing, just stay away from structs....

[pie_flavor]

@_P_ said in OOP is TRWTF:

Wait, does anyone use struct at all in C# except for Vectors (which is used a lot because of Unity)? It seems to me that they cause nothing but lots of confusion whenever they're used because nobody bothers to understand how they work, unless you really need that performance, but you'd be implementing it yourself by then.

Huh? What do you mean they're confusing? How is the concept of a value type confusing? Not to mention, no, the stdlib is absolutely peppered with them (date-times, GUIDs, etc.).

[pie_flavor]

@powerlord said in OOP is TRWTF:

@mott555 said in OOP is TRWTF:

C# structs are pretty rare, and they're odd enough that you shouldn't pick structs over classes unless you know their quirks, have a compelling reason, and are willing to do things like override .Equals(). It's also possible there are a bunch of calculated properties with no backing variable, or that provide different views of the same field or something, and a naive memberwise check would end up checking a bunch of potentially-slow properties that a custom .Equals() would skip.

In short, C# structs are really weird.

For any data class, not overriding Equals is a wtf.

For any language with a concept of data classes, requiring overriding equals is a wtf.

[pie_flavor]

@topspin said in OOP is TRWTF:

So the C# compiler should just go ahead and at compile time create an implementation that does member-wise compare instead of doing the same at runtime with reflection.

It doesn't even need to do that. Just do the C# equivalent of

const size: usize = mem::size_of::<TheStruct>();
let a: [u8; size] = mem::transmute(the_struct);
let b: [u8; size] = mem::transmute(the_struct2);
a == b

[Applied Mediocrity]

@pie_flavor said in OOP is TRWTF:

It doesn't even need to do that

What about floating-point +0.0 and -0.0? Arguably, they're equal, but CLR doesn't know you might be storing floating-point in your struct, so it needs to check every field with reflection in case you do.

f/e: I skimmed an article about this last night and this is all I remember.

[topspin]

@pie_flavor @Applied-Mediocrity It doesn't really matter one way or another. If the compiler front-end generates the code equivalent of a member-wise copy, the optimizer will figure out if that can be replaced by a memcmp or not.

[Applied Mediocrity]

@topspin Yes, but how else us, managed peasants, are supposed to deliver code metrics while also earning a chunk?

Suppose me, a managed peasant, is using structs everywhere, but then I find out they're actually slow. Then I piss around with the profiler, Google some stuff, fix the problem with 2k LoC of Equals overrides, push an update and have written myself, say, a new graphics card, and life is good

[dkf]

@Carnage said in OOP is TRWTF:

Like... What?

That crazy old user needs to put down his browser and switch off his computer until such time as all the software on it is delivered to him on disk (I guess he'll accept DVDs if they're read-only) as it is currently all delivered online and is thus vulnerable to trouble and teh haXXorz!!!

[dkf]

@pie_flavor said in OOP is TRWTF:

How is the concept of a value type confusing?

It isn't. The quirks of how they implemented them do seem to be confusing though.

[DogsB]

@Carnage Another tibit from that comment

The fact is, we need more programmers and we’re not getting enough of them

No. We have too many bad ones at the moment. We need to raise the bar and weed out the scala hacks.

*edit. Wow! that comment got very weird towards the end.

[Carnage]

@DogsB said in OOP is TRWTF:

@Carnage Another tibit from that comment

The fact is, we need more programmers and we’re not getting enough of them

No. We have too many bad ones at the moment. We need to raise the bar and weed out the scala hacks.

*edit. Wow! that comment got very weird towards the end.

Yeah, he was veering into coherent SpecateSwamp territory that at the end.

[pie_flavor]

@dkf said in OOP is TRWTF:

@pie_flavor said in OOP is TRWTF:

How is the concept of a value type confusing?

It isn't. The quirks of how they implemented them do seem to be confusing though.

What are those quirks?

[DoctorJones]

@topspin said in OOP is TRWTF:

Encapsulation is the trojan horse of OOP.
What we have never been told is that encapsulation, in fact, is glorified global state.

Wow, I missed that one. I couldn't muster the mental capacity to cut through all of his drivel, because it was too cringeworthy. But if that's a good representative line, wow.

It's a real case of "you keep using that word...".

It's always fun when someone tries to write a rant about something they don't fully understand.

@Gąska said in OOP is TRWTF:

OOP and FP aren't at odds. You can use both at the same time

If the OP ever reads this, I think it might be too much to wrap his head around.

[dkf]

@pie_flavor said in OOP is TRWTF:

What are those quirks?

According to what I have read in this thread, equality on structs is done through reflection in C#. That seems weird to me.

[pie_flavor]

@dkf but it has no bearing on semantics. Nothing is any more confusing code-wise.

[Gąska]

@pie_flavor said in OOP is TRWTF:

@dkf but it has no bearing on semantics.

Yes, semantics matter, but there's also real life. Move constructors in C++ were the biggest revolution in that language's entire history, even though semantics didn't change almost at all.

[mott555]

@pie_flavor said in OOP is TRWTF:

@dkf said in OOP is TRWTF:

@pie_flavor said in OOP is TRWTF:

How is the concept of a value type confusing?

It isn't. The quirks of how they implemented them do seem to be confusing though.

What are those quirks?

The one that's bitten me the most was passing a struct into a function that thinks it can modify the struct, then finding the original struct hasn't changed once the function returned. The function was operating on a copy of the struct, not the original, and the copy was popped off the stack and discarded after it was modified, and whoever wrote the code didn't realize structs are copied around instead of passed by reference.

Then, I've seen code that tries to work around that by passing a reference to the struct, e.g. void myFunction(ref SomeStructType aStruct), only to blow up due to race conditions/untimely callbacks/multithreading issues when the original struct gets popped out of the stack while something else has a reference to it.

Usually, this happens because someone somewhere read that "Structs are faster than classes!" and started using them without trying to understand them, which is also tricky because a lot of docs will say "Structs go on the stack and not the heap, unlike classes, but don't tell anyone this because it's a .NET implementation detail and is not guaranteed behavior and could change with future version."

[pie_flavor]

@mott555 That's not a "quirk" of the struct though. That's the entire point of a struct. What language can you possibly come from where you have never heard of a value type before? It's like saying that nobody should use static classes because they have this quirky behavior that prevents them from being instantiated.

[pie_flavor]

@Gąska said in OOP is TRWTF:

@pie_flavor said in OOP is TRWTF:

@dkf but it has no bearing on semantics.

Yes, semantics matter, but there's also real life. Move constructors in C++ were the biggest revolution in that language's entire history, even though semantics didn't change almost at all.

I'm not sure that had anything to do with what I said.

[mott555]

@pie_flavor said in OOP is TRWTF:

@mott555 That's not a "quirk" of the struct though. That's the entire point of a struct. What language can you possibly come from where you have never heard of a value type before?

Mainly, Java (or Java as it was 10 years ago, I haven't really touched it since then).

[Gąska]

@pie_flavor certain ways of using C# structs are bad because PERFORMANCE and nothing else. C++ move constructors are great because PERFORMANCE and nothing else.

[boomzilla]

@pie_flavor said in OOP is TRWTF:

That's not a "quirk" of the struct though.

[pie_flavor]

@mott555 said in OOP is TRWTF:

@pie_flavor said in OOP is TRWTF:

@mott555 That's not a "quirk" of the struct though. That's the entire point of a struct. What language can you possibly come from where you have never heard of a value type before?

Mainly, Java (or Java as it was 10 years ago, I haven't really touched it since then).

Java has value types. Only eight of them, but it's got them

[dfdub]

@mott555
So, as always, programmers who don't understand low-level details like memory locations and calling conventions are TRWTF and struct works just fine.

[dfdub]

@Dragoon said in OOP is TRWTF:

Since this is now the Haskell thread:
https://insights.dice.com/2019/07/29/5-programming-languages-probably-doomed/

Note: The article is utter trash

From the comments:

But I wouldn’t hold my breath for a Cobol job, or soon, Ruby…

If only that guy knew anything about the job market for Cobol programmers. They may have horrible jobs, but they're very well-compensated and in high demand.

[mott555]

@dfdub said in OOP is TRWTF:

@mott555
So, as always, programmers who don't understand low-level details like memory locations and calling conventions are TRWTF and struct works just fine.

75% of the programmers I've ever met don't even understand basic programming fundamentals. Toss structs at them and their computer will spontaneously combust, so the safest thing to say in C# land is "Structs are weird, don't use them unless you really have a compelling case."

If you're coming from a C background, it's different. But our universities are churning out people with Java, JavaScript, and some Ruby and Python, plus a bit of whatever the hipster-language-of-the-week is.

[dfdub]

Another good one. I think I found Dilbert's PHB in the comments:

Actually, all are going away. There’s no reason an AI couldn’t map business logic, in a formalized but pretty sloppy natural language, directly into, say, llvm internal representation code. It will develop its own IR language eventually too, something that works more like biochemistry: massively parallel, redundant, evolutionary.

I wonder if that person wrote something similar about MongoDB 5 years ago.

[dfdub]

@mott555 said in OOP is TRWTF:

If you're coming from a C background, it's different. But our universities are churning out people with Java, JavaScript, and some Ruby and Python, plus a bit of whatever the hipster-language-of-the-week is.

I wouldn't trust a university that doesn't teach low-level details or non-interpreted languages without huge runtimes at all. Some kind of assembly in their hardware class, a bit of C in the OS class, or at least some C++ or Rust in an algorithms course?

If your B.Sc. courses for Computer Science don't require at least one of those, you're studying at WTF-U.

[error]

@dfdub said in OOP is TRWTF:

Actually, all are going away. There’s no reason an AI couldn’t map business logic, in a formalized but pretty sloppy natural language, directly into, say, llvm internal representation code. It will develop its own IR language eventually too, something that works more like biochemistry: massively parallel, redundant, evolutionary.

I'm imagining the s that would ensue if he got what he wished for.

"The computer does exactly what you tell it to do, no more and no less," is both the easiest and the hardest thing for users to grasp.

[dfdub]

@error said in OOP is TRWTF:

"The computer does exactly what you tell it to do, no more and no less," is both the easiest and the hardest thing for users to grasp.

In the case of AI, it's more like "you better pray you trained the computer to do what you think you trained it to do".

[DogsB]

A man that is a bit too fond of his factories but otherwise solid advice.

https://medium.com/better-programming/fp-toy-7f52ea0a947e

[dkf]

@dfdub said in OOP is TRWTF:

So, as always, programmers who don't understand low-level details like memory locations and calling conventions are TRWTF and struct works just fine.

Just been dealing with a student who doesn't understand the difference between float and unsigned int.

[boomzilla]

@dfdub said in OOP is TRWTF:

Another good one. I think I found Dilbert's PHB in the comments:

"Actually, all are going away. There’s no reason an AI couldn’t map business logic, in a formalized but pretty sloppy natural language, directly into, say, llvm internal representation code. It will develop its own IR language eventually too, something that works more like biochemistry: massively parallel, redundant, evolutionary."

I'm sure it will work just as well as using natural language to communicate system requirements from business users to developers does!

[pie_flavor]

@mott555 That really is the dumbest thing I've ever heard of. What's wrong with "it behaves like int except you can make your own"?