21–30 of 120 posts
JSON is popular because there is a straightforward mapping from JSON to native types in many programming languages.
Earlier quoted context omitted.
... while the lispers where still counting the closing parens needed to finally get their code running SCNR
This thread has been yet another fruitful contribution to the language wars. There seems to be something inherent in us that feels the need to turn our tools into our religion. It's not terribly productive.
Earlier quoted context omitted.
... while the lispers where still counting the closing parens needed to finally get their code running SCNR
This thread has been yet another fruitful contribution to the language wars. There seems to be something inherent in us that feels the need to turn our tools into our religion. It's not terribly productive.
SCNR is an old usenet acronym and stands for "sorry. could not resist". I was a) being sarcastic and b) just making fun for the list crowd. I totally agree that if the parens issue is a non-issue for you and you feel comfortable and productive writing lisp code than go ahead.
In fact, I have the utmost respect for people able to wrap their heads around that syntax.
The argument that XML can have various different structures for storing a person's name, while JSON provides one simple solution, doesn't fly. You could run into something like { "Person": { "property": { "type": "first-name", "value": "John" }, "property": { "type": "last-name", "value": "Smith" } } } This begs the question, "Why would you do something that convoluted?" Well, you can ask the same of the XML examples…
Earlier quoted context omitted.
eval() strikes me as a dangerous thing, security-wise.
How? I'm evaluating strings that are built with my javascript code or from my server code, not arbitrary user input from other users. Yes the user is able to enter parenthesis into a textbox, and those become part of the evaluated string, but I regex replace out everything but the actual parenthesis.
JSON just assumes messages are going to trivially fit into naive data structures, and so provides fewer options.
Earlier quoted context omitted.
Only the ones too clueless to use Emacs or another editor that does it for you.
For some reason, every time I let an editor automatically insert a closing parenthesis, quotation, or brace, I almost always end up with extras at the end, which is just as frustrating, if not harder to debug, as not enough. Maybe it's the way I tend to backstep as I think my way through the code flow, but it never ceases to happen whenever I step foot into Eclipse or Visual Studio...
User issue here. I never have the problem you refer to. Don't have the editor/IDE insert the parens/brackets. Have it check them for you. Emacs can do a momentary highlight of the opening paren/bracket whenever you type the close of the pair. I used to use that to make sure I'm writing exactly what I thought I was writing. If my code is too convoluted for me to know that I'm correct in a split second when seeing the open paren highlight, then I know it's time for me to refactor/rewrite the method.
In my present project, I use a similar facility in the Smalltalk browser.
The argument that XML can have various different structures for storing a person's name, while JSON provides one simple solution, doesn't fly. You could run into something like { "Person": { "property": { "type": "first-name", "value": "John" }, "property": { "type": "last-name", "value": "Smith" } } } This begs the question, "Why would you do something that convoluted?" Well, you can ask the same of the XML examples…
John
Smith
The "XML requires you to build your own parse tree" argument isn't valid; XML libraries are fully capable of handing you a DOM-style tree, and of allowing you to pull things out of the tree without writing your own traversal code. JSON just assumes messages are going to trivially fit into naive data structures, and so provides fewer options.
The CPU is spending more time dealing with XML than it is doing useful work. If it's a big file, this is very significant.
In JSON, you get the same expressiveness without the hassle.
Earlier quoted context omitted.
This thread has been yet another fruitful contribution to the language wars. There seems to be something inherent in us that feels the need to turn our tools into our religion. It's not terribly productive.
no. but fun. SCNR is an old usenet acronym and stands for "sorry. could not resist". I was a) being sarcastic and b) just making fun for the list crowd. I totally agree that if the parens issue is a non-issue for you and you feel comfortable and productive writing lisp code than go ahead. In fact, I have the utmost respect for people able to wrap their heads around that syntax.
For the true rockstar coder "wrapping your head around" any reasonable syntax should be a triviality.