From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thompson, David" Subject: Re: Switching to ECMAscript Date: Tue, 1 Apr 2014 14:48:32 -0400 Message-ID: References: <87k3b9l6xs.fsf@gnu.org> <20140401140750.GA4471@debian> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42523) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WV3jr-0003F8-42 for guix-devel@gnu.org; Tue, 01 Apr 2014 14:48:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WV3jl-0003nb-Gb for guix-devel@gnu.org; Tue, 01 Apr 2014 14:48:47 -0400 Received: from na6sys009bog032.obsmtp.com ([74.125.150.106]:51047) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WV3jl-0003nU-CQ for guix-devel@gnu.org; Tue, 01 Apr 2014 14:48:41 -0400 Received: by mail-pb0-f54.google.com with SMTP id ma3so10225443pbc.41 for ; Tue, 01 Apr 2014 11:48:32 -0700 (PDT) In-Reply-To: <20140401140750.GA4471@debian> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Andreas Enge Cc: guix-devel On Tue, Apr 1, 2014 at 10:07 AM, Andreas Enge wrote: > Hello, > > this is quite outrageous, and if you decide to follow this road, I am certain > to quit the project, and maybe even fork it. > > I agree that the choice of using Scheme/Guile was maybe made in a hurry and > prematurely. Scheme dialects seem to follow the paradigm "one language, one > programmer" - at the Chaos Communication Congress, I did not meet two people > at the Lisp table programming in the same dialect! With our number of contri- > butors, we have already quite transgressed on this rule. Also, the functional > paradigm is a bit dated. Admittedly, we have package "objects", inheriting > from others, but this feels a bit like an add-on to modernise the language. > > However, there are much more reasonable choices than Ecmascript, with its > quirky object model, and whose functional features imply that maybe we would > not completely get rid of the past. Personally, I think we should switch to > Python. > > Among my teaching colleagues, this is now the language of choice - just about > everybody uses it! So I think that on the way to world domination, which we > should strive for, this will give us lots of opportunity (and set a positive > precedent in the GNU project, which could also use such a modernising boost). > Personally, getting a grasp on Python would be very helpful for me and serve > as an introduction to Sage, the major free mathematics software regrouping > more or less all such free software under one umbrella. > > Python is a modern programming language, and I think that also from an equal > opportunity point of view it would be a good choice: While Lisp is a left- > over from a time where computer science was essentially at the reach of > white males in the developed world, a switch could be seen as a step towards > a more inclusive environment (notice, for instance, that the OLPC Sugar > environment is written in Python). > > It is unfortunate that also Nix prepares a switch to Ecmascript; while > I consider it a positive sign that they envision an alternative language, > maybe there is still the possibility of convincing them of the merits of > Python; we might even join forces and form one community. > > What do you think? > > Andreas > > Andreas, I think that you are on to something with Python. It is more widely used in systems programming on GNU/Linux than any Lisp dialect or even ECMAScript. However, I don't think Python is the complete answer. I don't think that we should discard the elegance and simplicity of s-expressions and the power of macros so hastily. Therefore, I suggest we seriously consider using Hy[0]. Hy is a Lisp dialect that is embedded in Python. Using Hy we can get the best of both worlds. We'll have Python's extensive collection of libraries and object oriented programming features at our disposal without sacrificing s-expressions and macros. Ludovic mentioned that we would have to implement Python in Guile, but I think that since we're rewriting the code anyhow, we can eschew Guile in favor of CPython. Guile has served us well up to this point, but it looks like it's just not going to scale. I think that 1 year would be plenty of time to make this change as well. Thoughts? - Dave [0] Hy http://hylang.org