[erlang-questions] Coon - new tool for building Erlang packages, dependency management and deploying Erlang services

[Charles Hixson]

Did you ever read how much Exxon paid to find a name that wasn't taken 
and wasn't objectionable?  Whee!  I was shocked.  (I couldn't find a 
link for it in a short Google search, and I don't remember the exact 
figure, but it was more than the cost of the most recently built college 
dorm.)

But it's also true that it's important that a name be easily memorable, 
which lets out the SHA-1 choice...though that makes a good unique 
identifier.

Picking a good name is hard.  But to me this doesn't seem a wise choice.

On 02/12/2018 09:58 AM, Joe Armstrong wrote:
> Goodness - what a lot of mails.
>
> When choosing a name the following algorithm is used by many
> organisations and people
>
>      1) Choose a name
>      2) Check in all known languages if this might offend someone
>          if it does goto 1)
>
> (There are even companies you can hire that do this, if it's a big product)
>
> If I wrote some software I would like it to be discussed for the right
> reasons, which are
>
>      - it is useful
>      - it is beautiful
>      - it solves some interesting problem
>      - it raises and solves some interesting problem
>
> I would not like it to be discussed for my skills in naming the damn code.
>
> 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.
>
> If you choose the wrong name you can accidentally offend people, even if this
> is not your intention - offending people has consequences.
>
> Cheers
>
> /Joe
>
>
>
>
> On Mon, Feb 12, 2018 at 6:28 PM,  <zxq9@REDACTED> wrote:
>> On 2018年2月12日月曜日 12時10分20秒 JST Tom Santero wrote:
>>> Putting the project's name aside for a moment, there are two things I'd
>>> like to point about:
>> THANK YOU
>>
>>> 1. i would never pull a pre-built binary from a 3rd party into one of my
>>> projects. lol security?
>> I disagree, in that we are right back in "trusting trust" territory. I prefer building from source (for a number of reasons) but source or not, for nearly everyone (perhaps actually everyone) who builds a project that involves external dependencies, the security is only as strong as the signature on the code received (and implicitly, the trust of the signature scheme employed) and the trust of the review process which granted the signature.
>>
>> Both are greviously lacking in using direct-from-github packages (whether source or pre-built) as repository inputs.
>>
>>> 2. that this project doesn't address rebar3/relx/hex at all means it is at
>>> odds with the direction the community has been pushing toward for several
>>> years now, and makes it relatively useless
>> I disagree again. In this era we have full-blown systems to drive; the common case today is NOT to deploy to a resource-strapped or custom-built piece of hardware that can never be accessed by system administrators. The common environment today is more like a (to use an awful term) "devops" environment where people want things to rebuild in the lightest possible way and "just go". Which is to say, people desperately wish that Erlang (not to mention Elixir) code could be more commonly built and run the way Python projects that use virtualenv can be.
>>
>> I think the to-date direction of the Erlang community de facto practices is a bit dated, being built around the ancient and original assumption "everything has to be an Erlang distribution".
>>
>> -Craig
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions