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

Adriano Ferreira aferreira at shopzilla.com
Sun Aug 24 09:53:57 PDT 2008


2008/8/23 Luis Motta Campos <luismottacampos at yahoo.co.uk>:
> Adriano Ferreira wrote:
>>
>> É totalmente furado dizer que JSON é YAML aprimorado. Está mais para
>> JSON é YAML estilizado (muito estilizado e limitado).
>
> 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.

"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

"JSON Closer to YAML, But No Cigar (Thanks Alot, Whitespace!) " by why
http://redhanded.hobix.com/inspect/jsonCloserToYamlButNoCigarThanksAlotWhitespace.html

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

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

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.

JSON perde muito da riqueza estilística do YAML (cujo ponto chave de
venda é a legibilidade até para leigos). JSON obriga ao uso de uma
série de marcadores léxicos (aspas, chaves, colchetes) que o fazem
lembrar o rigor do XML com seus "tags", tags de fechamento, atributos
entre aspas, que são muito mais estritos que o HTML por exemplo.

Para ilustrar considere a leitura de um documento JSON (que também é YAML) como:

{"nick": "Philarp Tremaine", "rank": "infantry",
  "badge": "orange-striped, syrup-scented"}

e sua transformação em YAML no trecho abaixo.

$ perl -MJSON -MYAML -e 'print Dump( decode_json( shift ) )' '{"nick":
"Philarp Tremaine", "rank": "infantry",
  "badge": "orange-striped, syrup-scented"}'
---
badge: 'orange-striped, syrup-scented'
nick: Philarp Tremaine
rank: infantry

Questão de preferência: eu prefiro a versão YAML para ler, do que a
sopa de chaves e aspas do JSON.

> "Estilizado" não se aplica.

Sim. Estilizado se aplica como mencionado acima e nas referências
citadas. Não estou dizendo que JSON nasceu como YAML, mas o ponto de
contato do JSON como subconjunto de YAML foi reconhecido e inclusive
reforçado por revisões do formato. Então meus comentários aplicam-se
dentro da perspectiva de que JSON é uma fração de YAML. Note que isto
não é lá muito importante do ponto de vista de quem quer se concentrar
apenas no JSON e no que ele pode representar.

> "Limitado", talvez. Mas o mais importante é
> frizar que JSON não consegue expressar coisas que YAML foi desenhado para
> expressar. Assim, JSON *não* *é*. YAML.

Realmente não consegue. Nada de estruturas recursivas, nada de tipos
de dados, etc., etc.

> Por favor evite fazer afirmações confusas sobre as duas linguagens. Já é
> complicado explicar que uma é melhor que a outra, as pessoas acham que "dado
> é dado", e que a forma como você representa os seus dados tem muito pouca
> relação com a solução do problema, o que basicamente contradiz o trabalho da
> vida do Niklaus Wirth, um respeitável cientista da computação, educador e
> programador.

Algumas afirmações podem ser confusas segundo o conhecimento e boa
vontade de quem recebe a informação. Acho que é um caso destes.

>
>> 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.
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

>> O propósito do JSON é bem menos pretensioso: um subconjunto de
>> JavaScript para descrever estruturas de dados para serem usados como
>> linguagem de serialização e inter-comunicação entre partes de uma
>> aplicação (inclusive partes que usem diferentes linguagens, como Perl
>> ou Java no servidor e JS no browser).
>
> Isso, é a definição e objetivo descritos no website www.json.org, eu
> consegui encontrar.
>
>> A vantagem de JSON é que é extramente simples. A desvantagem é essa
>> também. :-)
>
> 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.

> Tão aí mais dois centavos. Espero que isso seja produtivo.
> Putamplexos.
> --
> Luis Motta Campos is a software engineer,
> Perl Programmer, foodie and photographer.
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm at pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>


More information about the SaoPaulo-pm mailing list