Your experience with SOAP is vastly different than mine to the point where I almost laughed out loud at your anecdote about adding a new web service dependency in a few seconds. SOAP is inherently complex, and needlessly so in my opinion. I've got personal battle-scars from trying to make Apache Axis and .NET play nice with all the various WS-* extensions needed for our use case.

There are always going to be people who, for lack of time, effort, education, whatever, use simple tools wrong. That's not an argument against simplicity. It is a recurring and false hubris to think we can fully specify any system and be "done." In the real world the are always confounding factors that violate the assumptions and constraints of any system we design. When that happens, I vastly prefer the more adaptable, less codified, simple system.

The fact that even those people above can still get stuff done even when using the tools "incorrectly" is an argument for the simple approach, in my view.

> trying to make Apache Axis and .NET play nice

That's key. If client and server were both .NET or both Axis, things were easier. As soon as they differed -- prepare for long-term pain such as restricting the data types you want to use to string and int. Limited interoperability.

> The fact that even those people above can still get stuff done even when using the tools "incorrectly" is an argument for the simple approach, in my view.

Spot on.

> I could crack open Visual Studio in the morning and simply add a web service dependency to my project. In a matter of milliseconds -- seconds at worst -- it would automatically cough up a C# client for whatever it is that I wanted to talk to, and I could immediately start coding some actual business logic

Visual Studio is a vastly underrated tool. If you're doing something it supports within the Microsoft ecosystem it can just plough through all of it for you. Doubly so if you add Jetbrains Rider.

The thing is, whenever we see something like this, it's because it's either easier to reimplement the thing from scratch than work out what the correct already-implemented solution should be, OR the already-implemented solution simply doesn't work in your environment because it's not supported.

It is sometimes depressing to watch the Javascript ecosystem try to build standard workflows only to knock them over again once they've managed to place one brick upon another, but Microsoft are quite capable of doing the same thing of their own accord (I say as someone surveying the wreckage that is WinUI3)

Schema languages for "REST" exist (OpenAPI, RAML), and many people use them, but they certainly haven't taken off to the extent that WSDL did. I find that odd.

The new hotness is gRPC, which is based on protocol buffers, which uses an out-of-band schema file (you can do a certain amount with protobufs without a schema file, but nothing very useful). People appear to be happily adopting that, and aren't complaining about the need for a schema.

The only factor here is that the developer you were talking to here appears to be an idiot. They’d fuck it up in any stack. The technology is immaterial.

There's such a thing as falling into the pit of success.

A successful REST implementation using hand-rolled JSON protocols is in the middle of a vast field with hidden man traps full of sharpened bamboo spikes.

Equally vile is the majority of applications reliant on WS-* based protocols, their appalling lack of semantic consistency, cross-vendor incompatibilities, byzantine failure modes, and grotesquely siloed enterprise runtimes.

Equating certain technologies with incompetence, especially coupled to a blinkered misrepresentation of how to use them, remains a wholly unjustifiable misattribution. What's more, doing so with a reference to "the kids" further indicates a poor grasp of programmer demographics, and especially the denizens of this forum.

To sum up: most software is shit. Any correlations to variations in the uniformity of the shit that you may have observed are globally unsupportable.