TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Hjson, the Human JSON

50 点作者 chris-at超过 10 年前

24 条评论

coreymgilmore超过 10 年前
The point of JSON is to have a standard way for data-interchange. Adding the complexity of &quot;sometimes you might have quotes, sometimes not&quot; and &quot;you can display multi-line strings in different ways&quot; gets away from this.<p>JSON is great already. I don&#x27;t really see this as necessary. I could understand the comments (but use &#x2F;&#x2F; instead of # as per Javascript comments) to increase clarity to people who don&#x27;t know the original design syntax. But the others do not seem really useful.
评论 #8432986 未加载
评论 #8433389 未加载
pdw超过 10 年前
Well, that completely misses the point of JSON: simple and unambiguous syntax.<p>If you want something that&#x27;s easier to edit for config files, you can use YAML.
评论 #8432870 未加载
评论 #8432893 未加载
评论 #8433093 未加载
评论 #8433782 未加载
评论 #8432871 未加载
评论 #8433106 未加载
danso超过 10 年前
All of these ideas are good (from a consumer perspective, it&#x27;s too early in the morning to think about implementation issues)...but I have to ask out loud what I frequently just think...why don&#x27;t we just start adopting YAML more? Or, at least, a subset of the &quot;safe&quot; kind of YAML, mostly restricted to what JSON can do?
评论 #8433055 未加载
评论 #8432811 未加载
评论 #8433246 未加载
评论 #8432804 未加载
drobilla超过 10 年前
I will never understand the tendency, especially in the web community, to consider complicated, ambiguous, inconsistent, and difficult to parse syntaxes as &quot;friendly&quot;.<p>It might seem like a good idea at first, but over time it just results in a culture that publishes horrifically broken markup, and increasingly baroque implementations that try to work around every possible screw-up instead of simply flagging errors. This is, in my opinion, the biggest screw-up of the web: if early browsers simply flagged errors and pointed out where and what they are clearly, the web would be a much nicer place. Instead, actually writing a parser for web markup is a nearly impossible task, and not the weekend hack it should be.<p>One of the, if not the, great thing(s) about JSON is its beautifully simple syntax. 5 images on json.org precisely explain what it is, and that&#x27;s that. You can write a parser for it in basically any language without any fancy libraries or frameworks in a few hours. That is a good thing, regardless of whether you personally would ever have to do such a thing, because it keeps the barrier of entry low and trickles through the ecosystem in positive ways.<p>Missing the point of JSON? Yes, but missing much more, including lessons that should have been learned.<p>That said, a few of the ideas are good ones (comments and such), but the bad ones (making crucial delimiters optional) are so bad they more than outweigh the benefits.
kator超过 10 年前
Seems like a construed attempt to make JSON easier for &quot;humans&quot; (whatever those are) but in general JSON isn&#x27;t something my mom worries about. I&#x27;m not sure why something like a simplified YAML couldn&#x27;t be used for the intended use cases.<p>I&#x27;ve been doing a lot of ansible work recently and YAML feels fairly reasonable and I can show it to my wife and she &quot;gets&quot; what is happening.<p>Sorry just reminds me of: <a href="http://xkcd.com/927/" rel="nofollow">http:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;</a><p>Maybe we need a HN bot that links that automatically?
draegtun超过 10 年前
The more you try and push JSON along these lines the more it ends up looking like Rebol.<p>Here are the examples in Rebol:<p><pre><code> [ ; comments ;; specify rate in requests&#x2F;second rate: 1000 ; quoting key: &#x27;value text: &quot;Look ma, some quotes!&quot; ; path &amp; HTML path: %\c\windows inject: &lt;div class=&quot;important&quot;&gt;&lt;&#x2F;div&gt; ; no need for escapes space: %\c\windows\foo%20bar.txt space2: %&quot;\c\windows\foo bar.txt&quot; ; no commas one: 1 two: 2 ; multiline string haiku: { Line 1 Line 2 Line 3 } ; array&#x2F;list&#x2F;block fav-numbers: [1 2 3 6 42] ; and finally... name: &#x27;hjson desc: &quot;Rebol data format&quot; main: %.&#x2F;lib&#x2F;rebol.reb version: 1.0.1 tags: [ json hjson rebol ] ; and really finally... light-switch: on useful: yes boolean: true co-ords: 10x100 ip: 192.168.100.1 date: 1-Jan-1970 ] </code></pre> Of course this shouldn&#x27;t be a surprise because Douglas Crockford cites Rebol as an influence on JSON.<p>For those interested have a look at REN (REadable Notation), a subset&#x2F;dialect of Rebol, which is an attempt to produce a <i>standardised</i> format - <a href="https://github.com/humanistic/REN" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;humanistic&#x2F;REN</a>
bsimpson超过 10 年前
It would be nice if JSON accepted comments and Python&#x2F;ES5 have proven the developer ergonomics of trailing commas, but I&#x27;m not convinced the rest of these are improvements.
评论 #8432827 未加载
zimbatm超过 10 年前
Selfish plug, here&#x27;s another JSON derivative that&#x27;s optimised for single-line representations like log lines: <a href="https://github.com/zimbatm/lines" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;zimbatm&#x2F;lines</a><p>Ping me if you want to help out.
评论 #8433118 未加载
dkyc超过 10 年前
JSON is great. Please don&#x27;t change JSON.
评论 #8433095 未加载
thom_nic超过 10 年前
Comments are nice when your JSON is at-rest (e.g. in a file) but more often than not it&#x27;s in-flight and my code is probably not adding comments when building a message.<p>Come to think of it, what would an API look like that <i>writes</i> HJSON? Not pretty, probably.<p>I like the unquoted strings and trailing comma, but the rest I don&#x27;t think is unnecessary. I&#x27;d be happy with the standard ECMAScript map literal format.
评论 #8433214 未加载
donpdonp超过 10 年前
The &#x27;next JSON&#x27; should be EDN. It addresses the shortcomings suggested by hjson and more. It has comments, all commas are gone, it has symbols (aka light-weight strings), it has built-in support for time and uuid objects.<p><a href="https://github.com/edn-format/edn" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;edn-format&#x2F;edn</a>
daigoba66超过 10 年前
Why do our machine data formats (JSON, XML, etc) need to be more human friendly? I don&#x27;t build business processes that involve a human reading and manipulating JSON or XML.<p>I don&#x27;t choose a data format for readability. In fact I think that&#x27;s one of the least important factors. I choose JSON when the producer or consumer is JavaScript code. That&#x27;s pretty much the only reason, I think, to pick JSON over XML or anything else.<p>Also, both JSON and XML are terrible for config file intended to be manually edited.
评论 #8433063 未加载
dfkf超过 10 年前
Handling of strings is way too complex for very little gain, but the rest - trailing commas, comments and no quotes for alphanumeric keys - are actually quite useful. They complicate syntax only a little, yet make writing JSON by hand much nicer. These small additions merely take us back to Javascript object initialization syntax, straitjacketed version of which Crockford called JSON.
jgillich超过 10 年前
Something similar I&#x27;ve used in the past is cson [1]. It is like JSON but in CoffeeScript, which allows comments and multi-line strings as well.<p>[1]: <a href="https://github.com/bevry/cson" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bevry&#x2F;cson</a>
njs12345超过 10 年前
Typesafe have something similar, HOCON: <a href="https://github.com/typesafehub/config/blob/master/HOCON.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;typesafehub&#x2F;config&#x2F;blob&#x2F;master&#x2F;HOCON.md</a>
mst超过 10 年前
Having an ultra-relaxed JSON for config files is an excellent idea; ingy and I called our take on it JSONY - see <a href="http://p3rl.org/JSONY" rel="nofollow">http:&#x2F;&#x2F;p3rl.org&#x2F;JSONY</a> for some examples.
garrison超过 10 年前
I see many mentions of YAML in the comments, but why not TOML? (<a href="https://github.com/toml-lang/toml" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;toml-lang&#x2F;toml</a>)
评论 #8433065 未加载
Maken超过 10 年前
I fail too see how this is a improvement over YAML.
jcromartie超过 10 年前
So basically YAML?
harel超过 10 年前
Sorry, was there a problem with JSON that I wasn&#x27;t aware of? Oh, you mean, the problem of following the spec or not paying attention. Ok, in that case I see high adoption rates for this. Or, we can just make sure we do follow the spec and pay attention to what we&#x27;re doing and stick with what works and is practically an industry standard.
评论 #8433157 未加载
drivingmenuts超过 10 年前
<a href="http://xkcd.com/927/" rel="nofollow">http:&#x2F;&#x2F;xkcd.com&#x2F;927&#x2F;</a>
rbobby超过 10 年前
No support for dates... which I think is the most glaring problem with JSON.
mattybrennan超过 10 年前
ew
iLoch超过 10 年前
<a href="http://xkcd.com/927" rel="nofollow">http:&#x2F;&#x2F;xkcd.com&#x2F;927</a><p>Cut it out. JSON is fine.