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

Frederico Recsky frederico at gmail.com
Sun Aug 24 10:41:34 PDT 2008


Olá,

Massa o topico. Eu tinha feita a pergunta porque o eden no irc uma vez
tinha me sugerido JSON e na época eu não o conhecia.

Valeu todo mundo mas agora vou voltar com meu XML :P.

/me corre para não apanhar.

[]'s  :)

2008/8/24 Adriano Ferreira <aferreira em shopzilla.com>:
> 2008/8/23 Luis Motta Campos <luismottacampos em 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 em pm.org
>> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>>
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm em pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>


-- 
____________________________
Frederico Recsky
Linux User: #253572
http://www.fred.eti.br
http://www.perl.org.br


More information about the SaoPaulo-pm mailing list