There is no issue with having each functionality being its own function or cli command. That's just good design.

The issue is when each function/command is a separate package that needs to tracked separately and depends on 10 additional packages.

I would like to see the typical dependency tree of a linux distro, I guess it is shallower and has a smaller fanout than a JS application.

Judging the shitstorm of left-pad, they might do one thing, but they don’t do it well.

Except that the philosophy is beautiful and extremely useful due to composability

It's those random lib authors who take the philosophy too literal that fail the community

> Except that the philosophy is beautiful and extremely useful due to composability

The philosophy is beautiful on the surface, which is exactly how far beauty extends.

Write some load-bearing software using a litany of software all connected by pipes throwing untyped text streams around to various handles. If you do this, and you do not experience problems due to composability, one of the following is true: 1) you aren't doing real work, 2) your software exists in an environment which never changes, which is very rare for most people (meaning that you have fixed your environment enough to wallpaper over problems with composability.)

statically compiled stuff and strongly typed data is the only way to longevity that is worth the time you need to put in to a system that must work.

The philosophy itself is solid. The implementation is another matter. The only reason to go monolithic is because of technical limitations or commercial and financial considerations IMO.

> The philosophy itself is solid.

For some things, yes. For ad-hoc stuff, composability is amazing. Once in awhile I need to use a wrench to fix my car, and I have a whole array of wrenches to accommodate most needs I have with that car. I would never drive the car with a wrench still in place holding something together, and that's what the Unix philosophy promotes: take all these small tools which each do their thing and create some larger "grander-purpose" software with them.

That works if you need to do a one-time (or at least infrequent) analysis of some raw text, but I have learned over and over to not rely on the passing of plain text between programs for anything that you need to work later on. Something always changes which breaks it. Always. Maybe not for a year, but some update happens which subtly changes the output of a command which breaks stuff down the line.

With typed data checking and compiled applications (the opposite of passing untyped text between individual tools) I can easily account for errors before they happen, and rely on tests which exercise these things, and gain significant performance improvements over piped single-purpose tools, in less time overall.

I fully agree about the problems and limitations with plain text and the lack of structure and types. It was the composability aspect of the philosophy I had in mind.