OOP is TRWTF

[ObjectMike]

@error said in OOP is TRWTF:

@dfdub said in OOP is TRWTF:

Assuming that keywords mean exactly the same in different languages is not the best idea in general.

const in JS is equivalent to readonly|final|val (C#, Java, Kotlin) and notably signifies neither immutability nor a JIT-time constant value.

---

Filed under: And JS is a good language.

That's one feature I miss from C++, const correctness.

[Gąska]

@mikehurley guess which language also has const correctness (and done it better than C++!)

[Carnage]

@Gąska said in OOP is TRWTF:

@mikehurley guess which language also has const correctness (and done it better than C++!)

Wild ass guess, but Rust? (I haven't looked into rust at all, and I am very good at forgetting stuff so everything I read about it here I've forgotten) Everyone seems to talk up rust these days, so it wouldn't surprise me if it has const correctness.

I do miss const correctness from C++, and I have ever since I started working in other languages.

[cvi]

@mikehurley said in OOP is TRWTF:

That's one feature I miss from C++, const correctness.

Good news. C++20 is scheduled to deliver more const than ever before:

• plain old const
• constexpr
• consteval
• perhaps constinit

[ObjectMike]

@Gąska said in OOP is TRWTF:

@mikehurley guess which language also has const correctness (and done it better than C++!)

To be clear of what I'm talking about --

C++ allows you to mark functions as "const" meaning the compiler won't allow them to change any object state. I believe (may be wrong) it also included checks against child objects (const function calls a child's mutating function) since those children are part of the object's state. In something like scala or kotlin you can get a lot of that by using val instead of var, but C++ would also allow you to lock down a whole function so it couldn't modify any vars either.

I am not talking about var vs val for local variables or fields. From what I remember, "const correctness" only refers to what I described with functions, at least in C++ lingo.

[topspin]

@cvi said in OOP is TRWTF:

@mikehurley said in OOP is TRWTF:

That's one feature I miss from C++, const correctness.

Good news. C++20 is scheduled to deliver more const than ever before:

• plain old const
• constexpr
• consteval
• perhaps constinit

God damn, more stupid special cases to read up on because constexpr isn’t.

[topspin]

@mikehurley the effect is basically what you’d get if you think of the this pointer as explicit. Normal methods take an unqualified T* this, const methods take a const T* this. The rest follows from the normal rules for const variables and overload resolution.
The same goes for && and volatile qualifiers on methods, the latter of which are to be removed afaik.

Also, yes, he was talking about rust. Not sure if the better only is about const by default or if there’s more to it.

[Gąska]

@mikehurley said in OOP is TRWTF:

@Gąska said in OOP is TRWTF:

@mikehurley guess which language also has const correctness (and done it better than C++!)

To be clear of what I'm talking about --

C++ allows you to mark functions as "const" meaning the compiler won't allow them to change any object state. I believe (may be wrong) it also included checks against child objects (const function calls a child's mutating function) since those children are part of the object's state.

Yes, that's what I'm talking about (and yes, you're right about child objects). Rust has all that too, with a few improvements. First, it's not just checking for constness (in Rust it's called immutability), but also for whether a value was moved - once it's gone, it's gone, and you can't mistakenly call any methods on it anymore. Second, when you have an immutable reference to an object, it statically guarantees that nobody else can mutate the value either for as long as you have that reference - you can safely assume that even if you call random callbacks you've received, even if there's other threads running, even if you took hours to do your part, a vector with length 5 stays at length 5.

Edit: and as @topspin pointed out, everything is immutable by default.

[topspin]

@topspin It's late and I'm not thinking clearly, but current thoughts are:

• constinit: why doesn't constexpr do that?
• consteval: why would you want that?

Waiting for static constevalconstinit constexpr const int x = 42; for maximum redundancy.

[Parody]

@topspin said in OOP is TRWTF:

@topspin It's late and I'm not thinking clearly, but current thoughts are:

• constinit: why doesn't constexpr do that?
• consteval: why would you want that?

Waiting for static constevalconstinit constexpr const int x = 42; for maximum redundancy.

Maybe C++23 will roll it all up into constall, which applies all of the consts that apply at that point of compliation. This may, however, cause conflict with the proposed addition of constconst.

[error]

Luckily, there's const_cast.

[cvi]

@topspin said in OOP is TRWTF:

constinit: why doesn't constexpr do that?

(It's too late as you say.)

consteval: why would you want that?

I read somewhere that it's partially in preparation for upcoming compile time reflection and additional meta-programming stuff. Essentially, it paves the way for defining standard library functions that don't make sense in a run-time context (e.g., manipulating types, but with a "normal" function-like syntax, instead of the template mess).

Waiting for staticconstevalconstinit constexpr const int x = 42; for maximum redundancy.

Go for CUDA, and throw in an additional __constant__ into that declaration.

[Parody]

@error said in OOP is TRWTF:

Luckily, there's const_cast.

Maybe that's what constconst tries to prevent: no casting, no converting, no taking addresses. Actually, just don't use that variable at all. :)

[Gąska]

@Parody said in OOP is TRWTF:

Actually, just don't use that variable at all. :)

A lot of standard library functions should be marked as constconst.

[topspin]

@Parody said in OOP is TRWTF:

This may, however, cause conflict with the proposed addition of constconst.

[pie_flavor]

@sockpuppet7 said in OOP is TRWTF:

Structs seem simple enough that I guess most people won't feel they need to look at that.

How can they be simple enough that you don't feel the need to look into whether they have value semantics? The entire point of a struct is its value semantics; if they seem simple enough but you don't know they have value semantics then you would have to believe they have some other purpose that they don't actually.

[pie_flavor]

@Carnage said in OOP is TRWTF:

@Gąska said in OOP is TRWTF:

@mikehurley guess which language also has const correctness (and done it better than C++!)

Wild ass guess, but Rust? (I haven't looked into rust at all, and I am very good at forgetting stuff so everything I read about it here I've forgotten) Everyone seems to talk up rust these days, so it wouldn't surprise me if it has const correctness.

I do miss const correctness from C++, and I have ever since I started working in other languages.

It's not meant to be a wild ass guess. The crab is one of the Rust symbols (hell knows why).

[DogsB]

@boomzilla said in OOP is TRWTF:

@mott555 said in OOP is TRWTF:

@topspin Back to the original point, (I don't even remember who made it), .Equals() / == is slow on structs that don't override those because the runtime has to use Reflection to discover all fields and do a memberwise equality check. Somehow, people found this surprising, when anyone who understands why "C# structs are different" ought not be surprised by this...which of course fell into a bunch of nearly-unrelated pissing contests over whether or not structs are weird.

A lot of the crowd around here assumes everyone should be as much of a language standards nerd as they are. Or that they have a degree in programming.

A lot of that crowd should realise by now that to most of us software development is a job not a vocation.

[dkf]

@pie_flavor said in OOP is TRWTF:

The crab is one of the Rust symbols (hell knows why).

Maybe it gives you cancer?

[topspin]

@pie_flavor said in OOP is TRWTF:

The crab is one of the Rust symbols (hell knows why).

cRUSTacean.
Oh, you meant a good explanation? Sorry, I got nothing.

[dfdub]

@DogsB said in OOP is TRWTF:

@boomzilla said in OOP is TRWTF:

@mott555 said in OOP is TRWTF:

@topspin Back to the original point, (I don't even remember who made it), .Equals() / == is slow on structs that don't override those because the runtime has to use Reflection to discover all fields and do a memberwise equality check. Somehow, people found this surprising, when anyone who understands why "C# structs are different" ought not be surprised by this...which of course fell into a bunch of nearly-unrelated pissing contests over whether or not structs are weird.

A lot of the crowd around here assumes everyone should be as much of a language standards nerd as they are. Or that they have a degree in programming.

A lot of that crowd should realise by now that to most of us software development is a job not a vocation.

That's not really an excuse for not understanding or not wanting to understand your own specialty, though. "I've never needed to know this before" is not a sentence that any professional should ever say when things go wrong.

Yep, software development is just a job. That's why I don't want to work for a company which expects you to have side projects or learn new stuff in your own free time. But that's not an excuse for only knowing the bare minimum to be able to believably pretend to management that you can perform your job duties and a general lack of curiosity.

Edit: Before the flamewar continues: This is supposed to be a general statement, unrelated to the specific topic discussed above.

[boomzilla]

@pie_flavor said in OOP is TRWTF:

How can they be simple enough that you don't feel the need to look into whether they have value semantics?

TDEMSYR

Why would I even think about that?

[DogsB]

@dfdub said in OOP is TRWTF:

@DogsB said in OOP is TRWTF:

@boomzilla said in OOP is TRWTF:

@mott555 said in OOP is TRWTF:

@topspin Back to the original point, (I don't even remember who made it), .Equals() / == is slow on structs that don't override those because the runtime has to use Reflection to discover all fields and do a memberwise equality check. Somehow, people found this surprising, when anyone who understands why "C# structs are different" ought not be surprised by this...which of course fell into a bunch of nearly-unrelated pissing contests over whether or not structs are weird.

A lot of the crowd around here assumes everyone should be as much of a language standards nerd as they are. Or that they have a degree in programming.

A lot of that crowd should realise by now that to most of us software development is a job not a vocation.

That's not really an excuse for not understanding or not wanting to understand your own specialty, though. "I've never needed to know this before" is not a sentence that any professional should ever say when things go wrong.

Yep, software development is just a job. That's why I don't want to work for a company which expects you to have side projects or learn new stuff in your own free time. But that's not an excuse for only knowing the bare minimum to be able to believably pretend to management that you can perform your job duties and a general lack of curiosity.

Edit: Before the flamewar continues: This is supposed to be a general statement, unrelated to the specific topic discussed above.

Quite a few people on the forum do this as work and a hobby. They don't appear to grasp that not everyone feels the same about software development. They think like Martin Fowler. You must study the craft for 20 hours a week outside of work! Calm down bob. It's just work for most of us. Nothing to get that excited about. On the other hand you're not likely to excel and break into higher pay packets without putting in that extra work.

To be fair though this structs .equals() thing does sound like something that anyone using them should know. Reminds me of HashMaps in java. When you pull iterators out of them you can't guarantee the order of the items. Everywhere I've worked I've had to fix a bug related that.

[dkf]

@DogsB said in OOP is TRWTF:

Reminds me of HashMaps in java. When you pull iterators out of them you can't guarantee the order of the items. Everywhere I've worked I've had to fix a bug related that.

I'll take “what is LinkedHashMap and why would you care?” for 10, Bob.

[DogsB]

@dkf said in OOP is TRWTF:

@DogsB said in OOP is TRWTF:

Reminds me of HashMaps in java. When you pull iterators out of them you can't guarantee the order of the items. Everywhere I've worked I've had to fix a bug related that.

I'll take “what is LinkedHashMap and why would you care?” for 10, Bob.

That's rarely the answer too.

[dfdub]

@DogsB said in OOP is TRWTF:

They think like Martin Fowler. You must study the craft for 20 hours a week outside of work! Calm down bob. It's just work for most of us.

I think there's a sane middle ground: It's just work and shouldn't affect your private life, but you should also care about what you're doing, stay curious and act like a professional. Many programmers don't do any of that, which is why this site exists.

[boomzilla]

@dkf said in OOP is TRWTF:

@DogsB said in OOP is TRWTF:

Reminds me of HashMaps in java. When you pull iterators out of them you can't guarantee the order of the items. Everywhere I've worked I've had to fix a bug related that.

I'll take “what is LinkedHashMap and why would you care?” for 10, Bob.

I think you misunderstood. I read his comment as similar to @blakeyrat's thing where DBs should return records in random order (at least some of the time) in the absence of an explicit ordering. Because some dev will see the order and make assumptions about it that come back to bite them.

[dkf]

@DogsB said in OOP is TRWTF:

@dkf said in OOP is TRWTF:

@DogsB said in OOP is TRWTF:

Reminds me of HashMaps in java. When you pull iterators out of them you can't guarantee the order of the items. Everywhere I've worked I've had to fix a bug related that.

I'll take “what is LinkedHashMap and why would you care?” for 10, Bob.

That's rarely the answer too.

It's either that or a TreeMap, which is for when you have a suitable ordering on the keys independent of the insertion order. Almost all uses of a map should be one of those three.

[DogsB]

@dkf said in OOP is TRWTF:

@DogsB said in OOP is TRWTF:

@dkf said in OOP is TRWTF:

@DogsB said in OOP is TRWTF:

Reminds me of HashMaps in java. When you pull iterators out of them you can't guarantee the order of the items. Everywhere I've worked I've had to fix a bug related that.

I'll take “what is LinkedHashMap and why would you care?” for 10, Bob.

That's rarely the answer too.

It's either that or a TreeMap, which is for when you have a suitable ordering on the keys independent of the insertion order. Almost all uses of a map should be one of those three.

I'm probably dated on this one but the last time I did this and used a TreeMap it almost bit me on the ass. When the map contained somewhere north of 10000 value pairs. Insertion slowed to a crawl. It was faster to use a hashmap and just sort the contents.

@boomzilla said in OOP is TRWTF:

I think you misunderstood. I read his comment as similar to @blakeyrat's thing where DBs should return records in random order (at least some of the time) in the absence of an explicit ordering. Because some dev will see the order and make assumptions about it that come back to bite them.

Deliberately doing that is retarded but I've also had to fix bugs where developers made those assumptions. I can see where he's coming from but no.

@dfdub said in OOP is TRWTF:

I think there's a sane middle ground: It's just work and shouldn't affect your private life, but you should also care about what you're doing, stay curious and act like a professional. Many programmers don't do any of that, which is why this site exists.

I imagine that its most developers. They see it as just a day job. It's not a career. It's just a way to pay the bills. No different to working the tills at Tesco. I suspect this is where the 10x myth comes from. You have a small group of people who give it their all where as most people it's nine to five.

I suspect I'm in your middle ground. I don't throw massive amounts of time at it but I study the tech I'm using so that I can use it more effectly. I think I'm probably hitting the edge of my incompetence and to get into senior and higher paying roles I'm going to have to throw more time at my profession.

[dkf]

@DogsB said in OOP is TRWTF:

It was faster to use a hashmap and just sort the contents.

Sometimes that's definitely true. The big problem with treemaps is that they're internally expensive. (At that scale, I'd be thinking about moving the data into a local DB.)

[sockpuppet7]

@dfdub said in OOP is TRWTF:

That's not really an excuse for not understanding or not wanting to understand your own specialty, though. "I've never needed to know this before" is not a sentence that any professional should ever say when things go wrong.

As someone who switches languages and environments like a girl changes her clothes, I really need to be able to focus on what I need when learning.

[dkf]

@sockpuppet7 said in OOP is TRWTF:

As someone who switches languages and environments like a girl changes her clothes

A new set for every Friday night, desperately hoping that nobody else at the club has the same combo?

[error]

@boomzilla said in OOP is TRWTF:

@dkf said in OOP is TRWTF:

@DogsB said in OOP is TRWTF:

Reminds me of HashMaps in java. When you pull iterators out of them you can't guarantee the order of the items. Everywhere I've worked I've had to fix a bug related that.

I'll take “what is LinkedHashMap and why would you care?” for 10, Bob.

I think you misunderstood. I read his comment as similar to @blakeyrat's thing where DBs should return records in random order (at least some of the time) in the absence of an explicit ordering. Because some dev will see the order and make assumptions about it that come back to bite them.

I seem to recall DirectX initializes newly allocated buffers with noise in debug mode but zeroes in release, to prevent similarly baseless assumptions.

[error]

@DogsB said in OOP is TRWTF:

You have a small group of people who give it their all where as most people it's nine to five.

I'm in the category of people who are really passionate about programming, but are completely bored by 95% of what gets assigned at work and are mostly checked out unless a really interesting problem comes along.

My hobby projects keep me sane and my s out of production code.

[dfdub]

@dkf said in OOP is TRWTF:

A new set for every Friday night, desperately hoping that nobody else at the club has the same combo?

The JavaScript ecosystem in a nutshell.

[pie_flavor]

@boomzilla said in OOP is TRWTF:

@pie_flavor said in OOP is TRWTF:

How can they be simple enough that you don't feel the need to look into whether they have value semantics?

TDEMSYR

Why would I even think about that?

Because that is the single purpose and single difference of them. If you think you understand structs but don't understand they have value semantics, then what the fuck are you understanding about structs?

[Gąska]

@dkf said in OOP is TRWTF:

desperately hoping that nobody else at the club has the same combo?

That part is easy - Haskell

[topspin]

@Gąska that’s what all the hipsters think.

https://www.washingtonpost.com/nation/2019/03/07/hipsters-all-look-same-man-inadvertently-confirms/?utm_term=.67cfb00749df

[boomzilla]

@pie_flavor said in OOP is TRWTF:

@boomzilla said in OOP is TRWTF:

@pie_flavor said in OOP is TRWTF:

How can they be simple enough that you don't feel the need to look into whether they have value semantics?

TDEMSYR

Why would I even think about that?

Because that is the single purpose and single difference of them. If you think you understand structs but don't understand they have value semantics, then what the fuck are you understanding about structs?

Kids are funny.

[pie_flavor]

@boomzilla said in OOP is TRWTF:

@pie_flavor said in OOP is TRWTF:

@boomzilla said in OOP is TRWTF:

@pie_flavor said in OOP is TRWTF:

How can they be simple enough that you don't feel the need to look into whether they have value semantics?

TDEMSYR

Why would I even think about that?

Because that is the single purpose and single difference of them. If you think you understand structs but don't understand they have value semantics, then what the fuck are you understanding about structs?

Kids are funny.

Ah, the ol' 'I've run out of answers so here's an insult'.
Old people are predictable.

[boomzilla]

@pie_flavor said in OOP is TRWTF:

@boomzilla said in OOP is TRWTF:

@pie_flavor said in OOP is TRWTF:

@boomzilla said in OOP is TRWTF:

@pie_flavor said in OOP is TRWTF:

How can they be simple enough that you don't feel the need to look into whether they have value semantics?

TDEMSYR

Why would I even think about that?

Because that is the single purpose and single difference of them. If you think you understand structs but don't understand they have value semantics, then what the fuck are you understanding about structs?

Kids are funny.

Ah, the ol' 'I've run out of answers so here's an insult'.

Yet another thing you think you know but don't. I've changed my mind. It's not funny any more.

[pie_flavor]

https://i.imgur.com/YFrWMI2.png

[_P_]

@pie_flavor said in OOP is TRWTF:

https://i.imgur.com/YFrWMI2.png

Florida Man Invented Object-Oriented Programming By Accident

[Mason_Wheeler]

@Dragoon said in OOP is TRWTF:

Elliot Suzdalnitski  /  Mar 16, 2021

Object-Oriented Programming  —  The Trillion Dollar Disaster

OOP is considered by many to be the crown jewel of computer science. The final solution to code organization. The end to all of our…

This author is an idiot, pushing a bunch of propaganda we've all seen before, including a bunch of outright lies. Probably the most notable is the claim that Alan Kay invented object-oriented programming, and that it was never supposed to have classes, virtual methods, etc.

None of that is true. OOP was first created in Simula, a language that took (imperative) ALGOL and added classes, virtual methods, etc to it. It came up with a model that looked a lot like the "standard OOP model" everyone's familiar with these days vis a vis Java and C#.

A few years later, Alan Kay and a few others developed something very, very different, based on message passing. It had nothing to do with the Simula model (intentionally; he was familiar with Simula and rejected a lot of the ideas that it was based on) and its alternate model has been a failure in the marketplace of ideas everytime it's been re-introduced.

Why does Alan Kay get so much credit for "inventing OOP" then? Because he did something very different but superficially similar: he invented the term. Coding with objects had been around since Simula, but he was the one who took the word "object" and added the word "oriented", and of course he claimed that what that really meant was Smalltalk.

[_P_]

@Mason_Wheeler said in OOP is TRWTF:

@Dragoon said in OOP is TRWTF:

https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-️-92a4b666c7c7

This author is an idiot, pushing a bunch of propaganda we've all seen before, including a bunch of outright lies. Probably the most notable is the claim that Alan Kay invented object-oriented programming, and that it was never supposed to have classes, virtual methods, etc.

None of that is true. OOP was first created in Simula, a language that took (imperative) ALGOL and added classes, virtual methods, etc to it. It came up with a model that looked a lot like the "standard OOP model" everyone's familiar with these days vis a vis Java and C#.

A few years later, Alan Kay and a few others developed something very, very different, based on message passing. It had nothing to do with the Simula model (intentionally; he was familiar with Simula and rejected a lot of the ideas that it was based on) and its alternate model has been a failure in the marketplace of ideas everytime it's been re-introduced.

Why does Alan Kay get so much credit for "inventing OOP" then? Because he did something very different but superficially similar: he invented the term. Coding with objects had been around since Simula, but he was the one who took the word "object" and added the word "oriented", and of course he claimed that what that really meant was Smalltalk.

You're expecting the JS ecosystem to actually learn the history of programming languages?

[djls45]

@pie_flavor quoted in OOP is TRWTF:

In the simple example above, the line count has more than doubled just to extract a single method. Why does refactoring create even more complexity, when the code is being refactored in order to decrease complexity in the first place?

Lines-of-code is not that great of a proxy for code complexity.

[djls45]

@Captain said in OOP is TRWTF:

2. defining the semantics of taking values out of value with type m a and passing them into a function that that takes in an a and returns an m b (which guarantees that we stay "in" the monad)

Let me see if I've got this right:
A monad is a piece of code that takes a value a of type m, returns a value b of type m, and in between, feeds a into another piece of code that takes a parameter of type m and returns a value of type m.

[_P_]

@djls45 said in OOP is TRWTF:

@Captain said in OOP is TRWTF:

2. defining the semantics of taking values out of value with type m a and passing them into a function that that takes in an a and returns an m b (which guarantees that we stay "in" the monad)

Let me see if I've got this right:
A monad is a piece of code that takes a value a of type m, returns a value b of type m, and in between, feeds a into another piece of code that takes a parameter of type m and returns a value of type m.

a and b are not values, they're types too; and m is a type that has one type hole, aka they takes a type and produce a type (you can think of them like generics, as in m<a>). When a type with one type hole has implementations for return and >>=/join which obeys a few mathematical laws, we call that type a monad as in it satisfies the requirement for being a monad.

e.g We say that List is a monad because List<a> for all types a can satisfy the requirements for monads by return v = [v] and (>>=) = concatMap / flat_map (the verification is left as an exercise to the reader).

Other than that it's nothing special, becaues monad is not the end goal; you can still use [v] and concatMap / flat_map perfectly fine without any knowledge of monads. It's more like you're creating a class, and in the end when you look at the implementation you realize that, hey, my class can be made an instance of IEnumerable too! Not making your class an instance of IEnumerable in spite of that fact wouldn't make the methods in your class any different, but it gives more insight into the nature of your class and provides more integration to the core language libraries, so in the end it's generally A Good Thing .

[Mason_Wheeler]

Eric Lippert does a surprisingly good job of explaining monads in terms of concepts normal programmers are familiar with.

TLDR: A monad is a design pattern involving a generic type with one type parameter, whose principal purpose is to "enhance" a base type with some new property, that can be applied to basically any base type, and that obeys certain specific rules:

A monad is a generic type M<T> such that:

• There is some sort of construction mechanism that takes a T and returns an M<T>. We’ve been characterizing this as a method with signature static M<T> CreateSimpleM<T>(T t)
• Also there is some way of applying a function that takes the underlying type to a monad of that type. We’ve been characterizing this as a method with signature: static M<R> ApplySpecialFunction<A, R>(M<A> monad, Func<A, M<R>> function)

Finally, both these methods must obey the monad laws, which are:

• Applying the construction function to a given instance of the monad produces a logically identical instance of the monad.
• Applying a function to the result of the construction function on a value, and applying that function to the value directly, produces two logically identical instances of the monad.
• Applying to a value a first function followed by applying to the result a second function, and applying to the original value a third function that is the composition of the first and second functions, produces two logically identical instances of the monad.

(If this summation still sounds a bit weird, read the articles. It's surprisingly clear when he builds the concept up from first principles.)

[loopback0]

@_P_ said in OOP is TRWTF:

You're expecting the JS ecosystem to actually learn the history of programming languages?

JS developers would struggle to learn the history of JS, considering how fast it changes.