Hacker News new | ask | show | jobs
by falcolas 3476 days ago
Here's the part I find most humorous. Machine to Machine communication has already been attempted, and it always fell back to requiring human intervention. Web Services Description Language (WSDL) was an attempt to exactly this, and it failed.

WSDL didn't fail because it frequently tried to describe SOAP connectivity (and everyone knows that SOAP is obviously bad for all things), it failed because it was still people writing the APIs and the descriptions of those APIs. And since people aren't perfect, humans had to intervene to find and fix the bugs to properly communicate with a WSDL defined API.

Until AI gets good enough, or we adopt a specific definition to meet all use cases (should be fun to watch), such attempts are going to keep failing. Because it's humans hiding in the box of the turk, and will be for the forseeable future, and computers are still pretty terrible at communicating with humans.

3 comments

"It's not enough for your computers to agree, you have to agree on what they're supposed to agree about."

Credit to Matt Levine: https://www.bloomberg.com/view/articles/2016-01-19/banks-oil...

The whole point of WSDL I thought was to look at statically-typed code and be able to dynamically generate the XML schema (and the XML) without human intervention -- that you can look at the code, know the types it uses and how it uses them, and then generate the WSDL based on that information?
.NET and Java had good support for statically generating them (correctly even!) from code, but I never had the pleasure of integrating with such a service. Even in that case though, there were developers who used strings for everything instead of the correct types, didn't handle null correctly, etc.

Overwhelmingly in practice people wrote wsdls and xsds by hand, incorrectly, and treated them as secrets instead of publishing them along with the API endpoints. There was other "enterprise" BS during the XML craze too. In one case I even had to work around bugs in an IBM XML firewall, or its configuration. It was a nightmare[1].

[1] https://en.wikipedia.org/wiki/XML_appliance

They were a bit of a nightmare. Fun highlights:

    - IsBooleanPropertyIncludedBoolean
    - Massive, incredibly slow to build libraries
    - Check everything in case it was null
    - Never really sure what was wrong when it went wrong
There was quite a massive cognitive overhead and overkill for often querying one little thing.

Also they'd sometimes break and you'd have to hand edit the wsdl's to get them to work again (at least salesforce used to break theirs every now and again, the wsdl would be incompatible with the .Net tool because of certain character not escaping properly).

Well, when correctly implemented, working with WSDLs can be almost pleasant
I think the issue is that we are not ready to accept communication mechanisms that guess about the meaning of data and take action. Guessing on the shape, or completeness of the data.

We haven't crossed that valley yet, mostly because we don't produce code that way either (flow instead of code). If we allowed that style of data flow, and a means of functional side-effect-free-validation waves hands vaguely, interop between different systems becomes an eventuality of the modeling.

The question is mostly... is the cpu-burn to detect the model that yields good results (ML-ish), cheaper than the human burn to write it on paper and agree. Present day we are ignoring the answer to that cost question for a variety of reasons...