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

171–180 of 189 posts

Re: A modest proposal

#171

Post by falcolas »

krapp wrote: post #164
guitarbill wrote: post #158

Earlier quoted context omitted.

> 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.…

> It's weird that a language with the mantra "explicit is better than implicit"

The lack of braces enforces a certain style - something that can be found throughout Python. For example, the lack of multi-line lambda statements.

> braces implied by the negative space

It's easier to think of it in the same way that the compiler does: indent and dedent. Indent? Creating a new scope. Dedent? Exiting the current scope. All of the "constant 4 spaces" and "spaces instead of tabs" simply makes it easier for humans to interpret the indent and dedents visually.

In my experience in writing code in multiple languages: even when using braces you, the coder, still effectively require indentation to visually parse blocks. Yes, copying and pasting code is a touch harder, and most text editors are too lazy to parse for indents and dedents, but the first is mitigated by applying basic DRY principles, the second by installing a python-aware plugin.

Re: A modest proposal

#172

Post by guitarbill »

krapp wrote: post #164
guitarbill wrote: post #158

Earlier quoted context omitted.

> 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.…

The INI example is in response to "Don't make your users created multilayered objects". Personally, I cannot stand TOML, but there's no accounting for taste.

I think the significant whitespace is a pragmatism thing. If you're already doing it, do it consistently, if you're already doing it consistently do you really need brackets? The answer is no, and the added bonus is you (and everybody else) is forced to do the whitespace consistently. I'll take a consistently formatted codebase over inconsistencies any day!

Re: A modest proposal

#173

Post by coldtea »

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.

>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."

In Python's case it's not just an aesthetic -- the whitespace is also functional, so that mistake can't happen just for aesthetics.

Re: A modest proposal

#174

Post by falcolas »

rbanffy wrote: post #80
web007 wrote: post #57

I'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.

You can always parse using an eval. I guess it should work. /me ducks.

Sigh.

Don't duck too much. This kind of config implementation is actually pretty common in some other languages. Clojure, for example. Most configuration files for Clojure programs are written in Clojure, and defended as such.

I also see it frequently done in Python and Ruby, given how simple they make it to dynamically import random files as modules. I've even watched a colleague rant about how they couldn't figure out how to do exactly this in Go.

Re: A modest proposal

#175

Post by captainmuon »

drodgers wrote: post #68
captainmuon wrote: post #45

When I use JSON, I usually make sure that the parser supports trailing commas and comments, even if I have to add that myself. The reason is that I deal a lot with machine-generated but potentially user-edited JSON. Anything else is needlessly masochistic. When producing JSON for others, I just use the minimal consensus format (read: the "official" spec).

I do the same, but instead of switching/patching the JSON parser, I replace it with a YAML one. YAML was designed to be a superset of JSON precisely so that it could be used as an upgrade path. It also allows comments and neat multiline string formatting (in addition to trailing commas).

That is a good option, but YAML is too complex for my taste, with the optional indentation based syntax. JSON + comments, like what sublime text uses for configs, is a sweet spot for me. If you know JS or Python, you can probably write it instinctively.

Re: A modest proposal

#176

Post by falcolas »

thanksgiving wrote: post #168
NateDad wrote: post #148

Earlier quoted context omitted.

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.

I think he's attempting to point out a shortcoming of yaml; I can reproduce it myself in Python.

That said, I've never run up against this myself - in the face of potential ambiguity I attempt to be explicit, and surround it in quotes to be explicit string.

TOML itself is going through its own growth pains brought on by a rather sizable spec. For example:

    >>> pytoml.loads("foo = 20:20:20")
    [...]
    pytoml.core.TomlError: (1, 9): msg

Re: A modest proposal

#177

Post by falcolas »

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

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.

If it's something you do thousands of times a second, then opening, reading, and parsing a config file is absolutely something you should be caching, no matter the implementation.

Re: A modest proposal

#178

Post by krapp »

seanwilson wrote: post #170
krapp wrote: post #165

Earlier quoted context omitted.

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…

The conventions around whitespace and code formatting are not universal, and the problem is once the compiler has to care about whitespace, it's no longer whitespace, it's code.

Code has to be correct in ways whitespace doesn't. Some people use tabs, some people use spaces. Some people even use both. In terms of whitespace, it doesn't really matter.

But, if your language cares which of the visually indistinguishable but otherwise incompatible kinds of non-printing characters you're formatting your code with, then it can still fail while visually communicating the correct information to the reader.

Re: A modest proposal

#179

Post by keymone »

coldtea wrote: post #162
keymone wrote: post #161

Earlier quoted context omitted.

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?

In what world having multiple cues with opposite meanings is considered good?

Re: A modest proposal

#180

Post by tomp »

simias wrote: post #58
tomp wrote: post #29

Earlier quoted context omitted.

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" }…

I read your comment more as an endorsement of implicit returns. Make no mistake, I love those. I've been using them most of my life, first in OCaml and then in Scala.

I just think that using the semicolon to make the function return unit instead is problematic. It would be better to have the type system guide that decision, like in Scala. It would be even better to have an explicit `ignore` function or something (like in OCaml) to signal to the compiler that you really want to ignore the value and you only care about uthe side effect. I mean, why would you ever write just e.g. `a < b;`?

Post reply on HN