There's obviously going to be a lot of subjectiveness around the design of shell languages but I've found this is one domain where a certain amount of ugliness is overall better than going for syntax purity because the majority of time you're writing shell code it's in a REPL, it's repetitive, and often it's because you're already trying to optimise on developer effort (otherwise you'd have written the thing in Go/Java/Python/whatever anyway). And while C-style syntax does offer some familiarity for developers that can help with readability, their primary function is really to provide hints to the compiler rather than aid development.
So ~7 years ago my shell went from looking a lot like yours, with the same methods and syntax, to fewer namespaces and more Bash-isms but using C-style braces only sparingly (eg to clearly denote different scopes of code).
To illustrate this, your same code for my shell would look something like the following:
trypipe {
get https://api.ipify.org?format=json | [body] | set resp
let total=0
$resp[ip] | jsplit: '\.' | foreach i { let total=$total+$i }
if { = total > 100 } {
echo "The sum of [$resp[ip]] is a large number, $total."
}
}
(I don't have a `sum` method so there is some ugliness there. But that's a pretty simple language addition should people want it.)Your code is definitely more readable to your average developer. But the real question is how does it fair in an interactive shell? That, for me, is the real make or break of all these new alternative shell languages that are cropping up these days (and where I've focused most of my effort) because we already have plenty of write once read many languages. Where the industry is lacking is good write many read once languages.
Don't get me wrong, I think it's fantastic the work you're doing. This isn't a criticism in any way! More general curiosity how you guys have approached the interactive shell problem with a bit of back story about the journey I took when following a similar path as yourselves.