<div dir="ltr">Hi,<div><br></div><div>I'm going to move myself from around 0.1 nano smug-lisp-weenies to 0 for a little bit and make some rather serious comments:</div><div><br></div><div>Was this a joke?</div><div><br></div><div>Yes. I'm not going to change in any way, even if I get flak for making this joke. There is a fine line between what you can say and what you can't, and unless you are willing to walk it now and then, you will not be able to make jokes. I also firmly believe people are able to make their own decisions on the positive/negative impact jokes have on a community. If you can't ignore one jester in the corner, how can you even rule the court? In short: If you evaluate a community on a single incident you don't align with, then you are bound to fail every community in the long run.</div><div><br></div><div>Dissecting the frog^Wjoke would make it die, but anyway here goes: the joke is not about the writer of the NPM is-positive-integer package, yet it may look like it. If you read what is public on Twitter, the package writer makes some points about this:</div><div><br></div><div>* It is written in earnest and not as a joke because it is useful</div><div>* It is useful not because of its contents, but because there is a test suite around the given function. You can easily make the argument that modern software should be small packages with formal proof in Coq for their specifications. The package is a convergence toward that point.</div><div>* Javascript, in all its insanity of a semantics, has no native integer representation. So you need to handle situations where you get NaN, -Infinity, and other floating point inputs.</div><div>* The package writer has many other, larger, packages and as such is not a beginner. I'm pretty confident that the writer is a competent person.</div><div><br></div><div>It is even funnier in Haskell or OCaml, than Erlang, where the type system can implicitly kill most of the corner cases automatically. In Janes St. Core stdlib for OCaml, we have:</div><div><br></div><div>val sign : int -> Sign.t</div><div><br></div><div>with Sign.t being</div><div><br></div><div>type t = Pos | Neg | Zero</div><div><br></div><div>so 'let positive x = Int.sign x = Pos' is enough to implement it. Most of the scaffolding is already in the standard library in this case.</div><div><br></div><div>The reason you have many odd-looking libraries in Javascript is due to it having really bad and inconsistent semantics. Asking if something is an array doesn't work in IE8, so you have to resort to hoop-jumping in order to make a fully portable isArray function. And thus, a seemingly insane package is born into NPM. Erlang, in constrast, has a pretty moldy standard library where there is little consistency. But the *semantics* of Erlang are pretty straightforward. Thus we avoid these kinds of special-case libraries.</div><div><br></div><div>Jokes aside, Klaus Trainer has a point worth following in the long run I think. We don't need much more work on that package before we can run Cuter inside the test suite and we are pretty close to a template. In this case, the library itself *has* to be simple because it is not the desired output: the packaging is. A really nice point was that it took me about 5 minutes to build the initial package and publish it on <a href="http://hex.pm">hex.pm</a>. This turnaround time is something which wouldn't have been possible, had it not been for the work in Elixir around <a href="http://hex.pm">hex.pm</a>.</div><div><br></div><div>Another interesting point is that this repository has had lots of collaboration. In fact, I'm already being overrun in the commit graph by other people, and their work is better than mine. I find the test suites export-hack beautiful, and wouldn't have come up with that myself :)</div><div><br></div><div>Benoit says that a library cannot contain a single function, but should be a natural collection of like functions. I would agree a priori. But one problem, which may hit Javascript, is that dead-code-elimination and linking may not be that easy. So if you pull in a large library, you are implicitly forced to download all of that library for your web page. Proper DCE would eliminate that, but alas, Javascript is not going to get it (and neither is Erlang - DCE requires a good static linking phase to get the full benefits). By keeping packages small, you can avoid this problem.</div><div><br></div><div>The real problem, which is more important to address, is how you handle "evil" or "malicious" packages in a repository. NPM, to my knowledge, does not isolate building and packaging, in the sense that a build step can evaluate arbitrary code. This leads to dangerous situations where the mere build step can take over machines, while the package itself contains no maliciousness.</div><div><br></div><div>The other problem, of which most people have identified immutability as a solution, is that when you pull the packages at time T, you expect the packages to be the same. But as time goes on, your dependencies might experience a "Temporal Collapse"---A package is being updated in a way that is not compatible with your code, and you cannot reproduce your build. The package manager of the Elm language, while imperfect, uses types to enforce semantic version constraints on packages in an attempt to alleviate this problem. The other temporal problem is when a package is deleted and a new maintainer takes over the the package name. You need a way to tell the dependents they are now using a different package. This is why I really like the idea of locking dependencies in Rebar3, and I hold that we should address our packages by a cryptographic checksum over their content for integrity.</div><div><br></div><div>Authentication is another subject, and it is quite hard to get right in package managers. It is highly non-trivial and needs to protect against typical attack vectors, for instance the take-over of a central repository by a company. And it has to be simple in the sense that the "Signal" or "WhatsApp" applications are: using a cryptographically secure system should be no harder than using the system without in most cases.</div><div><br></div><div>Finally, there is HTTP Status Code 451 "Unavailable For Legal Reason", when a package is removed by law. It breaks the immutability solution. I think it would be fair to say that the package should be removed from the repository in such cases, and the name given to the rightful owner. But it is not fair the takeover happens retroactively at the very instant as this leads to Temporal Collapse. Rather, you would like a "sunset" period, in which the earlier version of the package, which people rely on, are still present for download with deprecation warnings. This gives dependents a chance at updating their systems, without leading to immediate breakage. I think we, as programming communities in general, should try to get this into our law-systems such that 3rd parties are not hit by accident.</div><div><br></div><div>Finally, in full accordance with the toxic person I am, I'll sign this and say I fully stand by everything I did with the joke. And it will not be the last such you see from me, though I think I'll pass on April the 1st now :)</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 26, 2016 at 8:42 AM, Benoit Chesneau <span dir="ltr"><<a href="mailto:bchesneau@gmail.com" target="_blank">bchesneau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Sat, Mar 26, 2016 at 4:21 AM Klaus Trainer <<a href="mailto:klaus_trainer@posteo.de" target="_blank">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></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>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">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><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div>