<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Mar 26, 2016 at 4:21 AM Klaus Trainer <<a href="mailto:klaus_trainer@posteo.de">klaus_trainer@posteo.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm wondering whether nobody can't see the actual benefit of providing a<br>
library that does such a trivial thing, but not more. Is it just people<br>
here that can't see through their smugness?<br>
<br>
Aside from apparently rickrolling Joe Armstrong, Jesper's library is a<br>
great demonstration for a minimal solution to the following problem.<br>
<br>
Provide a library that meets these requirements:<br>
<br>
* it has a README that explains what problem this library solves<br>
* it has a meaningful and clearly recognizable name<br>
* it is available under an OSI-approved software license<br>
* it is available via the platform's most commonly accepted package<br>
  repository<br>
* one can easily include the provided package in an existing project by<br>
  using any of the platform's commonly accepted build tools<br>
* its source code is provided via a distributed version control system<br>
* it uses semantic versioning<br>
* it has code documentation explaining the parts in the source code that<br>
  are not self-explanatory<br>
* it has tests<br>
* it has type specifications<br>
* the type specifications are actually checked when the tests are run<br>
* it has code coverage analysis<br>
* the code coverage analysis is actually done when the tests are run<br>
* the tests are run automatically in a continuous integration system<br>
  when someone commits code to the main repository or proposes changes<br>
  to it<br>
* one can easily see the status of the continuous integration tests at<br>
  first glance<br>
<br>
Some additional things that are important to have in open source<br>
projects, but that are still missing from this library (and which would<br>
make great contributions, I guess):<br>
<br>
* end user documentation that shows how to get started and provides a<br>
  couple of code examples that demonstrate how to use it<br>
* API documentation<br>
* a CHANGELOG that explains breaking changes and provides upgrade<br>
  instructions<br>
* a code of conduct and information on how it will be enforced and where<br>
  to report violations<br>
* information on how to contribute: e.g. contributing guidelines, how to<br>
  get support, examples for past contributions, suggestions for future<br>
  contributions<br>
* instructions for reporting issues (where and how etc.)<br>
* links to additional resources that are relevant to the topic: e.g.<br>
  mailing lists, standards, alternative implementations<br>
<br>
Beside its platform's technical superiority, the only other thing the<br>
Erlang community currently seems to be justified to feeling smug about<br>
is its own very smugness. It nicely shows how smugness can be<br>
implemented in a recursive way (which I hope is tail recursive, though).<br>
Well, and there's also some humor, which is often jerky, and sometimes<br>
also funny. If the Erlang community would have a reason for feeling<br>
smug about a vast ecosystem of projects that meet most of the above<br>
standards (or maybe  even exceed them), that would be great!<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a></blockquote><div><br></div><div>This is a joke right?</div><div><br></div><div>First it's not a library. A library is a *collection* of similar things. There is no collection with one function.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>- benoît</div></div></div>