[SP-pm] contras do JSON was: Re: Logar access.log do Squid no Mysql usando File::Tail

[Luis Motta Campos]

Oies, Adriano. Isto está ficando bom :)

Luis Motta Campos wrote:
>> Calminha aí. Não força a barra. Apenas por que uma linguagem parece
>>  com a outra, você não pode sair trocando de compilador assim, sem 
>> mais nem menos, e esperar que as coisas "simplesmente funcionem". 
>> Não tem mágica.

Adriano Ferreira wrote:
> "YAML is JSON" by why (o autor do YAML.rb, que é parte da 
> distribuição padrão Ruby e da biblioteca Syck) 
> http://redhanded.hobix.com/inspect/yamlIsJson.html

Eu acho que este cara está falando "use YAML", não o contrário.
E eu não vi uma demonstração aceitável para a compatibilidade do parser.
Ser um subconjunto é condição necesssária mas não suficiente, lembre-se.

De qualquer forma, é bom saber que dá para resolver boa parte dos casos
com YAML, ao invés de usar JSON.

> "JSON Closer to YAML, But No Cigar (Thanks Alot, Whitespace!) " by 
> why 
> http://redhanded.hobix.com/inspect/jsonCloserToYamlButNoCigarThanksAlotWhitespace.html
> 
> 
Este post já aponta mais um problema:

<quote>
However, another minor difference has been found. In JSON structures,
the colon and comma need not be spaced out between items in a
collection. In YAML, they do. Observe:

  # valid JSON, also valid YAML
  {"nick": "Philarp Tremaine", "rank": "infantry",
   "badge": "orange-striped, syrup-scented"}

  # valid JSON, not valid YAML
  {"nick":"Philarp Tremaine","rank":"infantry",
   "badge":"orange-striped, syrup-scented"}

YAML requires the space after each colon or comma. This is because YAML
supports commas and colons in plain, unquoted strings.
</quote>

O que na realidade suporta a minha afirmação de que JSON não é YAML. ;)

> JSON on the Web, or: The Revenge of SML by Simon St. Laurent 
> http://www.xml.com/pub/a/2006/07/05/json-on-the-web-or-the-revenge-of-sml.html
> 
> 
"It's a subset of YAML, as it turns out. Well, not a perfect subset at
first, but with the departure of JavaScript comments, it's very close.
JSON can be a perfect subset of YAML, if colons and commas are followed
by spaces."

Este cara e o cara antes dele concordam comigo: JSON é *quase*, mas *só
quase* um subconjunto de YAML. Assim, eu mantenho a minha afirmação:
JSON não é YAML.

> e uma penca de outras referências que podem ser encontradas com uma 
> busca por "json subset yaml" no bom e velho Google.

Bom, se você lesse as referências, ia entender que isso é o contrário do
que você estava tentando afirmar. Mas obrigado, acho que o meu ponto
está bem ilustrado, agora.

> Presta atenção que não é mágica -- foi proposital a eliminação de 
> algumas "features" do JSON (como comentários /**/ e aspas simples) 
> para encaixá-lo como subconjunto do YAML.

OK, eu te dou esta - eu aprendi isto lendo novamente as referências dos
textos que você apontou.

> (...) eu prefiro a versão YAML para ler, do que a sopa de chaves e 
> aspas do JSON.

Bom, a gente concorda neste ponto, então. Ótimo. :)

>>> Quando o YAML foi criado, propositalmente foram criados pontos de
>>>  contato entre Python, JavaScript e Perl. Por exemplo, (1) a 
>>> relevância de indentação como em Python, (2) sintaxe "chave: 
>>> valor" como em Python, JavaScript e os cabeçalhos de mensagens de
>>>  e-mail como definido em algum RFC que eu não sei o número nem o 
>>> link, (3) mil e umas opções de "quote" inspiradas no TIMTOWTDI e 
>>> sintaxe do Perl.
>> 
>> Desculpa, meu caro, mas eu não consigo encontrar referências para 
>> suportar esta afirmação na documentação do YAML. Quer por favor me 
>> apontar para elas?
> 
> Porque você não consegue encontrar, não significa que não existam.

Isso é verdade. Foi por isso que eu te perguntei, não quis ser irônico. 
Por favor me desculpe se foi isso que pareceu.

> Lembro de ter lido há um bom tempo estas afirmações nas palavras dos
>  próprios autores de YAML: Oren Ben-Kiki, Clark Evans e Brian
> Ingerson (hoje conhecido como Ingy döt Net). Como eu não procurei o
> bastante, no momento só tenho algumas referências de segunda mão
> como:
> 
> Look Ma, No Tags By Kendall Grant Clark http://www.xml.com/lpt/a/1005
> 
> "As for YAML's other influences, section 1.2 of the specification 
> generously exhibits them. Python fans will be happy to note that it 
> uses whitespace as a block delimiter. It also steals ideas from MIME,
>  HTML, XML and SOAP, including aliasing, application-specific types,
>  and a namespace mechanism which is part Java package naming and part
>  XML URI-based namespace naming. But perhaps the biggest influence on
>  YAML is Perl -- which I, as a Python devotee, had to learn not to 
> hold against it! -- especially in the way YAML conceptualizes data 
> structures and types, which it distinguishes into scalars, like 
> integers and strings, and collections, like hashes and arrays."
> 
> que na verdade aponta que estas afirmações podem ser encontradas na 
> própria especificação YAML. Aqui: http://yaml.org/spec/1.2/#id2507330
> 

Lamento, mas eu acho que o que está infeliz na tua afirmação é a 
expressão "pontos de contato". Copiar notação de outras linguagens não é 
"estabelecer contato" com elas. Estabelecer contato com elas é tentar 
aproveitar funcionalidades já existentes nas linguagens, como por 
exemplo JSON tenta fazer com Javascript.

Lamento, mas foi apenas agora que eu compreendi o que você estava 
querendo dizer com "pontos de contato".

>> Por favor, não confunda "simples" com "simplório". JSON é simplório
>>  - não foi criado para ser uma linguagem de representação de dados,
>>  foi criado como um recurso de geração de código JS para
>> representar uma determinada estrutura de dados em memória. É a
>> implementação de Data::Dumper em Javascript, para traçar um
>> paralelo meio tosco.
> 
> Chamar JSON de simplório não contribui para o fato de que hoje muitos
>  'frameworks' utilizam-o como meio de comunicação em aplicações web 
> entre o servidor e o cliente (muitas vezes na forma de scripts Ajax).
>  Simples ou simplório, o uso que se faz hoje de JSON faz desta 
> tecnologia uma estória de sucesso, que não pode ser facilmente 
> ignorada por alguém trabalhando no nicho onde o JSON tem este 
> sucesso.

(Você é da velha guarda, mas "estória" caiu em desuso depois da reforma 
da língua em 1990 - eu fiquei curioso para saber a sua idade, mas este é 
o tipo de conversa que a gente pode ter na mesa do bar, ou, pelo menos, 
em privado)

Não. Chamar JSON de simplório na verdade denigre o uso que se faz hoje. 
E não, eu não acho que ter muita gente usando signifique que seja uma 
coisa boa: cito como exemplos os casos clássicos do VHS e do Windows, 
duas porcarias vendidas em massa para o público ignorante e sedento por 
"tecnologia" acessível.

Meu papel aqui não é assentir com os padrões pré estabelecidos, mas 
questioná-los e fazer as pessoas pensarem sobre por que elas usam XML, 
JSON e outras porcarias, quando elas tem acesso a coisas melhores. Não 
tenho a pretenção de que as pessoas parem de usar estas tecnologias tão 
cedo, mas eu não vou deixar de fazer o meu papel de analista e crítico 
por causa disso.

Por favor não me leve à mal, Adriano. :) Você foi muito bacana, 
respondendo à mensagem com tanto cuidado. Obrigado pelo seu interesse e 
pelas coisas que você me motivou a aprender para continuar este 
argumento com você. Vamos fazer isso mais vezes.

Putamplexos.
-- 
Luis Motta Campos is a software engineer,
Perl Programmer, foodie and photographer.