Yes, exactly. I have a few slogans for this, but one is that the shell language should compose with the rest of the operating system, which is "processes and f

Yes, exactly. I have a few slogans for this, but one is that the shell language should compose with the rest of the operating system, which is "processes and files". It's a situated language. So I have been making the point that the "narrow waist" of shell is still processes and files. Whereas the narrow waist of Python and Lua is functions and compound data structures like dicts/lists (tables). One thing that is not quite obvious until you design AND USE a shell language is that if you have these conflicting narrow waists, you have problems of composition, and you will offload this complexity onto your users. From a very quick look at the hush docs, it is Lua with some shell-like stuff grafted on. I believe that will cause cause such problems in programs. They will be longer and harder to write. You will have more edge cases. ---- I hit this issue many times in Oil, and I wrote many posts tagged #software-architecture about it: http://www.oilshell.org/blog/tags.html?tag=software-architecture#software-architecture http://www.oilshell.org/blog/tags.html?tag=software-architec... Unix Shell: Philosophy, Design, and FAQs http://www.oilshell.org/blog/2021/01/philosophy-design.html http://www.oilshell.org/blog/2021/01/philosophy-design.html makes several of these points. This recent post http://www.oilshell.org/blog/2022/03/backlog-arch.html http://www.oilshell.org/blog/2022/03/backlog-arch.html asks: - Should shells have two tiers? - Both external processes and internal "functions"? - Both pipelines of bytes and pipelines of structured data? - Another one I'm working on now: Both exit codes and Python-like exceptions? In Oil the answer is yes for the first 2, but a subtle point is that the former are PRIMARY and still the narrow waist; the latter are helpers. Dicts and Lists exist to help you deal with files (and produce JSON and TSV); but they're not the primary structures of the program. I've also discussed this issue pretty extensively with the authors of the NGS and Elvish shells. A related recent comment: https://old.reddit.com/r/ProgrammingLanguages/comments/ub5vij/what_was_considered_problematic_with_unsigned/i63at3x/ https://old.reddit.com/r/ProgrammingLanguages/comments/ub5vi... Having unsigned / signed and sync / async (what color is your function?) are similar problems of composition in language design. I call them "Perlis-Thompson" problems. There is no easy answer but IMO it's vital to explicitly think about and address these problems. C has a flawed solution to the combinatorial explosion (implicit conversions), and it's caused problems and been lamented for ~50 years. There's also a good quote in that thread about why unsigned sizes in STL were a language design mistake.