Switching to ECMAscript

Switching to ECMAscript

[Ludovic Courtès]

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

Hello,

Over the last few months I have been questioning some of the choices
that were initially made for Guix.  So I finally took the time to
investigate more what could be done about it, and specifically I’ve been
playing with Guile’s ECMAscript front-end.

This is what’s already possible with Guile 2.0:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,L ecmascript
Happy hacking with ECMAScript!  To switch back, type `,L scheme'.
ecmascript@(guile-user)> require('guix');
;;; <unknown-location>: warning: possibly unbound variable `require'
$1 = #<<js-module-object> 1e325a0>
ecmascript@(guile-user)> require('gnu.packages.vim');
$2 = #<<js-module-object> 1660370>
ecmascript@(guile-user)> $2['vim'];
$3 = #<package vim-7.4 gnu/packages/vim.scm:32 3ad0c60>
ecmascript@(guile-user)> $1['open-connection'] ();
$4 = #<build-daemon 256.14 24fe840>
ecmascript@(guile-user)> $1['package-derivation']($4, $3);
$5 = #<derivation /gnu/store/kksx3yywbmkjswwj84d58brrdryvjbwi-vim-7.4.drv => /gnu/store/3wacq9b5qhnk1vn82jggnc10rb1ib4hl-vim-7.4 2d25cd0>
--8<---------------cut here---------------end--------------->8---

Pretty cool, no?

ECMAscript lacks some features that we’re used to, such as records and
macros (which we rely on a lot for package definitions, see [0]), but
OTOH it has the neat notion of “object properties.”  And of course, it’s
very popular, and GNU hackers are usually familiar with it.

In fact, as I already mentioned in my FOSDEM talk [1], things like npm
already nicely leverage that, so we don’t even have to come up with a
new format for package definitions.

So the plan would be to start rewriting package definitions in JS, to
start with, and then go ahead with the (guix ...)  modules.  Hopefully
we can reach feature parity with the current Guix within a year or so.

Another thing I would like to improve in the next months is the
packaging model.  The functional paradigm has its pros, but it has also
been causing us difficulties.  I would like to allow build processes to
access the root file system, so we can do things like “post-install
hooks.”  I don’t have any clear road map on this one though, so
suggestions are welcome!

Comments?

Thanks,
Ludo’.

[0] Section 3.3, http://arxiv.org/abs/1305.4584
[1] See around slide 29,
    http://www.gnu.org/software/guix/guix-fosdem-20140201.pdf

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

Re: Switching to ECMAscript

[Alex Sassmannshausen]

Hi Ludo,

I think this sounds like a great plan! I think a year's re-writing of
package definitions is definitely a price worth paying so we can get rid
of the "ivory tower" functional paradigm: just think of all the other
developers we could recruit to Guix!

I might not be able to help though as my JS is pretty rusty…

Alex

Ludovic Courtès writes:

> Hello,
>
> Over the last few months I have been questioning some of the choices
> that were initially made for Guix.  So I finally took the time to
> investigate more what could be done about it, and specifically I’ve been
> playing with Guile’s ECMAscript front-end.
>
> This is what’s already possible with Guile 2.0:
>
> --8<---------------cut here---------------start------------->8---
> scheme@(guile-user)> ,L ecmascript
> Happy hacking with ECMAScript!  To switch back, type `,L scheme'.
> ecmascript@(guile-user)> require('guix');
> ;;; <unknown-location>: warning: possibly unbound variable `require'
> $1 = #<<js-module-object> 1e325a0>
> ecmascript@(guile-user)> require('gnu.packages.vim');
> $2 = #<<js-module-object> 1660370>
> ecmascript@(guile-user)> $2['vim'];
> $3 = #<package vim-7.4 gnu/packages/vim.scm:32 3ad0c60>
> ecmascript@(guile-user)> $1['open-connection'] ();
> $4 = #<build-daemon 256.14 24fe840>
> ecmascript@(guile-user)> $1['package-derivation']($4, $3);
> $5 = #<derivation /gnu/store/kksx3yywbmkjswwj84d58brrdryvjbwi-vim-7.4.drv => /gnu/store/3wacq9b5qhnk1vn82jggnc10rb1ib4hl-vim-7.4 2d25cd0>
> --8<---------------cut here---------------end--------------->8---
>
> Pretty cool, no?
>
> ECMAscript lacks some features that we’re used to, such as records and
> macros (which we rely on a lot for package definitions, see [0]), but
> OTOH it has the neat notion of “object properties.”  And of course, it’s
> very popular, and GNU hackers are usually familiar with it.
>
> In fact, as I already mentioned in my FOSDEM talk [1], things like npm
> already nicely leverage that, so we don’t even have to come up with a
> new format for package definitions.
>
> So the plan would be to start rewriting package definitions in JS, to
> start with, and then go ahead with the (guix ...)  modules.  Hopefully
> we can reach feature parity with the current Guix within a year or so.
>
> Another thing I would like to improve in the next months is the
> packaging model.  The functional paradigm has its pros, but it has also
> been causing us difficulties.  I would like to allow build processes to
> access the root file system, so we can do things like “post-install
> hooks.”  I don’t have any clear road map on this one though, so
> suggestions are welcome!
>
> Comments?
>
> Thanks,
> Ludo’.
>
> [0] Section 3.3, http://arxiv.org/abs/1305.4584
> [1] See around slide 29,
>     http://www.gnu.org/software/guix/guix-fosdem-20140201.pdf

Re: Switching to ECMAscript

[Ludovic Courtès]

I’m delighted to see there’s a synergy around JavaScript with the Nix
folks:

  http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html

Ludo’.

Re: Switching to ECMAscript

[Andreas Enge]

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

Re: Switching to ECMAscript

[Felipe López]

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

2014-04-01 4:45 GMT-05:00 Ludovic Courtès <ludo@gnu.org>:

> Hello,
>
> Over the last few months I have been questioning some of the choices
> that were initially made for Guix.  So I finally took the time to
> investigate more what could be done about it, and specifically I’ve been
> playing with Guile’s ECMAscript front-end.
>
> This is what’s already possible with Guile 2.0:
>
> --8<---------------cut here---------------start------------->8---
> scheme@(guile-user)> ,L ecmascript
> Happy hacking with ECMAScript!  To switch back, type `,L scheme'.
> ecmascript@(guile-user)> require('guix');
> ;;; <unknown-location>: warning: possibly unbound variable `require'
> $1 = #<<js-module-object> 1e325a0>
> ecmascript@(guile-user)> require('gnu.packages.vim');
> $2 = #<<js-module-object> 1660370>
> ecmascript@(guile-user)> $2['vim'];
> $3 = #<package vim-7.4 gnu/packages/vim.scm:32 3ad0c60>
> ecmascript@(guile-user)> $1['open-connection'] ();
> $4 = #<build-daemon 256.14 24fe840>
> ecmascript@(guile-user)> $1['package-derivation']($4, $3);
> $5 = #<derivation /gnu/store/kksx3yywbmkjswwj84d58brrdryvjbwi-vim-7.4.drv
> => /gnu/store/3wacq9b5qhnk1vn82jggnc10rb1ib4hl-vim-7.4 2d25cd0>
> --8<---------------cut here---------------end--------------->8---
>
> Pretty cool, no?
>
> ECMAscript lacks some features that we’re used to, such as records and
> macros (which we rely on a lot for package definitions, see [0]), but
> OTOH it has the neat notion of “object properties.”  And of course, it’s
> very popular, and GNU hackers are usually familiar with it.
>
> In fact, as I already mentioned in my FOSDEM talk [1], things like npm
> already nicely leverage that, so we don’t even have to come up with a
> new format for package definitions.
>
> So the plan would be to start rewriting package definitions in JS, to
> start with, and then go ahead with the (guix ...)  modules.  Hopefully
> we can reach feature parity with the current Guix within a year or so.
>
> Another thing I would like to improve in the next months is the
> packaging model.  The functional paradigm has its pros, but it has also
> been causing us difficulties.  I would like to allow build processes to
> access the root file system, so we can do things like “post-install
> hooks.”  I don’t have any clear road map on this one though, so
> suggestions are welcome!
>
> Comments?
>
> Thanks,
> Ludo’.
>
> [0] Section 3.3, http://arxiv.org/abs/1305.4584
> [1] See around slide 29,
>     http://www.gnu.org/software/guix/guix-fosdem-20140201.pdf
>

:| :) :D :D

-- 
Luis Felipe López Acevedo
http://sirgazil.bitbucket.org/

[-- Attachment #2: Type: text/html, Size: 3565 bytes --]

Re: Switching to ECMAscript

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> this is quite outrageous

[...]

> 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.

Right.  To be honest, the other options I considered were Lua (Guile has
a front-end!), APL (GNU has an implementation!), and Python.

Of these, Python would definitely be a contender as far as creating a
synergistic modernizing dynamic in GNU and beyond goes.  However,
there’s the practical problem that there’s no GNU implementation at the
moment, and so we’d have to reinvent that wheel, which takes time.

ECMAscript sounds like a perfect intermediate choice, while awaiting a
Python front-end for Guile.  Maybe in a year or two we can start
rewriting from ECMAscript to Python?  How does that sound?

Thanks for your feedback,
Ludo’.

Re: Switching to ECMAscript

[Thompson, David]

On Tue, Apr 1, 2014 at 10:07 AM, Andreas Enge <andreas@enge.fr> 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

Re: Switching to ECMAscript

[Ludovic Courtès]

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

Since we failed to reach consensus, I hereby declare that we’ll stick
with Scheme and the functional packaging paradigm.

Foolishly yours,
Ludo’.

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