4 ms·

C#'s System.Object base type contains a ToString, allowing any richer object to fallback into such inefficient systems if required. I'd also caution that "ever

C#'s System.Object base type contains a ToString, allowing any richer object to fallback into such inefficient systems if required. I'd also caution that "everything is a string so no need to read the documentation" is unrealistic and even outright dangerous. *NIX's string philosophy has directly resulted in multiple security vulnerabilities.

Semaphor 4y ago
Just FYI, I’m reasonably certain that parent is being satirical.
- KronisLV 4y ago
  I'm not so sure about the documentation part, but this seems valid at face value: > it's one of the pillars of the unix philosophy at work - text is the universal interface. In general, text is indeed the lowest common denominator that's available to you and fits with the majority of GNU tools nicely (and how most *nix distros are structured). Of course, some structure helps, since dealing with something like Nginx or Apache2 text logs might not be as nice as having your logs in JSON, though in regards to configuration files or program output there's lots of nuance - structured text (like JSON) will be easier to work with programmatically but might not be as nice to look at. Working with binary data in comparison can be asking for problems, to the point where using SQLite for your application data might make more sense: https://sqlite.org/appfileformat.html https://sqlite.org/appfileformat.html In this particular case, however, the conversions were made within the confines of a single program, so the interop is indeed not a valid concern here. A properly written type might indeed allow you to avoid various inefficiencies. If you're not serializing your objects and whatnot to make the life of the consumer of your data easier (be it another tool, or a REST/SOAP API client that needs JSON/XML, or a configuration file on the file system), then there's not that much point in doing those conversions.
  - joepie91_ 4y ago
    Unfortunately "text is the universal interface" is pretty much a lie, for the exact same reason that "bytes in memory are the universal interface" is a lie. An interface has some kind of structure for the data (and operations) that it represents. That structure may be explicitly defined or left implicit, but it is always there. And in the vast majority of cases, that structure is more complex than "a single independent string". That's where the whole "pipe text between processes" approach breaks down - in many cases, you aren't just dealing with a single string, but with some sort of structured data that just happens to be encoded as human-readable text. That it's "text" is entirely immaterial to the structure of the data, or how to work with it. And that's how you end up with every CLI tool implementing its own set of subtly incompatible data parsers and stringifiers. This is strictly worse than having a standardized structural format to communicate in.
    - KronisLV 4y ago
      > That structure may be explicitly defined or left implicit, but it is always there. But this is something that every piece of software out there has to deal with. By this reasoning, claiming that RESTful APIs can evolve over time and don't need something like WSDL (though OpenAPI still exists) is also a similar lie, because there absolutely are assumptions about how things are structured by anyone and everyone who actually needs to integrate with the API. Even "schema-less" data storage solutions like MongoDB are then also built on similar lies, because while you can throw arbitrary data at them to store it, querying the data later will still depend on some assumptions about the data structure. I'm inclined to agree, and yet, RESTful APIs are still very popular and seem to have much success (though some push for more "immutable" APIs that are versioned, which is nice), as do "schema-less" data stores in certain domains. Edit: you can also say that about everything from CLI tools or even dynamic programming languages as a whole. I think there's more to it. > And that's how you end up with every CLI tool implementing its own set of subtly incompatible data parsers and stringifiers. This is strictly worse than having a standardized structural format to communicate in. I suspect that this is where opinions might differ. Half-assing things and counting on vaguely compatible (at a given point in time) implementations has been the approach on which many pieces of software are built to solve numerous problems. On one hand, that is ignorant, but on the other hand - how often is the output from "ls -la" going to change its format, really? The majority of CLI tool writers seem to understand how brittle and bad everything is and thus treat their data formats carefully, adding a whole bunch of different flags as needed, or allowing for custom formats, like: "lsblk --output UUID,LABEL,SIZE" For many out there, that's good enough. At least to the point where something like PowerShell isn't mainstream, despite some great ideas in it (or other shells that would let you work with objects, instead of text).
notatoad 4y ago
yeah, i'm not trying to say it's a good idea. but the parent asked why, and the answer is essentially because we're lazy, it's easy, and it works often enough that we can get away with it. i figured the article we're all commenting on would be evidence enough of why it's not necessarily a good idea.

Semaphor 4y ago

Just FYI, I’m reasonably certain that parent is being satirical.

KronisLV 4y ago
I'm not so sure about the documentation part, but this seems valid at face value: > it's one of the pillars of the unix philosophy at work - text is the universal interface. In general, text is indeed the lowest common denominator that's available to you and fits with the majority of GNU tools nicely (and how most *nix distros are structured). Of course, some structure helps, since dealing with something like Nginx or Apache2 text logs might not be as nice as having your logs in JSON, though in regards to configuration files or program output there's lots of nuance - structured text (like JSON) will be easier to work with programmatically but might not be as nice to look at. Working with binary data in comparison can be asking for problems, to the point where using SQLite for your application data might make more sense: https://sqlite.org/appfileformat.html https://sqlite.org/appfileformat.html In this particular case, however, the conversions were made within the confines of a single program, so the interop is indeed not a valid concern here. A properly written type might indeed allow you to avoid various inefficiencies. If you're not serializing your objects and whatnot to make the life of the consumer of your data easier (be it another tool, or a REST/SOAP API client that needs JSON/XML, or a configuration file on the file system), then there's not that much point in doing those conversions.
- joepie91_ 4y ago
  Unfortunately "text is the universal interface" is pretty much a lie, for the exact same reason that "bytes in memory are the universal interface" is a lie. An interface has some kind of structure for the data (and operations) that it represents. That structure may be explicitly defined or left implicit, but it is always there. And in the vast majority of cases, that structure is more complex than "a single independent string". That's where the whole "pipe text between processes" approach breaks down - in many cases, you aren't just dealing with a single string, but with some sort of structured data that just happens to be encoded as human-readable text. That it's "text" is entirely immaterial to the structure of the data, or how to work with it. And that's how you end up with every CLI tool implementing its own set of subtly incompatible data parsers and stringifiers. This is strictly worse than having a standardized structural format to communicate in.
  - KronisLV 4y ago
    > That structure may be explicitly defined or left implicit, but it is always there. But this is something that every piece of software out there has to deal with. By this reasoning, claiming that RESTful APIs can evolve over time and don't need something like WSDL (though OpenAPI still exists) is also a similar lie, because there absolutely are assumptions about how things are structured by anyone and everyone who actually needs to integrate with the API. Even "schema-less" data storage solutions like MongoDB are then also built on similar lies, because while you can throw arbitrary data at them to store it, querying the data later will still depend on some assumptions about the data structure. I'm inclined to agree, and yet, RESTful APIs are still very popular and seem to have much success (though some push for more "immutable" APIs that are versioned, which is nice), as do "schema-less" data stores in certain domains. Edit: you can also say that about everything from CLI tools or even dynamic programming languages as a whole. I think there's more to it. > And that's how you end up with every CLI tool implementing its own set of subtly incompatible data parsers and stringifiers. This is strictly worse than having a standardized structural format to communicate in. I suspect that this is where opinions might differ. Half-assing things and counting on vaguely compatible (at a given point in time) implementations has been the approach on which many pieces of software are built to solve numerous problems. On one hand, that is ignorant, but on the other hand - how often is the output from "ls -la" going to change its format, really? The majority of CLI tool writers seem to understand how brittle and bad everything is and thus treat their data formats carefully, adding a whole bunch of different flags as needed, or allowing for custom formats, like: "lsblk --output UUID,LABEL,SIZE" For many out there, that's good enough. At least to the point where something like PowerShell isn't mainstream, despite some great ideas in it (or other shells that would let you work with objects, instead of text).

notatoad 4y ago

yeah, i'm not trying to say it's a good idea. but the parent asked why, and the answer is essentially because we're lazy, it's easy, and it works often enough that we can get away with it. i figured the article we're all commenting on would be evidence enough of why it's not necessarily a good idea.