Complainers in this thread might take a look at YAML
A modest proposal
51–60 of 189 posts
Re: A modest proposal
#52I really dislike JSON. It's better than XML, but not by much. There are several fundamental problems with JSON, one of which being that you have to duplicate the field names over and over again. It's just not a very structured format. Trailing commas is the least of my concerns. I would like to see protobuf take over at this point.
CBOR [1] has an extension to allow string references [2], so field names won't take up much space.
[1] RFC-7049, also http://cbor.io/
[2] http://cbor.schmorp.de/stringref It won't make much sense unless you already understand CBOR encoding, but it's a registered extension.
Re: A modest proposal
#53Earlier quoted context omitted.
In Rust, omitting the last semicolon in a block indicates an implicit return of the final expression of the block.
That's terrible, to have semantics depend on such a tiny syntax change that's so easy to miss.
IANAPLRESEARCHER, but to my understanding, it actually unifies the semantics. The return value is always the result of the last expression, and its type may either be something non-trivial, or `()` which is what `expr;` returns.
This makes it easier to write and use generic code for which you don't know the return type (could be `String`, could be `()`), without insisting on special cases for "returns a thing" and "doesn't".
Example: I hold a thing of type `T` and want to let you call a function on it. I can write this generically as
pub trait WithMut {
fn with_mutR>(&mut self, func: F) -> R;
}
Re: A modest proposal
#54I really dislike JSON. It's better than XML, but not by much. There are several fundamental problems with JSON, one of which being that you have to duplicate the field names over and over again. It's just not a very structured format. Trailing commas is the least of my concerns. I would like to see protobuf take over at this point.
It's an unstructured format, that's the point. You can't edit a protobufs in an editor.
Maybe not in vanilla text editors, but I don't see a reason you couldn't have an Emacs mode or special-purpose editor that lets you manipulate protobufs as text or structured data, respectively.
Re: A modest proposal
#55Re: A modest proposal
#56I really dislike JSON. It's better than XML, but not by much. There are several fundamental problems with JSON, one of which being that you have to duplicate the field names over and over again. It's just not a very structured format. Trailing commas is the least of my concerns. I would like to see protobuf take over at this point.
It's an unstructured format, that's the point. You can't edit a protobufs in an editor.
Actually, there is a built-in ASCII format for them as well. It's a little less flexible than the binary serialisation though.
There's a canonical JSON serialisation in v3 as well, although obviously that doesn't solve the OP's problem...
Re: A modest proposal
#57I'm surprised this got voted up considering how dismissive (and, frankly, mean) HN was to "JSON5" a few years back https://news.ycombinator.com/item?id=4031699
Trailing commas have been fine everywhere in JS since IE7 - it's about time all interpreters have this as an option, and preferably on by default.
Re: A modest proposal
#58Earlier quoted context omitted.
In Rust, omitting the last semicolon in a block indicates an implicit return of the final expression of the block.
That's terrible, to have semantics depend on such a tiny syntax change that's so easy to miss.
It's actually super nifty and IMO a great feature. However I think one of the reasons it works so well is that Rust is statically and very strongly typed, in a more dynamic language it would be hard to keep track of what's going on.
An other reason it works is that almost everything is an expression in Rust, including things like `if` statements. So for instance you can write:
let message =
if auth_ok() {
"success"
} else if tries Note that this won't work if one branch returns string an and other returns an integer for instance since the type of "message" must be known at compile time.
It also works well for getter functions and lambdas, for instance:
fn is_empty(&self) -> bool {
self.len == 0
}
list.sort_by(|a, b| a.key I can see where you're coming from though, it's easy to dismiss this feature as a bad idea on paper, especially if you've been traumatized with Javascript's insane handling of semicolumns. In practice however it's a rather useful sugar and so far it's been harmless in my experience. It basically makes the language more lispy.
Re: A modest proposal
#59The title is a possible reference to this satirical essay about solving poverty through cannibalism: https://en.wikipedia.org/wiki/A_Modest_Proposal
That's the problem with using "a modest proposal" for serious suggestions: you're supposed to use it for satire.
Wait, so is the op actually suggesting we be able to use commas? I thought op meant to say people who want to use commas are exactly like people who want to eat human babies to solve the problem of child poverty.
Re: A modest proposal
#60Earlier quoted context omitted.
That's terrible, to have semantics depend on such a tiny syntax change that's so easy to miss.
I wish there was times that HN supported Quadratic Voting[0] so that I could more (but costly) up votes to a really sane and pertinent comment. [0] http://ericposner.com/quadratic-voting/
I've never heard about quadratic voting before. This is very interesting!