Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A modest proposal

happyassassin.net

Post reply on HN
Print view View original

111–120 of 189 posts

Re: A modest proposal

#111

Post by masklinn »

donatj wrote: post #102
masklinn wrote: post #38

Earlier quoted context omitted.

In Erlang, commas and semicolons are separators not terminators . So you are in fact disallowed to have a semicolon at the end of a sequence of clauses, it's either nothing (for case) or a period (for functions)

It sounds dumb, but this was actually one of the things that turned me off Erlang despite my interest.

It's definitely weird, but it allows for neat stuff e.g. in Emacs' erlang-mode when you type a semicolon it automatically creates a new clause (function or case) for you.

Re: A modest proposal

#112

Post by mrunkel »

LoSboccacc wrote: post #104
Illniyar wrote: post #103

Earlier quoted context omitted.

no, we downvote things that state an opinion as fact without even an attempt at explaining why, especially when done in a tone that is aggressive and disrespectful.

It's not an opinion however. JSON is a standard. Kinda worries me professionals use it without having a clue.

The reason why something did or didn't make it into a standard are definitely opinions. All sneak had to do was to provide a link to the "damned good reason."

Re: A modest proposal

#113

Post by Illniyar »

LoSboccacc wrote: post #104
Illniyar wrote: post #103

Earlier quoted context omitted.

no, we downvote things that state an opinion as fact without even an attempt at explaining why, especially when done in a tone that is aggressive and disrespectful.

It's not an opinion however. JSON is a standard. Kinda worries me professionals use it without having a clue.

That JSON has a "good reason" for disallowing comments is an opinion, it could be a popular, well-known and established opinion or it could be completely uninformed. To know the difference one must explain it.

Also standards change, and professionals use their tools in ways the original creators did not imagine a lot, that doesn't make them clueless. Heck, even JSON is a result of professionals misusing a programming language syntax for a serialization protocol.

Re: A modest proposal

#116

Post by clouddrover »

kayamon wrote: post #9
megapatch wrote: post #2

Yes, please! This applies to many other lists as well, not only restricted to JSON. Besides, imagine a world of Java, Javascript, C-like anything, where you would be DISALLOWED to have a semicolon after the last statement in a block. Crazy thought, right?

Welcome to Pascal.

How do you mean? In Pascal the semicolon after the last statement of a block is optional. So, for example, this:

  function square(const x : Integer) : Integer;
  begin
    result := x * x;
  end;
Is equivalent to:

  function square(const x : Integer) : Integer;
  begin
    result := x * x
  end;
If you mean in if-then-else constructions, then yes the semicolon must be at the end of the statement:

  if (condition) then
    dosomething
  else
    dosomethingelse;

Re: A modest proposal

#117

Post by DaiPlusPlus »

seanwilson wrote: post #96
rootlocus wrote: post #74

Earlier quoted context omitted.

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…

Yeah...that's frustrating. For a Chrome Extension manifest JSON file I was recently editing, you have to enter a description field that I found out is limited to around 100 characters after a failed upload. I wanted to add a comment above this field so myself and anyone else editing the file was aware of this in the future (a good use of comments in my opinion). I'm not going go through the hassle of a build step to…

If the consuming program allows it, you can fake a comment by storing it as a JSON property value:

  { "myComment": "This is a comment!", "realValue": 1 }

Re: A modest proposal

#118

Post by wscott »

Scanning the comments I don't see my reason for wanting trailing commas: version control.

You want to preserve the history of your code and to be able to easily query your VC system about the providence of each line of code. I want to add a new item to the end of the list, I also need to add a comma to the end of the previous line. This makes my commit larger than needed and it muddies the code history.

Just let me make simple incremental additions to a file as it changes.

Re: A modest proposal

#119

Post by callumlocke »

mschuster91 wrote: post #110
crdoconnor wrote: post #70

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.

YAML can go off and die in a fire... especially because it cannot transfer the data type, which JSON can: you have either an integer, a float or a string. Also some libraries want the values escaped, some not, some barf on non-alphanumeric keys... JSON is pretty much standardized across the board.

I use YAML all the time (for config) and the things you mention have caused no more than one minute's frustration in my life. JSON is great for serialisation, YAML for little config files that need frequent hand-editing during development.

Re: A modest proposal

#120

Post by seanwilson »

DaiPlusPlus wrote: post #117
seanwilson wrote: post #96

Earlier quoted context omitted.

Yeah...that's frustrating. For a Chrome Extension manifest JSON file I was recently editing, you have to enter a description field that I found out is limited to around 100 characters after a failed upload. I wanted to add a comment above this field so myself and anyone else editing the file was aware of this in the future (a good use of comments in my opinion). I'm not going go through the hassle of a build step to…

If the consuming program allows it, you can fake a comment by storing it as a JSON property value: { "myComment": "This is a comment!", "realValue": 1 }

That's what I did actually. I don't like it though. A comment is really saying "this is a note for the reader that isn't used at runtime". Putting a comment in as a value goes against that and it uses up memory when the file is read in.
Post reply on HN