[erlang-questions] [ANN] Positive version 13.3.7

Klaus Trainer <>
Sat Mar 26 04:21:29 CET 2016

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
* 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
* 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
* 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!

More information about the erlang-questions mailing list