[erlang-questions] [ANN] Positive version 13.3.7

[Jesper Louis Andersen]

Hi,

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:

Was this a joke?

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.

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:

* It is written in earnest and not as a joke because it is useful
* 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.
* 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.
* 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.

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:

val sign : int -> Sign.t

with Sign.t being

type t = Pos | Neg | Zero

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.

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.

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 hex.pm. This turnaround time
is something which wouldn't have been possible, had it not been for the
work in Elixir around hex.pm.

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 :)

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.

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.

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.

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.

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.

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 :)


On Sat, Mar 26, 2016 at 8:42 AM, Benoit Chesneau <bchesneau@REDACTED>
wrote:

>
>
> 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
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


-- 
J.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160326/56e8cc16/attachment.htm>