public inbox for cygwin-talk@cygwin.com
 help / color / mirror / Atom feed
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-talk@cygwin.com
Subject: Re: I have a dream: A modern scripting language everywhere
Date: Tue, 09 Dec 2014 10:32:00 -0000	[thread overview]
Message-ID: <20141209103208.GA31138@calimero.vinschen.de> (raw)
In-Reply-To: <26DFE265-C444-48DC-B1A6-1E4596EB9366@etr-usa.com>

[-- Attachment #1: Type: text/plain, Size: 3446 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-12-09 10:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-08 23:00 Warren Young
2014-12-09 10:32 ` Corinna Vinschen [this message]
2014-12-09 21:08   ` Warren Young
2014-12-10 11:31     ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141209103208.GA31138@calimero.vinschen.de \
    --to=corinna-cygwin@cygwin.com \
    --cc=cygwin-talk@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).