Re: erlang-questions Digest, Vol 360, Issue 10

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: erlang-questions Digest, Vol 360, Issue 10

Roman Rabinovich
What is this bull, I'm not interested in naming conventions. It's not Erlang related so stop sending it.

On 12 Feb 2018 7:25 pm, <[hidden email]> wrote:
Send erlang-questions mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://erlang.org/mailman/listinfo/erlang-questions
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of erlang-questions digest..."


Today's Topics:

   1. Re:  Coon - new tool for building Erlang packages, dependency
      management and deploying Erlang services (Miguel Morales)
   2. Re:  Coon - new tool for building Erlang packages, dependency
      management and deploying Erlang services (Joe Armstrong)
   3. Re:  Coon - new tool for building Erlang packages, dependency
      management and deploying Erlang services (Vlad Dumitrescu)
   4. Re:  Coon - new tool for building Erlang packages, dependency
      management and deploying Erlang services (Eric des Courtis)
   5. Re:  Coon - new tool for building Erlang packages, dependency
      management and deploying Erlang services (Mahesh Paolini-Subramanya)
   6. Re:  Coon - new tool for building Erlang packages, dependency
      management and deploying Erlang services (Stefan Strigler)


----------------------------------------------------------------------

Message: 1
Date: Mon, 12 Feb 2018 13:38:26 -0800
From: Miguel Morales <[hidden email]>
To: "Lloyd R. Prentice" <[hidden email]>
Cc: Erlang <[hidden email]>
Subject: Re: [erlang-questions] Coon - new tool for building Erlang
        packages, dependency management and deploying Erlang services
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

I'm a hispanic developer in North America. This name is certainly
offensive. I'm a big proponent of free speech and am against overreaching
social justice causes.
However, in this case, if you want the project to succeed I highly
recommend changing the name.

On Mon, Feb 12, 2018 at 1:35 PM, Lloyd R. Prentice <[hidden email]>
wrote:

> Hello,
>
> Jesper and Joe do make good sense to me.
>
> And, more, I would like to see much more informed debate on the technical
> merits of this new tool.
>
> As aside, however, I haven?t seen so much activity on this list since I
> first subscribed some four years ago.
>
> Note that we haven?t heard from any North American black Erlang
> programmers on this list. Why would that be?
>
> I?m a privileged, white (so far as I know from my spotty genealogy,
> although the recent work on the Chadwick man casts some doubt), provincial
> North American male.
>
> Some in my genetic/gender/national cohort feel that our group is being
> grievously discriminated against. I don?t happen to feel so for plenty of
> socio-economic reasons.
>
> Nevertheless, the name of this new tool did seem unfortunate in the
> extreme to me. Were my skin black, from everything I know, I would
> definitely feel a twinge of pain and resentment every time one of the many
> words used historically to define me as less than a respected human being
> was tossed around in casual conversation.
>
> But some on this list are correct. One can be overly sensitive and some
> groups do exploit these sensitivities for politely advantage.
>
> Nevertheless, we must acknowledge that naming of software packages in
> these times has many cross-cultural implications.
>
> For us, that is the Erlang community, the big question is how can we learn
> and grow together regardless of our respective cultural heritages? How can
> we minimize the contentious bickering and trolling that has infected so
> much discourse across the web?
>
> Tribalism is a reality in our world. Every tribe has its own taboos,
> sensitivities, and moral blind spots.
>
> But our world is ever more interconnected and interdependent. Empathy and
> respect for the feelings of others can go a long way toward reducing the
> friction of cross-cultural exchange. As can respectful discussion of
> differences.
>
> For me, this thread reinforces my belief in this principle.
>
> All the best,
>
> LRP
>
>
> Sent from my iPad
>
> On Feb 12, 2018, at 3:06 PM, Jesper Louis Andersen <
> [hidden email]> wrote:
>
> On Mon, Feb 12, 2018 at 6:58 PM Joe Armstrong <[hidden email]> wrote:
>
>>
>> I have said on many occasions that code should be named by the SHA1
>> checksum of
>> the content - as far as I know this would not offend people - apart
>> from those who
>> thought the name could be a tad simpler.
>>
>>
> I might have said this before, but here goes:
>
> Using a cryptographic checksum for a package and then pointing the name to
> the checksum would have saved Node.js npm package manager a lot of
> headaches when people remove, rename or otherwise destroy packages.
>
> It also allows you to comply with legal requests with a sunset period. As
> in "I hear you, and the name will be given to you. But we give people 6
> months time to upgrade before we remove the old checksummed packages".
>
> I'm interested in why someone did not try this yet. Or if one tried, why
> it didn't work out. It seems very obvious to build a
> content-addressable-store for your packages.
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> Sent from my iPad
>
> On Feb 12, 2018, at 3:06 PM, Jesper Louis Andersen <
> [hidden email]> wrote:
>
> On Mon, Feb 12, 2018 at 6:58 PM Joe Armstrong <[hidden email]> wrote:
>
>>
>> I have said on many occasions that code should be named by the SHA1
>> checksum of
>> the content - as far as I know this would not offend people - apart
>> from those who
>> thought the name could be a tad simpler.
>>
>>
> I might have said this before, but here goes:
>
> Using a cryptographic checksum for a package and then pointing the name to
> the checksum would have saved Node.js npm package manager a lot of
> headaches when people remove, rename or otherwise destroy packages.
>
> It also allows you to comply with legal requests with a sunset period. As
> in "I hear you, and the name will be given to you. But we give people 6
> months time to upgrade before we remove the old checksummed packages".
>
> I'm interested in why someone did not try this yet. Or if one tried, why
> it didn't work out. It seems very obvious to build a
> content-addressable-store for your packages.
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180212/44a7c7ac/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 12 Feb 2018 22:58:01 +0100
From: Joe Armstrong <[hidden email]>
To: Vlad Dumitrescu <[hidden email]>
Cc: Erlang <[hidden email]>
Subject: Re: [erlang-questions] Coon - new tool for building Erlang
        packages, dependency management and deploying Erlang services
Message-ID:
        <CAANBt-q3xXoE6-dWey+WNQex8Nqp=[hidden email]>
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 12, 2018 at 10:06 PM, Vlad Dumitrescu <[hidden email]> wrote:
>
> On Mon, Feb 12, 2018 at 9:06 PM, Jesper Louis Andersen
> <[hidden email]> wrote:
>>
>> On Mon, Feb 12, 2018 at 6:58 PM Joe Armstrong <[hidden email]> wrote:
>>>
>>>
>>> I have said on many occasions that code should be named by the SHA1
>>> checksum of
>>> the content - as far as I know this would not offend people - apart
>>> from those who thought the name could be a tad simpler.
>>>
>>
>> I might have said this before, but here goes:
>> Using a cryptographic checksum for a package and then pointing the name to
>> the checksum would have saved Node.js npm package manager a lot of headaches
>> when people remove, rename or otherwise destroy packages.
>> It also allows you to comply with legal requests with a sunset period. As
>> in "I hear you, and the name will be given to you. But we give people 6
>> months time to upgrade before we remove the old checksummed packages".
>> I'm interested in why someone did not try this yet. Or if one tried, why
>> it didn't work out. It seems very obvious to build a
>> content-addressable-store for your packages.
>
>
> I'm not sure I understand this completely. Using the checksum of a package
> as identifier is IMHO only useful if it is used in the dependencies list of
> other packages. If the deps list uses names (and people will use names
> anyway, not checksums), then the problem remains that in case a package is
> renamed and another one reuses the name, we don't know to which one a
> reference points.

The dependency list should be a list of checksums and NOT a list of
names - this list of
checksums has itself a checksum (the "true" name of the package).

A human readable name is just an alias to a checksum - two different
human readable names
are the "same" if they are aliases to the same checksum.

Basically files should be named by their checksums - for fairly
obvious reasons of
convenience tools should hide or reveal these names when necessary or
appropriate.

For a given content the checksum is unique.

To handle renamings you just need a lookup table of

      {Name, Time, Checksum} tuples that tracks changes to the name of
the checksum over time

Should be easy (Famous last words rule applies here)

Cheers

/Joe




>
> Anyway, hex.pm has a field named "checksum" and it is that value that is
> stored in rebar.lock. So the hash key is there, but I don't see how it is
> useful except for tools.
>
> best regards,
> Vlad
>


------------------------------

Message: 3
Date: Mon, 12 Feb 2018 23:36:37 +0100
From: Vlad Dumitrescu <[hidden email]>
To: Joe Armstrong <[hidden email]>
Cc: Erlang <[hidden email]>
Subject: Re: [erlang-questions] Coon - new tool for building Erlang
        packages, dependency management and deploying Erlang services
Message-ID:
        <CAA-EFXuQDn4DX1NjikcNKBW+WjAu7pqeFm+=[hidden email]>
Content-Type: text/plain; charset="utf-8"

On Mon, Feb 12, 2018 at 10:58 PM, Joe Armstrong <[hidden email]> wrote:

> On Mon, Feb 12, 2018 at 10:06 PM, Vlad Dumitrescu <[hidden email]>
> wrote:
> > On Mon, Feb 12, 2018 at 9:06 PM, Jesper Louis Andersen
> > <[hidden email]> wrote:
> >> Using a cryptographic checksum for a package and then pointing the name
> to
> >> the checksum would have saved Node.js npm package manager a lot of
> headaches
> >> when people remove, rename or otherwise destroy packages.
> >> It also allows you to comply with legal requests with a sunset period.
> As
> >> in "I hear you, and the name will be given to you. But we give people 6
> >> months time to upgrade before we remove the old checksummed packages".
> >> I'm interested in why someone did not try this yet. Or if one tried, why
> >> it didn't work out. It seems very obvious to build a
> >> content-addressable-store for your packages.
> >
> >
> > I'm not sure I understand this completely. Using the checksum of a
> package
> > as identifier is IMHO only useful if it is used in the dependencies list
> of
> > other packages. If the deps list uses names (and people will use names
> > anyway, not checksums), then the problem remains that in case a package
> is
> > renamed and another one reuses the name, we don't know to which one a
> > reference points.
>
> The dependency list should be a list of checksums and NOT a list of
> names - this list of
> checksums has itself a checksum (the "true" name of the package).
>
> A human readable name is just an alias to a checksum - two different
> human readable names
> are the "same" if they are aliases to the same checksum.
>
> Basically files should be named by their checksums - for fairly
> obvious reasons of
> convenience tools should hide or reveal these names when necessary or
> appropriate.
>
> For a given content the checksum is unique.
>
> To handle renamings you just need a lookup table of
>
>       {Name, Time, Checksum} tuples that tracks changes to the name of
> the checksum over time
>

Thanks for the explanation, I understand the mechanics, but not the "real
world usage".

* A checksum referes to a {package_name, time} tuple, so there is no way to
refer to the package in general. Except by its name.

* Even if there was, nobody is going to say "For a gizmo processing
library, we have to choose
between B17556DB683000BA50370B16C0619DF1337E7AF7ECBF7D64FBF8D1D6BCE3109B
and 7ACC7D785B5ABE8A6E9ADBDE926A24E481F29956DD8B4DF49E3E4E7BCC92A018, which
one is better?" So people will use names.

* Now the project is presumably configured in a file, written by a
programmer - again the name will be used. The hash can be retrieved and
stored by the build tool, so that we get a hard reference...

* ... which is exactly what rebar and mix do with hex.pm (if I get it
right), except they use the version string instead of timestamp. So if
hex.pm keeps track of timestamps and of historical mappings between names
and hashes, then it's done!

* However, the imprecision of using names remains because we're humans.
Tools already use hashes.

Am I misunderstanding something?

best regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180212/bfdae329/attachment-0001.html>

------------------------------

Message: 4
Date: Mon, 12 Feb 2018 17:55:29 -0500
From: Eric des Courtis <[hidden email]>
To: Erlang <[hidden email]>
Subject: Re: [erlang-questions] Coon - new tool for building Erlang
        packages, dependency management and deploying Erlang services
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Everyone, stop acting like a bunch of Java programmers and get back to work!

On Mon, Feb 12, 2018 at 4:58 PM, Joe Armstrong <[hidden email]> wrote:

> On Mon, Feb 12, 2018 at 10:06 PM, Vlad Dumitrescu <[hidden email]>
> wrote:
> >
> > On Mon, Feb 12, 2018 at 9:06 PM, Jesper Louis Andersen
> > <[hidden email]> wrote:
> >>
> >> On Mon, Feb 12, 2018 at 6:58 PM Joe Armstrong <[hidden email]> wrote:
> >>>
> >>>
> >>> I have said on many occasions that code should be named by the SHA1
> >>> checksum of
> >>> the content - as far as I know this would not offend people - apart
> >>> from those who thought the name could be a tad simpler.
> >>>
> >>
> >> I might have said this before, but here goes:
> >> Using a cryptographic checksum for a package and then pointing the name
> to
> >> the checksum would have saved Node.js npm package manager a lot of
> headaches
> >> when people remove, rename or otherwise destroy packages.
> >> It also allows you to comply with legal requests with a sunset period.
> As
> >> in "I hear you, and the name will be given to you. But we give people 6
> >> months time to upgrade before we remove the old checksummed packages".
> >> I'm interested in why someone did not try this yet. Or if one tried, why
> >> it didn't work out. It seems very obvious to build a
> >> content-addressable-store for your packages.
> >
> >
> > I'm not sure I understand this completely. Using the checksum of a
> package
> > as identifier is IMHO only useful if it is used in the dependencies list
> of
> > other packages. If the deps list uses names (and people will use names
> > anyway, not checksums), then the problem remains that in case a package
> is
> > renamed and another one reuses the name, we don't know to which one a
> > reference points.
>
> The dependency list should be a list of checksums and NOT a list of
> names - this list of
> checksums has itself a checksum (the "true" name of the package).
>
> A human readable name is just an alias to a checksum - two different
> human readable names
> are the "same" if they are aliases to the same checksum.
>
> Basically files should be named by their checksums - for fairly
> obvious reasons of
> convenience tools should hide or reveal these names when necessary or
> appropriate.
>
> For a given content the checksum is unique.
>
> To handle renamings you just need a lookup table of
>
>       {Name, Time, Checksum} tuples that tracks changes to the name of
> the checksum over time
>
> Should be easy (Famous last words rule applies here)
>
> Cheers
>
> /Joe
>
>
>
>
> >
> > Anyway, hex.pm has a field named "checksum" and it is that value that is
> > stored in rebar.lock. So the hash key is there, but I don't see how it is
> > useful except for tools.
> >
> > best regards,
> > Vlad
> >
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180212/ab1a53f3/attachment-0001.html>

------------------------------

Message: 5
Date: Tue, 13 Feb 2018 05:21:32 +0530
From: Mahesh Paolini-Subramanya <[hidden email]>
To: Erlang <[hidden email]>
Subject: Re: [erlang-questions] Coon - new tool for building Erlang
        packages, dependency management and deploying Erlang services
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Identifiers matter. They tell the world a lot about how something is
perceived. Naming can get awfully hard, *depending on the reach* - what
might work really well in rural Alabama might not work so well in San
Francisco (and vice-versa). If you're in Branding, and don't have  ADL
database
<https://www.adl.org/education/references/hate-symbols?cat_id[147]=147>
auto-completing
in your URL-bar, you're not going to get very far.

Intent matters. Of course it does. Maybe you *want* to appeal to racists
and nationalists - I mean, its' working quite well as a strategy in quite a
bit of the world these days. On the other hand, if you *don't*, and someone
points out to you that your choice of words may not be the wisest choice,
well, you might want to reconsider it (?). Note that the point here isn't
"people shouldn't be offended". People *are* offended, and thats about all
that matters - remember, this is about the marketing aspects of naming.

Empathy matters. Put yourself in somebody else's shoes - and ask yourself
how they might feel about your actions. Not how they *should* feel, but how
they might *actually* feel.

Privilege matters. I grew up as a Brahmin, in India. It's been a *long* while
- 30 years - since the default privilege that comes from that upbringing
has been useful, but even now, when I end up on the receiving end of
stop-and-frisked, being brown in the wrong place, casual and explicit
racist invective, and the works, I fall back on that privilege. It's not an
explicit thing - it's having been part of an entire culture where being
brahmin means I'm better than *those people*.

Employee retention matters. I spend a lot of time, energy, and yes, money,
in getting people up to speed, developing trust in each other, and working
cohesively as a team. It's a delicate thing, this balance, and the last
thing I need is casual racism or gender-issues into the mix.

Cheers

(?) In the 70s, I pretty freely using the n-word. I grew up in a fairly
disconnected part of India at the time (Kanpur), and we, literally, did not
know (and heck, hadn't ever seen) any african-americans - and about the
only context around this we had was some spectacularly racist faux-westerns
by an author named J.T.Edson. Fast-forward a few years, to my
graduate-school days in the U.S at Notre Dame, and my (pretty rapid)
discovery that, well, I probably shouldn't.



On Mon, Feb 12, 2018 at 9:38 PM, Roman Galeev <[hidden email]> wrote:

> The worst part of it that nobody is offended at this very moment, but Fred
> speaks for people who could be offended, in his opinion. But could they, or
> could they not nobody knows (except them, but they are not present). Maybe
> the same people could be offended by other words as well, how do we know?
> And should we really care (having quite offensive names in the wild
> already)? Should we run all possible project names through the council of
> these people?
>
> On Mon, Feb 12, 2018 at 4:56 PM, Zachary Kessin <[hidden email]> wrote:
>
>> I would like to second what Fred said. I just went through
>> something like this in a different context and I have to say "its not
>> reasonable that <Group> is offended" is a pretty bad apology.
>> ?
>>
>> Zach Kessin - CEO Finch Software
>> I boost sales with retail chatbots for fashion and cosmetics
>> <a href="tel:%2B972%2054%20234%203956" value="+972542343956">+972 54 234 3956 <+972%2054-234-3956> / <a href="tel:%2B44%20203%20734%209790" value="+442037349790">+44 203 734 9790
>> <+44%2020%203734%209790> / <a href="tel:%2B1%20617%20778%207213" value="+16177787213">+1 617 778 7213 <(617)%20778-7213>
>> Book a meeting with me <https://calendly.com/zkessin/chatbot>
>>
>> On Mon, Feb 12, 2018 at 5:46 PM, Fred Hebert <[hidden email]> wrote:
>>
>>>
>>>
>>> On Mon, Feb 12, 2018 at 10:29 AM, <[hidden email]> wrote:
>>>
>>>> On 2018?2?12???? 10?16?51? JST Fred Hebert wrote:
>>>> > Intent does not matter.
>>>>
>>>> No.
>>>>
>>>> Fred, I have enormous respect for you and have gone several rounds with
>>>> you on several subjects, each time having learned something for my own
>>>> part. On technical subjects, anyway.
>>>>
>>>> But... INTENT
>>>>
>>>> You are demonstraby wrong already. Just stop. You will not win against
>>>> the weight of history.
>>>>
>>>
>>> I am not wrong in not wanting to ever introduce this library in my god
>>> damn workplace. Because I know and have worked with people who do find this
>>> kind of shit offensive.
>>>
>>> I'm happy you live in a place and in a context where everyone is fine
>>> with that. This has not been the reality of the people I have spent time
>>> with both professionally and personally.
>>>
>>>
>>>>
>>>> This is becoming some SJW ridiculousness already, not because you care
>>>> about that but because of the ambient temperature. I know SJW flippancy is
>>>> not your intent, but that is the only place this winds up going these days.
>>>> That is not a small failure -- it quickly becomes a systemic one, not just
>>>> in a concurrent software system of ephemeral importance, but a concrete
>>>> socio-economic one of critical importance that pays for all the other
>>>> parties we enjoy.
>>>>
>>>
>>> I'm surprised that you find the idea that using a term that can very
>>> reasonably be construed as racist is *SJW flippancy*.
>>>
>>> Let's take a quick look by looking at first definitions on Urban
>>> Dictionary for a game. I picked random animal names or short terms:
>>>
>>>    - https://www.urbandictionary.com/define.php?term=coon
>>>    Insulting term for a black person
>>>    - https://www.urbandictionary.com/define.php?term=doggo
>>>    An alternate term for a dog used on meme pages to express the
>>>    meaning of the picture. Usually found in captions.
>>>    - https://www.urbandictionary.com/define.php?term=Cat
>>>    The definitive pet.
>>>    - https://www.urbandictionary.com/define.php?term=dog
>>>    Not a cat
>>>    - https://www.urbandictionary.com/define.php?term=fox
>>>    A beautiful and attractive woman
>>>    - https://www.urbandictionary.com/define.php?term=whale
>>>    noun; a wealthy patron to a casino, gets paid special attention by a
>>>    casino host so the patron will feel comfortable to gamble more money.
>>>
>>>  Oh hm. Sorry I guess the usage is really forgotten for that one.
>>>
>>> *Intent does not matter* is not me saying that the author of the lib is
>>> racist or ill-intended. It's me saying that no matter the original intent,
>>> the consequences will be the result of the reader's interpretation. Look
>>> this is even a principle in literary review called *The death of the
>>> author* (https://en.wikipedia.org/wiki/The_Death_of_the_Author):
>>>
>>> In his essay, Barthes argues against the method of reading and criticism
>>>> that relies on aspects of the author's identity?their political views,
>>>> historical context, religion, ethnicity, psychology, or other biographical
>>>> or personal attributes?to distill meaning from the author's work. In this
>>>> type of criticism, the experiences and biases of the author serve as a
>>>> definitive "explanation" of the text. For Barthes, this method of reading
>>>> may be apparently tidy and convenient but is actually sloppy and flawed:
>>>> "To give a text an author" and assign a single, corresponding
>>>> interpretation to it "is to impose a limit on that text".
>>>>
>>>> [...]
>>>>
>>>> In a well-known quotation, Barthes draws an analogy between text and
>>>> textiles, declaring that a "text is a tissue [or fabric] of quotations",
>>>> drawn from "innumerable centers of culture", rather than from one,
>>>> individual experience. The essential meaning of a work depends on the
>>>> impressions of the reader, rather than the "passions" or "tastes" of the
>>>> writer; "a text's unity lies not in its origins", or its creator, "but in
>>>> its destination", or its audience.
>>>>
>>>
>>> The whole point is that you cannot reasonably expect the author to be
>>> around to give meaning and maintain these things. What the author intends
>>> is not relevant in the long run because the interpretation can get away
>>> from it. It's like in satire: good satire/irony/sarcasm must be visible and
>>> enough in your face that it won't be construed as supporting the system you
>>> are attempting to criticize.
>>>
>>> Intent does not matter.
>>>
>>>
>>>
>>>> Riddle me this:
>>>> If we cannot undersand enough about the software systems that WE WRITE
>>>> OURSELVES that we need the "let it crash" mentality, how is it that we
>>>> somehow understand to a manifest degree the economic and social value
>>>> systems (which are profoundly more complex than our petty software systems)
>>>> that we can dictate value within them? By what restart mechanism is this
>>>> all brought back to a "reasonble default"?
>>>>
>>>> I am sincerely desirous of an answer here, because I have a profound
>>>> respect for your intellect but cannot imagine that you have properly
>>>> considered the alternatives or where this path of discourse winds up
>>>> eventualy going.
>>>>
>>>
>>> I very much stand by *intent does not matter*. It matters to me in this
>>> context and I do not yet judge Valery negatively, I trust that *raccoon*
>>> was indeed the original name intent. It does not mean that other people
>>> will do the same. Expecting other people to do the same is downright absurd
>>> and foolish. If your entire position relies on explaining every single
>>> person the origin of the name for things to go well, you have taken the
>>> losing battle of tilting at windmills. This is the hill you die on. What
>>> I'm doing here is giving a really fucking serious warning of how much
>>> windmill tilting you'll get into.
>>>
>>> If you want me to go by the *Let it Crash* maxim, the idea of *let it
>>> crash* is to not try to handle all the errors and letting them fail
>>> early and often. Start from a clean slate rather than trying to correct
>>> corrupted state. What I'm doing here is trying to crash this stupid ass
>>> project name as early as possible so the author doesn't get stuck trying to
>>> handle every error coming their way in the near future. Look at it this
>>> way. You even have a bunch of terms for it in this single thread: *SJW
>>> Flippancy.* Loic brought up *identity politics*. Roman is trying make a
>>> tally of who is it who's offended in the first place as if that made any
>>> difference the moment this gets out of here.
>>>
>>> If you can't see that as a warning sign when this discussion is taking
>>> place within mailing list regulars, what will be a reasonable waning sign
>>> to you?
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> [hidden email]
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
>
> --
> With best regards,
>      Roman Galeev,
>      <a href="tel:%2B420%20702%20817%20968" value="+420702817968">+420 702 817 968 <+420%20702%20817%20968>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


--

*Mahesh Paolini-Subramanya
<http://www.gravatar.com/avatar/204a87f81a0d9764c1f3364f53e8facf.png>That
tall bald Indian guy..*
*Twitter <https://twitter.com/dieswaytoofast> | Blog
<http://dieswaytoofast.blogspot.com/> | G+
<https://plus.google.com/u/0/108074935470209044442/posts> | LinkedIn
<http://www.linkedin.com/in/dieswaytoofast>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180213/e9f6ee53/attachment-0001.html>

------------------------------

Message: 6
Date: Tue, 13 Feb 2018 00:25:05 +0000
From: Stefan Strigler <[hidden email]>
To: Mahesh Paolini-Subramanya <[hidden email]>
Cc: Erlang <[hidden email]>
Subject: Re: [erlang-questions] Coon - new tool for building Erlang
        packages, dependency management and deploying Erlang services
Message-ID:
        <CAE7Uswfz4EfwGqaYo+kXjhXBTYfffFhq5z6u2G=[hidden email]>
Content-Type: text/plain; charset="utf-8"

+1 Mahesh, you're the best, thanks for taking that effort!


On Tue, Feb 13, 2018 at 12:51 AM Mahesh Paolini-Subramanya <
[hidden email]> wrote:

> Identifiers matter. They tell the world a lot about how something is
> perceived. Naming can get awfully hard, *depending on the reach* - what
> might work really well in rural Alabama might not work so well in San
> Francisco (and vice-versa). If you're in Branding, and don't have  ADL
> database
> <https://www.adl.org/education/references/hate-symbols?cat_id[147]=147> auto-completing
> in your URL-bar, you're not going to get very far.
>
> Intent matters. Of course it does. Maybe you *want* to appeal to racists
> and nationalists - I mean, its' working quite well as a strategy in quite a
> bit of the world these days. On the other hand, if you *don't*, and someone
> points out to you that your choice of words may not be the wisest choice,
> well, you might want to reconsider it (?). Note that the point here isn't
> "people shouldn't be offended". People *are* offended, and thats about all
> that matters - remember, this is about the marketing aspects of naming.
>
> Empathy matters. Put yourself in somebody else's shoes - and ask yourself
> how they might feel about your actions. Not how they *should* feel, but
> how they might *actually* feel.
>
> Privilege matters. I grew up as a Brahmin, in India. It's been a *long* while
> - 30 years - since the default privilege that comes from that upbringing
> has been useful, but even now, when I end up on the receiving end of
> stop-and-frisked, being brown in the wrong place, casual and explicit
> racist invective, and the works, I fall back on that privilege. It's not an
> explicit thing - it's having been part of an entire culture where being
> brahmin means I'm better than *those people*.
>
> Employee retention matters. I spend a lot of time, energy, and yes, money,
> in getting people up to speed, developing trust in each other, and working
> cohesively as a team. It's a delicate thing, this balance, and the last
> thing I need is casual racism or gender-issues into the mix.
>
> Cheers
>
> (?) In the 70s, I pretty freely using the n-word. I grew up in a fairly
> disconnected part of India at the time (Kanpur), and we, literally, did not
> know (and heck, hadn't ever seen) any african-americans - and about the
> only context around this we had was some spectacularly racist faux-westerns
> by an author named J.T.Edson. Fast-forward a few years, to my
> graduate-school days in the U.S at Notre Dame, and my (pretty rapid)
> discovery that, well, I probably shouldn't.
>
>
>
> On Mon, Feb 12, 2018 at 9:38 PM, Roman Galeev <[hidden email]> wrote:
>
>> The worst part of it that nobody is offended at this very moment, but
>> Fred speaks for people who could be offended, in his opinion. But could
>> they, or could they not nobody knows (except them, but they are not
>> present). Maybe the same people could be offended by other words as well,
>> how do we know? And should we really care (having quite offensive names in
>> the wild already)? Should we run all possible project names through the
>> council of these people?
>>
>> On Mon, Feb 12, 2018 at 4:56 PM, Zachary Kessin <[hidden email]>
>> wrote:
>>
>>> I would like to second what Fred said. I just went through something like this in a different context and I have to say
>>> "its not reasonable that <Group> is offended" is a pretty bad apology.
>>> ?
>>>
>>> Zach Kessin - CEO Finch Software
>>> I boost sales with retail chatbots for fashion and cosmetics
>>> <a href="tel:%2B972%2054%20234%203956" value="+972542343956">+972 54 234 3956 <+972%2054-234-3956> / <a href="tel:%2B44%20203%20734%209790" value="+442037349790">+44 203 734 9790
>>> <+44%2020%203734%209790> / <a href="tel:%2B1%20617%20778%207213" value="+16177787213">+1 617 778 7213 <(617)%20778-7213>
>>> Book a meeting with me <https://calendly.com/zkessin/chatbot>
>>>
>>> On Mon, Feb 12, 2018 at 5:46 PM, Fred Hebert <[hidden email]> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Feb 12, 2018 at 10:29 AM, <[hidden email]> wrote:
>>>>
>>>>> On 2018?2?12???? 10?16?51? JST Fred Hebert wrote:
>>>>> > Intent does not matter.
>>>>>
>>>>> No.
>>>>>
>>>>> Fred, I have enormous respect for you and have gone several rounds
>>>>> with you on several subjects, each time having learned something for my own
>>>>> part. On technical subjects, anyway.
>>>>>
>>>>> But... INTENT
>>>>>
>>>>> You are demonstraby wrong already. Just stop. You will not win against
>>>>> the weight of history.
>>>>>
>>>>
>>>> I am not wrong in not wanting to ever introduce this library in my god
>>>> damn workplace. Because I know and have worked with people who do find this
>>>> kind of shit offensive.
>>>>
>>>> I'm happy you live in a place and in a context where everyone is fine
>>>> with that. This has not been the reality of the people I have spent time
>>>> with both professionally and personally.
>>>>
>>>>
>>>>>
>>>>> This is becoming some SJW ridiculousness already, not because you care
>>>>> about that but because of the ambient temperature. I know SJW flippancy is
>>>>> not your intent, but that is the only place this winds up going these days.
>>>>> That is not a small failure -- it quickly becomes a systemic one, not just
>>>>> in a concurrent software system of ephemeral importance, but a concrete
>>>>> socio-economic one of critical importance that pays for all the other
>>>>> parties we enjoy.
>>>>>
>>>>
>>>> I'm surprised that you find the idea that using a term that can very
>>>> reasonably be construed as racist is *SJW flippancy*.
>>>>
>>>> Let's take a quick look by looking at first definitions on Urban
>>>> Dictionary for a game. I picked random animal names or short terms:
>>>>
>>>>    - https://www.urbandictionary.com/define.php?term=coon
>>>>    Insulting term for a black person
>>>>    - https://www.urbandictionary.com/define.php?term=doggo
>>>>    An alternate term for a dog used on meme pages to express the
>>>>    meaning of the picture. Usually found in captions.
>>>>    - https://www.urbandictionary.com/define.php?term=Cat
>>>>    The definitive pet.
>>>>    - https://www.urbandictionary.com/define.php?term=dog
>>>>    Not a cat
>>>>    - https://www.urbandictionary.com/define.php?term=fox
>>>>    A beautiful and attractive woman
>>>>    - https://www.urbandictionary.com/define.php?term=whale
>>>>    noun; a wealthy patron to a casino, gets paid special attention by
>>>>    a casino host so the patron will feel comfortable to gamble more money.
>>>>
>>>>  Oh hm. Sorry I guess the usage is really forgotten for that one.
>>>>
>>>> *Intent does not matter* is not me saying that the author of the lib
>>>> is racist or ill-intended. It's me saying that no matter the original
>>>> intent, the consequences will be the result of the reader's interpretation.
>>>> Look this is even a principle in literary review called *The death of
>>>> the author* (https://en.wikipedia.org/wiki/The_Death_of_the_Author):
>>>>
>>>> In his essay, Barthes argues against the method of reading and
>>>>> criticism that relies on aspects of the author's identity?their political
>>>>> views, historical context, religion, ethnicity, psychology, or other
>>>>> biographical or personal attributes?to distill meaning from the author's
>>>>> work. In this type of criticism, the experiences and biases of the author
>>>>> serve as a definitive "explanation" of the text. For Barthes, this method
>>>>> of reading may be apparently tidy and convenient but is actually sloppy and
>>>>> flawed: "To give a text an author" and assign a single, corresponding
>>>>> interpretation to it "is to impose a limit on that text".
>>>>>
>>>>> [...]
>>>>>
>>>>> In a well-known quotation, Barthes draws an analogy between text and
>>>>> textiles, declaring that a "text is a tissue [or fabric] of quotations",
>>>>> drawn from "innumerable centers of culture", rather than from one,
>>>>> individual experience. The essential meaning of a work depends on the
>>>>> impressions of the reader, rather than the "passions" or "tastes" of the
>>>>> writer; "a text's unity lies not in its origins", or its creator, "but in
>>>>> its destination", or its audience.
>>>>>
>>>>
>>>> The whole point is that you cannot reasonably expect the author to be
>>>> around to give meaning and maintain these things. What the author intends
>>>> is not relevant in the long run because the interpretation can get away
>>>> from it. It's like in satire: good satire/irony/sarcasm must be visible and
>>>> enough in your face that it won't be construed as supporting the system you
>>>> are attempting to criticize.
>>>>
>>>> Intent does not matter.
>>>>
>>>>
>>>>
>>>>> Riddle me this:
>>>>> If we cannot undersand enough about the software systems that WE WRITE
>>>>> OURSELVES that we need the "let it crash" mentality, how is it that we
>>>>> somehow understand to a manifest degree the economic and social value
>>>>> systems (which are profoundly more complex than our petty software systems)
>>>>> that we can dictate value within them? By what restart mechanism is this
>>>>> all brought back to a "reasonble default"?
>>>>>
>>>>> I am sincerely desirous of an answer here, because I have a profound
>>>>> respect for your intellect but cannot imagine that you have properly
>>>>> considered the alternatives or where this path of discourse winds up
>>>>> eventualy going.
>>>>>
>>>>
>>>> I very much stand by *intent does not matter*. It matters to me in
>>>> this context and I do not yet judge Valery negatively, I trust that
>>>> *raccoon* was indeed the original name intent. It does not mean that
>>>> other people will do the same. Expecting other people to do the same is
>>>> downright absurd and foolish. If your entire position relies on explaining
>>>> every single person the origin of the name for things to go well, you have
>>>> taken the losing battle of tilting at windmills. This is the hill you die
>>>> on. What I'm doing here is giving a really fucking serious warning of how
>>>> much windmill tilting you'll get into.
>>>>
>>>> If you want me to go by the *Let it Crash* maxim, the idea of *let it
>>>> crash* is to not try to handle all the errors and letting them fail
>>>> early and often. Start from a clean slate rather than trying to correct
>>>> corrupted state. What I'm doing here is trying to crash this stupid ass
>>>> project name as early as possible so the author doesn't get stuck trying to
>>>> handle every error coming their way in the near future. Look at it this
>>>> way. You even have a bunch of terms for it in this single thread: *SJW
>>>> Flippancy.* Loic brought up *identity politics*. Roman is trying make
>>>> a tally of who is it who's offended in the first place as if that made any
>>>> difference the moment this gets out of here.
>>>>
>>>> If you can't see that as a warning sign when this discussion is taking
>>>> place within mailing list regulars, what will be a reasonable waning sign
>>>> to you?
>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> [hidden email]
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> [hidden email]
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>>
>> --
>> With best regards,
>>      Roman Galeev,
>>      +420 702 817 968 <+420%20702%20817%20968>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
>
> --
>
> *Mahesh Paolini-Subramanya
> <http://www.gravatar.com/avatar/204a87f81a0d9764c1f3364f53e8facf.png>That
> tall bald Indian guy..*
> *Twitter <https://twitter.com/dieswaytoofast> | Blog
> <http://dieswaytoofast.blogspot.com/> | G+
> <https://plus.google.com/u/0/108074935470209044442/posts> | LinkedIn
> <http://www.linkedin.com/in/dieswaytoofast>*
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180213/fbabb381/attachment.html>

------------------------------

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


End of erlang-questions Digest, Vol 360, Issue 10
*************************************************

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions