I would argue that it thrives in those most basic cases, and isn't really suited to building truly complex systems. But I also don't think there's anything wrong with that. There's a use-case for simple pieces that are easy to snap together, and I think that use-case has been greatly under-served because lots of things that aim for it end up as complicated, multi-faceted APIs.

You could almost say that micro-services are trying to follow in the Unix tradition. But the problem is that a) they don't really get used in that ideal, small-scale use-case because they're almost always written and consumed internally, not exposed to the public, and b) they do get used in those huge, complex cases where their lego-ness stops being a virtue and starts being a liability.

> starts being a liability

SaaS is all the rage now, and the business of SaaS is disincentivized from making "lego-like" software. The easier it is to interoperate, arguably the easier it is to replace or reimplement your service.

Because a lot of the value of unix tools is derived from their interoperability, they play nice with each other.

Yeah, that is part of the problem too. Any for-profit corp would love to lock people in, and software megacorps no longer need to interoperate for their own survival. So we see increased lock-in across most of the (commercial) software world.

An interesting inverse-example is Slack, which does lots of interop with other services, because it isn't a trillion-dollar company that can attempt to give you everything you need under a single roof.

> I would argue that it thrives in those most basic cases, and isn't really suited to building truly complex systems

Right, just like LEGOS thrive in simple cases, are not suited for building complex systems.

That is why the idea of "Software LEGOs" is not reality. Or you can say that Unix Pipes are "software LEGOs", with similar limitations.

In your practice you have favored an alternative. (not "in practice", implying absolute)

In my practice I have used both with great success. For logging, parsing, and displaying playback data from field systems, UNIX and UNIX-like tools have been incredible. VNLog in particular is a wonderful way to interact with data if you need just a bit of structure on top of unix outputs.

And anyway, getting from not-so-great data to something that a typed library in language X can parse is a great job for plain old Unix tools.

I’m saying in the sense of “time I put in to value I get out”, I’ve put quite a lot of time into bash, but even though I’ve done certain actions many times, I remember few.

I recently picked up Swift and it was a dream. Never used it in nearly the same degree, but I was highly productive quickly.

The thing is: I don’t think it’s a bad paradigm (everything a stream of text), it’s just the “IDE” sucks completely. If there was inline autocomplete, peek-ahead results, a “verbose mode” where the options are all more like typed full-English objects, instant fuzzy search of actions, multi line with an easy way to edit, etc, it would probably be fantastic and I’d be a 100x shell developer. It would also basically feel like an IDE at that point for a normal programming language!

In practice it's been massively successful for decades.