I would be interested too if that's an actual theory. My experience has largely been that if you're willing to admit you were wrong about something, most reasonable people will appreciate it over you doubling down.

If they pile on after you have conceded, typically they come off much worse socially in my opinion.

(This is a reflection on human behavior, not a statement about any specific work environment. How much this is or isn't true varies by place.)

In my experience, it's something of a sliding scale as you go higher in the amount of politicking your environment requires.

Lower-level engineers and people who operate based on facts appreciate you admitting you were incorrect in a discussion.

The higher you go, the more what matters is how you are perceived, and the perceived leverage gain of someone admitting or it being "proven" they were wrong in a high-stakes situation, not the facts of the situation.

This is part of why, in politics, the factual accuracy of someone's accusations may matter less than how successfully people can spin a story around them, even if the facts of the story are proven false later.

I'm not saying I like this, but you can see echoes of this play out every time you look at history and how people's reactions were more dictated by perception than the facts of the situation, even if the facts were readily available.

honestly, that's not my experience. sure you can admit in front of your friends, family and people that know you even if they are not your friend.

Admitting the mistake in front of strangers, usually leads to them making the shortcut next time and assuming you are wrong again.

you wont get any awards for admitting the mistake.

> If they pile on after you have conceded, typically they come off much worse socially in my opinion.

Those who are obsessed with their reputation above morality have usually had a lot of practice punching down, and they don't really look as bad as someone being dunked on who gets confused.

I think this is like a cornerstone of bullying. It seems to work in social situations. I'm sure everyone reading this comment can picture it.

I would imagine operator overloading helps with vectors so you can do things like:

    public static Vector operator -(Vector a, Vector b)
    {
        Vector v = new Vector();
        v.X = a.X - b.X;
        v.Y = a.Y - b.Y;

        return v;
    }

So then you can just write:

    Vector result = myVector1 - myVector2;

Also if you wrote the JS equivalent of that, each vector would be 3-4 individually heap-allocated doubles in v8, because they aren't able to allocate floating-point values inline. There would also be a new heap allocation for the result vector itself when performing each operation. The overhead really adds up. :/

At one point Mozilla had a prototype implementation of strongly-typed value types in JavaScript, but it fell by the wayside once WebAssembly became a thing.

You can use an array to keep the doubles together. V8 has something like half a dozen different array types, depending on what is inside and how it's used.

Why not implement a method?

var result = myvector1.sub(myvector2)

It would be nice if they let you forgo the credits to sign up without a phone number.

Then they ask for your card info.

What sorts of things are wrong with .NET in your view? As someone who recently started working with it after using Java for years, it has been refreshing and largely enjoyable for me.

You must have not had to work with SOAP then.

Nobody does anymore, so I don't see how that counts as a valid criticism of current .Net.

If you deal with (some parts of) the public sector, you certainly will encounter SOAP. For example - those online drivers-ed courses you buy in California to get rid of a ticket? They all talk to a SOAP backend maintained by the State.

Certainly SOAP isn't everywhere the way it used to be (thankfully), but it's out there and isn't going away any time soon.

> isn't going away any time soon.

Funny you think that. That's one of the major complaints about .NET 5+ is that WCF was dropped as an officially supported library and .NET is pushing people to REST and/or gRPC. (I think gRPC will suffer many of the same SOAP problems eventually, but it's the current hotness, thanks Google.) Every .NET HN article is full of complaints that WCF is dead and they have SOAP services to maintain and .NET is telling them to go away and do something new. There's a community project named CoreWCF trying to make the transition easier and even they are not trying to implement all of WS-* and SOAP madness and trying to make the transitions easier to REST or gRPC if you like that Google-branded SOAP smell better.

In .NET 5+ SOAP is already dead and good riddance. It's probably going to live forever on .NET Framework 4.x servers for legacy apps, but the message seems to be loud enough: "those are legacy apps now".

SOAP isn't actually that bad if you use it with a typed language like C#. It's hell trying to use it with something like Ruby/Python though - I remember struggling to talk to a SOAP API with Ruby and getting into headaches that my data was being rejected until I realised that the XML properties had to be in the exact order unlike JSON which doesn't care usually.

Import a WSDL into Visual Studio and you've got your client code automatically generated & documented (if the API was written properly), works pretty nicely to be fair. Even easier than using something like Nswag to generate JSON clients from Swagger/OpenAPI specs.

I never gave the Visual Studio WSDL code-generator the respect it deserved at the time. With hindsight, it was amazingly easy to use and generally "just worked".

> (if the API was written properly)

A very important caveat! I remember we hired some consultants from a world-renowned tech company - let's call them Big Red for now - and their big integration deliverable was a SOAP API with... one method. It accepted a string, and returned a string. And what was that one string? ...A SOAP request! The best code-generator in the world wouldn't have helped.

To this day I wonder if we actually ended up paying for that. I sure hope we didn't.

SOAP and the related libraries in .NET are pretty unfun to work with. However they are so old and unused compared to modern development that it’s not really a good comparison.

Like I have a Java app I am struggling with currently and not a fan of, but its on Java 8 so I don’t consider it representative of whatever I might find in modern Java despite the fact that I am working with it in modern times