[erlang-questions] No JSON/MAPS interoperability in 17.0?

[Fred Hebert]

On 03/14, José Valim wrote:
> Just to be clear: I was not advocating for bait-and-switch. I was not
> advocating for optimizing "hello world".
> 
> I was/am advocating for providing "higher level abstractions" that are
> first proved to be useful in production. A direct consequence of having
> those is that it would provide more palpable abstractions for those getting
> started with the language. Point in case: one of the patterns proposed (the
> task pattern) *already* exists in OTP and is used in the OTP codebase
> itself. It is not an invention nor a bait-and-switch mechanism.
> 
> I know you know it, as you were the one who pointed it out. :)
> 

Right, I merged both topics at once -- I didn't mean to imply you were
doing bait and switch, but that we disagreed on the 70% solution idea.

I prefer a single more difficult 100% solution than having both a 70%
solution that I have to unlearn to then get to the 100% one (at which
point I'll have needed to learn two ways to get the same result, plus
legacy code). I think it's worth making a bigger effort at the beginning
if it means you don't end up duplicating work later on.

People are free to disagree with me on that, however, and this isn't a
topic that is objectively debatable as far as I can tell. I don't think
either of us will move our positions on this and that's entirely fine.

A JSON library the way Joe briefly described it is what would be bait
and switch to me, because it has extremely deep pitfalls. (I also
understand that this is a mailing list post where conciseness can be of
use!)

> It should be clear to everyone that providing a built-in solution does not
> mean "we never get to talk about it, ever again". In fact, this is
> something the OTP documentation in general does pretty well: making it
> clear (with the green and red boxes) when something in particular must be
> used or avoided.
> 
> Personally, I am against including JSON by default too. But arguing the
> reason to not include it is because someone can make a bad design decision
> or because it will automatically stop all discussion around the other
> solutions seems to be a very weak point against it.

This gets harder with a strong commitment to backwards compatibility,
which is one of the number one features of using Erlang for me. Code
that worked yesterday will work tomorrow, except for exceptional
circumstances which are announced a long time in advance anyway.

If you're building a JSON library and that you have notices that say
"please don't use it, we're only testing the waters", then why include
it in the language *at all*? There are plenty of mature JSON libraries
in the wild already. This is already work done, no need to repeat it an
Nth time inside the language.

I know you were talking in more general cases, and I'm a strong believer
of evaluating context to make a decision. There are areas where it's
definitely worth trying within Erlang (and the VM), but JSON just isn't
one to me.

Regards,
Fred.