From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9767 invoked by alias); 9 Dec 2014 21:08:55 -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 9754 invoked by uid 89); 9 Dec 2014 21:08:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: etr-usa.com Received: from etr-usa.com (HELO etr-usa.com) (130.94.180.135) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 09 Dec 2014 21:08:52 +0000 Received: (qmail 30564 invoked by uid 13447); 9 Dec 2014 21:08:51 -0000 Received: from unknown (HELO polypore.west.etr-usa.com) ([73.26.17.49]) (envelope-sender ) by 130.94.180.135 (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 9 Dec 2014 21:08:51 -0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: I have a dream: A modern scripting language everywhere From: Warren Young In-Reply-To: <20141209103208.GA31138@calimero.vinschen.de> Date: Tue, 09 Dec 2014 21:08:00 -0000 Content-Transfer-Encoding: quoted-printable Message-Id: <42A9A630-5450-4E6C-AE15-16650A82FDE7@etr-usa.com> References: <26DFE265-C444-48DC-B1A6-1E4596EB9366@etr-usa.com> <20141209103208.GA31138@calimero.vinschen.de> To: The Vulgar and Unprofessional Cygwin-Talk List X-IsSubscribed: yes X-SW-Source: 2014-q4/txt/msg00003.txt.bz2 On Dec 9, 2014, at 3:32 AM, Corinna Vinschen wr= ote: > 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(*). True, but that=92s also the biggest weakness of shell scripting: it takes a= fork() to get almost anything of consequence done. It was seen as a big advance when we got internal arithmetic in the shell i= nstead of having to call out to bc. Arithmetic is one of the core competen= cies of electronic computers going back to Konrad Zuse, yet shell scripts c= ouldn=92t do it internally until, what, ksh93? [1] Mind, I do a lot of shell scripting, and I=92m happy to have it, relative t= o the situation in stock Windows. The POSIX shell environment might actually be the biggest draw of Cygwin fo= r me. Some might say it=92s the package repository instead, but I suspect = most Cygwin users are installing a relatively small set of non-Base package= s. But let=92s get back on topic: I don=92t believe we would have kSLOC scale shell scripts if we had somethi= ng more capable to write highly-portable programs in, which can sit in the = gap between sh and C. Imagine how much nicer the Autotools would be if they could count on someth= ing more powerful than POSIX.1. It=92s a big enough problem that it=92s be= en independently re-solved several times, in unsatisfactory ways: - CMake and Jam are written in C, so you have to build a separate tool befo= re you can build the program you actually wanted, rather than just run a sc= ript under an interpreter already on the system. - SCons and Bakefile require Python, and Ant requires Java. None of these tools behave like the Autotools, just writing out a platform-= independent set of scripts that run pretty much everywhere, except for Bake= file, which is built on top of Autotools. > 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. > 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 =93too big=94 observations. This cannot be a fatal flaw, though. The success of C and C++ prove that i= t is possible to have a sincerely standardized language with a large-ish li= brary. A standardization effort focused on increasing the likelihood of widespread= reimplementation to near-certainty with an expectation of high compatibili= ty among implementations would have to keep a lid on the scope of the libra= ry, just as has been done for C and C++. If Perl, Python or Ruby went through such a process, I=92d expect them to l= eave quite a lot of the current =93standard=94 library out of the formal st= andard. This can be done successfully, as with .NET Micro Framework and J2= ME. [2][3] Just to pick on one random example, it wouldn=92t be reasonable to expect R= uby=92s gdbm module to survive a standardization effort. Otherwise, even R= uby=92s standard library is too big to expect anyone else to reimplement it= .[4] I carefully qualified the term =93standard=94 above because I want to sweep= aside such =93standards=94 as the current .NET one, which is little more t= han a formal effort to document whatever Visual Studio happened to be able = to compile at the time they started work. We have Mono *despite* the ECMA = and ISO standards, not as a result. It=92s looking like .NET is going to follow the Perl/Lua route. Microsoft = recently released enough of .NET under a liberal enough license that we may= end up with just one widely-ported open source implementation, rather than= a true standard in the C/sh sense.[5] Python does have a bunch of independent reimplementations of the core langu= age. (PyPy, Iron Python, Jython=85) But, the =93batteries included=94 phi= losophy of the library again puts it into the =93too big=94 camp, unless yo= u prune it way back as part of standardization. Javascript and Scheme are both sincere standards in the C/sh sense, and thu= s have been widely reimplemented, with high levels of cross-compatibility. = Lua could be in the same camp, but the MIT license it=92s released under m= akes formal standardization and reimplementation pointless. These three ar= e all *too* small to solve our problem here: they=92d have to be considerab= ly extended to compete with shell scripting. > the shell itself never > requires "extensions". No "plugins=94. POSIX.1 is the shell=92s standard library. I don=92t have to tell you that it=92s pretty big. :) > 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++. Also observe the resilience of Perl 5 and Python 2. =93New and better,=94 = is correctly seen here as =93breaks all my existing code.=94 [1] Is that not where $((a+b)) and typeset -i came from? [2] http://en.wikipedia.org/wiki/.NET_Micro_Framework [3] http://en.wikipedia.org/wiki/Java_Platform,_Micro_Edition [4] http://www.ruby-doc.org/stdlib-2.1.5/ [5] http://blogs.msdn.com/b/dotnet/archive/2014/11/12/net-core-is-open-sour= ce.aspx