From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23247 invoked by alias); 10 Dec 2014 11:31:56 -0000 Mailing-List: contact cygwin-talk-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: cygwin-talk-owner@cygwin.com Reply-To: The Vulgar and Unprofessional Cygwin-Talk List Mail-Followup-To: cygwin-talk@cygwin.com Received: (qmail 23238 invoked by uid 89); 10 Dec 2014 11:31:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: calimero.vinschen.de Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 10 Dec 2014 11:31:53 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id F300F8E12E1; Wed, 10 Dec 2014 12:31:50 +0100 (CET) Date: Wed, 10 Dec 2014 11:31:00 -0000 From: Corinna Vinschen To: cygwin-talk@cygwin.com Subject: Re: I have a dream: A modern scripting language everywhere Message-ID: <20141210113150.GA24242@calimero.vinschen.de> Reply-To: cygwin-talk@cygwin.com Mail-Followup-To: cygwin-talk@cygwin.com References: <26DFE265-C444-48DC-B1A6-1E4596EB9366@etr-usa.com> <20141209103208.GA31138@calimero.vinschen.de> <42A9A630-5450-4E6C-AE15-16650A82FDE7@etr-usa.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <42A9A630-5450-4E6C-AE15-16650A82FDE7@etr-usa.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2014-q4/txt/msg00004.txt.bz2 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 5343 On Dec 9 14:07, Warren Young wrote: > On Dec 9, 2014, at 3:32 AM, Corinna Vinschen = wrote: > > On Dec 8 15:59, Warren Young wrote: > >>=20 > >> Anyone else see a path out of this situation? > >=20 > > 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(*). >=20 > True, but that=E2=80=99s 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=E2=80=99t 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=E2=80=99m happy to have it, > relative to the situation in stock Windows. >=20 > The POSIX shell environment might actually be the biggest draw of > Cygwin for me. Some might say it=E2=80=99s the package repository instea= d, > but I suspect most Cygwin users are installing a relatively small set > of non-Base packages. Just that everybody installs something else. > But let=E2=80=99s get back on topic: >=20 > I don=E2=80=99t 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. >=20 > 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. >=20 > This is part of what I was getting at with my =E2=80=9Ctoo big=E2=80=9D o= bservations. >=20 > 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=E2=80=99d expect t= hem > to leave quite a lot of the current =E2=80=9Cstandard=E2=80=9D library ou= t of the > formal standard. This can be done successfully, as with .NET Micro > Framework and J2ME. [2][3] >=20 > Just to pick on one random example, it wouldn=E2=80=99t be reasonable to > expect Ruby=E2=80=99s gdbm module to survive a standardization effort. > Otherwise, even Ruby=E2=80=99s standard library is too big to expect anyo= ne > else to reimplement it.[4] Absolutely. > [...] > > the shell itself never > > requires "extensions". No "plugins=E2=80=9D. >=20 > POSIX.1 is the shell=E2=80=99s standard library. >=20 > I don=E2=80=99t have to tell you that it=E2=80=99s 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. >=20 > 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. =E2=80=9CNew and bet= ter,=E2=80=9D > is correctly seen here as =E2=80=9Cbreaks all my existing code.=E2=80=9D 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 --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUiC8mAAoJEPU2Bp2uRE+gx30QAImu2aEaFaeSXs0sUPh9wznx Guzu3puK7okGJ9no56tyIL9dYASjOa7ahDL9mIApcgn30soSns0z3Ftonk8eM4WS lkJm1QXOResX2fsYcn08fxCH5d6Ngka9k6eIse68wsZ8HXAAmEr5DNVJHEw7VSyW ISjO52uIyHT7+ZzEXoKFIqNpqOiCKMZpyq8I9Dot+RaNa4qDD9Gi13Cci3fluDhP z5GfNP8s5ViFiv+sFiY7gfy/mU7ZVbvQrQL4dA4B0ZqKjgGhTu13tHAabMPSbf0L JuFMNIqxpYU1pxsMXSorHWxvYuB07UJjm9aVVx5lz6fxnAzyGrF3F+d7V9q7FNM0 GzSHOMI9e543wjzI/3aNzy+7c56W6FD59388EN7qM0lvDlKVL11ciBNqR2Ld9usZ Zs49qJ/5I0Lk5eKOQ+GLN6Lt3oiPDtnuCuAhFw2s0tX5repUYehnM1nZazkfVSmq JPNCgKrcMpTFHAzOSLDEHF3TiCrcPL3IRgNOCJEcTzSoAUt3NpwORTjQ2/Cgn8UL 3cn/Yxh2SQlIvXSZPGxKD3x01uz3cinrlxEOqWgL0nLYq4uVTdx0MefY3hkAwExP /5krc6bhSyagWtAqsJlp9y6TRGfW1lW+g+YLShbYV5s/tJLX8vkHebNAn/GT77O2 Qy1d/neMiijwVb2lVPEN =tWOe -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM--