Live data from Hacker News

A modest proposal

happyassassin.net

121–130 of 189 posts

Re: A modest proposal

#121
post #90
post #73

Earlier quoted context omitted.

> Not sure what the rationale for commas in lists is, though. Well, you need some separator, and spaces won't do since [x y] has x applied to y.

Good point. Although could, in principle, make space-between-list-items higher precedence than function application. E.g.: [x (func y) z]

But how do you write a list with only one element, x (func y) z?

Re: A modest proposal

#122
post #90

Earlier quoted context omitted.

Good point. Although could, in principle, make space-between-list-items higher precedence than function application. E.g.: [x (func y) z]

But how do you write a list with only one element, x (func y) z ?

[(x (func y) z)]

Re: A modest proposal

#123
post #88
post #77

Earlier quoted context omitted.

Anyone looking for a “better JSON” night was well just move to YAML. Someone managed to make JSON5 the config format for something here and we wasted way too long before switching that over to YAML. Now we have a bunch of JSON5 with comments we’ve gotta manually transcribe.

Every YAML parser I've ever used has been literal magnitudes slower than the slowest JSON parser. It's way too flexible a format. > YAML may seem ‘simple’ and ‘obvious’ at a glance, but it’s actually not. The YAML spec is 23,449 words; for comparison, TOML is 838 words, JSON is 1,969 words, and XML is 20,603 words. https://arp242.net/weblog/yaml_probably_not_so_great_after_a...

If data is so big that parsing is a bottleneck, that seems like the wrong case for YAML. It's good for hand-edited and human-readable config files, and it's fast enough for that.

Re: A modest proposal

#124
post #77

Earlier quoted context omitted.

Anyone looking for a “better JSON” night was well just move to YAML. Someone managed to make JSON5 the config format for something here and we wasted way too long before switching that over to YAML. Now we have a bunch of JSON5 with comments we’ve gotta manually transcribe.

First, JSON is not just used for config, and I've yet to find the an API to parse YAML in the browser natively. Secondly, JSON is here and you have to deal with it everyday, so smoothing the work wouldn't hurt. Finally, if you have to pick a format, take TOML. Less error prone than YAML, faster, and injecting executable code and shooting your in the foot is not part of the standard. The fact that a lot of ini files a…

I cannot follow TOML at all. YAML is nice and obvious in the limited basically json subset I use whereas nested maps in TOML are a nightmare.

Re: A modest proposal

#125
post #88
post #77

Earlier quoted context omitted.

Anyone looking for a “better JSON” night was well just move to YAML. Someone managed to make JSON5 the config format for something here and we wasted way too long before switching that over to YAML. Now we have a bunch of JSON5 with comments we’ve gotta manually transcribe.

Every YAML parser I've ever used has been literal magnitudes slower than the slowest JSON parser. It's way too flexible a format. > YAML may seem ‘simple’ and ‘obvious’ at a glance, but it’s actually not. The YAML spec is 23,449 words; for comparison, TOML is 838 words, JSON is 1,969 words, and XML is 20,603 words. https://arp242.net/weblog/yaml_probably_not_so_great_after_a...

It's got a lot of bad features which should not really be used. The core is good though.

Re: A modest proposal

#126
This is one of my most favorite Lua features -- trailing commas are allowed in table constructors.

When generating code, it is so wonderful to not have to have the logic to track the first or last object ....

Re: A modest proposal

#127

Earlier quoted context omitted.

It may be used as such but it shouldn't be. YAML serves this purpose much better. JSON works better as a language independent serialization format that is incidentally readable.

Yeah json is a fact of life, the fact yaml exists doesn't change that. Actually, toml is even better than yaml and yet...

TOML's array/table syntax is kind of confusing, especially when you're a few levels deep. Having meaningful whitespace in YAML makes it clearer.

It's also kind of messy when you have a lot of multiline strings.

Re: A modest proposal

#128

Earlier quoted context omitted.

So can you fill the rest of us in on the reason then?

You can blame Crockford for that: [1] TLDR: Basically, in a typical Crockford move, he saw people were using them in a specific way he did not like (to store parsing parameters), so he removed them entirely. I say "typical Crockford" because some of his JS linting rules are gratuitous overkill in my opinion. He also suggests that if you want comments, you should pipe the config file through a minifier that removes th…

It's an excelent reason in my opinion.

Re: A modest proposal

#129

Earlier quoted context omitted.

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/

Thanks for the link, I started reading the paper. I love this: Groups frequently make collective decisions through majority rule. Legislators pass bills by majority; shareholders make most corporate decisions by (share-weighted) majority rule, as do directors; clubs, university faculties, and civic associations typically use majority rule as well. The reason that they do so is not entirely clear. (Emphasis mine).

>The reason that they do so is not entirely clear.

Not clear? It's almost too clear as to be tautological.

They do because they (a) think all members should have equal say, (b) most members in the group want X to be done.

Unless we're talking about submitting to force or listening to expertise, why would many people wanting to do something, let fewer people tell them what to do instead?

Heck, if it comes to fighting for what's to be done (the most effective but primitive form of getting a decision), the majority could beat up the minority and have its way anyway.

Re: A modest proposal

#130
post #88

Earlier quoted context omitted.

Every YAML parser I've ever used has been literal magnitudes slower than the slowest JSON parser. It's way too flexible a format. > YAML may seem ‘simple’ and ‘obvious’ at a glance, but it’s actually not. The YAML spec is 23,449 words; for comparison, TOML is 838 words, JSON is 1,969 words, and XML is 20,603 words. https://arp242.net/weblog/yaml_probably_not_so_great_after_a...

It's got a lot of bad features which should not really be used. The core is good though.

The problem with talking about 'cores', is I still have to parse and handle the entire language if I want to claim to support YAML.

I've used JSON is some constrained places, I can't imagine writing my own YAML parser, or hacking an existing one into a constrained place (no memory allocation for example).

Post reply on HN