[erlang-questions] JSON for STDLIB

[Theepan]

 Hi,



ASN.1 isn't just a "transfer-format", it's something OTP itself *uses*.
Without the ASN.1 application, there would be no public_key application,
and therefore no SSL, to name one.

JSON would be just sitting there. What's the point?



<Theepan>If I argue to your point -- not all the libraries in the STDLIB
are used internally. Moreover, in a software development platform,
libraries are not just meant to be used internally.</Theepan>

Another argument against it is one you cited in your email: there are
already a variety of open source JSON libraries. Each has different
properties and are useful to different people. Why would you include one
and basically doom the others? Which one would you bundle? Will that choice
make sense to everyone?



<Theepan> The library that caters to the language necessities, that imposes
better coding practice, that performs better, that is hardware efficient
should be included, may be with modifications. If the libraries are out in
the wild, the developer will spend their valuable time in selecting the
library , than concentrating on solving the business problem.

</Theepan>

Finally, I'm not sure what's the point? If you are using Erlang.mk, to use
jsx, you need to add this single line to your Makefile:

DEPS = jsx

If jsx was part of OTP, you would need to add this single line to your
Makefile:

OTP_DEPS = jsx



<Theepan>How you include it into the build is not the issue. It does not
have to be through Erlang.mk. There are couple of other package management
systems for Erlang. Also, after a direct install, you can simply refer it
in the release file in one line. The issue is not of technical nature, but
the bigger picture. Continuity/Faster sync with Erlang
evolutions/Simplicity/Regulation/Completeness. etc</Theepan>

The advantage of bundling it in OTP are not obvious, to say the least.

In general I believe OTP should reduce the number of libraries it comes
with, not increase it. It's easy to find a library fitting your needs
nowadays. Erlang.mk for example has 470 packages and you can search them in
one easy command: make search q=json



<Theepan>As a software development, developers would not expect to have
fragmentation of libraries. As I already mentioned, Erlang.mk is not the
only Erlang package management out there, but it is not the issue here.
JSON library is a good candidate to be including into the STDLIB, with of
course bounds on loose definitions like JavaScript engines do.</Theepan>



On Mon, Sep 7, 2015 at 1:09 PM, Loïc Hoguin <essen@REDACTED> wrote:

> On 09/07/2015 03:34 AM, Theepan wrote:
>
>> Team,
>>
>> Is there any reason why a JSON library is not included into Erlang/OTP
>> releases? Since it was initially planned for telco systems, it includes
>> ASN.1 library. It has some other transfer-format libraries as well.
>>
>
> ASN.1 isn't just a "transfer-format", it's something OTP itself *uses*.
> Without the ASN.1 application, there would be no public_key application,
> and therefore no SSL, to name one.
>
> JSON would be just sitting there. What's the point?
>
> Another argument against it is one you cited in your email: there are
> already a variety of open source JSON libraries. Each has different
> properties and are useful to different people. Why would you include one
> and basically doom the others? Which one would you bundle? Will that choice
> make sense to everyone?
>
> Finally, I'm not sure what's the point? If you are using Erlang.mk, to use
> jsx, you need to add this single line to your Makefile:
>
> DEPS = jsx
>
> If jsx was part of OTP, you would need to add this single line to your
> Makefile:
>
> OTP_DEPS = jsx
>
> The advantage of bundling it in OTP are not obvious, to say the least.
>
> In general I believe OTP should reduce the number of libraries it comes
> with, not increase it. It's easy to find a library fitting your needs
> nowadays. Erlang.mk for example has 470 packages and you can search them in
> one easy command: make search q=json
>
> Cheers,
>
> --
> Loïc Hoguin
> http://ninenines.eu
> Author of The Erlanger Playbook,
> A book about software development using Erlang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150907/c2cab088/attachment.htm>