On Dec 8 15:59, Warren Young wrote: > It’s sad that we still can’t count on stronger scripting languages > than POSIX shell and Awk in 2014. We have many better languages, but > none are part of POSIX, so we can’t count on having them everywhere. > > Perl and Python are probably too big > [...] > I love the Javascript dialect (!) of Scheme. Say what you want > against JS; it could be better, but those who say it’s the worst > language on the planet are either ignorant or being hyperbolic. > > But, fan though I am, I’ll quickly acknowledge that Javascript isn’t > going to solve this problem any time soon, either. The universality > of the web has pushed a JS interpreter onto pretty much every > computing device big enough to have a keyboard, but the only hope for > turning it into an effective Unix scripting language is coming via > node.js, and they’re years away from adding enough library support to > JS to make it fit for such a battle. > > I think only Ruby is powerful enough, small enough, and > non-controversial enough to solve this. It’s Perlish and Pythonic and > Scheme-like enough to have wide appeal and applicability. I’m not a > Ruby fan. I came up via Perl, and Ruby never struck me as different > enough to be worth switching. But, if I could count on Ruby > everywhere, that would change things. > > Swift would be a nice solution, but it’ll never really escape the > confines of the Apple world. The same goes for any of the .NET > languages, even with all this new openness. > > Anyone else see a path out of this situation? The neat thing with shell scripting is that it's relatively easy and by using tools like awk, sed, etc easy to extend in functionality(*). Everybody can cobble together simple scripts, and over time everybody can cobble together more complex scripts. The complexitiy and inhibition level to learn a complex scripting language is higher, I think. But the worst problem with non-shell scripting languages is that you introduce yet another level of "library" functions. That's the biggest difference between shell scripting and scripting in "high-level" scripting languages: (*) Shell scripts are basically the shell (pardon the pun) about the soft bits, collected from other standarized tools. With the help of dozen small helpers, io-redirection and variable substitution you can create the most complex scripts. However, the shell itself never requires "extensions". No "plugins". High-level scripting languages have to provide all this stuff by themselves. They either have a mighty library, or they have to allow to create new libraries, or they have a plugin mechanism. But there will always be yet another functionality missing, so the thing grows and grows and nobody is able to keep track what you can do and what you can't, and how, and in how many variations you can do the same. And then, years after creating all this stuff, a couple of core developers are really unhappy with what they created because it's missing some important feature, or it's too slow, or whatever, and they start to create "version 2" of their scripting language, deliberately or accidentally breaking backward compatibility with the already given ecosystem. It's a mess. This will (hopefully) never happen with shell scripting. And this is why shell scripting prevails. IMHO. Corinna