Jonathan Blow

I think they have generally the right idea, but it looks like they have been around for a number of years and not necessarily that much software has been made? I suspect because they are still tangled up in the complexity of unix, and why if you want to simplify things would

you pick awk as one of the few things you rewrite ... it doesn't make sense to me, because the real problem is the unix philosophy, not awk. 'st' seems alright, except the fact that it's limited to X-Windows is again a big problem (and probably drives complexity).

Looking more, I see that sbase has a lot of programs in it (it was not obvious from the page), but ... again it's just replicating the unix complexity but making it simpler. That's fine, but the real problem is the unix complexity.

the approach of separating complexity into simpler/leaner *programs* can be considered harmful (see vswhere), but do you disagree with the general notion of dividing problems into components and simplifying each of them? [2/]

I think dividing problems into subproblems is important and is the main way things get done when programming. But I think what gets taught in school these days is almost always overdividing, heavily.

I'd like to better understand how to move on from Unix. Taking a random use case like (grep | sort | sed), are you saying there should be one application that can chain all of these things for you (and each functionality could, optionally, be a library for reuse elsewhere)?

So you'd have a "fatter" binary called TextParser or whatever, that could do all of these individual things and chain them, and under the hood it'd be linking to libgrep or whatever else for other developers?