[erlang-questions] [ANN] Positive version 13.3.7

[Andrew Berman]

Geez, I can't believe it's an issue that we're making fun of what happened
or about the JavaScript language.  Oh, the horror.  One thing no one has
mentioned is that the reason there is a library like left pad for JS is
because JS has to deal with size constraints.  Erlang doesn't have that
issue.  JS is used on the front-end, so forcing a client to download
unnecessary code is a no-no, especially on mobile devices.

JavaScript is a language in a state of change right now.  They're turning a
browser language into a server one and they're figuring it out.  They'll
fix the issues and they'll come out on top, but really services like Github
are to blame for npm-gate.

I come from the Java world.  What I love about the Java world is that we
have Apache (and Spring and JBoss) that I can pretty much trust.  They have
the commons libraries, for example, which are a group of useful utilities
that prevent me from having to constantly rewrite the same methods over and
over (and left pad is a method within one).  I really wish Erlang and
Javascript had some foundation like Apache that I could trust and that
doesn't just accept any random library.  We're missing the filter!  It's
just not there (or maybe they're not advertising themselves well).  I don't
trust the code written by some random guy on Github, which is usually just
abandoned (I am guilty of this as well).  Github is good for what it is,
but come on, not everyone is a great programmer and I don't know who is or
who isn't based on their Github repo, and I don't have time to muck through
their code.  I just want to get what I want and not have to worry about
it.  So when Apache (or JBoss or Spring) releases something, I can
certainly feel more confident in the release and that it's going to be
supported in some fashion.

We're a group of really smart people, so instead of wasting time on
discussing the merits of a joke (which I thought was awesome, I mean, go
look at the issues in the repo!), we should be looking at this as a
learning experience and helping our community grow and prosper.  If I was
to ask you which JSON library to use, why is it that I'd get different
answers?  It's crazy.  I just want one which I know is going to work and be
supported.  I know Garret talked about this in one of his talks as a reason
for why Erlang is not widely used.

Rant over,

Andrew

On Sat, Mar 26, 2016 at 5:35 AM Jesper Louis Andersen <
jesper.louis.andersen@REDACTED> wrote:

> 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.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160326/31acefcf/attachment.htm>