31–40 of 43 posts
If it can be done in JSON it can also be done in YAML. I pick YAML.
Have you read the specs for both? You should read the JSON spec. It will take you ten minutes. The YAML spec ( http://yaml.org/spec/1.2/spec.html ) may take you a little longer. . .
Earlier quoted context omitted.
Have you read the specs for both? You should read the JSON spec. It will take you ten minutes. The YAML spec ( http://yaml.org/spec/1.2/spec.html ) may take you a little longer. . .
S-expressions will take you ten seconds still nobody uses them. YAML is made to simplify the lives of the reader and the writer, not the parser. Let the parser suffer, let the coder rejoice. You pick your own level of suffering, I pick mine. Deal?
Earlier quoted context omitted.
If the idea is to reduce verbosity, I'd much prefer CSON. YAML just has way too much "magic" parsing behavior.
Not bad, a second close just behind YAML in my picks. Nothing can beat this: name: Taylor Swift Absolutely nothing, no matter how you dress it.
name "Taylor Swift"
Earlier quoted context omitted.
Sure. S-expressions[1] are a notation for nested data structures. They can be used to spell out data as well as code. In fact both code and data look the same when expressed using s-expressions.[2] When the article's author describes both code and data using JSON, it sounds a little strange to me. While JSON is capable to describing nested data structures, JSON's syntax is much more verbose than s-expressions. I feel…
Although I'm also skeptical of coding in JSON, s-expressions are pretty close to a JSON subset (with the caveat that everything needs to be quoted). (x . (y . (z . NIL))) ['x', ['y' , ['z', null]]]
Earlier quoted context omitted.
Sure. S-expressions[1] are a notation for nested data structures. They can be used to spell out data as well as code. In fact both code and data look the same when expressed using s-expressions.[2] When the article's author describes both code and data using JSON, it sounds a little strange to me. While JSON is capable to describing nested data structures, JSON's syntax is much more verbose than s-expressions. I feel…
Although I'm also skeptical of coding in JSON, s-expressions are pretty close to a JSON subset (with the caveat that everything needs to be quoted). (x . (y . (z . NIL))) ['x', ['y' , ['z', null]]]
JSON is the new XML. Except XML was actually designed to have semantics, while similar attempts in JSON are just hacks. In general, JavaScript is becoming the new J2EE. Ambitious ideas, clueless implementations, insane complexity.
1. OP article has nothing to do with JavaScript. 2. It's not like the JS community is anti-XML, most JS libs/frameworks still use HTML/XML markup for rendering. 3. The JS community is vast and diverse - generalisations around 'clueless implementations, insane complexity' don't make a lot of sense.
Its pretty anti-XML outside of node. Pure-js solutions for xml are not as great as built in features other languages provide, while JS only natively does JSON.
>generalisations around 'clueless implementations, insane complexity' don't make a lot of sense.
When you are creating languages that compile to JS and adding entire markup ontop of it along with literally hundreds of dependencies in any average project, JS has plenty of insane complexity.
Earlier quoted context omitted.
1. OP article has nothing to do with JavaScript. 2. It's not like the JS community is anti-XML, most JS libs/frameworks still use HTML/XML markup for rendering. 3. The JS community is vast and diverse - generalisations around 'clueless implementations, insane complexity' don't make a lot of sense.
>It's not like the JS community is anti-XML, most JS libs/frameworks still use HTML/XML markup for rendering. Its pretty anti-XML outside of node. Pure-js solutions for xml are not as great as built in features other languages provide, while JS only natively does JSON. >generalisations around 'clueless implementations, insane complexity' don't make a lot of sense. When you are creating languages that compile to JS an…
Like parent said, this project doesn't compile to JS. It's simply a JSON to native mapping.
Earlier quoted context omitted.
1. OP article has nothing to do with JavaScript. 2. It's not like the JS community is anti-XML, most JS libs/frameworks still use HTML/XML markup for rendering. 3. The JS community is vast and diverse - generalisations around 'clueless implementations, insane complexity' don't make a lot of sense.
>It's not like the JS community is anti-XML, most JS libs/frameworks still use HTML/XML markup for rendering. Its pretty anti-XML outside of node. Pure-js solutions for xml are not as great as built in features other languages provide, while JS only natively does JSON. >generalisations around 'clueless implementations, insane complexity' don't make a lot of sense. When you are creating languages that compile to JS an…
Earlier quoted context omitted.
If the idea is to reduce verbosity, I'd much prefer CSON. YAML just has way too much "magic" parsing behavior.
Not bad, a second close just behind YAML in my picks. Nothing can beat this: name: Taylor Swift Absolutely nothing, no matter how you dress it.
So why JSON of all things? When I reached the "write a full declarative program in JSON" section I was internally screaming "but s-expressions!"
Same thinking, I expect, that gave us XSLT.
On the other hand, students of the past will notice that Jsonette looks awfully similar to Ant build files, which sucked. JSON/XML/YAML is a horrible way to construct general-purpose programs. Computing languages exist for a reason.