Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The rise and rise of JSON (2017)

twobithistory.org

Post reply on HN
Print view View original

81–90 of 107 posts

Re: The rise and rise of JSON (2017)

#81

Post by chriswarbo »

jcelerier wrote: post #61
taeric wrote: post #4

Earlier quoted context omitted.

You would have loved s-expressions in a typical lisp setup, then. :) And you have also obviously never fallen victim to slightly off spec JSON parsers and folks that took advantage of them. Trailing commas? Definitely useful. Until they break a system. (Oddly, I have been stricken lately by how much people hate the extra parens of lisp, but nobody bats an eye at the pointless commas of every other language...)

> (Oddly, I have been stricken lately by how much people hate the extra parens of lisp, but nobody bats an eye at the pointless commas of every other language...) I just checked an a comma is a grand total of three filled pixels on my coding font in my screen while a parenthese is 12 pixels. Parentheses are freakin visual bloat. Just look at this : https://i.imgur.com/UTGjbI5.png

I think that's a poor reason to choose a concrete syntax, and if it really bothers you it's easy enough to have your machine display them however you want.

For example, I use https://www.emacswiki.org/emacs/DimParentheses to make parentheses unobtrusive. I sometimes want to see them if they're at my cursor position, so I use https://www.emacswiki.org/emacs/ShowParenMode to highlight that one and its corresponding opener/closer. I use https://www.emacswiki.org/emacs/ParEdit to automatically keep parens/quotes/etc. balanced, move around whole subexpressions, etc. I'm sure there are similar tools for different editors (e.g. there's an incomplete list at https://github.com/shaunlebron/history-of-lisp-parens/blob/m... )

There's a screenshot of this setup at http://chriswarbo.net/blog/2017-08-29-s_expressions.html

Re: The rise and rise of JSON (2017)

#82

Post by senozhatsky »

bouke wrote: post #78
senozhatsky wrote: post #21

Earlier quoted context omitted.

> would be nice to have a tool that could translate xml schema to json schema and back. Hmm, after a quick search I found a bunch of json-to-xml and xml-to-json converters, including libraries. E.g. JSON-Java library [0]. May be same things exist for .Net. Is this what you meant? [0] https://github.com/stleary/JSON-java -ss

I think parent was talking about the document definition (schema) instead. So not to rely on the document instance for the translation definition.

Ah, got it. Thanks. I wasn't entirely sure, admittely not a very experienced json user. Does term "schema" apply to json in the same way it applies to XML?

/* Well... so... One can convert JSON to XML and apply XML schema verification. That's partly a joke :) */

-ss

Re: The rise and rise of JSON (2017)

#83

Post by vorg »

rhencke wrote: post #80
gaius wrote: post #44

Earlier quoted context omitted.

Ah, Groovy. All the brevity of Java and all the type safety of JavaScript. I had no idea anyone still used it, let alone loved it!

That's an unfortunate stance on Groovy. Groovy code is often far more brief than Java's, and it has some beautifully expressive capability for making DSLs, both through its world-view on closures and its ability for the developer to walk and modify the AST at compile time (see, for example, the @Canonical attribute for how this can be useful) While I, too, wish it built on a statically typed base, Groovy offers ameni…

If you need to use the JVM ...

> walk and modify the AST at compile time

Clojure is best for this. A macro only a few lines long in Clojure will do the same as what a few hundred lines in Apache Groovy are required for. It's possible to walk the AST in Groovy but it's verbose and messy.

> CompileStatic that go a long way

Both Kotlin and Scala are both statically typed from the ground up, instead of having a @CompileStatic annotation tacked on later.

> the brevity and expressiveness of Groovy

Groovy started off in 2003 as a functionally similar clone of Beanshell, which had already existed since 1999, but with closures added. Someone then translated all the standard functional methods from Ruby into Groovy's codebase. Of course, Jython, a JVM version of Python, has been around since 1997. So Groovy is a relative late comer to the JVM in this regard.

Groovy tried to be a bit of everything for everyone on the JVM, but has ended up being used only for 20-line build scripts in Gradle.

Re: The rise and rise of JSON (2017)

#85

Post by amaccuish »

I feel like the best takeaway here is that XML is a document format, and JSON is for programmatic interchange, e.g. APIs. That's at least how I operate, and I use both XML and JSON for various things. My APIs are all JSON, but if I'm serialising some data to disk, or for export etc, it's usually XML.

Re: The rise and rise of JSON (2017)

#86

Post by ktpsns »

One aspect about JSON is the lack of comments. This makes it mostly unsuitable as a configuration language and in fact simple "JSON for humans" such as https://hjson.org/ and https://json5.org/ exist. In my opinion, this is a design flaw and if JSON would be a bit more human-oriented, it could be much more widespread in non-web contexts.

Re: The rise and rise of JSON (2017)

#87

Post by dragonwriter »

asavinov wrote: post #53
dragonwriter wrote: post #50

Earlier quoted context omitted.

Pretty much any time I've seen something like this, relevant inner element of the book is: ... ...

It is again a workaround because is a member of a collection - it is not a tuple attribute. Which suggests that we cannot enforce this separation and an application has to understand itself which element is an object property and which element is a member of a collection.

> It is again a workaround because is a member of a collection - it is not a tuple attribute.

Its an element not an attribute, but the set of elements and the set of attributes are both collections.

> Which suggests that we cannot enforce this separation and an application has to understand itself which element is an object property and which element is a member of a collection

It's true that that is not part of bare XML and the nature of attributes vs. elements, even though you want to impose it there.

OTOH to the extent that those words correspond to a well-rounded semantic distinction, it is arguably captured in schema languages, and not mere application-level knowledge.

Re: The rise and rise of JSON (2017)

#88

Post by fenwick67 »

ktpsns wrote: post #86

One aspect about JSON is the lack of comments. This makes it mostly unsuitable as a configuration language and in fact simple "JSON for humans" such as https://hjson.org/ and https://json5.org/ exist. In my opinion, this is a design flaw and if JSON would be a bit more human-oriented, it could be much more widespread in non-web contexts.

I actually like that JSON has no comments.

With comments in a data transmission format you will end up with things like "conditional comments" in IE.

I agree there are certainly many better configuration languages.

Re: The rise and rise of JSON (2017)

#89

Post by mixedCase »

seanwilson wrote: post #28
ToFab123 wrote: post #15

So, when do we get a typescript for JSON? You mean a schema like XML has? It looks like typesafe programming languages are on the rise, yet, when it comes to the format used for data exchange we go from typesafe to unstructured. I find that odd.

You've got a point. I really like TypeScript but I haven't found a nice way yet to process the results of APIs that return JSON in a type safe manner. I'm surprised there isn't a standard way to do this yet.

Check out io-ts.

Re: The rise and rise of JSON (2017)

#90

Post by rurban »

ktpsns wrote: post #86

One aspect about JSON is the lack of comments. This makes it mostly unsuitable as a configuration language and in fact simple "JSON for humans" such as https://hjson.org/ and https://json5.org/ exist. In my opinion, this is a design flaw and if JSON would be a bit more human-oriented, it could be much more widespread in non-web contexts.

It is not design flaw, it was a conscious decision to enhance security. JSON is still the only secure (and fast) generic transport protocol, all others but msgpack are insecure by design. The various attempts to "enhance" json with types, datetime, comments, ... just make it worse, don't fall into that trap.

The latest JSON changes also made it more insecure, while they didn't clarify the missing spec points, so even they fell into that trap. msgpack is more also a bit insecure than JSON, but not as dramatic as XML, YAML, BSON, ...

Post reply on HN