> the mystery behind function overloading In NGS the common case for multiple dispatch would be to define your own type and then add methods to existing multim

> the mystery behind function overloading In NGS the common case for multiple dispatch would be to define your own type and then add methods to existing multimethod to handle that type; additionally I've simplified the dispatch algorithm exactly for this reason - unclear answer to "what's going to be called actually?". > function overloading is supported in the same way that its also supported in Bash too where you might have a function but if there is a alias of the same name that will take priority. I don't think it is called overloading. That's very different from having two methods with the same name and the "right one" is called based on types of passed arguments. > interpreting an indexed argument into an named arguments. In NGS it happens in exactly one place, when main() is called. At that point command line arguments are automatically parsed based on main() parameters and passed to main(). I don't think I understand your reasoning behind not including named parameters. > NGS likes to expose its smart features whereas in murex they're abstracted away a little Sounds about right. Power to the people! > Having different behaviours for different executables hard coded into the shell is one behaviour I purposely avoided. I can see why. NGS prefers to do the right thing in most cases and have shorter and cleaner code. Yes adding some risk, which I see as not that big - exception when an exit code was "ok" for unknown program (unknown external programs default to exception on non-zero exit code). I also dream about moving the hard coded information about programs into separate schema, which could be re-used between different shells. That would be similar to externally provided typescript definitions for existing code, described at https://www.typescriptlang.org/docs/handbook/declaration-files/templates/module-d-ts.html https://www.typescriptlang.org/docs/handbook/declaration-fil... > differ between Linux, BSD, Windows, "detect program variant" feature in the schema I mentioned above > hard coding executable behaviour Yep, smells a bit > causes more potential issues than it solves. I think in particular situation with exit codes the risk is low. > users expect the shell to understand all external executables but there are some you haven't anticipated thus breaking expectation / assumptions Yes. Downside. That's the kind of surprises that suck. Need to make sure at least the docs are clearly warning about this. > So instead I've relied on having foundational logic that is consistent. Totally understandable. > STDERR contains a failed message (eg "false", "failed", etc) or STDERR is > STDOUT[6]. This has covered every use case I've come across. Sounds also like potentially surprising, somewhat similar to handling exit codes. Yes, it's not per program and that's why it's better but still. > Additionally STDERR is highlighted red by default As it should! Yes! > mini-stack trace Yes, please! > testing framework baked into the shell language. Same in NGS but https://github.com/ngs-lang/ngs/issues/494 https://github.com/ngs-lang/ngs/issues/494 :) > So its fair to say I've spent a significant amount of time designing smarter ways of handling failures than your average shell scripting language. As I'm sure you have too. I guess. Differently of course :) > Personally I just describe it as "error handling" because in my view this is how peoples expectations are rather than the reality of handling forked executables. Sounds like I was not clear enough as if something is not uniform in this regard in NGS. Exceptions are not only for external programs. It just happens that external program can be called inside "if" condition; an exception might occur there.