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

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Dec  9 14:07, Warren Young wrote:
> On Dec 9, 2014, at 3:32 AM, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:
> > On Dec  8 15:59, Warren Young wrote:
> >> 
> >> 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(*).
> 
> True, but thatâs also the biggest weakness of shell scripting: it
> takes a fork() to get almost anything of consequence done.

Clean separation of tasks.  If the task crashes it doesn't crash the
shell.

> It was seen as a big advance when we got internal arithmetic in the
> shell instead of having to call out to bc.  Arithmetic is one of the
> core competencies of electronic computers going back to Konrad Zuse,
> yet shell scripts couldnât do it internally until, what, ksh93? [1]

Well, yes.  And I admit freely that I'm using bash extensions.  Bash's
variable substitutions allow to create scripts calling cut, sed or grep
a lot less.

> Mind, I do a lot of shell scripting, and Iâm happy to have it,
> relative to the situation in stock Windows.
> 
> The POSIX shell environment might actually be the biggest draw of
> Cygwin for me.  Some might say itâs the package repository instead,
> but I suspect most Cygwin users are installing a relatively small set
> of non-Base packages.

Just that everybody installs something else.

> But letâs get back on topic:
> 
> I donât believe we would have kSLOC scale shell scripts if we had
> something more capable to write highly-portable programs in, which can
> sit in the gap between sh and C.

If you look close enough, you can always find a gap.  To me, the only
reason to see a gap between sh and C is my own laziness.  Sometimes I'd
like to try something without having to *think* about coding up in
either shell or C.  However, the gap-filling stuff *still* requires
thinking.  There's not a lot of tools which solve your problem right
there, on the spot, with a miracle commandline option.

> [...]
> > The complexitiy and inhibition
> > level to learn a complex scripting language is higher, I think.
> 
> The gap between Bash and Perl/Python/Ruby is indeed large, but not so
> large as the gap between Bash and C.

Au contraire, mon capitan.  The complexity in C vs. P/P/R is not in the
language.  Take a look into any one perl script not written by yourself.
The *only* problem of C vs. scripting languages is... the compiler.
C isn't interpreted.  Thus you can't just run C code, you have to
compile it.  So, to learn C, you also have to learn using build tools.
This is the double step you have to take to learn any compiled programming
language and that's what keeps people shying away, even if they know
the ins and outs of some script language.

> > But the worst problem with non-shell scripting languages is that you
> > introduce yet another level of "library" functions.
> 
> This is part of what I was getting at with my âtoo bigâ observations.
> 
> This cannot be a fatal flaw, though.  The success of C and C++ prove
> that it is possible to have a sincerely standardized language with a
> large-ish library.

Yes, but this is the standard library.  This is the OS-specifc part.
This is what you need to know to implement the other.  This is the
core of programming and no scripting langauge works without it.

Scripting languages add another layer on top of that.  That's what
I was talking about.  YA layer of libs, and plugins, and plugins
for plugins.

> If Perl, Python or Ruby went through such a process, Iâd expect them
> to leave quite a lot of the current âstandardâ library out of the
> formal standard.  This can be done successfully, as with .NET Micro
> Framework and J2ME. [2][3]
> 
> Just to pick on one random example, it wouldnât be reasonable to
> expect Rubyâs gdbm module to survive a standardization effort.
> Otherwise, even Rubyâs standard library is too big to expect anyone
> else to reimplement it.[4]

Absolutely.

> [...]
> > the shell itself never
> > requires "extensions".  No "pluginsâ.
> 
> POSIX.1 is the shellâs standard library.
> 
> I donât have to tell you that itâs pretty big. :)

LOL.  You're redefining for the sake of argument.  But, yes, in a sense,
this is a "standard library".

> > 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 certainly does happen, but observe that D and Objective C have so
> far failed to kill off C and C++.

You can't kill C ;)

> Also observe the resilience of Perl 5 and Python 2.  âNew and better,â
> is correctly seen here as âbreaks all my existing code.â

Which is good, I guess.  Cgf and I often discussed if Cygwin should move
to a complete reimplementaion "Cygwin 2", but in the end we'd probably
have had the same problems as perl 5.


Corinna

Attachment: pgp5c4xMFLh88.pgp
Description: PGP signature