I don't think languages like Go and Scala deserve the author's scorn, simply because they're not supposed to solve the author's problem. But in the context of a no-holds barred rant, maybe that's forgivable (and who doesn't love a good rant now and then?).
What it sounds like is that the author wants a superior replacement to Bash. Having recently written hundreds of lines of Bash script, I feel the author's pain there. I've used Python for other things, and it made some things better and some worse. In particular, Python could make calling external programs and parsing their output easier, but I don't think that was ever a design goal for the language.
I think the language that comes closest to addressing the author's vision might be Powershell, but it's stuck in the Windows ghetto and doesn't seem to have had any influence on other languages and certainly not on any Unix/Linux-friendly languages. That's probably too bad.
And as a final note, I'd love it if there were a standard option to get JSON output out of your typical Unix command-line tool. This might be of limited utility in Bash, but when calling tools from Python, for example, it would make many things a lot easier.
Agreed. I'm kind of amazed that nothing dramatically better than Bash has come along on *nix (sure Zsh is better but only incrementally so). It seem like we could create a command line oriented programming language that would be miles ahead of Bash by incorporating the last 25 years of language design. I would love a shell with the following:
- Real functions instead of having to use 'echo' to return values
- Parsing script params also defines autocompletion (think completion parser combinators such as those found in SBT (Simple Build Tool))
- Support for FRP (funtional reactive programming) would make interacting with streams and sockets much easier
- Support for JSON streams as well as plain text
Maybe one day I will finally get the time to write such a shell.
Yeah, I love Bash as a UI, and I love the ability to capture what I'm saying and trivially preserve it in a script (check out the edit-and-execute-command readline function, if you're not familiar with it - ctrl-x ctrl-e in emacs mode, v in vi mode). But once a script gets to be more than 10 lines it's time to think about rewriting it. By 100, you almost definitely want something else. Mind you, I say this as someone who's spent a year working on a >100kLOC bash project. There's stuff to love, but it's not a language to build systems in.
Recently, I've become somewhat enamoured of the Shelly library for Haskell, for my "bash that's grown too big".
"And as a final note, I'd love it if there were a standard option to get JSON output out of your typical Unix command-line tool. This might be of limited utility in Bash, but when calling tools from Python, for example, it would make many things a lot easier."
Tooling up Bash to deal happily (generating, processing, consuming) with JSON would be fantastic - it would help make all the world's JSON API's available first-class! It seems that jq is a great start here.
What it sounds like is that the author wants a superior replacement to Bash. Having recently written hundreds of lines of Bash script, I feel the author's pain there. I've used Python for other things, and it made some things better and some worse. In particular, Python could make calling external programs and parsing their output easier, but I don't think that was ever a design goal for the language.
I think the language that comes closest to addressing the author's vision might be Powershell, but it's stuck in the Windows ghetto and doesn't seem to have had any influence on other languages and certainly not on any Unix/Linux-friendly languages. That's probably too bad.
And as a final note, I'd love it if there were a standard option to get JSON output out of your typical Unix command-line tool. This might be of limited utility in Bash, but when calling tools from Python, for example, it would make many things a lot easier.