This is the mail archive of the cygwin-talk mailing list for the cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: I have a dream: A modern scripting language everywhere

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.


Attachment: pgpBM3E1A1ZPC.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]