my latest blog post

my latest blog post

[Catonano]

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

I just published my latest blog post

In this post I discuss Guix

And I discuss Guile too

I understand that the language is strong and I expect someone to be upset

But I feel this is due

Happy reading

http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html

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

Re: my latest blog post

[Joshua Branson]

Catonano <catonano@gmail.com> writes:

> I just published my latest blog post
>
> In this post I discuss Guix
>
> And I discuss Guile too
>
> I understand that the language is strong and I expect someone to be upset
>
> But I feel this is due
>
> Happy reading
>
> http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html


That was a long post!  Thanks for taking the time to send it!  I really
don't have much room to talk about the guix or guile community, because
I'm not a contributer, at all.

My 2 cents are:

I personally dislike that saying "guys" on IRC is frowned upon.  In my
personal life I use "guys" when I'm talking to a group of people, even
if some are women.  Are there women in the guix community that are
offended by the use of "guys"?

And I did not really know how Mark H. Weaver responded to you, but it
sounds like you expected him to answer many of your questions.  I have
had a prominent free software developer gently tell me that I just need
to read the man page.  That he doesn't have time to answer all of my
questions.  I would not describe that as toxic behavior.

And I would agree that Ludo is amazing!  He is exceedingly active in the
guix community.  He answers almost ALL emails!  He's even answered some
of mine, and sometimes I did not get back to him.  And he will still
answer any questions that I have.  The man is a legend!

Re: my latest blog post

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

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?

Joshua Branson writes:

> I personally dislike that saying "guys" on IRC is frowned upon.  In my
> personal life I use "guys" when I'm talking to a group of people, even
> if some are women.  Are there women in the guix community that are
> offended by the use of "guys"?

There may be, and even if there weren't, I certainly know many women (or
generally non-male, and heck, even many male) developers who are
bothered by that language.  The question isn't just whether or not we're
upsetting someone currently (though that's important), it's also whether
we're losing the opportunity to grow our community to include such
people going forward.

Re: my latest blog post

[Fis Trivial]

Christopher Lemmer Webber writes:

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

Hi, I have been interested in utilizing guix to make a development
environment like the one offered in python. Guix can provide package
management like pip, isolated environment like virtualenv and many many
more. The only thing not in position is a build system that can use all
this like setup tools in python.  I don't have good enough knowledge to
do it over day, but anyway I tried to "get started". Actually I have
already wrote a little prototype that generates ninja syntax in
scheme. But I uses chez scheme to run the code even I stick with r6rs. I
will explain why.

During the process, I bumped into some problems that I have never
encountered before. One of them is that GNU's tool chain, in general,
it's quite not user friendly. I didn't notice it before, but now it has
becoming more and more explicit. In the case of guile, is the lack of
proper error message, usable interactive debugger. I made a few attempt
to improve it but I was told that it would be too difficult for me[1]. I
don't have the problem with this answer, actually I was glad that
someone points out the fact I need more experience so I won't waste my
time. Little off topic, what I want to say is that, if I didn't tried to
evaluate any code from string, how come a modern interpreter can tell me
the error is happened in "unknown file" "unknown line"? Especially the
"unknown file". All the error messages points to the internal of
compiler, when it comes to the part that's relevant to my code, it
becomes unknown. I used to believe these user related feature is well
established, and would be included in any formal non-alpha
version of compiler or interpreter. Please don't feel offended, I wrote
this mail and the one to the guile's mailing list is because I wanted to
help, not to complain.

The case can be made to other parts of GNU tool chain, like in the gcc
mailing list, people suggested others to use clang-tidy[2], the language
server is never implemented, lacks of tutorial style documents. The
failing of autotools is also an example. Even more, texinfo lacks all
the merit in modern documentation facility, like code highlighting,
snarfing documentation from source code, a text form that's easy to read
and follow like markdown or org-mode. Emacs made an exception, I believe
the rich document embedded inside various parts of Emacs and the precise
and helpful information for every defined variables play an great
contribution.(I especially appreciate the feature that let me jump
around elisp code even the variable is defined in C source).

So, in general, I believe that, if the guile project still have the
desire of making some waves, user friendliness should be the first
priority. Not those improvement mentioned in the manual like
implementing python. Once we can get the tool chain in right position to
lower the bar for new comers, implementing optional feature isn't too
far away. Guile's performance and system facility is quite good in the
realm of interpreted languages, based on it we can made a lots of stuff
like implementing a improved scala, being an extension language like
lua. But all this is based on the assumption that people can use their
very limited spare time to get started (Not get it done, just get
started).

If you read this through, thanks for your patient and time.

Best wishes.


[1]: http://lists.gnu.org/archive/html/guile-devel/2018-06/msg00003.html
[2]: https://gcc.gnu.org/ml/gcc/2018-05/msg00067.html

Re: my latest blog post

[Ricardo Wurmus]

Fis Trivial <ybbs.daans@hotmail.com> writes:

> time. Little off topic, what I want to say is that, if I didn't tried to
> evaluate any code from string, how come a modern interpreter can tell me
> the error is happened in "unknown file" "unknown line"? Especially the
> "unknown file".

I cannot answer this without more context.

In the case of Guix this sometimes happens because of code staging,
which is described in detail here:

    https://arxiv.org/abs/1709.00833

It’s a known limitation that is not easy to solve in general.

> So, in general, I believe that, if the guile project still have the
> desire of making some waves, user friendliness should be the first
> priority. Not those improvement mentioned in the manual like
> implementing python.

Different people work on different things that they find interesting.
It’s not a good idea to tell other people what they should spend their
volunteering time on.  Somebody who currently works on bringing Python
to the Guile VM may be in a unique position to do just that, but would
be a terrible choice for the job of improving compiler messages.

A volunteer project of this size simply doesn’t work this way.

I do know, though, that a discussion on guix-devel@gnu.org is not going
to lead to the desired outcome in Guile.  Only work on Guile can achieve
that.  For discussions about Guile, to submit proposals and to volunteer
your time for implementing the proposals, please continue this
discussion with the Guile community on guile-devel@gnu.org.

--
Ricardo

Re: my latest blog post

[Catonano]

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

2018-06-08 6:24 GMT+02:00 Christopher Lemmer Webber <cwebber@dustycloud.org>
:

> 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

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

Re: my latest blog post

[Fis Trivial]

>
> 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.
>
Actually, I tried a few options. The best one is chicken scheme, which
has an option "-analyze-only", used together with geiser, Flycheck can
provide various form of checking in Emacs. But chicken compiles scheme
into c code which brought some other problems into scope. Flycheck has a
similar checker for racket too, but doesn't work quite correctly on my
platform and racket has deviated too much from standard scheme
language, I want my code could be ported to guile later easily. So I chose
chez scheme to get started, which has default setting for portable
scheme and gives informative error messages on command line.

Re: my latest blog post

[Ricardo Wurmus]

Hi Catonano,

> 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

These are very closely linked.  I mention this because it may not be
obvious to people like myself who don’t work on compilers.

FWIW, people *are* working on improving the experience of programming
with Guile.  Some do this by working on Geiser, others by writing
libraries that are well-suited for exploratory programming with Geiser,
etc.

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

Exactly.  Please note that the compiler is currently being modified, so
it is not a good idea to start other big architectural changes right
now.

> I just think that the problem deserves to be mapped out so that people know
> what they're getting into

Certainly.  We cannot demand of other people to do this work for us,
though.  If you follow guile-devel you will also see that some compiler
changes have resulted in certain regressions, which are debugged,
addressed, and ultimately fixed.  Losing certain means of debugging
things would also be considered a regression, and they can generally be
handled in the same way.

Andy’s time is still limited.  What other people can do is discuss
*specific* cases on guile-devel and work towards a solution.  But please
do not demand of others to explain everything in detail.  (I’m directing
this at everyone who heeds my advice to go to guile-devel, not at any
one person in particular.)  In order to have a positive impact you also
need to learn enough about the state of the art to ensure that the
discussions can be productive.

For compiler design I have a lot of things to read before being able to
contribute meaningfully to a discussion; all I can do is record
instances where Guile produces poor error messages and try to figure out
what led to this outcome.  Once I’ve done my work I can share this with
other developers and get their input.


Some final remarks:

I should say that I’m rather unhappy with your labelling of the Guile
community as “toxic” or “full of jerks”.  This has not been my
experience at all, neither in my communications with the maintainers,
nor in the response to my modest contributions.

I will say that it is a rather quiet community, though.  What you called
“the silent treatment” is just silence, which is occasionally punctured
by helpful comments.  As a co-maintainer of Guix I would feel very
uncomfortable if my replying to some (but not all) emails would be
construed as an act of aggression, or really any kind of silent attempt
at communicating something.  In that case I’d much rather *not* respond
to any emails.

With regards to the shouting match on #guile that you linked in your
blog post, I can only say that I would have likely stepped in had this
happened when I was around.  Textual communication certainly should not
reach these levels of apparent aggression.

--
Ricardo

Re: my latest blog post

[Catonano]

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

2018-06-08 16:25 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Hi Catonano,
>
> > 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
>
> These are very closely linked.  I mention this because it may not be
> obvious to people like myself who don’t work on compilers.
>
> FWIW, people *are* working on improving the experience of programming
> with Guile.  Some do this by working on Geiser, others by writing
> libraries that are well-suited for exploratory programming with Geiser,
> etc.
>

I know

I'm not negating anyone's efforts

> 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)
>
> Exactly.  Please note that the compiler is currently being modified, so
> it is not a good idea to start other big architectural changes right
> now.
>
> > I just think that the problem deserves to be mapped out so that people
> know
> > what they're getting into
>
> Certainly.  We cannot demand of other people to do this work for us,
> though.


I'm not demanding anything to anyone

I *offered* to edit the manual in a way that is more bearable in my
opinion, in regard to macro expansion.

I don't now if I will ever be able to offer a proper macro stepping tool

Should I be able, I'd be glad to provide the community with it


> If you follow guile-devel you will also see that some compiler
> changes have resulted in certain regressions, which are debugged,
> addressed, and ultimately fixed.  Losing certain means of debugging
> things would also be considered a regression, and they can generally be
> handled in the same way.
>

Again: I didn't negate anyone's work

I explicitl wrote that what made the difference is not the technology


> Andy’s time is still limited.  What other people can do is discuss
> *specific* cases on guile-devel and work towards a solution.  But please
> do not demand of others to explain everything in detail.  (I’m directing
> this at everyone who heeds my advice to go to guile-devel, not at any
> one person in particular.)  In order to have a positive impact you also
> need to learn enough about the state of the art to ensure that the
> discussions can be productive.
>

I think I demonstrated I am ready to put some effort into this

And I think this remark is unfair

I know Andy was in good faith. I acknowledged again and again that there is
a cognitive (cultural ?) problem

What I proposed is to focus on where we are now so that the right direction
can be envisioned

I didn't scream that I want better error messages _right now_

Maybe the lesson here should be that the quality of the experience should
be taken into account in the first place and not as an afterthough, as if
it was the need of a random user

I was trying to underline the feedback that was brought here by a user

And I brought some feedback myself

Believe it or not, I am trying to _help_ Guile to improve

And the improvement is not technological, it's cultural

And saying I should come on guile-dev and actually provide what I thin is
useful, nowing that I can't (not immediately is not a fair answer either

Because it's equivalent to a "fuck you"

This is discussed in some of the links I provided too

I devolved some time in making my case

It's some articulated and well thoug feedback. Of the kind that the Guile
community is sorely missing

As for macro expansion, how would I have been supposed to know the context
of macro expansion ?

Shouldn't I have been asking ?



> For compiler design I have a lot of things to read before being able to
> contribute meaningfully to a discussion; all I can do is record
> instances where Guile produces poor error messages and try to figure out
> what led to this outcome.  Once I’ve done my work I can share this with
> other developers and get their input.
>

I don't know if I will ever delve into the compiler

For now, I just wanted to understan the store monad

Macro expansion is the first step of compiling, as far as I understand,
anyway.

So taking care that it's reasonably discussed could be a first step in
having more compiler hackers, some day

I am trying to contribute from where I am, not from where you require me to
be

And this is valuable too, to some extent

If you don't see this, than you are confirming the cultural problem that I
strived to depict

Some final remarks:
>
> I should say that I’m rather unhappy with your labelling of the Guile
> community as “toxic” or “full of jerks”.  This has not been my
> experience at all, neither in my communications with the maintainers,
> nor in the response to my modest contributions.
>

Good for you
My experience was different


> I will say that it is a rather quiet community, though.  What you called
> “the silent treatment” is just silence, which is occasionally punctured
> by helpful comments.  As a co-maintainer of Guix I would feel very
> uncomfortable if my replying to some (but not all) emails would be
> construed as an act of aggression, or really any kind of silent attempt
> at communicating something.  In that case I’d much rather *not* respond
> to any emails.
>

Ok, I already applogized to Mark for having assumed that his silence was
aggression, when it wasn't

Someone else made me notice this too

I'll apologize to you too

But if you take a look at thhe guile-user mailing list, and another loo at
the guix-dev mailing list (or even to the guix help mailing list) you'll
get 2 completely different outlooks

Maybe it's not aggression

Still there's something deeply different going on in the 2 places


> With regards to the shouting match on #guile that you linked in your
> blog post, I can only say that I would have likely stepped in had this
> happened when I was around.  Textual communication certainly should not
> reach these levels of apparent aggression.
>

What do you mean with "apparent" ?
I felt it was pretty substantial

I think that person should be reprimanded  and possibly temporary banned
from the channels

My partecipation in the shouting was only a pale substitute of what I deem
opportune

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

Re: my latest blog post

[Ricardo Wurmus]

Catonano <catonano@gmail.com> writes:

>> Andy’s time is still limited.  What other people can do is discuss
>> *specific* cases on guile-devel and work towards a solution.  But please
>> do not demand of others to explain everything in detail.  (I’m directing
>> this at everyone who heeds my advice to go to guile-devel, not at any
>> one person in particular.)  In order to have a positive impact you also
>> need to learn enough about the state of the art to ensure that the
>> discussions can be productive.
>>
>
> I think I demonstrated I am ready to put some effort into this
>
> And I think this remark is unfair

I wrote this:

   But please do not demand of others to explain everything in detail.
   (I’m directing this at everyone who heeds my advice to go to
   guile-devel, not at any one person in particular.)

Rephrasing: I’d like to point this out to people who take this
opportunity to bemoan the lack of other features or who disagree with
what they think are different priorities.  You do not feel addressed if
you know you’ve made efforts in this area.

> And saying I should come on guile-dev and actually provide what I thin is
> useful, nowing that I can't (not immediately is not a fair answer either
>
> Because it's equivalent to a "fuck you"

Wow.  No.

I think that’s an *extremely* uncharitable reading of what I wrote.  I
will refrain from further comments in this thread lest what I write will
be misconstrued in a similar fashion.

>> With regards to the shouting match on #guile that you linked in your
>> blog post, I can only say that I would have likely stepped in had this
>> happened when I was around.  Textual communication certainly should not
>> reach these levels of apparent aggression.
>>
>
> What do you mean with "apparent" ?

I’m pretty bad at gauging emotion in textual communication and it’s
generally not easy to infer the intended tone in short text messages.
That said, the exchange you linked to appeared to me to be of an
aggressive nature.  That’s what I mean by “apparent”.

--
Ricardo

Re: my latest blog post

[Catonano]

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

2018-06-09 14:24 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Catonano <catonano@gmail.com> writes:
>
> >> Andy’s time is still limited.  What other people can do is discuss
> >> *specific* cases on guile-devel and work towards a solution.  But please
> >> do not demand of others to explain everything in detail.  (I’m directing
> >> this at everyone who heeds my advice to go to guile-devel, not at any
> >> one person in particular.)  In order to have a positive impact you also
> >> need to learn enough about the state of the art to ensure that the
> >> discussions can be productive.
> >>
> >
> > I think I demonstrated I am ready to put some effort into this
> >
> > And I think this remark is unfair
>
> I wrote this:
>
>    But please do not demand of others to explain everything in detail.
>    (I’m directing this at everyone who heeds my advice to go to
>    guile-devel, not at any one person in particular.)
>
> Rephrasing: I’d like to point this out to people who take this
> opportunity to bemoan the lack of other features or who disagree with
> what they think are different priorities.  You do not feel addressed if
> you know you’ve made efforts in this area.
>

This is another of your points I can't process now

I'll try again later



>
> > And saying I should come on guile-dev and actually provide what I thin is
> > useful, nowing that I can't (not immediately is not a fair answer either
> >
> > Because it's equivalent to a "fuck you"
>
> Wow.  No.
>
> I think that’s an *extremely* uncharitable reading of what I wrote.  I
> will refrain from further comments in this thread lest what I write will
> be misconstrued in a similar fashion.
>

O, I'll try to clarify this one too.
Just not now



>
> >> With regards to the shouting match on #guile that you linked in your
> >> blog post, I can only say that I would have likely stepped in had this
> >> happened when I was around.  Textual communication certainly should not
> >> reach these levels of apparent aggression.
> >>
> >
> > What do you mean with "apparent" ?
>
> I’m pretty bad at gauging emotion in textual communication and it’s
> generally not easy to infer the intended tone in short text messages.
> That said, the exchange you linked to appeared to me to be of an
> aggressive nature.  That’s what I mean by “apparent”.
>


It was of an aggressive nature

I was assaulted in an arbitrary, unwarranted and uncalled for way

It was wild

Because I had used G-golf as an example

I had also used Skribilo as another example

You now what Ludo did ?

Instead of calling me an hopeless moron unwilling to learn, he went and
updated Skribilo, without saying a single word

I noticed

And I appreciated it

So, yes, it was aggressie indeed

Again. I'll try to be more complete later

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

Re: my latest blog post

[Christopher Lemmer Webber]

Catonano writes:

> Instead of calling me an hopeless moron unwilling to learn, he went and
> updated Skribilo, without saying a single word
>
> I noticed
>
> And I appreciated it
>
> So, yes, it was aggressie indeed
>
> Again. I'll try to be more complete later

I think it's great that Ludovic responded so nicely with Skribilo.
Though I read what Ricardo wrote... I think he never called you anything
of the sort, and if I had read only your email I would have gotten the
impression that he had (I am not sure if this is what you intended here,
maybe you were referring to something else, but I think it applies to at
least the comment where you interpreted what Ricardo said as "f--- you").
If I were in Ricardo's situation I think I would feel very hurt.

I think part of the conflict here is you're saying you're seeing some
things that you think are clearly missing from the project, and here are
some things that you'd like to see changed, and here are some things you
are offering to change.  And that I think is very good.  But you are
also identifying some things you'd like to see changed that you don't
yet know how to change.  Ricardo is suggesting that you learn more about
them and jump in to help change them.

Is this a hostile thing to do?  Well, if it were used as a way to
dismiss the request entirely, probably.  But what I think Ricardo is
trying to say is that the Guile community is resource-strapped (which it
is, being run by volunteers).  We cannot demand that anyone who is
volunteering work on a specific thing, but we can ask and make
suggestions.  And one excellent way to make changes happen is to learn
and step into the role of making them happen.

Not everyone can, and this is true and I fully agree.  To that end, I
think that's where bug reports come in, and making an appeal to the
community to work on a specific thing is useful.  But I also think that
it is true that everyone can help in some ways, and that we also
remember that everyone is volunteering.  We cannot expect that
everything that we would like done will be done because all volunteers
only have so much energy.  To that end, a call to "please help" is not
necessarily dismissive... it may be a call to ask you to be empowered,
and a call to say that your contributions would be welcome and
appreciated.

Most importantly, I think we should not put negative words in another
person's mouth that they did not say or intend.  I linked "Assume Good
Faith" earlier because I think we cannot build a strong community
together without doing so.  To put more negative words in place of what
someone said puts them on the defensive and makes it hard to come
towards further progress.  This is a collaborative game... let's
recognize that, and all work together to make it a better place.

Re: my latest blog post

[Christopher Lemmer Webber]

Ricardo Wurmus writes:

> Catonano <catonano@gmail.com> writes:
>
> I wrote this:
>
>    But please do not demand of others to explain everything in detail.
>    (I’m directing this at everyone who heeds my advice to go to
>    guile-devel, not at any one person in particular.)
>
> Rephrasing: I’d like to point this out to people who take this
> opportunity to bemoan the lack of other features or who disagree with
> what they think are different priorities.  You do not feel addressed if
> you know you’ve made efforts in this area.
>
>> And saying I should come on guile-dev and actually provide what I thin is
>> useful, nowing that I can't (not immediately is not a fair answer either
>>
>> Because it's equivalent to a "fuck you"

I think at a moment like this it's important to step back a
moment... Wikipedia has a good philosophy here called "Assume Good
Faith":

  https://en.wikipedia.org/wiki/Wikipedia:Assume_good_faith

Making Guile into a friendlier environment for newcomers is important.
But if we are to have a friendly environment, the only way that can
happen is if we believe that in general we have a culture of
collaboration.  That doesn't mean we don't hold people accountable if
they are clearly demonstrating disrespectful or hostile behavior.  But
there's no way to have a collaborative environment if we don't try to
give people the benefit of the doubt that they wish to work together to
improve things.

Re: my latest blog post

[Mark H Weaver]

Hi Catonano,

Catonano <catonano@gmail.com> writes:

> I just published my latest blog post
>
> In this post I discuss Guix
>
> And I discuss Guile too
>
> I understand that the language is strong and I expect someone to be upset
>
> But I feel this is due
>
> Happy reading
>
> http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html

I appreciate you sharing your thoughts on this.  I wanted to apologize
for making you feel badly; it honestly was not my intent to shame you in
any way.

To be honest, I felt a bit defensive when you seemed to contradict my
claim that 'macroexpand-1' would be difficult to implement in a modern
Hygienic macro expander, when you pointed to the Racket documentation
and asked (possibly rhetorically) whether Racket had hygienic macros.
What felt to you like "slight shaming" might have been somehow related
to my feeling defensive about this.

My lack of response until now to your most recent message in that thread
was not because my "patience was exhausted", as you wrote, but only
because I'm stretched far too thin, and I haven't yet figured out how to
respond to your last message.

I simply don't have enough time for all of the things I'd like to do, so
many important things get dropped on the floor.  I respond to user
questions and bug reports sporadically, when I have the time and energy
to do so.  It's nothing personal.

For what it's worth, I think that your line of questions about
'macroexpand-1' was perfectly reasonable, and neither worthy of shame
nor of feeling like an idiot.  The details of modern macro expanders are
quite difficult, and I suspect that even seasoned Scheme hackers rarely
understand them in depth.

     Regards,
       Mark

Re: my latest blog post

[Catonano]

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

Mark,

2018-06-07 19:03 GMT+02:00 Mark H Weaver <mhw@netris.org>:

I appreciate you sharing your thoughts on this.  I wanted to apologize
> for making you feel badly; it honestly was not my intent to shame you in
> any way.
>

Thank you for your kind and measured words
I appreciate both the tone and the content of your reply

I am very reassured by your statement that you find my quuestions about
macro expansion reasonable and legitimate

My feeling was not positive and I'm only happy of having been wrong


> To be honest, I felt a bit defensive when you seemed to contradict my
> claim that 'macroexpand-1' would be difficult to implement in a modern
> Hygienic macro expander, when you pointed to the Racket documentation
> and asked (possibly rhetorically) whether Racket had hygienic macros.
> What felt to you like "slight shaming" might have been somehow related
> to my feeling defensive about this.
>

I see

On my side, I was a bit adversary because I feel that a macro stepper is a
fundamental feature of a scheme system and in Guile it's less than an
afterthought

I understand that implementing it is too much work

But I think that the manual should at least mention macro stepping as a
missing feature, it should mention the internal APIs that you indicated in
that thread and the uncertainties around them

What I want to convey is that the user shouldn't be left in the dark about
macro stepping

On the bright side, after this discussion, I offer to contribute a
paragraph for the manual where the macro stepping missing feature is
discussed

It will still be a missing feature, but at least the user will know what
she needs to know

I'd use the enlightening example you provided, the warings you raised and
the notions contained in the paragraph about the syntax helpers

Probably the part that's not about syntax helpers should be pulled out from
there and integrated in the new paragraph



> My lack of response until now to your most recent message in that thread
> was not because my "patience was exhausted", as you wrote, but only
> because I'm stretched far too thin, and I haven't yet figured out how to
> respond to your last message.
>
> I simply don't have enough time for all of the things I'd like to do, so
> many important things get dropped on the floor.  I respond to user
> questions and bug reports sporadically, when I have the time and energy
> to do so.  It's nothing personal.
>

I'm so relieved in learning you didn´t shrug it

Someone else made me notice that the lack of an answer can't always be
interpeted as an aggression, as I did in my post.

I did, indeed.

The lack of an answer hits me, admittedly

I apologize for being emotional about this


>
> For what it's worth, I think that your line of questions about
> 'macroexpand-1' was perfectly reasonable, and neither worthy of shame
> nor of feeling like an idiot.  The details of modern macro expanders are
> quite difficult, and I suspect that even seasoned Scheme hackers rarely
> understand them in depth.
>
>      Regards,
>        Mark
>


thanks

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

Re: my latest blog post

[Nils Gillmann]

Catonano transcribed 7.7K bytes:
> Mark,
> 
> 2018-06-07 19:03 GMT+02:00 Mark H Weaver <mhw@netris.org>:
> 
> I appreciate you sharing your thoughts on this.  I wanted to apologize
> > for making you feel badly; it honestly was not my intent to shame you in
> > any way.
> >
> 
> Thank you for your kind and measured words
> I appreciate both the tone and the content of your reply
> 
> I am very reassured by your statement that you find my quuestions about
> macro expansion reasonable and legitimate
> 
> My feeling was not positive and I'm only happy of having been wrong
> 
> 
> > To be honest, I felt a bit defensive when you seemed to contradict my
> > claim that 'macroexpand-1' would be difficult to implement in a modern
> > Hygienic macro expander, when you pointed to the Racket documentation
> > and asked (possibly rhetorically) whether Racket had hygienic macros.
> > What felt to you like "slight shaming" might have been somehow related
> > to my feeling defensive about this.
> >
> 
> I see
> 
> On my side, I was a bit adversary because I feel that a macro stepper is a
> fundamental feature of a scheme system and in Guile it's less than an
> afterthought
> 
> I understand that implementing it is too much work
> 
> But I think that the manual should at least mention macro stepping as a
> missing feature, it should mention the internal APIs that you indicated in
> that thread and the uncertainties around them
> 
> What I want to convey is that the user shouldn't be left in the dark about
> macro stepping
> 
> On the bright side, after this discussion, I offer to contribute a
> paragraph for the manual where the macro stepping missing feature is
> discussed
> 
> It will still be a missing feature, but at least the user will know what
> she needs to know
> 
> I'd use the enlightening example you provided, the warings you raised and
> the notions contained in the paragraph about the syntax helpers
> 
> Probably the part that's not about syntax helpers should be pulled out from
> there and integrated in the new paragraph

Just my brief encouragement:

I'm not sure how active the Guile documentation writer(s) are, but if you
know how to write it or initially draft something that would be great.
Writing the code is good, but documenting it affects much more people and
would be a good outcome of the discussion :)

> > My lack of response until now to your most recent message in that thread
> > was not because my "patience was exhausted", as you wrote, but only
> > because I'm stretched far too thin, and I haven't yet figured out how to
> > respond to your last message.
> >
> > I simply don't have enough time for all of the things I'd like to do, so
> > many important things get dropped on the floor.  I respond to user
> > questions and bug reports sporadically, when I have the time and energy
> > to do so.  It's nothing personal.
> >
> 
> I'm so relieved in learning you didn´t shrug it
> 
> Someone else made me notice that the lack of an answer can't always be
> interpeted as an aggression, as I did in my post.
> 
> I did, indeed.
> 
> The lack of an answer hits me, admittedly
> 
> I apologize for being emotional about this
> 
> 
> >
> > For what it's worth, I think that your line of questions about
> > 'macroexpand-1' was perfectly reasonable, and neither worthy of shame
> > nor of feeling like an idiot.  The details of modern macro expanders are
> > quite difficult, and I suspect that even seasoned Scheme hackers rarely
> > understand them in depth.
> >
> >      Regards,
> >        Mark
> >
> 
> 
> thanks

Re: my latest blog post

[Catonano]

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

2018-06-08 11:39 GMT+02:00 Nils Gillmann <ng0@n0.is>:

> Just my brief encouragement:
>

> I'm not sure how active the Guile documentation writer(s) are, but if you
> know how to write it or initially draft something that would be great.
> Writing the code is good, but documenting it affects much more people and
> would be a good outcome of the discussion :)
>
>
Thank you Nils, 🙏

I'll do my best 😊

(use lots of emojis !!)

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

Re: my latest blog post

[Mark H Weaver]

Hi Catonano,

Thank you for your email.  I don't have time to make a proper response
yet, but for now I will respond to just one point:

Catonano <catonano@gmail.com> writes:
> On my side, I was a bit adversary because I feel that a macro stepper
> is a fundamental feature of a scheme system and in Guile it's less
> than an afterthought

As far as I know, Racket is the only Scheme implementation with a macro
stepper for hygienic macros.  Do you know of any others?

So, I strongly disagree that a macro stepper is a "fundamental feature
of a scheme system".  In fact, Scheme first appeared in 1975, and first
gained hygienic macros in 1986, but it was not until ~2007 that a macro
stepper for Scheme appeared, for Racket (called PLT Scheme at the time).
The paper, <https://www2.ccs.neu.edu/racket/pubs/gpce07-cf.pdf>,
described it as "the first macro stepper for Scheme".

> I understand that implementing it is too much work

It's not that it's too much work; it just hasn't yet been done.

> But I think that the manual should at least mention macro stepping as
> a missing feature,

If it were part of a Scheme standard, or even a very commonly
implemented extension, then I would agree that we should document its
absence.  However, as far as I know, Racket is the only Scheme
implementation that has a macro stepper.  So, this is not a feature that
users generally expect to have in a Scheme implementation.

I disagree that the Guile manual should specifically call attention to a
missing feature that almost no other Scheme implementation includes.

Whenever people switch from one Scheme implementation to another, they
will notice many missing features and APIs, and some new ones.  In your
case, you noticed that Guile lacks Racket's macro stepper, but there are
a great many other things in Racket which Guile lacks.

If we were to start documenting all of the features that exist in at
least one Scheme implementation as missing features, that's quite a
slippery slope.  I don't want to go down that slope.

If this were a common confusion among our users, then there would be
some justification for this, but it's not a common confusion.  In the
decade since the first Scheme macro stepper was invented, you are the
_only_ person who has reported confusion from the absence of this
feature in Guile.

That's not to say that you're unreasonable; it's simply due to your
particular experience of being acquainted with this feature of Racket
and perhaps being surprised that Guile didn't have it.  This same thing
could happen with _any_ feature of _any_ Scheme implementation.

Does that make sense?

     Regards,
       Mark

Re: my latest blog post

[Catonano]

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

Mark,

thank you again for your remarks

2018-06-08 20:05 GMT+02:00 Mark H Weaver <mhw@netris.org>:

> Hi Catonano,
>
> Thank you for your email.  I don't have time to make a proper response
> yet, but for now I will respond to just one point:
>
> Catonano <catonano@gmail.com> writes:
> > On my side, I was a bit adversary because I feel that a macro stepper
> > is a fundamental feature of a scheme system and in Guile it's less
> > than an afterthought
>
> As far as I know, Racket is the only Scheme implementation with a macro
> stepper for hygienic macros.  Do you know of any others?
>

Admittedly, no


> So, I strongly disagree that a macro stepper is a "fundamental feature
> of a scheme system".  In fact, Scheme first appeared in 1975, and first
> gained hygienic macros in 1986, but it was not until ~2007 that a macro
> stepper for Scheme appeared, for Racket (called PLT Scheme at the time).
> The paper, <https://www2.ccs.neu.edu/racket/pubs/gpce07-cf.pdf>,
> described it as "the first macro stepper for Scheme".
>

Oh wow !
I didn'tnow this article existed, I'll go to print it today !
Thanks for indicating that !


> > I understand that implementing it is too much work
>
> It's not that it's too much work; it just hasn't yet been done.
>
> > But I think that the manual should at least mention macro stepping as
> > a missing feature,
>
> If it were part of a Scheme standard, or even a very commonly
> implemented extension, then I would agree that we should document its
> absence.  However, as far as I know, Racket is the only Scheme
> implementation that has a macro stepper.  So, this is not a feature that
> users generally expect to have in a Scheme implementation.
>
> I disagree that the Guile manual should specifically call attention to a
> missing feature that almost no other Scheme implementation includes.
>
> Whenever people switch from one Scheme implementation to another, they
> will notice many missing features and APIs, and some new ones.  In your
> case, you noticed that Guile lacks Racket's macro stepper, but there are
> a great many other things in Racket which Guile lacks.
>
> If we were to start documenting all of the features that exist in at
> least one Scheme implementation as missing features, that's quite a
> slippery slope.  I don't want to go down that slope.
>
> If this were a common confusion among our users, then there would be
> some justification for this, but it's not a common confusion.  In the
> decade since the first Scheme macro stepper was invented, you are the
> _only_ person who has reported confusion from the absence of this
> feature in Guile.
>
> That's not to say that you're unreasonable; it's simply due to your
> particular experience of being acquainted with this feature of Racket
> and perhaps being surprised that Guile didn't have it.  This same thing
> could happen with _any_ feature of _any_ Scheme implementation.
>
> Does that make sense?
>

Yes, it does mae sense.

But I respectfully disagree

It's not that I don't see your point. Documenting Racet features as missing
features is not a slope you want to roll along and I wouldn't want either

But I still think a macro stepper is a fundamental feature of any scheme
system

The fact that only Racket provides a macro stepper is quite sad

But that says something of why scheme is a niche language, albeit being so
elegant and powerful

Tooling is not optional and it shouldn't be an afterthought

It shouldn't be, because the experience of the naive programmer _does
matter_

The maturity of tooling is one of the ranks used to evaluate the viability
of programming environments

I have been playing with Clojurescript before approaching Guix and in the
beginnings the clourescript tooling was sorely lacking many features and
lagging in many ways

But that was acnowledged as a problem or at least as a legitimate whish
list issue

In my post I argued that the communities of other programming languages are
way more thriving than the Gule one

I think that your approach to macro stepping is an example of what's wrong
with this culturre, that is in part academic, in part GNU

I acknowledged that this is  a cognitive problem, I acknowledged that
there's a lack of resources

But I won't acknowledge that this is ok

It's not

So I understand that you don't want the manual states macro stepping as a
missing feature

But I think that macro stepping should be explicitly mentioned

Maybe it could be somethiing along the lines of

"
a tool that should go along with hygienic macrro expansion is a macro
stepping facility, in order to allow people to dissect and learn macro
based libraries

Guile has no macro stepper but not all is lost !
...""

and then it would go on in explaining what you explained to me on the
mailing list

Honestly I think that keeping this inforrmation hidden deep in the guts of
a paragraph about something else is plainly unfair to users

Assuming that users read academic articles about programming languages in
order to know your way aroung Guile is not reasonable

Guile is not a research project or a doctorate thesis

Guile is supposed to be a liberating and empowering tool

Isn't it ? Maybe I misinterpreted ?

Assuming that in order to fully take advantage of it you should be an
academic is as elitarist as I can conceive

Now, I undertsand that it's not a consumer product either

Neither Clojure is, by the way.

But, jeez, you can't require reading academic articles and then wonder how
come the community is so small !!

This is exactly what should be done to keep the Guile community as small as
possible !
Academics or academics wannabe only !

This is a self serving prophecy !

The GNU tools should cater to the freedom of _final users_ not universities
and corporations only !

Or did I misinterpet this too ?

The first computer in my adult life was an Apple Macintosh (a Performa 6200)

In the Apple world the software was said to be autoexplicative, if any
software required to read a manual before the use it was considered to be
BAD DESIGN and used to be frowned upon.

And here I am required to read academic articles !!

I know it's unpalatable to you, but Apple did A LOT to popularize computing

Apple DEFINED the desktop as we know it today and then defined the mobile
phones as we now them today

While Guile is on the verge of complete irrelevance

I repeat: THE COMPUTER FOR THE REST OF US is still a lesson !!

I honestly thhin that thhe Guile communty should do an effort to step out
of its comfort zone.

If you offer hygienic macro expansion then you also have to offer the tools
to allow people to play with them !

The monad accessing the daemon, how would I delve in it ?

Is it supposed to be an artifact in support of an academic article and once
published there's nothing more to be done/said about it ?

I mean, you all are competent people. Don't you see the difference in the
spirit of te communities of, say, python, javascript or R ?

Now, again, Mark, this is not personal

I know you're in good faith.

I understand where you're coming from.

And I also undertsand that this tirade of mine will be unpalatable to you.
I'm sorry.

I'd like you to understad also where I AM COMING FROM

What I'm trying to do,  here, believe it or not, is improving Guile.

And the improvement that Guile needs is not technological. It's cultural.

Now, please, tell me: is it worth that I edit the manual to include in a
reasonable way the notions that you provided my with about macro stepping ?

Or would you refuse to merge it ?

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

Re: my latest blog post

[Ricardo Wurmus]

Catonano <catonano@gmail.com> writes:

> Assuming that users read academic articles about programming languages in
> order to know your way aroung Guile is not reasonable

I fail to see how this follows from Guile’s lack of a macro stepper.  To
be honest, I never even heard of a macro stepper before.  And I have
never felt the need to read computer science papers to “know my way
around Guile”.  (I have not studied computer science, so it isn’t that
my background allowed me to skip papers that are mandatory for other
users of Guile.)

The sentence above seems like an exaggeration to me.

(I say this with no hostility, just with surprise.)

> The monad accessing the daemon, how would I delve in it ?

The Guix manual should explain it fully, while assuming that the concept
of a monad is known (because that’s not a Guix or Guile invention).  If
it fails to do that then the Guix manual should be updated.

--
Ricardo

Re: my latest blog post

[Catonano]

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

2018-06-09 12:39 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Catonano <catonano@gmail.com> writes:
>
> > Assuming that users read academic articles about programming languages in
> > order to know your way aroung Guile is not reasonable
>
> I fail to see how this follows from Guile’s lack of a macro stepper.


Then you were not following

Mark indicated me a paper about the first macro stepper in history


> To
> be honest, I never even heard of a macro stepper before.


I haden't heard of it neither

I am following Mark's distinction, here, between a macro stepper and
macroexpand-1

I don't know if other schemes lack macroexpand-1 too but at this point it
wouldn't be relevant anymore


> And I have
> never felt the need to read computer science papers to “know my way
> around Guile”.  (I have not studied computer science, so it isn’t that
> my background allowed me to skip papers that are mandatory for other
> users of Guile.)
>
> The sentence above seems like an exaggeration to me.
>

Ok, thans for your contribution


> (I say this with no hostility, just with surprise.)
>

we have a loooong way to go



>
> > The monad accessing the daemon, how would I delve in it ?
>
> The Guix manual should explain it fully, while assuming that the concept
> of a monad is known (because that’s not a Guix or Guile invention).


And how would I know what a monad is without reading academic materials ?

Maybe Haskell is a requirement in order to use Guile//Guix ?

"assuming that the concept of a monad is known" is a problem.

Someone would want to _learn_ what a monad is AND how it can be implemented
in scheme, by dissecting this Guix macro based feature

Do you think that the code should be kept obscure and unaccessible ?

So much for the Emacs of distros

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

Re: my latest blog post

[Ricardo Wurmus]

Hi Catonano,

> 2018-06-09 12:39 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:
>
>>
>> Catonano <catonano@gmail.com> writes:
>>
>> > Assuming that users read academic articles about programming languages in
>> > order to know your way aroung Guile is not reasonable
>>
>> I fail to see how this follows from Guile’s lack of a macro stepper.
>
>
> Then you were not following
>
> Mark indicated me a paper about the first macro stepper in history

I did follow the discussion and I did see Mark mentioning the paper.
Since Guile does not *have* a macro stepper, reading a paper about how a
macro stepper was implemented is certainly not a requirement to use
Guile.  Obviously, to implement a macro stepper it is useful to know how
to do this.  But implementing a macro stepper is not what a Guile user
like myself would ever do.

>> And I have
>> never felt the need to read computer science papers to “know my way
>> around Guile”.  (I have not studied computer science, so it isn’t that
>> my background allowed me to skip papers that are mandatory for other
>> users of Guile.)
>>
>> The sentence above seems like an exaggeration to me.
>>
>
> Ok, thans for your contribution
>
>
>> (I say this with no hostility, just with surprise.)
>>
>
> we have a loooong way to go

I sense a lot of hostility in your responses to me and I don’t know why
that is.  The first sentence reads like unwarranted sarcasm to me,
because it does not seem to relate to what I wrote; the second sounds
belittling, as if my surprise at what seems like an exaggeration to me
is evidence of how far behind I am in my efforts to ensure that Guix and
Guile a welcoming to newcomers.

I’m sorry that you don’t find anything useful in my response above,
which relates my personal experience with Guile as someone who is not a
computer scientist.  I hoped it would be a useful data point.

As I find discussions like this exceptionally draining and discouraging,
detrimental to my ability to volunteer time to free software, I will
take some time off from this discussion after trying to respond to your
other message to me in this thread.

>> > The monad accessing the daemon, how would I delve in it ?
>>
>> The Guix manual should explain it fully, while assuming that the concept
>> of a monad is known (because that’s not a Guix or Guile invention).
>
>
> And how would I know what a monad is without reading academic materials ?
>
> Maybe Haskell is a requirement in order to use Guile//Guix ?
>
> "assuming that the concept of a monad is known" is a problem.

By analogy, do you think that assuming the concept of recursion would be
a problem?  Or the concept of a closure?  Would you say that this should
be explained in the *Guix* manual?  (These are sincere questions.)

We are using both of these constructs.  We are also using delayed
evaluation in the form of streams.  Luckily, those are provided as a
Guile library and are thus documented in the *Guile* manual.

> Someone would want to _learn_ what a monad is AND how it can be implemented
> in scheme, by dissecting this Guix macro based feature

I used “,expand” in the past to see the expansion of a macro
expression.  Here’s an example with the state monad:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,expand (with-monad %state-monad (return 1))
$3 = (let ((value 1))
  (lambda (state)
    ((@@ (guix monads) values) value state)))
--8<---------------cut here---------------end--------------->8---

This shows us that returning a monadic value in the state monad is the
same as returning a procedure that takes some state and returns it
alongside the value.

The Guix manual says about the things that we used:

--8<---------------cut here---------------start------------->8---
 -- Scheme Syntax: with-monad MONAD BODY ...
     Evaluate any ‘>>=’ or ‘return’ forms in BODY as being in MONAD.

 -- Scheme Syntax: return VAL
     Return a monadic value that encapsulates VAL.
--8<---------------cut here---------------end--------------->8---


Earlier, it also says something about what monads are all about:

--8<---------------cut here---------------start------------->8---
   This is where the ‘(guix monads)’ module comes in.  This module
provides a framework for working with “monads”, and a particularly
useful monad for our uses, the “store monad”.  Monads are a construct
that allows two things: associating “context” with values (in our case,
the context is the store), and building sequences of computations (here
computations include accesses to the store).  Values in a monad—values
that carry this additional context—are called “monadic values”;
procedures that return such values are called “monadic procedures”.
--8<---------------cut here---------------end--------------->8---

We’ve just seen the first part about associating “context” (in this case
some state) with values.  The second part requires a larger expression
to see how this is useful.

The Guix manual has an example right there:

--8<---------------cut here---------------start------------->8---
 -- Scheme Syntax: >>= MVAL MPROC ...
     “Bind” monadic value MVAL, passing its “contents” to monadic
     procedures MPROC...(1).  There can be one MPROC or several of them,
     as in this example:

          (run-with-state
              (with-monad %state-monad
                (>>= (return 1)
                     (lambda (x) (return (+ 1 x)))
                     (lambda (x) (return (* 2 x)))))
            'some-state)

          ⇒ 4
          ⇒ some-state
--8<---------------cut here---------------end--------------->8---

So this is an expression that somewhat uselessly computes the number 4
in a context where “some-state” is present.  We can use ,expand in the
REPL to see how this works, this time with a slightly simpler
expression that would compute 1 + 1 in some given context:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,expand (with-monad %state-monad
                               (>>= (return 1)
                                    (lambda (x) (return (+ 1 x)))))
$6 = (let ((mvalue
        (let ((value 1))
          (lambda (state)
            ((@@ (guix monads) values) value state))))
      (mproc (lambda (x)
               (let ((value (+ 1 x)))
                 (lambda (state)
                   ((@@ (guix monads) values) value state))))))
  "Bind MVALUE, a value in the state monad, and pass it to MPROC."
  (lambda (state)
    ((@@ (guix monads) call-with-values)
     (lambda () (mvalue state))
     (lambda (value state) ((mproc value) state)))))
--8<---------------cut here---------------end--------------->8---

This looks similar to the previous expression (see “mvalue”).  Looking
at the body, we see that this is a procedure that takes some state,
computes a new value by passing the state to “mvalue”, and then passes
that to the next action (the last lambda in the original expression).

I don’t think that the presence of the relevant documentation in the
Guix manual and the existence of a macro-expansion facility should be
taken as evidence that we “think that the code should be kept obscure
and unaccessible”.

I would also like to state, though, that the use of the state monad is
hardly essential for the purpose of extending or contributing to Guix.
If you find a way to improve the existing documentation, you know from
our past interactions that the maintainers and developers are very
welcoming of additions or changes to the manual.

--
Ricardo

Re: my latest blog post

[Catonano]

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

Ricardo,

you are right that in my last interaction there was some animosity and the
message was below the standard

I apologize

I see that you are maing an effort to deescalate. I appeciate that. Really

I also see that you are suggesting some techical remediation about the
store monad

And that is probably the most interesting result that came out of this
discussion until now

After all, I just wanted to understad what this monad macro does.

I'm sure you are in god faith and we are just having a misunderstanding due
to the fact that we come from different bacgrounds, even if you didn't
study computer science

In this very moment, I'm not abe to keep interacting lucidly, though

Because I lost my cool and I got tired

So I can't bring myself to read your technical contribution.

I probably need some time to regain my composture

I will probably go to the  beach to blow some steam off

I'll try again starting next monday, if you don't mind

So I can be more consequential, hopefully

For now, just a few notes

The first note is that macro expanding and macro stepping are not the same
thing


2018-06-09 14:14 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Hi Catonano,
>
> > 2018-06-09 12:39 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:
> >
> >>
> >> Catonano <catonano@gmail.com> writes:
> >>
> >> > Assuming that users read academic articles about programming
> languages in
> >> > order to know your way aroung Guile is not reasonable
> >>
> >> I fail to see how this follows from Guile’s lack of a macro stepper.
> >
> >
> > Then you were not following
> >
> > Mark indicated me a paper about the first macro stepper in history
>
> I did follow the discussion and I did see Mark mentioning the paper.
> Since Guile does not *have* a macro stepper, reading a paper about how a
> macro stepper was implemented is certainly not a requirement to use
> Guile.


Ok. I was following a thought of mine, I had to mae more explicit, probably

In my view, hacking a quick and dirt macro stepper and then use it to
explore some existing macros *IS* a requirement to use guile

Because there are some macro based libraries, so using a macro stepper is a
requirement for common usage

As I wrote, if you provide a language feature, you need to provide the
tooling for it too

The fact that Guile has no macro stepper is not enough to thin that using a
macro stepper is not a requirement
It's enough to think that Guile is missing a fundamental bit

But I understand that we can disagree on this

Obviously, to implement a macro stepper it is useful to know how
> to do this.  But implementing a macro stepper is not what a Guile user
> like myself would ever do.
>

Eh.
It seemed to me that implementing a macro stepper was reqired to me in
order to undertsand some existing macros

Maybe your last techical contribution, the one that I can't read rright
now,  proves this false

I'll try again next week and report back

Thanks for clarifiyng


> >> And I have
> >> never felt the need to read computer science papers to “know my way
> >> around Guile”.  (I have not studied computer science, so it isn’t that
> >> my background allowed me to skip papers that are mandatory for other
> >> users of Guile.)
> >>
> >> The sentence above seems like an exaggeration to me.
> >>
> >
> > Ok, thans for your contribution
> >
> >
> >> (I say this with no hostility, just with surprise.)
> >>
> >
> > we have a loooong way to go
>
> I sense a lot of hostility in your responses to me and I don’t know why
> that is.  The first sentence reads like unwarranted sarcasm to me,
> because it does not seem to relate to what I wrote; the second sounds
> belittling, as if my surprise at what seems like an exaggeration to me
> is evidence of how far behind I am in my efforts to ensure that Guix and
> Guile a welcoming to newcomers.
>
> I’m sorry that you don’t find anything useful in my response above,
> which relates my personal experience with Guile as someone who is not a
> computer scientist.  I hoped it would be a useful data point.
>

I' sure it is a data point

I'm not sure what you think it means

Does it mean that I had it coming ?

You think that I indiced David Pirotte in assaulting me in that way ?



> As I find discussions like this exceptionally draining and discouraging,
> detrimental to my ability to volunteer time to free software, I will
> take some time off from this discussion after trying to respond to your
> other message to me in this thread.
>
> >> > The monad accessing the daemon, how would I delve in it ?
> >>
> >> The Guix manual should explain it fully, while assuming that the concept
> >> of a monad is known (because that’s not a Guix or Guile invention).
> >
> >
> > And how would I know what a monad is without reading academic materials ?
> >
> > Maybe Haskell is a requirement in order to use Guile//Guix ?
> >
> > "assuming that the concept of a monad is known" is a problem.
>
> By analogy, do you think that assuming the concept of recursion would be
> a problem?  Or the concept of a closure?  Would you say that this should
> be explained in the *Guix* manual?  (These are sincere questions.)
>

No.
I think they should be explained in the Guile manual, though

The edit I am proposing about macro stepping is for the Guile manual, not
the Guix one


>
> We are using both of these constructs.  We are also using delayed
> evaluation in the form of streams.  Luckily, those are provided as a
> Guile library and are thus documented in the *Guile* manual.
>

as it shoud be


>
> > Someone would want to _learn_ what a monad is AND how it can be
> implemented
> > in scheme, by dissecting this Guix macro based feature
>
> I used “,expand” in the past to see the expansion of a macro
> expression.  Here’s an example with the state monad:
>

ok, from here on I couldn't read

as I said, I'll try again

Only: macro expanding and macr stepping are not the same thing


>
> --8<---------------cut here---------------start------------->8---
> scheme@(guile-user)> ,expand (with-monad %state-monad (return 1))
> $3 = (let ((value 1))
>   (lambda (state)
>     ((@@ (guix monads) values) value state)))
> --8<---------------cut here---------------end--------------->8---
>
> This shows us that returning a monadic value in the state monad is the
> same as returning a procedure that takes some state and returns it
> alongside the value.
>
> The Guix manual says about the things that we used:
>
> --8<---------------cut here---------------start------------->8---
>  -- Scheme Syntax: with-monad MONAD BODY ...
>      Evaluate any ‘>>=’ or ‘return’ forms in BODY as being in MONAD.
>
>  -- Scheme Syntax: return VAL
>      Return a monadic value that encapsulates VAL.
> --8<---------------cut here---------------end--------------->8---
>
>
> Earlier, it also says something about what monads are all about:
>
> --8<---------------cut here---------------start------------->8---
>    This is where the ‘(guix monads)’ module comes in.  This module
> provides a framework for working with “monads”, and a particularly
> useful monad for our uses, the “store monad”.  Monads are a construct
> that allows two things: associating “context” with values (in our case,
> the context is the store), and building sequences of computations (here
> computations include accesses to the store).  Values in a monad—values
> that carry this additional context—are called “monadic values”;
> procedures that return such values are called “monadic procedures”.
> --8<---------------cut here---------------end--------------->8---
>
> We’ve just seen the first part about associating “context” (in this case
> some state) with values.  The second part requires a larger expression
> to see how this is useful.
>
> The Guix manual has an example right there:
>
> --8<---------------cut here---------------start------------->8---
>  -- Scheme Syntax: >>= MVAL MPROC ...
>      “Bind” monadic value MVAL, passing its “contents” to monadic
>      procedures MPROC...(1).  There can be one MPROC or several of them,
>      as in this example:
>
>           (run-with-state
>               (with-monad %state-monad
>                 (>>= (return 1)
>                      (lambda (x) (return (+ 1 x)))
>                      (lambda (x) (return (* 2 x)))))
>             'some-state)
>
>           ⇒ 4
>           ⇒ some-state
> --8<---------------cut here---------------end--------------->8---
>
> So this is an expression that somewhat uselessly computes the number 4
> in a context where “some-state” is present.  We can use ,expand in the
> REPL to see how this works, this time with a slightly simpler
> expression that would compute 1 + 1 in some given context:
>
> --8<---------------cut here---------------start------------->8---
> scheme@(guile-user)> ,expand (with-monad %state-monad
>                                (>>= (return 1)
>                                     (lambda (x) (return (+ 1 x)))))
> $6 = (let ((mvalue
>         (let ((value 1))
>           (lambda (state)
>             ((@@ (guix monads) values) value state))))
>       (mproc (lambda (x)
>                (let ((value (+ 1 x)))
>                  (lambda (state)
>                    ((@@ (guix monads) values) value state))))))
>   "Bind MVALUE, a value in the state monad, and pass it to MPROC."
>   (lambda (state)
>     ((@@ (guix monads) call-with-values)
>      (lambda () (mvalue state))
>      (lambda (value state) ((mproc value) state)))))
> --8<---------------cut here---------------end--------------->8---
>
> This looks similar to the previous expression (see “mvalue”).  Looking
> at the body, we see that this is a procedure that takes some state,
> computes a new value by passing the state to “mvalue”, and then passes
> that to the next action (the last lambda in the original expression).
>
> I don’t think that the presence of the relevant documentation in the
> Guix manual and the existence of a macro-expansion facility should be
> taken as evidence that we “think that the code should be kept obscure
> and unaccessible”.
>
> I would also like to state, though, that the use of the state monad is
> hardly essential for the purpose of extending or contributing to Guix.
> If you find a way to improve the existing documentation, you know from
> our past interactions that the maintainers and developers are very
> welcoming of additions or changes to the manual.
>
> --
> Ricardo
>
>

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

Re: my latest blog post

[Mark H Weaver]

Catonano <catonano@gmail.com> writes:

> Now, please, tell me: is it worth that I edit the manual to include in
> a reasonable way the notions that you provided my with about macro
> stepping ?
>
> Or would you refuse to merge it ?

My position is that the manual is not an appropriate place to document
wishlist items for our TODO list, which is what this is.  So no, I would
not merge it into our manual.

However, I agree with you that a macro stepper would be a very useful
thing to have, to help people to debug and understand macro libraries.
I believe that the appropriate place for this is as a ticket in our bug
tracking system.  That is our preferred way to keep track of unsolved
bugs and TODO list items.

I would encourage you to file a ticket by sending an email to
bug-guile@gnu.org with all of the relevant information.

I would also ask that you consider the possibility that I am
not your enemy.

       Mark

Re: my latest blog post

[Thorsten Wilms]

On 07.06.2018 17:25, Catonano wrote:

> http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html

You imply that GNU groups are full of "smug jerk"s, say that "Guile is 
the realm of smugness and elitarism" and made statements like "The 
G-golf project is a tiny dot in the universe. You should be grateful 
that someone choses that to play with".

Just when you talk about how valuable it is when project contributors 
and especially the core developers step in when people use hurtful or 
even just unfortunate language or outright attack others ... you do all 
that!


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: my latest blog post

[Alex Vong]

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

Hello Catonano,

Catonano <catonano@gmail.com> writes:

> I just published my latest blog post
>
> In this post I discuss Guix
>
> And I discuss Guile too
>
> I understand that the language is strong and I expect someone to be upset
>
> But I feel this is due
>
> Happy reading
>
> http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html

It will be great if you enable https for your website. I have no
experience in making personal website (I had only done a web app hw
before) so I can't really help but Let's Encrypt seems to be a popular
choice[0].

Cheers,
Alex

[0]: https://letsencrypt.org/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: my latest blog post

[Julien Lepiller]

Le 2018-06-07 17:25, Catonano a écrit :
> I just published my latest blog post
> 
> In this post I discuss Guix
> 
> And I discuss Guile too
> 
> I understand that the language is strong and I expect someone to be
> upset
> 
> But I feel this is due
> 
> Happy reading
> 
> http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html

Hi,

that was a long but interesting reading :)

I won't be able to address your main points, about the Guile and the 
broader GNU
community. That's because even though I'm part of Guix, I haven't really 
interacted
with them (yet?). My only interactions were through Guix and a GHM I 
attended when
I wasn't a contributor to anything. I remember it as a friendly event 
though, so
your post is a bit of a surprise to me. Let me try and address some of 
the minor
points instead.

I read you're having trouble to find information from the section 
titles. Info manuals
have an index where it's easier to find things. But actually, what helps 
me the most
is to ignore the `info` command and open either the full .texi source or 
the "html
in one page" version. Then I can do full-text search, which is a lot 
quicker. Does
anyone know if there is a similar facility in the info program?

I've also found that GNU documentations were not excessively easy to 
navigate.
It's sometimes a bit hard to find information on something fuzzy like 
"what's the
function that returns only part of a string again?" or "is there 
something that can
grow like a list, but with O(1) access?", but it's a great document to 
have when
reading existing code: each procedure is very detailed and in a language 
that I find
easy to understand (although it sometimes refers to another part of the 
manual).

Ludo proposed to create a separate document for user stories and 
tutorials on how
to do specific things, Rekado suggested creating video tutorials 
explaining specific
points. I think this is the right direction.

About your concerns on recommending Guix to others, I think you're 
mistaken. I actually
discovered Guile through Guix and I haven't have any bad experience. I'm 
not on #guile
because people on #guix are generous enough to answer unrelated stupid 
questions :)
Guile was even my first functional programming language and I managed to 
learn just
enough of it to be able to create packages and system configurations. 
All of that
from reading existing code, copying parts that looked related to what I 
wanted to do
and not knowing what I was doing at all :). So from experience, you can 
use and even
contribute to guix without ever going to #guile. You just need a good 
tutorial from the
internet. My point is, if you don't want to recommand the guile 
community, you can still
recommand the friendly guix community.

Re: my latest blog post

[Clément Lassieur]

Hi Julien,

Julien Lepiller <julien@lepiller.eu> writes:

> I read you're having trouble to find information from the section titles. Info
> manuals
> have an index where it's easier to find things. But actually, what helps me
> the most
> is to ignore the `info` command and open either the full .texi source or the
> "html
> in one page" version. Then I can do full-text search, which is a lot
> quicker. Does
> anyone know if there is a similar facility in the info program?

Did you try the 's' shortcut?

https://www.gnu.org/software/texinfo/manual/info-stnd/info-stnd.html#Searching-Commands

Re: my latest blog post

[Julien Lepiller]

Le 2018-06-08 11:34, Clément Lassieur a écrit :
> Hi Julien,
> 
> Julien Lepiller <julien@lepiller.eu> writes:
> 
>> I read you're having trouble to find information from the section 
>> titles. Info
>> manuals
>> have an index where it's easier to find things. But actually, what 
>> helps me
>> the most
>> is to ignore the `info` command and open either the full .texi source 
>> or the
>> "html
>> in one page" version. Then I can do full-text search, which is a lot
>> quicker. Does
>> anyone know if there is a similar facility in the info program?
> 
> Did you try the 's' shortcut?
> 
> https://www.gnu.org/software/texinfo/manual/info-stnd/info-stnd.html#Searching-Commands

Ho, nice! Thank you! So 's' or '/' to search, and '{' or '}' to search 
previous/next occurence.
That's exactly what I wanted :)

Widen info

[Oleg Pykhalov]

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

Hello Julien,

Julien Lepiller <julien@lepiller.eu> writes:

[…]

> I read you're having trouble to find information from the section
> titles. Info manuals have an index where it's easier to find
> things. But actually, what helps me the most is to ignore the `info`
> command and open either the full .texi source or the "html in one
> page" version. Then I can do full-text search, which is a lot
> quicker. Does anyone know if there is a similar facility in the info
> program?

Clément already suggested you hitting ‘s’ key in ‘info’ program.

I want to add that if you have Emacs installed, you could invoke ‘M-x
info’ and then ‘C-x n w’ which will call “widen” to show all the manual.

Also, by reading ‘man info’ I've discovered ‘-o’ flag, which you could
try to use as an alternative to Emacs “widen”:

--8<---------------cut here---------------start------------->8---
info --subnodes -o - guix | less
--8<---------------cut here---------------end--------------->8---

[…]

Regards,
Oleg.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Widen info

[Julien Lepiller]

Le 2018-06-08 15:50, Oleg Pykhalov a écrit :
> Hello Julien,
> 
> Julien Lepiller <julien@lepiller.eu> writes:
> 
> […]
> 
>> I read you're having trouble to find information from the section
>> titles. Info manuals have an index where it's easier to find
>> things. But actually, what helps me the most is to ignore the `info`
>> command and open either the full .texi source or the "html in one
>> page" version. Then I can do full-text search, which is a lot
>> quicker. Does anyone know if there is a similar facility in the info
>> program?
> 
> Clément already suggested you hitting ‘s’ key in ‘info’ program.
> 
> I want to add that if you have Emacs installed, you could invoke ‘M-x
> info’ and then ‘C-x n w’ which will call “widen” to show all the 
> manual.
> 
> Also, by reading ‘man info’ I've discovered ‘-o’ flag, which you could
> try to use as an alternative to Emacs “widen”:
> 
> --8<---------------cut here---------------start------------->8---
> info --subnodes -o - guix | less
> --8<---------------cut here---------------end--------------->8---
> 
> […]
> 
> Regards,
> Oleg.

Fun, thanks for sharing :)

Re: my latest blog post

[Ludovic Courtès]

Hello!

Catonano <catonano@gmail.com> skribis:

> In this post I discuss Guix
>
> And I discuss Guile too
>
> I understand that the language is strong and I expect someone to be upset
>
> But I feel this is due
>
> Happy reading
>
> http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html

Thanks for sharing your thoughts!  I pretty much agree with the kind
words about the Guix group. ;-)

I didn’t know (I suppose I didn’t pay attention) to what happened to you
in Guile land, and I’m sad you experienced it and felt bad about the
whole story.

I feel that “GNU is toxic” and “Guile is toxic” are unhelpful, though.
I mean, we are GNU, and we are Guile.  GNU has its own set of problems
that we’ll have to deal with, and it’s a very big organization with its
own history etc., so improving things is difficult.  But Guile is a
small community, and I’m sure we can improve.

To me, the lesson as a Guile co-maintainer is that we should be paying
more attention in general.  I consider myself partly responsible for
this in that, although I’m still officially co-maintainer, I haven’t
been paying much attention to what’s going on on the Guile channels.  We
shouldn’t let hostile conversations like the one you experienced on
#guile through.  Perhaps what we need is someone to step up and help out
with Guile?  We should all care.

Thank you,
Ludo’.

Re: my latest blog post

[Catonano]

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

2018-06-08 15:49 GMT+02:00 Ludovic Courtès <ludo@gnu.org>:

> Hello!
>
> Catonano <catonano@gmail.com> skribis:
>
> > In this post I discuss Guix
> >
> > And I discuss Guile too
> >
> > I understand that the language is strong and I expect someone to be upset
> >
> > But I feel this is due
> >
> > Happy reading
> >
> > http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html
>
> Thanks for sharing your thoughts!  I pretty much agree with the kind
> words about the Guix group. ;-)
>
> I didn’t know (I suppose I didn’t pay attention) to what happened to you
> in Guile land, and I’m sad you experienced it and felt bad about the
> whole story.
>
> I feel that “GNU is toxic” and “Guile is toxic” are unhelpful, though.
> I mean, we are GNU, and we are Guile.  GNU has its own set of problems
> that we’ll have to deal with, and it’s a very big organization with its
> own history etc., so improving things is difficult.  But Guile is a
> small community, and I’m sure we can improve.
>

I agree that there's room for improvement

That's the reason why I wrote that post

I could have silently drift away and maybe move to Racket or to Pharo or to
knitting fishing nets, as thousands of people have already done

I thought that in providing my cut on the Guile experience I was providing
ground on which to operate

It was what I could do to help the Guile community to improve a bit.

I was maybe slightly presumptuos, yes


> To me, the lesson as a Guile co-maintainer is that we should be paying
> more attention in general.  I consider myself partly responsible for
> this in that, although I’m still officially co-maintainer,


Ah I didn't know this
I thought you were a _former_ comantainer

Had I nown you were still a comantainer, I wold have pinged you, when the
accident happened

I refrained from pinging you because I had understood that you had
explicitly stripped yourself of the Guile responsibility in order to
dedicate your efforts to Guix


> I haven’t
> been paying much attention to what’s going on on the Guile channels.  We
> shouldn’t let hostile conversations like the one you experienced on
> #guile through.


Definitely. I'm glad you acnowledge this



> Perhaps what we need is someone to step up and help out
> with Guile?  We should all care.
>

Should any initiative to improve the Guile channels come out of this, I
would consider this a huge success of my post 😊




>
> Thank you,
> Ludo’.
>
>
Thank you !

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

Re: my latest blog post

[myglc2]

On 06/07/2018 at 17:25 Catonano writes:

> I just published my latest blog post
>
> In this post I discuss Guix
>
> And I discuss Guile too
>
> I understand that the language is strong and I expect someone to be upset
>
> But I feel this is due
>
> Happy reading
>
> http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html

Hi Catonano,

Thank you for taking the time to contribute your thoughts. I am sorry to
see you getting so beat up by the responses.  Unfortunately the
nit-picking of criticisms and the "we are busy, why don't you dig in and
fix it" responses occur too often on the Guix lists.

Such responses are fundamentally unhelpful: A defensive response of
counter-criticism that spirals out of control buries the original input
and alienates potential new contributors. I agree with you that the
suggestion that you dig in and fix something you are struggling with is
a fundamentally unfriendly response.

I appreciate the effort you made to learn Guix and the risk you took to
report on the problems you experienced. I am interested in getting to
the root causes of your frustration. I re-read your post and
emails. Would it be fair to say ...

1) The monad/daemon/store is presented as central to Guix and is very
difficult to understand. If a Guix user really needs to understand it,
it needs to be explained better.

2) Sending Guix users upstream for Guile support is not working.

If these are correct, the reality is that only a few people on the
planet are in a position to address these issues. The rest of us have to
hope that they can see why it is important to stop coding long enough to
do so, perhaps in collaboration with a confused user or two ;-)

- George

Re: my latest blog post

[Mark H Weaver]

myglc2@gmail.com writes:

> On 06/07/2018 at 17:25 Catonano writes:
>
>> I just published my latest blog post
>>
>> In this post I discuss Guix
>>
>> And I discuss Guile too
>>
>> I understand that the language is strong and I expect someone to be upset
>>
>> But I feel this is due
>>
>> Happy reading
>>
>> http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html
>
> Hi Catonano,
>
> Thank you for taking the time to contribute your thoughts. I am sorry to
> see you getting so beat up by the responses.  Unfortunately the
> nit-picking of criticisms and the "we are busy, why don't you dig in and
> fix it" responses occur too often on the Guix lists.
>
> Such responses are fundamentally unhelpful: A defensive response of
> counter-criticism that spirals out of control buries the original input
> and alienates potential new contributors. I agree with you that the
> suggestion that you dig in and fix something you are struggling with is
> a fundamentally unfriendly response.

What kind of response would you consider acceptable?

I suppose the most helpful response would be for one of us to volunteer
our time to fix the bug, or to implement the feature you desire.

Are there any other acceptable responses, in your view?

       Mark

Re: my latest blog post

[Pjotr Prins]

On Sat, Jun 09, 2018 at 08:51:59PM -0400, Mark H Weaver wrote:
> myglc2@gmail.com writes:
> > Thank you for taking the time to contribute your thoughts. I am sorry to
> > see you getting so beat up by the responses.  Unfortunately the
> > nit-picking of criticisms and the "we are busy, why don't you dig in and
> > fix it" responses occur too often on the Guix lists.
> >
> > Such responses are fundamentally unhelpful: A defensive response of
> > counter-criticism that spirals out of control buries the original input
> > and alienates potential new contributors. I agree with you that the
> > suggestion that you dig in and fix something you are struggling with is
> > a fundamentally unfriendly response.
> 
> What kind of response would you consider acceptable?
> 
> I suppose the most helpful response would be for one of us to volunteer
> our time to fix the bug, or to implement the feature you desire.
> 
> Are there any other acceptable responses, in your view?
> 
>        Mark

And here we arrive at a fundamental problem that all *complex* free
software projects that have with many users. And these discussions end
up hurting/upsetting everyone involved!

The fact is that only a few people really understand any chosen part
of the project.

And these people tend to have day jobs, families and work on the
project in their spare time. In that spare time (maybe only a few
hours a week) they make choices what to work on - and, yes, it tends
to be what they think most important. Not what others think most
important. The Clojure developers are considered haughty and give
others the cold shoulder.  The Dlang people are very open, and get a
lot of abuse and kranks on their forum in return. You just can't win!!
It is easy to find examples about this. Some projects, notably Elixir,
are exceptionally good at the balancing act. But, it is not for
everyone. If you take Guile, what started this thread, it is really
one core language maintainer. What talent! Nothing to stop you from
jumping in...

I think Guix is a great project. Not only does it scale (ref.
the number of weekly contributors), the maintainers do a good job of
being nice where it matters. Guix had a community day at FOSDEM and out
of that came the recent work on 'guix pull' which is a great
improvement, ultimately asked for by the user community! I think that
is amazingly good.

Mark, indeed, from a contributor perspective the natural response is
to volunteer work on a topic users ask for. Since we write code, we
think in terms of responding in code. But that is not what this thread
is about. Here we have users who want *attention* for their
concern(s). My response to such users is two-fold: (1) dig in and prove
you understand the issue first. A lot of response goes by merit you
acquire. People tend to spend time on people they like/respect. So,
George, it is not a knee-jerk reaction. It is easy to talk, much less
easy to do. And coders and project maintainers know that. And (2)
bring up real issues on the bug tracker and try to fix them. That way
you get attention.

So, yes, dig in and try to fix it ;)

As in chess or football, people who acquire merit get taken seriously.
Not the person shouting on the side-line - unless they are respected
in some other way (maybe by giving money or other resources).

Talk is cheap. Coding is hard. We are always balancing this. I don't
contribute much to Guix at this point (other than talk ;), but we face
the exact same problems in other projects I am involved in. I get most
upset by the sense of entitlement that people have just because they
*use* my  work. Many an E-mail I wrote, but did not send, to users,
just to vent steam. I have a feeling I am not the only one. I.e., it
is not easy running a free software project. We want and like our
users, but not at all cost.

I think we should close this topic unless there are concrete
suggestions on how to improve and scale Guix development. As George
writes, we can encourage new contributors and users more, but I doubt
the route is to take core contributors away from their work. I think
the route is to improve our web presence by tutorials, blogs and
internationalization. And, in fact, those already are priorities.

Pj.

Re: my latest blog post

[Catonano]

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

2018-06-10 8:55 GMT+02:00 Pjotr Prins <pjotr.public12@thebird.nl>:

> On Sat, Jun 09, 2018 at 08:51:59PM -0400, Mark H Weaver wrote:
> > myglc2@gmail.com writes:
> > > Thank you for taking the time to contribute your thoughts. I am sorry
> to
> > > see you getting so beat up by the responses.  Unfortunately the
> > > nit-picking of criticisms and the "we are busy, why don't you dig in
> and
> > > fix it" responses occur too often on the Guix lists.
> > >
> > > Such responses are fundamentally unhelpful: A defensive response of
> > > counter-criticism that spirals out of control buries the original input
> > > and alienates potential new contributors. I agree with you that the
> > > suggestion that you dig in and fix something you are struggling with is
> > > a fundamentally unfriendly response.
> >
> > What kind of response would you consider acceptable?
> >
> > I suppose the most helpful response would be for one of us to volunteer
> > our time to fix the bug, or to implement the feature you desire.
> >
> > Are there any other acceptable responses, in your view?
> >
> >        Mark
>
> And here we arrive at a fundamental problem that all *complex* free
> software projects that have with many users. And these discussions end
> up hurting/upsetting everyone involved!
>
> The fact is that only a few people really understand any chosen part
> of the project.
>
> And these people tend to have day jobs, families and work on the
> project in their spare time. In that spare time (maybe only a few
> hours a week) they make choices what to work on - and, yes, it tends
> to be what they think most important. Not what others think most
> important. The Clojure developers are considered haughty and give
> others the cold shoulder.  The Dlang people are very open, and get a
> lot of abuse and kranks on their forum in return. You just can't win!!
> It is easy to find examples about this. Some projects, notably Elixir,
> are exceptionally good at the balancing act. But, it is not for
> everyone. If you take Guile, what started this thread, it is really
> one core language maintainer. What talent! Nothing to stop you from
> jumping in...
>
> I think Guix is a great project. Not only does it scale (ref.
> the number of weekly contributors), the maintainers do a good job of
> being nice where it matters. Guix had a community day at FOSDEM and out
> of that came the recent work on 'guix pull' which is a great
> improvement, ultimately asked for by the user community! I think that
> is amazingly good.
>
> Mark, indeed, from a contributor perspective the natural response is
> to volunteer work on a topic users ask for. Since we write code, we
> think in terms of responding in code. But that is not what this thread
> is about. Here we have users who want *attention* for their
> concern(s).


Ok. So ... ?


> My response to such users is two-fold: (1) dig in and prove
> you understand the issue first. A lot of response goes by merit you
> acquire. People tend to spend time on people they like/respect. So,
> George, it is not a knee-jerk reaction. It is easy to talk, much less
> easy to do. And coders and project maintainers know that. And (2)
> bring up real issues on the bug tracker and try to fix them. That way
> you get attention.
>
> So, yes, dig in and try to fix it ;)
>

Ah, I see

So: nothing.

Pjotr I ALREADY offered a contribution

The manual discusses some internal APIs in a paragraph about something else

That's unrespectful of reader's time

I proposed some edits

I keep reading, all around, that also not coding contributions are valuable

Are they ?

I also argued that macros are a part of scheme but the debugging
infrastructure doesn't cover them, at all

But of course, this is "talking", maybe I'm too entitled



> As in chess or football, people who acquire merit get taken seriously.
> Not the person shouting on the side-line - unless they are respected
> in some other way (maybe by giving money or other resources).
>

I'm glad I'm flushing out, people

You are expressing all your jerkiness in all its glory :-)



> Talk is cheap. Coding is hard.


Thinking is even harder


We are always balancing this. I don't
> contribute much to Guix at this point (other than talk ;), but we face
> the exact same problems in other projects I am involved in. I get most
> upset by the sense of entitlement that people have just because they
> *use* my  work. Many an E-mail I wrote, but did not send, to users,
> just to vent steam. I have a feeling I am not the only one. I.e., it
> is not easy running a free software project. We want and like our
> users, but not at all cost.
>

All costs ?

I repeat: the manual sucks and I proposed an edit to make it suck a bit less


I think we should close this topic unless there are concrete
> suggestions on how to improve and scale Guix development. As George
> writes, we can encourage new contributors and users more,


like you're doing with me ?


> but I doubt
> the route is to take core contributors away from their work.


Their work would be, as George argued, to code a bit less and do some home
keeping a bit more



> I think
> the route is to improve our web presence by tutorials, blogs and
> internationalization. And, in fact, those already are priorities.
>

good luck

By the way, a third person wrote me in private right now telling that Mark
was an asshole to them too and they stopped contributing to guix altogether

They made a conduct report but nothing happened, eventually they had to
talk to Ludo directly

It seems to me, Potr, tat the ones who should be doing their homewor is not
me

I'm doing even too much for you

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

Re: my latest blog post

[Ricardo Wurmus]

Catonano <catonano@gmail.com> writes:

> They made a conduct report but nothing happened, eventually they had to
> talk to Ludo directly

From the Code of Conduct:

   Instances of abusive, harassing, or otherwise unacceptable behavior
   may be reported by contacting the project team at
   guix-maintainers@gnu.org. All complaints will be reviewed and
   investigated and will result in a response that is deemed necessary
   and appropriate to the circumstances.

Reports made to the maintainers (i.e. Ludovic and myself) are taken
seriously.

--
Ricardo

Re: my latest blog post

[Catonano]

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

2018-06-10 11:29 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:

>
> Catonano <catonano@gmail.com> writes:
>
> > They made a conduct report but nothing happened, eventually they had to
> > talk to Ludo directly
>
> From the Code of Conduct:
>
>    Instances of abusive, harassing, or otherwise unacceptable behavior
>    may be reported by contacting the project team at
>    guix-maintainers@gnu.org. All complaints will be reviewed and
>    investigated and will result in a response that is deemed necessary
>    and appropriate to the circumstances.
>
> Reports made to the maintainers (i.e. Ludovic and myself) are taken
> seriously.
>
> --
> Ricardo
>
>

I reported the assault David Pirotte made to me

it was not taken seriously

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

Re: my latest blog post

[Ricardo Wurmus]

Catonano <catonano@gmail.com> writes:

> 2018-06-10 11:29 GMT+02:00 Ricardo Wurmus <rekado@elephly.net>:
>
>>
>> Catonano <catonano@gmail.com> writes:
>>
>> > They made a conduct report but nothing happened, eventually they had to
>> > talk to Ludo directly
>>
>> From the Code of Conduct:
>>
>>    Instances of abusive, harassing, or otherwise unacceptable behavior
>>    may be reported by contacting the project team at
>>    guix-maintainers@gnu.org. All complaints will be reviewed and
>>    investigated and will result in a response that is deemed necessary
>>    and appropriate to the circumstances.
>>
>> Reports made to the maintainers (i.e. Ludovic and myself) are taken
>> seriously.
[…]
>
> I reported the assault David Pirotte made to me
>
> it was not taken seriously

For the record:

1. I am not a maintainer of Guile
2. Ludovic and I are co-maintainers of Guix
3. Reports of Guix Code of Conduct violations should be made to the Guix
   maintainers.
4. I have not received a report about David Pirotte from you.  In fact,
   I have not received any report from you.

--
Ricardo

Re: my latest blog post

[Mark H Weaver]

Catonano <catonano@gmail.com> writes:

> By the way, a third person wrote me in private right now telling that
> Mark was an asshole to them too and they stopped contributing to guix
> altogether
>
> They made a conduct report but nothing happened, eventually they had
> to talk to Ludo directly

If you're accusing me of misconduct, please state your case.

      Mark

Re: my latest blog post

[Pjotr Prins]

On Sun, Jun 10, 2018 at 11:07:21AM +0200, Catonano wrote:
>    I'm glad I'm flushing out, people
>    You are expressing all your jerkiness in all its glory :-)

It is obvious by now that this person is trolling. Is there any reason
to listen to them?

Pj.

Re: my latest blog post

[Catonano]

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

2018-06-10 2:51 GMT+02:00 Mark H Weaver <mhw@netris.org>:

> myglc2@gmail.com writes:
>



>
> Are there any other acceptable responses, in your view?
>

I already proposed a way forward and I even asked you if you would refuse
to merge it

I see you attitute towards that, now.

Also:

yesterday night, before going to bed, I tought that you were nt answering
because you were "busy"

Maybe you were in a different time zone

the lack of an answer is not necessarily aggresion, someone of you noted

But then, when someone agrees with me, you reply instantly, with the usual
pathetic superiority and smugness

There, you have the Guile utter failure

You are a asshole, Mark

Regards

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

Re: my latest blog post

[Ricardo Wurmus]

Catonano,

this language is not at all acceptable anywhere on Guix as you can see
by referencing the Code of Conduct.

--8<---------------cut here---------------start------------->8---
Examples of unacceptable behavior by participants include:

* The use of sexualized language or imagery and unwelcome sexual attention or
advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others’ private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
--8<---------------cut here---------------end--------------->8---

It is one thing to call for a more welcoming community and quite another
to call people names and to assert that they act in bad faith as you
have been doing in the past days.  Please stop right now.

I encourage all to re-read the Code of Conduct.  You can find it in the
Guix git repository or online here:

    http://git.savannah.nongnu.org/cgit/guix.git/plain/CODE-OF-CONDUCT

--
Ricardo

Re: my latest blog post

[Catonano]

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

2018-06-10 11:26 GMT+02:00 Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>:

>
> Catonano,
>
> this language is not at all acceptable anywhere on Guix as you can see
> by referencing the Code of Conduct.
>
> --8<---------------cut here---------------start------------->8---
> Examples of unacceptable behavior by participants include:
>
> * The use of sexualized language or imagery and unwelcome sexual attention
> or
> advances
> * Trolling, insulting/derogatory comments, and personal or political
> attacks
> * Public or private harassment
> * Publishing others’ private information, such as a physical or electronic
> address, without explicit permission
> * Other conduct which could reasonably be considered inappropriate in a
> professional setting
> --8<---------------cut here---------------end--------------->8---
>
> It is one thing to call for a more welcoming community and quite another
> to call people names and to assert that they act in bad faith as you
> have been doing in the past days.  Please stop right now.
>
> I encourage all to re-read the Code of Conduct.  You can find it in the
> Guix git repository or online here:
>
>     http://git.savannah.nongnu.org/cgit/guix.git/plain/CODE-OF-CONDUCT
>
> --
> Ricardo
>


you chose to enfforce only some violations, not all of them

I am not surpried at all

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

Re: my latest blog post

[Ludovic Courtès]

Hi Catonano,

Catonano <catonano@gmail.com> skribis:

> you chose to enfforce only some violations, not all of them

This is a channel of the Guix project, and our code of conduct applies
on this channel (the other issue you referred to was on the Guile
channel and is not related to Guix.)

The insults and derogatory comments you made in this thread are not
acceptable at all.  Therefore, I ask you to calm down right now and to
get in touch with the people you attacked.

Thanks in advance,
Ludovic.

Re: my latest blog post

[Catonano]

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

2018-06-10 0:49 GMT+02:00 <myglc2@gmail.com>:

> On 06/07/2018 at 17:25 Catonano writes:
>
> > I just published my latest blog post
> >
> > In this post I discuss Guix
> >
> > And I discuss Guile too
> >
> > I understand that the language is strong and I expect someone to be upset
> >
> > But I feel this is due
> >
> > Happy reading
> >
> > http://catonano.v22018025836661967.nicesrv.de/the-gnu-community.html
>
> Hi Catonano,
>
> Thank you for taking the time to contribute your thoughts. I am sorry to
> see you getting so beat up by the responses.  Unfortunately the
> nit-picking of criticisms and the "we are busy, why don't you dig in and
> fix it" responses occur too often on the Guix lists.
>
> Such responses are fundamentally unhelpful: A defensive response of
> counter-criticism that spirals out of control buries the original input
> and alienates potential new contributors. I agree with you that the
> suggestion that you dig in and fix something you are struggling with is
> a fundamentally unfriendly response.
>
> I appreciate the effort you made to learn Guix and the risk you took to
> report on the problems you experienced. I am interested in getting to
> the root causes of your frustration. I re-read your post and
> emails. Would it be fair to say ...
>
> 1) The monad/daemon/store is presented as central to Guix and is very
> difficult to understand. If a Guix user really needs to understand it,
> it needs to be explained better.
>
> 2) Sending Guix users upstream for Guile support is not working.
>
> If these are correct, the reality is that only a few people on the
> planet are in a position to address these issues. The rest of us have to
> hope that they can see why it is important to stop coding long enough to
> do so, perhaps in collaboration with a confused user or two ;-)
>
> - George
>

Thank you George, I appreciate this

I alredy had 2 people writing to me _in private_ acknowledging my efforts

I invited them to "come out" but they didn't

So much for Guile friendliness

People are scared to speak their minds

Now, don't worry I won't revelate who you are

I just want to record the sorry state of this community

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

Re: my latest blog post

[Ludovic Courtès]

Catonano <catonano@gmail.com> skribis:

> I just want to record the sorry state of this community

You and I both know this community, having interacted on-line for a
while and having met in person as well.  Like you wrote in the first
part of your blog post, the state of this community is anything but sad.
I find it great to be a part of it, and so did you, at least until
recently.

What makes me sad is that suddenly you’re painting this whole group as
unwelcoming.  Not nice and not constructive, to say the least.

Ludo’.

Re: my latest blog post [everyone, please take a cooldown break]

[Nils Gillmann]

Hi,

I think it would be best if everyone involved would cool down for a couple of
days, restructure their thoughts and reflect on this thread. Look at what
they are doing, and at how they are reacting to other peoples reaction.
This topic is getting quiet heated, and other than the maintainers we
do not have established some kind of mderation. It can be hard to discuss
some topics online.
Text can sometimes fail to transport what we attampt to express, and
I have seen people step away from projects because of this.

Re: my latest blog post [everyone, please take a cooldown break]

[Christopher Lemmer Webber]

Nils Gillmann writes:

> Hi,
>
> I think it would be best if everyone involved would cool down for a couple of
> days, restructure their thoughts and reflect on this thread. Look at what
> they are doing, and at how they are reacting to other peoples reaction.
> This topic is getting quiet heated, and other than the maintainers we
> do not have established some kind of mderation. It can be hard to discuss
> some topics online.
> Text can sometimes fail to transport what we attampt to express, and
> I have seen people step away from projects because of this.

+1000

Re: my latest blog post [everyone, please take a cooldown break]

[Gábor Boskovits]

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

+1

2018-06-10 15:33 GMT+02:00 Christopher Lemmer Webber <cwebber@dustycloud.org
>:

> Nils Gillmann writes:
>
> > Hi,
> >
> > I think it would be best if everyone involved would cool down for a
> couple of
> > days, restructure their thoughts and reflect on this thread. Look at what
> > they are doing, and at how they are reacting to other peoples reaction.
> > This topic is getting quiet heated, and other than the maintainers we
> > do not have established some kind of mderation. It can be hard to discuss
> > some topics online.
> > Text can sometimes fail to transport what we attampt to express, and
> > I have seen people step away from projects because of this.
>
> +1000
>
>

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

Re: my latest blog post [everyone, please take a cooldown break]

[Kei Kebreau]

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

Gábor Boskovits <boskovits@gmail.com> writes:

> +1
>
> 2018-06-10 15:33 GMT+02:00 Christopher Lemmer Webber <cwebber@dustycloud.org>:
>
>  Nils Gillmann writes:
>
>  > Hi,
>  >
>  > I think it would be best if everyone involved would cool down for a couple of
>  > days, restructure their thoughts and reflect on this thread. Look at what
>  > they are doing, and at how they are reacting to other peoples reaction.
>  > This topic is getting quiet heated, and other than the maintainers we
>  > do not have established some kind of mderation. It can be hard to discuss
>  > some topics online.
>  > Text can sometimes fail to transport what we attampt to express, and
>  > I have seen people step away from projects because of this.
>
>  +1000

+1

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: my latest blog post [everyone, please take a cooldown break]

[swedebugia]

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

Hi

On June 10, 2018 4:37:17 PM GMT+02:00, Kei Kebreau <kkebreau@posteo.net> wrote:
>Gábor Boskovits <boskovits@gmail.com> writes:
>
>> +1
>>
>> 2018-06-10 15:33 GMT+02:00 Christopher Lemmer Webber
><cwebber@dustycloud.org>:
>>
>>  Nils Gillmann writes:
>>
>>  > Hi,
>>  >
>>  > I think it would be best if everyone involved would cool down for
>a couple of
>>  > days, restructure their thoughts and reflect on this thread. Look
>at what
>>  > they are doing, and at how they are reacting to other peoples
>reaction.
>>  > This topic is getting quiet heated, and other than the maintainers
>we
>>  > do not have established some kind of mderation. It can be hard to
>discuss
>>  > some topics online.
>>  > Text can sometimes fail to transport what we attampt to express,
>and
>>  > I have seen people step away from projects because of this.
>>
>>  +1000
>
>+1

+1
I would also like to point to resources that help me when I sometimes get into a heated discussion IRL and how to focus inward first to understand what is going on in me (with stimulus from the surrounding):
http://thework.com/en/do-work
https://www.youtube.com/watch?v=l7TONauJGfc
-- 
Cheers Swedebugia 

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