[erlang-questions] [ANN] Positive version 13.3.7

Benoit Chesneau bchesneau@REDACTED
Sat Mar 26 08:42:44 CET 2016


On Sat, Mar 26, 2016 at 4:21 AM Klaus Trainer <klaus_trainer@REDACTED>
wrote:

> I'm wondering whether nobody can't see the actual benefit of providing a
> library that does such a trivial thing, but not more. Is it just people
> here that can't see through their smugness?
>
> Aside from apparently rickrolling Joe Armstrong, Jesper's library is a
> great demonstration for a minimal solution to the following problem.
>
> Provide a library that meets these requirements:
>
> * it has a README that explains what problem this library solves
> * it has a meaningful and clearly recognizable name
> * it is available under an OSI-approved software license
> * it is available via the platform's most commonly accepted package
>   repository
> * one can easily include the provided package in an existing project by
>   using any of the platform's commonly accepted build tools
> * its source code is provided via a distributed version control system
> * it uses semantic versioning
> * it has code documentation explaining the parts in the source code that
>   are not self-explanatory
> * it has tests
> * it has type specifications
> * the type specifications are actually checked when the tests are run
> * it has code coverage analysis
> * the code coverage analysis is actually done when the tests are run
> * the tests are run automatically in a continuous integration system
>   when someone commits code to the main repository or proposes changes
>   to it
> * one can easily see the status of the continuous integration tests at
>   first glance
>
> Some additional things that are important to have in open source
> projects, but that are still missing from this library (and which would
> make great contributions, I guess):
>
> * end user documentation that shows how to get started and provides a
>   couple of code examples that demonstrate how to use it
> * API documentation
> * a CHANGELOG that explains breaking changes and provides upgrade
>   instructions
> * a code of conduct and information on how it will be enforced and where
>   to report violations
> * information on how to contribute: e.g. contributing guidelines, how to
>   get support, examples for past contributions, suggestions for future
>   contributions
> * instructions for reporting issues (where and how etc.)
> * links to additional resources that are relevant to the topic: e.g.
>   mailing lists, standards, alternative implementations
>
> Beside its platform's technical superiority, the only other thing the
> Erlang community currently seems to be justified to feeling smug about
> is its own very smugness. It nicely shows how smugness can be
> implemented in a recursive way (which I hope is tail recursive, though).
> Well, and there's also some humor, which is often jerky, and sometimes
> also funny. If the Erlang community would have a reason for feeling
> smug about a vast ecosystem of projects that meet most of the above
> standards (or maybe  even exceed them), that would be great!
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions


This is a joke right?

First it's not a library. A library is a *collection* of similar things.
There is no collection with one function.

Second, in which world do you live to think we can decently manage
thousands of dependencies for a project. Dependencies, on which you don't
have any control, forcing you to literally fetch the world to just  fix one
for your project or adapt it to your own needs. Imo the npm ecosystem is
the perfect application of the taylorization forcing each part of the chain
depending on each others, introducing as many bottleneck as you have links
in it. History proves that taylorization and the choice of using "one best
way" had effect on innovation, crystallising some parts of the chain,
making really hard to replace some parts of it and holding back the rests.
With the final result of stopping any innovation.  And this is exactly the
issue of the nodejs ecosystem. Without counting the risk that a crucial
part of the chain stop to be maintained forcing everyone to move to
another. Which may be difficult on rapidly markets. Also this is a very
unpleasant process.

Anyway back to this one unit code well tested. At the beginning of the
century we had these websites collecting snippets. People were able to
upload, download, comment and fixe these snippets. This has mostly gone
today (letting us with crappy things like stackoverflow). But the idea was
good. Maybe rather than having the faulty approach of one code, one
package, we could have tools allowing you to easily insert snippets in our
code while keeping a link to the source. Besides the copy-paste I mean. It
would at least allows us to appropriate this code and keep our authorship.

- benoît
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160326/02e79174/attachment.htm>


More information about the erlang-questions mailing list