[erlang-questions] JSON for STDLIB

Theepan vasdeveloper@REDACTED
Tue Sep 8 18:18:59 CEST 2015


Yes, That makes sense..

Theepan

On Tue, Sep 8, 2015 at 9:45 PM, Bob Ippolito <bob@REDACTED> wrote:

>
>
> On Tue, Sep 8, 2015 at 2:42 AM, Jesper Louis Andersen <
> jesper.louis.andersen@REDACTED> wrote:
>
>> On Mon, Sep 7, 2015 at 3:34 AM, Theepan <vasdeveloper@REDACTED> wrote:
>>
>>> Since Erlang is now widely used in internet domain, I believe that
>>> inclusion of JSON library under STDLIB is essential. There are many open
>>> source variants, but I like Jiffy and Jsx. They support MAPS too.
>>>
>>
>> Roughly, two variants of programming language standard libraries exist,
>> where most languages sit somewhere on the continuum of these extreme points:
>>
>> 1. Put as little as possible in the standard library. Usually only put
>> the things necessary to write the compiler itself, and the libraries which
>> are impossible to write without close support from the compiler/runtime.
>>
>> 2. Use the Stdlib to "bless" certain implementations of commonly used
>> libraries as the default. The Stdlib is considerably larger, but is
>> guaranteed to have seen lots of testing.
>>
>> It is not a priori clear one solution beats the other. There are
>> advantages and disadvantages to both models. Personally I lean toward
>> option 1, because I "come from" languages which used this model: Standard
>> ML and OCaml. The danger of such a model however is that you end up with
>> many stdlib implementations, and in statically typed languages you often
>> end up in situations where packages built for one stdlib are not compatible
>> with the other stdlib.
>>
>> This makes people yearn for option 2. But it is not without its
>> consequences either. Work on the stdlib is now centered around a few
>> people, so it will invariably move slower. The other problem is that
>> updates to the stdlib is now locked to the update rate of the compiler.
>> This is rarely desirable. And when new releases come out, everyone has to
>> scramble in order to upgrade everything in the stdlib they rely on. In a
>> more compartamentalized world, you can go update packages separately.
>>
>> JSON is particularly nasty because different characteristics are mandated
>> by different users. Some want fast JSON parsing. Some want correct JSON
>> parsing. Some want mapping rules into their Erlang world. For this reason,
>> there are always many disparate JSON libraries in any language (C has at
>> least 10, Java has at least 20). You *can* pick one and put into the
>> stdlib, but people still have to build their own to their wants.
>>
>> In my opinion, there are far too many libraries in the standard
>> Erlang/OTP distribution. This means more work on the Ericsson Erlang/OTP
>> team and we can't mint a new fix package for a separate area without
>> rolling a new point release for Erlang/OTP. Moving some things into
>> separate repositories would help a lot. But it also requires some work on
>> package management so the transition is as seamless as possible.
>>
>
> Yeah, what's really needed here is a working dependency management
> solution that the community standardizes on. Some brave person can build
> the high-performance library that does the low-level JSON stream parsing
> and nasty string/float encoding bits, and then a mountain of higher-level
> libraries can use that as a common dependency.
>
> -bob
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150908/b46d8130/attachment.htm>


More information about the erlang-questions mailing list