5 ms·
I'm not so sure about giving credit. Consider: package main import "fmt" func blah() bool { return false } func main() { x := 5 if(blah(
by andralex 16y ago
I'm not so sure about giving credit. Consider:
package main
import "fmt"
func blah() bool {
return false
}
func main() {
x := 5
if(blah()) {
x++;
}
fmt.Printf("%d\n", x)
}
(which prints 5) and then this:
package main
import "fmt"
func blah() bool {
return false
}
func main() {
x := 5
if(blah())
{
x++;
}
fmt.Printf("%d\n", x)
}
(which prints 6). Looks like a major problem to me, and at any rate it's a far cry from having made real (or any) progress. Python _did_ get whitespace right.
- stcredzero 16y agoPython's approach has always been highly pragmatic. Go's is as well, but with somewhat different goals. The Go team's goal seems to involve putting together a clean-enough syntax with fast-enough for systems programming performance combined with powerful-enough high-level concurrency model. They don't want to win the gold in any one category. They're going for the decathalon! In any case, language syntax should always take into account the expectation of programmer communities. If you push syntax too far, you lose too many people.
- andralex 16y agoThe point of my example was simple - Go's gross mishandling of whitespace is a permanent trap for the unwary and a huge liability for people coming from other languages. When D was nascent, many people proposed various schemes for making semicolons optional. I think it's great D didn't fall for such.
- stcredzero 16y agoName one language that doesn't have "a permanent trap for the unwary and a huge liability for people coming from other languages."
- jibal 16y agotu quoque fallacy -- the worst possible form of argument FOR something.
- stcredzero 16y agoOnly a fallacy if it's an argument for something. It's actually a criticism of your criticism. Oh hey, you tried to spin my comment with a different meaning. I guess you're guilty of an entirely different fallacy.
- kjksf 16y agoI don't really follow what in your example shows "gross mishandling of whitespace". The most popular languages are C, C++, Java and C# and Go's syntax is very similar to those. If anything, Python is the weird one in how it treats the whitespace and hence most likely to confuse people coming from other languages. As to optional semicolon elision - what is the problem with that? They make the code cleaner looking and gofmt will remove them for you even if you forget due to C/Java reflexes. I don't see the downside of making them optional.
- WalterBright 16y agoThe problem is that the code looks correct for anyone coming from C, C++, Java, D, Javascript, etc., but produces unexpected results.
- andralex 16y agoPlease make sure you give the example a close read, as it surprises even experienced Go programmers. Both examples look similar to code in the likes of C, C++, Java, and so on, _except_ the semantics gets radically changed depending on one line feed, which is very unlike those languages. I hope this clarifies things.
- deleted 16y ago[deleted]
- kjksf 16y agoI wrote a lot of code of C/C++ and my implicit assumption is that C syntax is serviceable. Since I don't see C syntax (or JavaScript syntax or Java syntax) as a major problem and Go is an improvement over those, I don't see Go syntax as a major problem. I agree with you that Python's syntax is cleaner but I would like to bring few novel syntax-related things that Go did that are not as commonly known and in some cases are improvements even over Python. In general I don't like deep indentation and Go has few things to help keep indentation to a minimum. 1. defer statement In Go you can say: f := os.Open("myfile.dat", ...) defer f.Close() That guarantees that f.Close() will be called at function exit. In Python/Java/C# to get the same guarantee, you would have to use try/finally block, introducing additional indentation for the code using f. 2. Syntax for defining methods on interfaces func (p *MyClass) Method(int i) { return p.x + i } The equivalent in Python would be: class MyClass(): def Method(i): return this.x + i Again, less indentation. 3. panic()/recover() way of handling fatal errors also doesn't introduce additional indentation level like try/catch blocks.
- andralex 16y agoIf you like defer's or panic's savings on indentation, you're in desperate need of D: http://www.digitalmars.com/d/2.0/statement.html#ScopeGuardStatement http://www.digitalmars.com/d/2.0/statement.html#ScopeGuardSt...
- drothlis 16y agoDoesn't the Go compiler flag as an error the fact that there's no "{" after the "if(blah())"? (On the same line, I mean.)
- drothlis 16y agoTo answer my own question: No, it doesn't.