Care to expand on why this isn't usable?
Because it doesn't work. Pipes need multiple processes and context switches to do what the same program on a good OS would do with a plain function call or memory access. It's not only slower, it requires programs to be split up in unnatural ways and needs all this extra code to serialize and copy data and read it back. Programmers have to do more work just to make things slower and less reliable. You can probably imagine how bad it would suck if every .o file had to be a separate executable in a separate process. That's why UNIX copied 20 year old (at the time) assembly technology. Combining multiple .o files into one program is done by the UNIX linker, which is based on the shitty "ar" tape archive format.
Another classic example of the unix haters fag blaming common developer kludges on Unix. People lazily tacking on unfitting features instead of either making it fit or designing a new, better tool is an old problem predating Unix and even computing: kludges and niggerrigging have existed since the dawn of mankind and will continue until our extinction.
They are not common developer kludges, they are found only in UNIX. They might be common today, but that's only because of the spread of C and UNIX. It was the equivalent to Pajeet software, some cheap outsourced crap companies could license without having to hire good programmers. AT&T was able to get away with it because they didn't make the hardware. Blaming the PDP-11 or VAX hardware for UNIX software bugs didn't matter to AT&T.
And what I said was that you just redefined what the thread is about in order to talk about Unix again. It's getting tiresome, really. Instead of further talking about the big design up front approach, you just rant about Unix.
For examples of big design up front, look at the design of Ada and Multics.
That may or may not be, but the reason for you getting sidetracked is that you are unable to leave Unix out of the equation, no matter what the discussion is about.
Chromium and Electron are good examples of "unix" software?
Compare that to how it would be done on a normal GUI system like Lisp machines, Xerox Alto, pre-OS X Macs, and even Windows. There was software with embedded Internet Explorer since Windows 98, basically doing the same thing as Electron. Users never needed multiple copies of Internet Explorer bundled with each program. The UNIX way has been like this ever since each C program that used printf needed to bundle its own copy.
Have you read what I wrote about static linking? You disregard whatever is being said and just talk about again.
Also: I'm aware that suckless and others advocate for static linking that still keeps results small, but I wouldn't necessarily call that common practice even among unix users.
Suckless programs are small despite the redundancy because they don't do 90% of what users want. Compare them to real software that had real memory constraints like the old Macs, Lisp machines, and Xerox Alto. That was not 10% software, but they had far smaller programs and memory requirements than this suckless garbage.
Subject: why Unix sucks
Some Andrew weenie, writing of Unix buffer-length bugs, says:
> The big ones are grep(1) and sort(1). Their "silent
> truncation" have introduced the most heinous of subtle bugs
> in shell script database programs. Bugs that don't show up
> until the system has been working perfectly for a long time,
> and when they do show up, their only clue might be that some
> inverted index doesn't have as many matches as were expected.
Unix encourages, by egregious example, the most
irresponsible programming style imaginable. No error
checking. No error messages. No conscience. If a student
here turned in code like that, I'd flunk his ass.
Unix software comes as close to real software as Teenage
Mutant Ninja Turtles comes to the classic Three Musketeers:
a childish, vulgar, totally unsatisfying imitation.