> (the documentation is very poor: "dialog dyn-amically with a running fcron daemon" didn't really invite me to think that it had a job scheduling UI)

I... uh.... read the documentation -rather than the second headings- and immediately understood that it had a job scheduling UI. :) I understand that we're all busy, but it does pay to take fifteen minutes or an hour every couple of weeks to sharpen the axe.

> it's not sufficiently built out that I will be able to trade my current toolset for it.

I never was claiming that you should. I was addressing your initial claim, mentioned a little bit later in this comment.

> For example, it seems that it lacks any process isolation.

Linux does that.

> Email-only reporting is not acceptable.

Consuming email is trivial. There are something like 349024823904 libraries and like a handful of good ones to do so in every popular language. :)

> I agree that Fcron is a better Cron. But I also think that it's a very poor Systemd.

Your initial assertion was that the only way to get a good cron was to implement systemd. I demonstrate that that's not true, and you counter with "Well, that cron's not systemd!"!

sigh.

> I'd much rather have a C program segfault on bad input right away...

You and I both know that it's trivial to write a C program that does exactly the same thing that your hypothetical poorly-written bash program does. :) Bash didn't invent Heisenbugs.

> It's one of the languages you mentioned. Ruby, Python, Erlang, Go, Nim, etc. all improve on the historical sloppiness of Unix.

/s/Unix/Bash or sh/ and I agree with your statement. I also note that Perl (shudder) is conspicuously absent from your list. :)

> There's much more to it than that, I believe. For example, preserving quoted arguments is a nightmare.

Thanks for the examples! I'll go over them over the next couple of days and see what I can learn from them. :D

> But I would bet that most developers don't even know that bash has first-class array support. (If you know a better solution,

Did you accidentally a sentence or two? Also, the recurring theme that I've been spotting here has been "Programmers who don't know their language often write bad or broken programs in that language.". Is this not one of the larger themes of your statements? :)

> Controlling SSH from scripts has always been painful and brittle for me.

Sorry, this is something that I've not yet had call to do. What exactly do you mean by "controlling SSH from shell scripts"? Something like

ssh user@host "someRemoteCommand $AND_A_SCRIPT_VAR_TOO"

embedded in your script? (Or the equivalent here-document?)

> As for "entire OS built on shell scripts", every Unix distro out there is built on tons of shell scripts.

That hardly means that the entire OS is built on shell scripts. I argue that the vast majority of the shell scripts out there are to handle process startup. While this is quite important, it's important to remember that the stuff that actually gets work done in the OS is very rarely written in Bash.

> Erlang's duck typing means it's susceptible to sloppy inputs just like any other duck-typed language.

I see what you're saying (and agree with your final sentence), but one could just as justifiably say

"C and C++'s ability to permit the programmer to override the specified type of a given variable means that such programs are susceptible to errors of sloppy logic. We should really be using Haskell to write our system management programming." ;)

Anyway. Thanks for the ongoing conversation. This has been quite informative.