From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catonano Subject: Re: my latest blog post Date: Fri, 8 Jun 2018 10:25:00 +0200 Message-ID: References: <877enaimsn.fsf@fastmail.com> <87po11j46q.fsf@dustycloud.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000da8883056e1d22b3" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44641) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fRChj-000118-VF for guix-devel@gnu.org; Fri, 08 Jun 2018 04:25:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fRChi-0000US-Ef for guix-devel@gnu.org; Fri, 08 Jun 2018 04:25:03 -0400 Received: from mail-yb0-x233.google.com ([2607:f8b0:4002:c09::233]:46161) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fRChi-0000UD-7i for guix-devel@gnu.org; Fri, 08 Jun 2018 04:25:02 -0400 Received: by mail-yb0-x233.google.com with SMTP id p22-v6so4115860yba.13 for ; Fri, 08 Jun 2018 01:25:02 -0700 (PDT) In-Reply-To: <87po11j46q.fsf@dustycloud.org> 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" To: Christopher Lemmer Webber Cc: guix-devel , Joshua Branson --000000000000da8883056e1d22b3 Content-Type: text/plain; charset="UTF-8" 2018-06-08 6:24 GMT+02:00 Christopher Lemmer Webber : > I think Catonano and Mark discussed things nicely earlier in the thread, > so I'm not going to weigh in on that (though I do agree that we would > can and should do better, but that also it's important to realize that > community members only have so many personal resources to be able to > respond sometimes). > Note taken. My bad > Guile still matters a lot to me. I think Guile has a long way to go, > but I look at it more that there is an opportunity for us to do better > than that we have failed currently. What can we do to move in the right > direction? > I think an important step is acknowledging the importance of the quality of the experience with GNU tools, as Fis also remarked. To me "the computer for the rest of us" is still a landmark I know that Apple is not commonly associated with software freedom concerns But the Apple computing experience has been empowering to countless people, me included. The experience does matter. So, is a macro stepping facility missing ? Clearly state so in the manual Andy Wingo has a post in which he lists tasks he'd lie to be implemented on Guile, many of them have to do with the file format of the compiled files. Some love should go to the quality of the experience too, not only to the tech issues Andy and Ludo are way too competent, they unawarely set the bar very high This is a cognitive issue, I understand that, I'm not blaming anyone Ludo openly said so in several occasions, he even included an indication about where a funtion was being declared and where it was being called in a scrap of Nix code, in one of his talks And I think he did so because *I* had said that in Nix I could't distinguish when a function was being declared and when it was being called So he's aware of the problem As for me I don't know exactly what cold be done I tried to elicit some debate I suggested some edits to the Guile manual These are tiny steps, more could be envisioned; I just can't come up with anything more right now Allow me only one last remark Fis claimed that the error messages that Guile provides them with don't include indications about in which file the error occurred So he's using Chez scheme instead of Guile, if I remember correctly I take from this that the Chez scheme error mesages are better. Mark wrote to Fis in that thread on the Guile mailing list that in order to have better error messages, the compiler should be modified (and that would be an awful lot of work) This is similar to the contrast on macro stepping Racket has a luxury macro stepping experience, Guile has no macro stepper So how does Chez scheme manage to provide better error messages ? I'm not trying to be adversarial again, here, Mark I just think that the problem deserves to be mapped out so that people know what they're getting into I praise software freedom myself But I think the empowerment component is being overlooked My suspect is that over the years, Andy Wingo made some design choices in implementing Guix that implicitly sacrificed the experience to the benefit of performance, or oter technical aspects Possibly because he was alone in this task and the amount of work he could devolve into Guile was finite. So now it's important to map things out so that we know where we are and where we want to aim. I know my contributions are extremely modest so I' not the most entitled person to discuss the design of GNU tools Please bear with me Making my concerns known is all I can do right now But I will look into the Guile manual in the coming days and I will try to draft a decent tractation of macro stepping in Guile scheme --000000000000da8883056e1d22b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
2018-06-08 6:24 GMT+02:00 Christopher Lemmer Webber <cwebber@dustycloud.org>:
I think Catonano and M= ark discussed things nicely earlier in the thread,
so I'm not going to weigh in on that (though I do agree that we would can and should do better, but that also it's important to realize that<= br> community members only have so many personal resources to be able to
respond sometimes).

Note taken. My bad<= br>=C2=A0
Guile still matters a lot to me.=C2=A0 I think Guile has a long way to go,<= br> but I look at it more that there is an opportunity for us to do better
than that we have failed currently.=C2=A0 What can we do to move in the rig= ht
direction?

I think an important step is= acknowledging the importance of the quality of the experience with GNU too= ls, as Fis also remarked.

To me "the computer for th= e rest of us" is still a landmark

I know that Apple = is not commonly associated with software freedom concerns

But the Apple computing experience has been empowering to countless people= , me included.

The experience does matter.
=
So, is a macro stepping facility missing ? Clearly state so = in the manual

Andy Wingo has a post in which he lists tas= ks he'd lie to be implemented on Guile, many of them have to do with th= e file format of the compiled files.

Some love should go= to the quality of the experience too, not only to the tech issues

<= /div>Andy and Ludo are way too competent, they unawarely set the bar very h= igh

This is a cognitive issue, I un= derstand that, I'm not blaming anyone

Ludo openly said so in several occasions, he even included an indica= tion about where a funtion was being declared and where it was being called= in a scrap of Nix code, in one of his talks

And I think he did so because *I* had said that in Nix I could= 9;t distinguish when a function was being declared and when it was being ca= lled

So he's aware of the problem

As for me I don't know exactly what cold be done

I tried to elicit some debate

I suggested some edits to the Guile manual

These are tiny steps, more could be envisioned; I jus= t can't come up with anything more right now

Allow me only one last remark

Fis claimed that the error messages that Guile provides them with = don't include indications about in which file the error occurred
So he's using Chez scheme instead of = Guile, if I remember correctly

I ta= ke from this that the Chez scheme error mesages are better.

Mark wrote to Fis= in that thread on the Guile mailing list that in order to have better erro= r messages, the compiler should be modified (and that would be an awful lot= of work)

This is similar to the contrast on macro stepping

Racket has a luxury macro stepping experience, Guile= has no macro stepper

So how does C= hez scheme manage to provide better error messages ?

I'm not trying to be= adversarial again, here, Mark

I ju= st think that the problem deserves to be mapped out so that people know wha= t they're getting into

I praise software freedom myself

But I think the empowerment component is being overl= ooked

My suspect is that over the y= ears, Andy Wingo made some design choices in implementing Guix that implici= tly sacrificed the experience to the benefit of performance, or oter techni= cal aspects

Possibly because he was= alone in this task and the amount of work he could devolve into Guile was = finite.

So now it's important t= o map things out so that we know where we are and where we want to aim.
=
I know my contributions are extremely = modest so I' not the most entitled person to discuss the design of GNU = tools

Please bear with me

Making my concerns known is all I can do rig= ht now

But I will look into the Gui= le manual in the coming days and I will try to draft a decent tractation of= macro stepping in Guile scheme
--000000000000da8883056e1d22b3--