5 ms·

If you think software interoperability is like railway gauges, then you simply don’t understand software.

by such12 4y ago

peoplefromibiza 4y ago
I've been doing software for 27 years. Thanks for the advice. I'll humbly begin studying again how software works. My fault for thinking that companies that sell the promise of self driving cars and colonizing Mars could solve the problem of making it possible to interoperate with other software products. I clearly underestimated the challenge and overestimated the abilities of their 10x employees and of their visionaries CEOs. I wonder how is that even possible that HTTP or e-mail came to be. Must be some kind of alien technology.
- such12 4y ago
  Are you aware that self-driving cars don’t work yet, and mars hasn’t been colonized? HTTP and Email are extremely narrow, have had vast amounts of work put into them over time, and are still deeply flawed. They have also developed at a glacial pace. Your examples show that money can’t magically solve hard problems, and ironically, that even the narrowest forms of interoperability are extremely hard.
  - peoplefromibiza 4y ago
    > HTTP and Email are extremely narrow HTTP is virtually running the World as it is. I wouldn't call its scope narrow. But probably I wasn't clear enough: we just need a way to access data and documentation. You don't need to know what kind of web server is running when you send a request and the WEB server don't need to know what kind of client is sending the request to answer. Interoperability is easy, if there is the will. If there is no will, let's mandate it by law. I don't see the problem. Your argument is: the perfect solution is impossible so it's pointless to even try. Which is provably false. Even more so because software interoperability existed, before companies started to lock everything down, to push their proprietary tracking soft... ehm apps. same reason they killed RSS I could connect to Goggle or Facebook chat with any XMPP client back then. WhatsApp protocol started as a a modified version of ejabberd (XMPP server). etc. Nobody asked for perfect. Flawed is still better than no solution. Human body is deeply flawed too, we don't renounce to live because we have to die anyway.
    - such12 4y ago
      > You don't need to know what kind of web server is running when you send a request and the WEB server don't need to know what kind of client is sending the request to answer. Exactly. It’s not an API - it’s a way to transfer arbitrary blocks of data. Applications that use http have to build an API on top. That’s why it’s not even close to a valid comparison, and yet it has still become extremely complex over time. > Flawed is still better than no solution. This not the case. In many cases flawed solutions simply fail.
      - peoplefromibiza 4y ago
        > It’s not an API - it’s a way to transfer arbitrary blocks of data Uh? API cannot transfer blocks of data? Again: this is not new, it's tedious, it's bureaucratic, it can be hairy, but it's not difficult.
        such12 4y ago
        > API cannot transfer blocks of data? This seems like a deliberate and silly misunderstand on your part. If you don’t realize that most API’s generally do more than simply transfer arbitrary blocks of data, then you have lied about your experience as a developer. HTTP is just a transfer protocol. It’s in the name.
        peoplefromibiza 4y ago
        > If you don’t realize that most API’s generally do more than simply transfer arbitrary blocks of data where did I say it? > HTTP is just a transfer protocol that's been hardly true since forever. POST, PUT, DELETE, PATCH etc ever heard of these verbs before?

If you think software interoperability is like railway gauges, then you simply don’t understand software.

by such12 4y ago

If you think software interoperability is like railway gauges, then you simply don’t understand software.

I've been doing software for 27 years. Thanks for the advice. I'll humbly begin studying again how software works. My fault for thinking that companies that sell the promise of self driving cars and colonizing Mars could solve the problem of making it possible to interoperate with other software products. I clearly underestimated the challenge and overestimated the abilities of their 10x employees and of their visionaries CEOs. I wonder how is that even possible that HTTP or e-mail came to be. Must be some kind of alien technology.

such12 4y ago
Are you aware that self-driving cars don’t work yet, and mars hasn’t been colonized? HTTP and Email are extremely narrow, have had vast amounts of work put into them over time, and are still deeply flawed. They have also developed at a glacial pace. Your examples show that money can’t magically solve hard problems, and ironically, that even the narrowest forms of interoperability are extremely hard.
- peoplefromibiza 4y ago
  > HTTP and Email are extremely narrow HTTP is virtually running the World as it is. I wouldn't call its scope narrow. But probably I wasn't clear enough: we just need a way to access data and documentation. You don't need to know what kind of web server is running when you send a request and the WEB server don't need to know what kind of client is sending the request to answer. Interoperability is easy, if there is the will. If there is no will, let's mandate it by law. I don't see the problem. Your argument is: the perfect solution is impossible so it's pointless to even try. Which is provably false. Even more so because software interoperability existed, before companies started to lock everything down, to push their proprietary tracking soft... ehm apps. same reason they killed RSS I could connect to Goggle or Facebook chat with any XMPP client back then. WhatsApp protocol started as a a modified version of ejabberd (XMPP server). etc. Nobody asked for perfect. Flawed is still better than no solution. Human body is deeply flawed too, we don't renounce to live because we have to die anyway.
  - such12 4y ago
    > You don't need to know what kind of web server is running when you send a request and the WEB server don't need to know what kind of client is sending the request to answer. Exactly. It’s not an API - it’s a way to transfer arbitrary blocks of data. Applications that use http have to build an API on top. That’s why it’s not even close to a valid comparison, and yet it has still become extremely complex over time. > Flawed is still better than no solution. This not the case. In many cases flawed solutions simply fail.
    - peoplefromibiza 4y ago
      > It’s not an API - it’s a way to transfer arbitrary blocks of data Uh? API cannot transfer blocks of data? Again: this is not new, it's tedious, it's bureaucratic, it can be hairy, but it's not difficult.
      - such12 4y ago
        > API cannot transfer blocks of data? This seems like a deliberate and silly misunderstand on your part. If you don’t realize that most API’s generally do more than simply transfer arbitrary blocks of data, then you have lied about your experience as a developer. HTTP is just a transfer protocol. It’s in the name.
        peoplefromibiza 4y ago
        > If you don’t realize that most API’s generally do more than simply transfer arbitrary blocks of data where did I say it? > HTTP is just a transfer protocol that's been hardly true since forever. POST, PUT, DELETE, PATCH etc ever heard of these verbs before?