Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
FWIW, ls in Research-V6 back in 1975 had 10 options. https://github.com/dspinellis/unix-history-repo/blob/Researc...
By BSD 3 in 1980 it had 11 options. https://github.com/dspinellis/unix-history-repo/blob/BSD-3-S...
The thing is, we can see even from the 1970s 'ls' how the Unix model doesn't meet the goal "to chain these simple programs together to create complex behaviors".
There is no option to escape or NUL terminate a filename, making it possible to construct a filename containing a newline which makes the output look like two file entries.
The option for that was added later.
There's also the issue that embedded terminal codes will be interpreted by the terminal.
For example the `file_ignored` function in `ls` would have made a nice reusable library (with standardized configuration params) and a cli tool (with standardized flags).
Missed opportunity to unify the shell and C, but I guess SmallTalk was kicking around at that time which went a whole lot further.
It's funny that we are still very much lacking this unification...
We don't have a high-level interpreted language that can also perform well as a system's language.
New systems languages are popping up all the time, but they are more and more hardcore (looking at you Rust). They don't embrace any aspect of scriptability.
The best effort I can think of is https://www.modular.com/.
Surely though, a native TypeScript-based language is the way. It by far has the nicest syntax out of the popular scripting languages today.
We have come so close...like with Dart...but still everyone seems to be avoiding the inevitability.
[1]: https://github.com/wertarbyte/coreutils/blob/master/src/ls.c