181–189 of 189 posts
Earlier quoted context omitted.
Hand-edited and human-readable? With significant whitespace and tab-space difference?
Human readability is exactly the point of significant whitespace. And I'm not sure how significant whitespace could even work without distinguishing between tabs and spaces, as a tab could represent any number of spaces.
Earlier quoted context omitted.
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 (lik…
Agree. The idea to attach additional semantics to ; is completely nuts, especially as ; is mandatory in Rust (usually, there are odd corner cases where it is not allowed).
Just get rid of mandatory ; completely and let the type system handle the rest.
Earlier quoted context omitted.
> 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?
Not on modern JS world, which allows for dangling , everywhere: http://2ality.com/2013/07/trailing-commas.html, so having a "," doesn't mean the line is not the last one anymore, just means "it's a line like any other".
It's time JSON gets up with the times -- especially since it's a totally backwards compatible improvement.
Earlier quoted context omitted.
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 (lik…
> I just think that using the semicolon to make the function return unit instead is problematic. Agree. The idea to attach additional semantics to ; is completely nuts, especially as ; is mandatory in Rust (usually, there are odd corner cases where it is not allowed). Just get rid of mandatory ; completely and let the type system handle the rest.
I guess you could use significant newlines like python but I never really liked that. I think Rust's compromise is pretty decent.
In particular it's the first time I hear people complaining about it, so far most users (myself included) seem to be praising it. Javascript's handling of semicolon is nuts, I wouldn't say Rust's is.
Earlier quoted context omitted.
In what world having multiple cues with opposite meanings is considered good?
In what world is the "," at the end of the final line an "opposite meaning" to ]? Not on modern JS world, which allows for dangling , everywhere: http://2ality.com/2013/07/trailing-commas.html , so having a "," doesn't mean the line is not the last one anymore, just means "it's a line like any other". It's time JSON gets up with the times -- especially since it's a totally backwards compatible improvement.
yeah, in other words - there should be no commas whatsoever. Weren't you the one complaining about redundancy?
I agree, trailing comma's and the lack of comments is extremely annoying in JSON. However, I think the underlying problem is tools using a serialization format for configuration to be the real problem here.
That AWS CloudFormation has added support for YAML is a great example of this and it's a great step forward. I think other tools should follow.
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.
Earlier quoted context omitted.
> I just think that using the semicolon to make the function return unit instead is problematic. Agree. The idea to attach additional semantics to ; is completely nuts, especially as ; is mandatory in Rust (usually, there are odd corner cases where it is not allowed). Just get rid of mandatory ; completely and let the type system handle the rest.
; is used to separate statements, how do you propose to get rid of that? I guess you could use significant newlines like python but I never really liked that. I think Rust's compromise is pretty decent. In particular it's the first time I hear people complaining about it, so far most users (myself included) seem to be praising it. Javascript's handling of semicolon is nuts, I wouldn't say Rust's is.
We have computers they are perfectly able infer them for me.
> Javascript's handling of semicolon is nuts, I wouldn't say Rust's is.
- JavaScript does insane things, as usual. This doesn't mean every implementation of semicolon inference has to be that bad and broken.
- Rust goes the other way by pretending it's still 1990.
There are plenty of languages out there that handle semicolon inference perfectly fine.
(Heck, I even let the IDE show me where the compiler has placed them.)
Earlier quoted context omitted.
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…
How is it not though? For every mainstream language it's standard convention to indent conditions and functions.
> 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.
This a complete non-issue to me. The pros of significant whitespace vastly overshadow any possible benefit of letting people choose tabs vs spaces and the latter issue is easily solved with IDEs anyway. I don't see people having any issues with this using Python either.
Personally, I think even naming conventions should be enforced by the language as well so people can stop wasting time debating insignificant details and in code reviews.