IMO the problem with the Unix model is not that it's been corrupted over time, but that it was fundamentally flawed from the start. I'm hardly the first to point this out, but sending around unstructured text makes doing some things inordinately hard (imagine writing a separate program to color ls's output, instead of having that as a flag) + going beyond pipes leads to the awful experience of programming in shell.
The Unix command line tools were designed to be usable in a lot of ad hoc situations. In an ad hoc situation, unstructured text is often what you have. So, to be usable for that, the command line tools had to be able to operate on unstructured text as input. That left two options - either also accept something structured as input, or accept only unstructured text as input.
"Usable in an ad hoc situation" gets us back to composability. If you can compose existing parts to meet a novel situation, that's better than having to carefully architect a solution. And the key to being able to do that is common interfaces. Unix did exactly that. And, for all the criticism, it works pretty well.
Can a well-designed interface do better? Sure. Can a well-designed interface deal with something outside the design parameters as well? Probably not.
I mean people still use `ls` everyday so it in fact did win. We have super rich GUIs, REPLs, the start menu, live programming environments and notebooks, web browser file listing capability, the ability to build your own web app to list files visually anyway you want.
Depends on how you define "functionality". You could say that ls's functionality is "providing a text listing of files in a directory. You can't get that from a GUI, certainly not without extra steps.
Why would anyone care about that difference? If I'm reading the listing, I don't care. My eyeballs don't care if the photons came from a GUI or text in a shell. But if I'm trying to pipe the results to another program, then I care. GUIs don't pipe well.
And people like me pipe the results of ls all the time.
How those bytes are interpreted is up to the endpoints of the streams. Sure, a lot of endpoints interpret byte streams as text. That's not Unix, that's a particular endpoint.
You will notice that Unix does not even offer 'text' files (like Windows does). Or ISAM files, or random access files. or Fortran carriage control. Just binary files. Because the Unix way is streams of bytes, and nothing more.
Further if you wanted to go with JSON or something you can, there's nothing preventing it. Pipes are based on unstructured text so you have that flexibility. If you want to add JSON ls and filter that through JSON sed to JSON less you can.
Finally 'the Unix way' is a cultural thing. It isn't set in stone. It can, and probably has evolved. So while you could argue that it meant that to some people at some time, that doesn't make it true today or in the future. The down side is that we have these disagreements over what 'the Unix way' is. But any philosophy that's been around for 40 years, in tech no less, has to be flexible, that's why it's stay relevant.
I disagree, the unix way has structure: lines of text each consisting of space-separated fields. The real issue is that sometimes your data has spaces, or even newlines, so the structure quickly isn't enough. And that "sometimes" happens xay more often than it has to, and the escape hatch is a mess.
> lines of text each consisting of space-separated fields
I wish! Back in the day, tools like iostat and vmstat printed tabular data using fixed width fields with no spaces between. This worked fine until the computers got bigger and faster, then the larger numbers filled the fields so they ran together making the output unreadable. A surprising number of vendors had this problem.
It's bizarre that this is the case given that ascii contains characters for this very purpose. There's record separator, group separator... Now if your data contains those, that's bad. But that's much rarer than containing ordinary whitespace.
I don't think so, this idea of JSON is a more modern interpretation and I'd say is counter to the UNIX philosophy, not an extension to it (it just so happens to squeeze into existing primitives a little better than e.g. a binary serialisation protocol).
