4 ms·

I have come to really think that a big problem in the open source world is the non-standardization of interfaces. Text over stdio and communicating processes i

I have come to really think that a big problem in the open source world is the non-standardization of interfaces. Text over stdio and communicating processes is just not the greatest; if every program standardized on C ABI library protocols, and offered stdio and socket interfaces to them, then suddenly the landscape of possibilities in software composition would be way broader. Herding daemons and managing docker containers when we have the linker and dynamic libraries just doesn’t feel sane or sanitary to me, especially outside of the Linux shell. This is how we end up with 50 different implementations of syntax parsers, fuzzy-finding, API clients, etc.

gumby 3y ago
> I have come to really think that a big problem in the open source world is the non-standardization of interfaces. Text over stdio and communicating processes is just not the greatest… We lost that battle in the late 70s/early 80s. It has nothing to do with the open source world.
- binary132 3y ago
  Open source has everything to do with interoperability of software.
  - gumby 3y ago
    The problem of ad hoc nonstandard text interfaces, in both source-available and priority code far predated the gnu manifesto, much less anything that happened since. That’s all.
    - gumby 3y ago
      s/priority/proprietary/
mickeyp 3y ago
> C ABI library protocols, and offered stdio and socket interfaces to them, then suddenly the landscape of possibilities in software composition would be way broader You've just invented a rudimentary and worse version of COM. (There are advantages in not limiting yourself to low-level tooling like ptys/pipes/sockets.) https://en.wikipedia.org/wiki/Component_Object_Model https://en.wikipedia.org/wiki/Component_Object_Model
- binary132 3y ago
  What is worse about native C FFI and structs-as-messages socket protocols as compared to the malebolge of Windows APIs?
  - fwip 3y ago
    COM, the interface, is not the same as the conglomeration of Windows APIs. A web-dev example might be that CSS, the language design, is not the same as the ever-growing and inconsistent set of properties that the browser uses to style documents.
Kamq 3y ago
> C ABI library protocols, and offered stdio and socket interfaces to them, then suddenly the landscape of possibilities in software composition would be way broader. I think it would have reduced composition in practice. Part of what you get out of "text as the universal interface" is tools that never heard of each other being able to work together. Because there's only a couple types: string, maybe number depending on the context, list (strings separated by spaces or newlines) and record (single line of a csv/tsv file), things can be kinda coerced into working together. You could get this with a type system... if you restrict yourself to at the most advanced List<String>, Map<String, String>, but you've lost ~80% of your type system value. As soon as anyone defines a custom struct, only tools that have heard of that type (which, in practice, end up being tools specifically made to work with it) can use it. Just using text with a few conventions is a really high utility point on the pareto curve for basically zero work. I could see some benefit in getting a system defined Path/URL type, but you'd really need to have a culture of sticking to built in types, and a system that offers types to cover basically every use-case.
- binary132 3y ago
  It's really hard for me to imagine a world being _less_ useful where a program like ls not only specifies the structure of its output in a way I can automatically read fields of without hand-parsing it, but also can be used by linking instead of having to run it in a subprocess whose input and output I have to manage, buffer, and so on and so forth.
  - Kamq 3y ago
    > useful where a program like ls not only specifies the structure of its output in a way I can automatically read fields of without hand-parsing it I don't think C ABI gets you this. Passing structs across ABI boundaries is kinda iffy, especially if you're using a different compiler than the program was originally compiled with. And lord knows what non-C programs would try to do.
    - binary132 3y ago
      I get it but all I can hear over and over is “arbitrary strings are better than a sound typesystem” and we all know that’s just not true.

gumby 3y ago

> I have come to really think that a big problem in the open source world is the non-standardization of interfaces. Text over stdio and communicating processes is just not the greatest… We lost that battle in the late 70s/early 80s. It has nothing to do with the open source world.

binary132 3y ago
Open source has everything to do with interoperability of software.
- gumby 3y ago
  The problem of ad hoc nonstandard text interfaces, in both source-available and priority code far predated the gnu manifesto, much less anything that happened since. That’s all.
  - gumby 3y ago
    s/priority/proprietary/

mickeyp 3y ago

> C ABI library protocols, and offered stdio and socket interfaces to them, then suddenly the landscape of possibilities in software composition would be way broader You've just invented a rudimentary and worse version of COM. (There are advantages in not limiting yourself to low-level tooling like ptys/pipes/sockets.) https://en.wikipedia.org/wiki/Component_Object_Model https://en.wikipedia.org/wiki/Component_Object_Model

binary132 3y ago
What is worse about native C FFI and structs-as-messages socket protocols as compared to the malebolge of Windows APIs?
- fwip 3y ago
  COM, the interface, is not the same as the conglomeration of Windows APIs. A web-dev example might be that CSS, the language design, is not the same as the ever-growing and inconsistent set of properties that the browser uses to style documents.

Kamq 3y ago

> C ABI library protocols, and offered stdio and socket interfaces to them, then suddenly the landscape of possibilities in software composition would be way broader. I think it would have reduced composition in practice. Part of what you get out of "text as the universal interface" is tools that never heard of each other being able to work together. Because there's only a couple types: string, maybe number depending on the context, list (strings separated by spaces or newlines) and record (single line of a csv/tsv file), things can be kinda coerced into working together. You could get this with a type system... if you restrict yourself to at the most advanced List<String>, Map<String, String>, but you've lost ~80% of your type system value. As soon as anyone defines a custom struct, only tools that have heard of that type (which, in practice, end up being tools specifically made to work with it) can use it. Just using text with a few conventions is a really high utility point on the pareto curve for basically zero work. I could see some benefit in getting a system defined Path/URL type, but you'd really need to have a culture of sticking to built in types, and a system that offers types to cover basically every use-case.

binary132 3y ago
It's really hard for me to imagine a world being _less_ useful where a program like ls not only specifies the structure of its output in a way I can automatically read fields of without hand-parsing it, but also can be used by linking instead of having to run it in a subprocess whose input and output I have to manage, buffer, and so on and so forth.
- Kamq 3y ago
  > useful where a program like ls not only specifies the structure of its output in a way I can automatically read fields of without hand-parsing it I don't think C ABI gets you this. Passing structs across ABI boundaries is kinda iffy, especially if you're using a different compiler than the program was originally compiled with. And lord knows what non-C programs would try to do.
  - binary132 3y ago
    I get it but all I can hear over and over is “arbitrary strings are better than a sound typesystem” and we all know that’s just not true.