3 ms·

I'm using JSON all the time, but it's hardly the be-all/end-all solution for even the basic use case of service payload serialization, let alone config file syn

I'm using JSON all the time, but it's hardly the be-all/end-all solution for even the basic use case of service payload serialization, let alone config file syntax or document syntax. To begin with, JSON lacks types for URLs, dates/times, and spatial data; it also lacks conventions for error messages and data graphs other than trees, etc. So I think Java not integrating JSON literals at the language level or some such actually is a plus.

hajile 9y ago
I think that lack is a strength. Lists, Maps, Booleans, Numbers, Strings. With these powers combined, you can create basically anything you can think of. Dates can be unix timestamps or ISO strings which are universal. Spatial data is a compound datatype anyway (plus, there are quite a few data representations depending on number of dimensions, cartesian vs polar, etc). The one datatype that JS could potentially benefit from is a byte array type, but even that can be accomplished with base64 "strings" or Lists of numbers. To me, it's much better to let every company send error messages in the format that makes sense to them rather than having the One True Error that doesn't quite work for anyone. My biggest complaints about JSON are syntactic. Optional comments, multi-line strings, and trailing commas would do wonders for day-to-day readability without significantly bloating the specs.
- tannhaeuser 9y ago
  Agree with your points regarding comments and multi-line strings; don't like optional commas, though. With respect to your "lack is strength" argument, I can't help but find this unconvincing. We all know JSON is derived from JavaScript object/array literal syntax; your argument is akin to retro-fitting the requirements for service payload serialization to the suboptimal de-facto situation with JSON.

3 ms·

I'm using JSON all the time, but it's hardly the be-all/end-all solution for even the basic use case of service payload serialization, let alone config file syn

by tannhaeuser 9y ago

hajile 9y ago
I think that lack is a strength. Lists, Maps, Booleans, Numbers, Strings. With these powers combined, you can create basically anything you can think of. Dates can be unix timestamps or ISO strings which are universal. Spatial data is a compound datatype anyway (plus, there are quite a few data representations depending on number of dimensions, cartesian vs polar, etc). The one datatype that JS could potentially benefit from is a byte array type, but even that can be accomplished with base64 "strings" or Lists of numbers. To me, it's much better to let every company send error messages in the format that makes sense to them rather than having the One True Error that doesn't quite work for anyone. My biggest complaints about JSON are syntactic. Optional comments, multi-line strings, and trailing commas would do wonders for day-to-day readability without significantly bloating the specs.
- tannhaeuser 9y ago
  Agree with your points regarding comments and multi-line strings; don't like optional commas, though. With respect to your "lack is strength" argument, I can't help but find this unconvincing. We all know JSON is derived from JavaScript object/array literal syntax; your argument is akin to retro-fitting the requirements for service payload serialization to the suboptimal de-facto situation with JSON.