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

161–170 of 189 posts

Re: A modest proposal

#161

Post by keymone »

coldtea wrote: post #157
keymone wrote: post #155

Earlier quoted context omitted.

> personal opinion I take it you didn't read my original comment? Also I disagree, dangling comma is a visual cue that the sequence has a continuation.

> Also I disagree, dangling comma is a visual cue that the sequence has a continuation We already have a mechanism for telling whether a sequence ends or not -- the opening and closing bracket for the sequence. No need to have a second redundant one. This way the last element is an ordinary part of the sequence as any other and doesn't need a special exception to its formatting like the omission of the comma. Besides…

You're talking about syntactic rules, I'm talking about visual cues.

IMO there is no reason to have commas at all so this discussion is pointless.

Re: A modest proposal

#162

Post by coldtea »

keymone wrote: post #161
coldtea wrote: post #157

Earlier quoted context omitted.

> Also I disagree, dangling comma is a visual cue that the sequence has a continuation We already have a mechanism for telling whether a sequence ends or not -- the opening and closing bracket for the sequence. No need to have a second redundant one. This way the last element is an ordinary part of the sequence as any other and doesn't need a special exception to its formatting like the omission of the comma. Besides…

You're talking about syntactic rules, I'm talking about visual cues. IMO there is no reason to have commas at all so this discussion is pointless.

>You're talking about syntactic rules, I'm talking about visual cues.

In what way is ] also not a visual cue?

Re: A modest proposal

#163

Post by seanwilson »

coldtea wrote: post #145
seanwilson wrote: post #91

Seeing as the vast majority of statements while coding aren't multiline, I wish there was a symbol to indicate that instead of a symbol to represent the end of a single line statement. I think Python has things right with the significant whitespace as well as it seriously reduces annoying errors caused by misbalanced brackets/braces. Going further with this, I wish languages would be more copy/paste friendly. For exa…

> I think Python has things right with the significant whitespace as well as it seriously reduces annoying errors caused by misbalanced brackets/braces. You still get errors caused by mis-indented statements which are almost just as hard to check (if the indent continues for 10-15 lines and is nested etc). And because of allowing to mix tabs and spaces, you also get other issues. I think go had the best idea in this…

> You still get errors caused by mis-indented statements which are almost just as hard to check (if the indent continues for 10-15 lines and is nested etc).

I find wrong indents miles easier to see than unbalanced brackets/braces though. A single bracket/brace is only one symbol so it's hard to spot but it completely changes the semantics (see Apple's goto fail error).

> I think go had the best idea in this with gofmt: all code should be auto-formatted absolutely the same -- then it becomes trivial to read.

Yes, I like this. There's so many pointless arguments about things to do with naming conventions and tabs vs spaces...just make it part of the language so people can argue about more important topics.

Re: A modest proposal

#164

Post by krapp »

guitarbill wrote: post #158
NateDad wrote: post #142

Earlier quoted context omitted.

Meaningful whitespace is horrid. I speak from 3.5 years of working on s project that exclusively used yaml as configuration. Yaml is horrid. Toml is way better. Yes, multilayered objects in toml are ugly. Don't make your users created multilayered objects for their configuration. That's just a bad UX regardless of the language.

> Meaningful whitespace is horrid Millions of Python programmers might disagree, not to mention that most programmers using languages with meaningless whitespace (as far as the computer is concerned) still put whitespace in there, because humans. And it isn't like INI is a great experience, either. Flat configs suck in their own ways.

It's weird that a language with the mantra "explicit is better than implicit" has, as a core feature, braces implied by the negative space of the left-hand margin of a text editor.

>And it isn't like INI is a great experience, either. Flat configs suck in their own ways.

Yes, INI isn't great, but people who object to significant whitespace don't object to the "whitespace" part, they object to the "significant" part. That code could not compile or have scope errors because of one extra space or because a space replaced a tab just seems absurd to some people.

This is something about which reasonable people can disagree.

Re: A modest proposal

#165

Post by krapp »

seanwilson wrote: post #163
coldtea wrote: post #145

Earlier quoted context omitted.

> I think Python has things right with the significant whitespace as well as it seriously reduces annoying errors caused by misbalanced brackets/braces. You still get errors caused by mis-indented statements which are almost just as hard to check (if the indent continues for 10-15 lines and is nested etc). And because of allowing to mix tabs and spaces, you also get other issues. I think go had the best idea in this…

> You still get errors caused by mis-indented statements which are almost just as hard to check (if the indent continues for 10-15 lines and is nested etc). I find wrong indents miles easier to see than unbalanced brackets/braces though. A single bracket/brace is only one symbol so it's hard to spot but it completely changes the semantics (see Apple's goto fail error). > I think go had the best idea in this with gofm…

goto fail was caused by a failure to use braces at all - ironically, it seems, for the same aesthetic reasons that significant whitespace is used, because it seems "cleaner."

Had braces been used, the error might have been easier to spot or might not have happened at all.

Re: A modest proposal

#166

Post by rpdillon »

seanwilson wrote: post #120
DaiPlusPlus wrote: post #117

Earlier quoted context omitted.

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.

On the flip side, I've always found it useful when debugging at a REPL to be able to read various kinds of metadata about objects, including documentation. Clojure is one example of this, but I wouldn't mind seeing it elsewhere as well.

https://clojure.org/reference/metadata

Re: A modest proposal

#167

Post by donatj »

callumlocke wrote: post #123
donatj wrote: 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...

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.

If it's something you do thousand of times a second, like say a php app parsing a config it makes a HUGE difference. A number of PHP framework that use YAML config files actually cache the results in memcache because a network request is faster than parsing YAML from local disk.

Re: A modest proposal

#168

Post by thanksgiving »

NateDad wrote: post #148
callumlocke wrote: post #123

Earlier quoted context omitted.

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.

Toml is far superior for hand editing. This is why yaml is terrible (aside from significant white space): foo: 80:80 bar: 22:22 baz: 22.22 What's the value of foo? It's the string "80:80". What's the value of baz? The float 22.22 What's the value of bar? The integer 1342. I rest my case about both readability and writability.

> bar: 22:22

I know zero toml (don't even know what toml stands for) but I'm pretty sure you meant the value of bar is the string 22:22 based on foo.

Re: A modest proposal

#169

Post by seanwilson »

rpdillon wrote: post #166
seanwilson wrote: post #120

Earlier quoted context omitted.

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.

On the flip side, I've always found it useful when debugging at a REPL to be able to read various kinds of metadata about objects, including documentation. Clojure is one example of this, but I wouldn't mind seeing it elsewhere as well. https://clojure.org/reference/metadata

Hmm, so I'm thinking about cases where you have 10K objects and you wouldn't want the metadata duplicated and attached to all of those. Would that happen in Clojure?

Re: A modest proposal

#170

Post by seanwilson »

krapp wrote: post #165
seanwilson wrote: post #163

Earlier quoted context omitted.

> You still get errors caused by mis-indented statements which are almost just as hard to check (if the indent continues for 10-15 lines and is nested etc). I find wrong indents miles easier to see than unbalanced brackets/braces though. A single bracket/brace is only one symbol so it's hard to spot but it completely changes the semantics (see Apple's goto fail error). > I think go had the best idea in this with gofm…

goto fail was caused by a failure to use braces at all - ironically, it seems, for the same aesthetic reasons that significant whitespace is used, because it seems "cleaner." Had braces been used, the error might have been easier to spot or might not have happened at all.

Significant whitespace forces the look of the code and the meaning of the code together to prevent mistakes like that though. It's really silly that indenting code within a condition is a universal code formatting convention but it's not enforced by the compiler. I can't think of any exceptions where you wouldn't want to indent code like that and it's obvious badly indented code can be misleading so I don't see why a compiler shouldn't pick that up for you.
Post reply on HN