31 ms·
Hjson, the Human JSON
- nikolay 10y agoJSON5 [0] is better as unlike Hjson, it doesn't include non-ECMASCript syntax. [0]: http://json5.org/ http://json5.org/
- kstenerud 10y agoWhy do you need ECMAScript syntax? It's not like you're going to directly feed a json file into a JS interpreter. Well, not unless you have a death wish.
- lucideer 10y agoBecause it's a syntax that needs no extra explanation. It's not a superset, so no extra add-on features need extra doc, and it's less of a subset then JSON so the rules of what's disallowed are much simpler.
- emodendroket 10y agoAnd yet again no date format. Am I the only person who is ever inconvenienced by this? It seems like it's so obviously the most glaring flaw with JSON that I'm surprised nobody wants to fix it.
- rhinoceraptor 10y agoJust use ISO 8601?
- emodendroket 10y agoSure, that would be fine. They could also use a totally wacky format, I don't care. The problem is that without a standard the JSON tools in different languages don't all agree on how to serialize dates and you end up needing to deserialize/serialize manually the smooth over the differences. The problem isn't that you can't represent dates; it's that there is no standard way to do it.
- _kst_ 10y ago> The problem isn't that you can't represent dates; it's that there is no standard way to do it. ISO 8601?
- eknkc 10y agoThat is a string. Not date.
- emodendroket 10y agoThat's not "standard." That's one of many ways that people represent dates in JSON, because the JSON specification itself does not mandate that you use any particular representation. If you use it there is no guarantee it will be recognized as a date on the other end.
- Kapow 10y agoWhat black hole are you sending JSON into where the only way they could know something is a date is if you use a date type? Why can't that be part of the data structure you agreed upon in order to communicate in the first place?
- eknkc 10y agoEven if there is an agreed on schema, parsers can generate native Date objects on the recipient if there is a date type. When you deserialize a nested graph of objects, it's hard to convert each date to an actual date if what you get is just a string. Makes it a lot easier during integration.
- emodendroket 10y agoWhy am I hand-writing code to supplement the parser? I mean, hell, we don't need JSON at all, why don't I just invent my own serialization format and write parsers for it in each environment I want to use it in.
- duaneb 10y ago
- Zardoz84 10y agoSDLang have support for date formats.
- emodendroket 10y agoCool. Never used D and that's the first I've heard about it but I have respect for any system that handles this problem. :)
- kennell 10y agoIt has always bothered me that the JSON standard does not allow for comments. Especially when you want to annotate some sample response/request.
- creshal 10y agoIt's an oversight, but does it really matter anywhere? YAML can be used for a JSON-y syntax that allows comments, which is good enough for most use cases.
- wnevets 10y agoIIRC douglas crockford purposely didn't include comments
- daxelrod 10y agoThey were explicitly removed: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG... HN discussion: https://news.ycombinator.com/item?id=3912149 https://news.ycombinator.com/item?id=3912149
- wnevets 10y agoSo definitely a thought out and purposeful decision, thanks for the links.
- deleted 10y ago[deleted]
- rrauenza 10y ago...and the lack of trailing commas.
- andreynering 10y agoIt's just a hack, but you can write a comment in a key that is supposed to be ignored: { "__comment": "The following config does...", "key": "value" } But I agree that it is not much intuitive.
- creshal 10y agoWhat's the difference to / advantage over YAML? When I want a loose syntax "JSON with comments", I can just use that instead.
- burke 10y ago> YAML expresses structure through whitespace. Significant whitespace is a common source of mistakes that we shouldn't have to deal with. > Both HOCON and YAML make the mistake of implementing too many features (like anchors, sustitutions or concatenation).
- eterm 10y agoBut this too has significant whitespace, acting as a comma in separating properties. (It's not clear whether you can mix commas and whitespace here.) Also this claims to not need escapes, but it's also not clear how this format handles a comma or a newline in strings without escaping, do they act as a comma to separate properties or do they act as natural commas/newlines?
- PuerkitoBio 10y agoOnly quoteless strings have no escapes, and according to the docs the rule is: > quoteless strings include everything up to the end of the > line, excluding trailing whitespace. (edit: formatting)
- eterm 10y agoSo this { foo:one, bar:two } Parses to "one," because it is a quoteless string? What about true and false, is false the boolean constant or a unquoted string "false".
- PuerkitoBio 10y agoI posted this in another thread here, but it's documented in the linked page: > A value that is a number, true, false or null in JSON is parsed as a value. > E.g. '3' is a valid number while '3 times' is a string.
- skybrian 10y agoNice idea. A nit: making trailing whitespace significant (rather than stripping it) seems like a bug.
- simonw 10y agoJSON plus comments and python-style multi-line strings is great. The thing where you can leave quotes off strings makes me nervous, especially the example where the value is HTML with its own embedded double quotes for attribute values. Not requiring quotes on strings like that looks like an obvious vector for injection attacks. I guess Hjson isn't designed to be generated automatically, but I'd prefer a format that is easy to generate safely. What I really want is JSON plus comments plus multi-line strings plus relaxed rules on trailing commas... While maintaining as simple and unambiguous a parsing model as possible.
- jaquers 10y agoHave you looked at JSON5? http://json5.org/ http://json5.org/
- novaleaf 10y agoi've used json5 since the beginning. it's great! just a couple week ago they merged in descriptive error messages too. No more wondering where the bug is!
- paulannesley 10y agoJSON5 looks really good. I'm not sure about this one part though, from a point of view of simplicity and interoperability when deserializing the data: > Numbers can include Infinity, -Infinity, NaN, and -NaN.
- echlebek 10y agoThis is a good thing. It means there is a 1:1 mapping between numbers in JSON5 and IEEE floats.
- zyxley 10y agoStrings without quotes leads to all kinds of trouble in YAML. You end up just quoting everything anyway the first time you need to use "false" or "[some words here]" as a string.
- bryanlarsen 10y agoThis spec repeats one of the problems with using YAML as a configuration spec. To quote: "if your key includes a JSON control character like {}[],: or space, use quotes if your string starts with { or [, use quotes" JSON and YAML are interchange formats, not configuration formats. Rather than than hacking up an interchange format, it's probably better to use something designed for configuration formats, like TOML.
- Sir_Cmpwn 10y agoI think it's reasonable to call YAML a configuration format.
- stormbeta 10y agoJSON is an interchange format, but YAML is pretty obviously meant for configuration, given the huge emphasis on human readability and editing. As for TOML, it's a good replacement for mostly-flat INI-style files but the syntax is really awkward for the kinds of places you'd normally use YAML, especially nesting lists/maps.
- bryanlarsen 10y agoTop line on yaml.org: What It Is: YAML is a human friendly data serialization standard for all programming languages.
- Zardoz84 10y agoor SDLang
- al2o3cr 10y ago"Both HOCON and YAML make the mistake of implementing too many features (like anchors, sustitutions or concatenation)" YMMV, but if you're aiming for a format that's edited / maintained by humans things like YAML's anchors and substitution are exactly the features I'd want...
- brandonbloom 10y agoJust the other day I commented complaining about JSON config files without comments, but now here I am complaining about _three_ ways to write a comment. OK, I can see two ways: block and line comments. But why two ways to write line comments? Why start off a new grammar with that added complexity?
- kleiba 10y agoAdded complexity for parser implementors, but arguably more freedom for the user. (?)
- zeven7 10y agoBut why?
- kleiba 10y agoYou mean why bother having multiple ways to comment? Well, I sometimes use both C-style (/* ... */) and C++-style (// ...) comments in the same file to sort of mark the relative importance of comments. But yeah, I guess that's not strictly necessary, I could do without.
- binarycrusader 10y agoI also notice everyone seems to keep silent about the fact that comments were intentionally left out of the final JSON specification to avoid abuse by parsers/vendors.
- drawkbox 10y agoComments would be nice but it is also nice to keep JSON pure and simple. There are some other json formats that use comments like jsoncpp but really not needed. But, if comments really are needed, another easy way to have comments is have a file that rides to the side of any json files or docs. Sometimes we use a markdown/text file next file.json -> file.json.md / file.json.txt to describe overall or a file.meta.json that has comments per key. This is only needed sometimes for physical files. If json is from the server, commenting can be done there or in docs if needed.
- slantyyz 10y agoThis looks a lot like like CSON but with better comment support.
- o_____________o 10y agoCSON? - https://github.com/bevry/cson https://github.com/bevry/cson - https://github.com/groupon/cson-parser https://github.com/groupon/cson-parser
- jordache 10y agothe json spec is pretty easy to follow, even for a human coder. this is overkill imo
- jordache 10y agoIn fact, reading the doc for this takes longer than the reading the JSON spec.
- deleted 10y ago[deleted]
- ninjakeyboard 10y agoI feel like HOCON fills the space pretty well, and has implementations in most languages now. https://github.com/typesafehub/config https://github.com/typesafehub/config But I'm a scala developer so I might be biased.
- talles 10y agoI have a (big) .NET project that uses multiple libraries one of them being Akka.NET which uses HOCON. Being honest, it felt completely awkward to use it in this respect (a little corner in the project that uses that different HOCON thing).
- twic 10y agoI'm not a Scala developer, and I don't think I'd ever heard of HOCON. Has it seen much adoption outside the Scala community?
- ebbv 10y agoThis abandons a lot of principles of JSON that are there to avoid ambiguous situations. The small benefits don't seem to outweigh the snake pit you're jumping into.
- fibo 10y agoIt already exists YAML. Also cson it is worth to look at.
- rhinoceraptor 10y agoI find YAML/cson very difficult to read.
- dorfsmay 10y agoNo include :-(
- dorfsmay 10y agoIs there an include functionality I missed, or do people think config file shouldn't have includes?
- JamilD 10y agoRigidity and consistency are not always bad things. They can help prevent bugs, security vulnerabilities, and they drastically reduce complexity of implementation. JSON might often be too rigid, but I think it's important to note that "easier" (in that you don't need to learn the syntax) isn't always better.
- kstenerud 10y agoYes. There are two distinct use cases here: configuration files, and interchange formats. For an interchange format, JSON does the job very well. Small, simple, human readable, easy to implement. For a configuration format, JSON leaves a lot to be desired. It's almost there, but has enough warts to be annoying. You're not going to get a one-size-fits-all format.
- IvanK_net 10y agoThis "easier" format is actually more "complex". JSON can be described with just a couple of simple rules (http://json.org/ http://json.org/ ), while this format adds many new rules (e.g. for doing same things in multiple ways). The more rules you have, the more things you have to remember, the harder it is to find the reason of the problem. BTW. it is very simple to do comments in JSON :) You can just add "comment1" : "This is my comment", to any object, it will be ignored by software that processes your file.
- mort96 10y agoI kind of like doing comments like this: "#": " my comment"
- ZenPsycho 10y agothe problem with that one is that some parsers have a meltdown if they encounter duplicate keys. sigh
- abraae 10y agoHa ha, I do exactly the same thing. Lack of comments is really the only beef I have with Json (well, no multi line text too I suppose). A new spec that just addressed those alone would be great.
- zbjornson 10y agoOy, someone loves yaml... I'm quite happy using a preprocessor like [0], which keeps the great simplicity of JSON and just allows comments. [0] https://www.npmjs.com/package/strip-json-comments https://www.npmjs.com/package/strip-json-comments
- creshal 10y ago> Oy, someone loves yaml... I don't, actually, I use preprocessors too¹, but since they're not always an option, I'd rather recommend yaml than have yet another pointless config file language needlessly fragment the market. ¹: Thankfully it's rather trivial in python: https://github.com/creshal/yspave/blob/master/yspave/pave.py#L33 https://github.com/creshal/yspave/blob/master/yspave/pave.py...
- amelius 10y agoIs "undefined" part of json? Imho it should be.
- svachalek 10y agoIf the key is not present, the value is "undefined" in JS. "null" is a supported value in JSON, to explicitly mark something as nonexistent. For me the biggest problem with JSON is lack of full floating point support, i.e. NaN, +-Infinity, -0.
- amelius 10y agoYou can stringify an object containing a property with an undefined value. Imho, parsing that back should give exactly the same data structure.
- xaduha 10y agoStandards are better when they are followed. Chicken and egg problem, these alternatives are DOA because they are not going to be popular. The only reason JSON is popular is because of Javascript. And the only reason Javascript is popular is because of the browsers and their history.
- aeturnum 10y agoThis looks pretty great. We've been looking for a replacement configuration format over our ancient ini files and had rejected JSON for TOML because TOML allows comments (and man, can comments be useful in configuration files). This looks like a nice medium-long term alternative.
- overcast 10y agoHonestly, I thought JSON was already very human readable/writable.
- rymohr 10y agoJSON is very readable/writable... to programmers. Most humans aren't programmers though. If you showed JSON to someone on the street they could probably understand the gist of it (if pretty printed). Good luck asking them to write it.
- overcast 10y agoI'll agree with that, but what is the use case for giving this to non-developers? Everything on this page looks like it's directed towards making JSON files slightly simpler for programmers.
- rymohr 10y agoI was referring to your comment about JSON in general. See my earlier comment [1] for more background. [1]: https://news.ycombinator.com/item?id=11501332 https://news.ycombinator.com/item?id=11501332
- orcasauce 10y agoYour argument is a layman can't puzzle out JSON easily, but do you think hjson is any better? Syntactically it's core seems to just be QOL improvements over writing JSON by hand. It isn't any more intuitive from my perspective. In fact, in many cases it seems less intuitive by offering a greater number of ways to do the same thing.
- rymohr 10y agoI agree completely. If you're going for human, you need to go a lot further (which is what I've tried to do with HONEY [1]). [1]: https://github.com/honey/honey https://github.com/honey/honey
- emodendroket 10y agoI'm not using a nonstandard JSON extension unless it implements a standard freaking date format. I also don't think bare strings are necessarily a great idea since they lose implicit type information.
- joeld42 10y ago- Someone saves data as text with a simple format - It works great, lots of people start using it - People start adding features to fix annoying things with the format, add support for binary data, comments, schemas, add more metadata etc.. - Many versions proliferate, people start writing converters and verifiers - A standards committee is formed and write an 800 page spec and 80kloc reference implementation - Eighteen different libraries wrap or reimplement the reference implementation - Someone gets fed up with this nonsense and converts their app to save their data in a new simple text format. - The circle of life continues. I love this idea and wish json had comments, too, but if you start hitting the point where JSON is not expressive or fluid enough, that's a hint that it's probably not the right thing for what you're doing. This variant puts a lot of work into human-friendly json, but if you're doing a lot of hand-editing of a file, it should probably not be JSON.
- Animats 10y agoAgreed. Do not want "relaxed JSON". There are editors for valid JSON. Use one of those.[1] [1] http://www.cleancss.com/json-editor/ http://www.cleancss.com/json-editor/
- streblo 10y agoObligatory: https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...
- cwyers 10y ago> Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser. And now you can't roundtrip the comments if for some reason your JSON parser needs to change something.
- dclowd9901 10y agoI would prefer not to inspect json for comments. Something is ambiguous, you should have a model definition sent along with everything else.
- joelthelion 10y agoThis is overkill, but someone PLEASE add comments to the next iteration of the json spec.
- Gedrovits 10y agoCongratulations, you've created something YAML-like, non-safe data structure.
- rymohr 10y agoHONEY was my take at the same problem. Still brainstorming on this one and not used in production yet. https://github.com/honey/honey https://github.com/honey/honey
- mtalantikite 10y agoCan someone explain why people want to use a data-interchange format like JSON for configuration files, rather than using a configuration file format like TOML? I've never understood why people want to use JSON for config files.
- querulous 10y agopretty much everything under the sun can encode and decode json, often as part of the stdlib toml requires you track down a toml parser, at the very least
- mtalantikite 10y agoYeah, that's fair. I've alway found json as a config format cumbersome though (like in Packer) and there are plenty of TOML parsers out there (https://github.com/toml-lang/toml#v040-compliant https://github.com/toml-lang/toml#v040-compliant). Maybe that's an argument for languages to start adding some configuration format other than XML into their standard libs.
- stormbeta 10y agoI agree about JSON, but I can't say I understand the logic behind TOML. I know it's supposed to be a config format, but it only seems to make any sense for INI-like configs that are little more than a flat key-value map. The places I see people using JSON/YAML/etc for config are much more likely to have nested structures that would be extremely awkward to represent in TOML. I think YAML was on the right track, and if you ignore the messier parts of the spec it works pretty well.
- mtalantikite 10y agoI was mainly using TOML as an example of a config format in contrast to JSON, I wouldn't say it's definitely the answer. Nesting is possible with TOML, but I'd agree that it could get pretty awkward depending on your needs: https://github.com/toml-lang/toml#array-of-tables https://github.com/toml-lang/toml#array-of-tables for example. I personally don't mind YAML all that much either, although the spec is pretty large.
- asb 10y agoAlso in this space, Jsonnet is well worth a look http://jsonnet.org/ http://jsonnet.org/
- wstrange 10y ago+1 jsonnet gives all the benefits of hjson - but also provides more powerful templating features
- sickbeard 10y agoI don't understand. doesn't commenting ruin the whole point of a human readable format? If you have to add comments, it means you need to communicate something that can be done in more concise way.
- baq 10y agowhat? comments are the most important factor of 'human-readability' by far. without them you can't e.g. explain what a particular key does, what is it's default value (if any), or perhaps the most important thing - you can't even put a link to the documation!
- sickbeard 10y agowhat does 'human-readability' mean? JSON is data-transmission format that is human readable.. which is why it happens to be more popular than XML (or SOAP) because you can read the data and see the data. It's not meant to transmit context (i.e. it's useless and that's what documentation is for).
- teen 10y agoIt's almost as if you're reinventing protobufs. XD
- teen 10y agoIt's almost as if you're reinventing protobufs. XD
- wwwtyro 10y agoI've used with great results in my procedural planet generator[1]. It's very forgiving, so made writing a "UI" with lots of complicated controls very easy for me. [1] http://wwwtyro.github.io/planet-3d/ http://wwwtyro.github.io/planet-3d/
- baq 10y agonice little project you've got there :)
- throwaway2093 10y agoWorst name ever. I'm not even joking... Perhaps it would be less offensive if the last three letters didn't spell the word "SON." This seems pedantic, I agree, but thus is the world we live in... Might I suggest "Human Readable JSON."
- bshimmin 10y agoI must be having a stupid day - what is offensive about this name?
- J_Darnley 10y agoI think it must be playing off the complaints about the Brotli compression algorithm using "bro" as a file extension. "Bro" and in this case "son" implying some sort of patriarchal dominance over computing. In short: a joke.
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- blueadept111 10y agoThe Jaunt JSON parser (Java) was my solution to this problem. It can handle arbitrarily dirty data, including missing quotes or using semicolons instead of quotes, missing quotes, etc. http://jaunt-api.com http://jaunt-api.com
- rhapsodic 10y agoLooks like a solution in search of problem, to me. JSON is designed to be machine-readable, and to the extent that I actually need to human-read JSON, which is not that much, I don't find it all that difficult.
- deleted 10y ago[deleted]
- dukoid 10y agoThere is also HUTN already: https://epsilonblog.wordpress.com/2008/09/15/new-in-hutn-071/ https://epsilonblog.wordpress.com/2008/09/15/new-in-hutn-071...
- cammil 10y ago"less mistakes" -> "fewer mistakes"
- OJFord 10y ago> , less mistakes, Does someone have a rather subtle sense of humour, or is that a genuine mistake?! (fewer*)
- jaybuff 10y agoAh, yes, the trailing comma in a list, which I like to refer to as the "Silicon Valley Comma" [ "a", "b", "c", ] // the silicon valley comma
- Retra 10y agoOf course it looks ugly if you list things horizontally... :)
- function_seven 10y agoIf that's the Silicon Valley Comma, what do you call this? [ "an , "array" , "of" , "things" ] Because I have an irrational hatred of that style. (Yes, I know the purported benefits when diffing files, I don't care :P)
- cheapsteak 10y agoThat's not as good as the SVC because you'll still get unnecessary diffs when prepending to the list SVC allows you to both prepend and append without adding extra diffs
- Mikhail_Edoshin 10y agoIt's a nice thing to have when you generate JSON programmatically :)
- ant6n 10y ago"Trailing commas are ignored." This is the most important :p
- kbenson 10y agoThis feels like a project that had a core idea that was good and justifiable (we'll take some of the common JSON mistakes such as extra commas and most asked for features sub as comments) and then felt the need to keep throwing in features to justify its existence, and now it's lost sight of its original goal. This can't even be parsed natively by major JavaScript implementations, so is it really JSON at all? Actually, I think that's the root of my complaints, that it's associating itself with JSON while clearly diverging from what was important originally in JSON. At this point it's just some incompatible format leveraging the JSON name. I think most my criticisms would be ameliorated if it was just some other JSON-similar format with a different name.
- educar 10y agoPossible bug: duplicate keys are not flagged as errors (in the demo atleast)
- tacone 10y agoTo be honest: relaxed formats usually bring a lot of glitches to keep in mind. It's probably easier to use stricter specifications. Take YAML, it looks pretty natural at first sight, but has a virtually infinite list of gotchas.
- crdoconnor 10y ago>has a virtually infinite list of gotchas. That's why I wrote this: https://github.com/crdoconnor/dumbyaml https://github.com/crdoconnor/dumbyaml YAML is far better with explicit typing and flow style, tag tokens and node anchors/references removed.
- DominoTree 10y ago"Helps reduce errors" - you're really trading errors for other errors - your behavior is now more ambiguous with more edge cases, but look, you don't have to place quotes around strings! (except when you still do)
- msane 10y agoSeems like it would be slower to deserialize.
- RangerScience 10y agoHi! I like what you've made. I have been working on something similar, although the Github is massively out of date and was never complete to begin with: https://github.com/narfanator/YAMLite https://github.com/narfanator/YAMLite (Also, I'm renaming it nowish on the up-to-date version). This parser handles YAML, JSON and XML. Interestingly, many of the features HJSON has, this has, by virtue of it being easier to implement during the parsing stage. The part I'd draw your attention to - and the part that I think warrants the most discussion - is the resulting data structure. I mostly can't tell what the structure is of the HJSON C# object - it looks like it does most of what I wanted to change about the existing C# JSON parsers, but maybe not all?
- partycoder 10y agoJSON parsers are not really slow. JSON is simple enough that allows multiple implementations for parsers and easy adoption. But HJSON additions have some serialization cost overhead. Because of this eventually you will need to convert your HJSON to JSON prior to deploying, and that would make things slower. You will be dealing with 2 formats instead of one. Then, do you really believe that adding all this syntactic "features" (overhead) will make it less error prone? It will make it more error prone because it has more things to consider!
- true_religion 10y agoIt's supposed to be used for config files like package.json and friends in the javascript world. It's going to be parsed essentially once---startup.
- partycoder 10y agoIn that regard I prefer HOCON.
- stock_toaster 10y agoThere is also libucl[1] which is kind of json like. FreeBSD is apparently starting to use of it for a few things. [1]: https://github.com/vstakhov/libucl https://github.com/vstakhov/libucl
- cyphar 10y agoI thought it looked cool when they said "nginx-like". But then I remembered that nginx has annoying string semantics and converts things to arrays in odd circumstances.
- dasmith91 10y agoSo it's YAML with all the cruft of JSON thrown back in?
- rurban 10y agoNope, just a readable JSON. YAML does much more, for many too much.
- curryhowardiso 10y agoSoon: Situation: there are 15 competing standards.[1] [1]: https://xkcd.com/927/ https://xkcd.com/927/
- herpityderp 10y agoThis looks cool, but their characterization of YAML is disingenuous YAML expresses structure through whitespace. Significant whitespace is a common source of mistakes that we shouldn't have to deal with. since every code editor ever used will take care of this for you.
- Ericson2314 10y agoGrammars people! If you don't provide it / promote it, I assume your "nice simple thing" is neither obvious nor thought-through. Sorry. Help me with my list of trendy things that took or are taking way to long to get a grammar: docopt, semver...
- drewm1980 10y agoShouldn't we keep our format specs simple and strict, and relegate aesthetic, and typo-correction stuff to the editor? i.e. something with aspects of clang-format (which tries hard not to change the meaning of your code even if it's broken), and the aggressive autocorrection necessary to make typing on a touchscreen work? I suppose there are converters from this to json, though, so maybe this is just a better specified way of converting keypresses from monkeys into something with well defined structure...
- joejev 10y agoso in this language these all do the same thing: abc "abc" abc, "abc", How does increasing the scope simplify things? Defining correct as "crashing less often" is a really bad idea, data formats _should_ be strict.
- pekk 10y agoYAML's problem is not "significant whitespace" which really isn't a major cause of mistakes.
- Zardoz84 10y agoAnd i should remember SDLang that now have a few years and reference implementations on Java, C# and Dlang . I don't see why we need reinvent the wheel again and again... https://github.com/Abscissa/SDLang-D/wiki/Language-Guide https://github.com/Abscissa/SDLang-D/wiki/Language-Guide
- jbergstroem 10y agoJust wanted to bring libucl into the game in case you are exploring json-like syntax: https://github.com/vstakhov/libucl#improvements-to-the-json-notation https://github.com/vstakhov/libucl#improvements-to-the-json-... In my eyes pretty much the perfect configuration library and syntax. Nginx-alike, number suffixes (1min, 2gb, ..), macros, variables, includes with priority, etc. Boom! Problem solved.
- liotier 10y ago> Let's make quotes for strings optional as well. This will end in tears.
- draegtun 10y agoHere's a previous HN discussion on Hjson - https://news.ycombinator.com/item?id=8432678 https://news.ycombinator.com/item?id=8432678
- Murk 10y agoComments, readability plus typabiliy where one of the main reasons I recently chose YAML for a configuration file. It seems YAML is a bit unloved these days, perhaps because it is more difficult to parse fully. YAML references also proved useful in my use case.
- anthay 10y agoOff topic, but related: I made a simple data-serialisation file format based on S-expressions, which may be of interest to some: http://loonfile.info/ http://loonfile.info/
- b34r 10y agoI'd rather just use YAML.
- rurban 10y agoYAML is insecure by default, JSON secure by default. There are not many secure transportation formats, JSON being one of the few. And JSON can be parsed much faster and easier than YAML, with its types, cyclic references and classes.
- roosterjm2k2 10y agoWhere is this drive to create dumb languages coming from? I dont mean dumb in the opinionated way, i mean, dumb in the way of "its hard to write proper code that follows rules, quoting and commas are hard" ... ... ... if quotes, commas and escaping is hard for you, you dont need to be an engineer....
- pas256 10y agoJSON for humans is called yaml.
- paulddraper 10y ago> Significant whitespace is a common source of mistakes that we shouldn't have to deal with. ...except you just made it significant. This is JSON. {"a":1,"b":2,"c":3} This is Hjson after applying the mods: {a:1b:2c:3} ....oh, it turns out Hjson actually does have significant whitespace.
- erez 10y agoHuman-readable json would've been a great idea, if it wasn't for the fact that json was NOT MEANT TO BE HUMAN READABLE. It is meant to be generated by a machine and not created by hand, neither it should be readable by humans, only parse-able by a computer. Treating your data interchange/serialization/configuration/markup formats as languages that should be human readable/writable is a cardinal sin of any person or company that engages in such practices.