4 ms·

Go has something of an imposed rigidity that a lot of C programmers I think wouldn't tolerate well (culturally, viscerally),- one example: the whole comment out

Go has something of an imposed rigidity that a lot of C programmers I think wouldn't tolerate well (culturally, viscerally),- one example: the whole comment out all unused variables because you commented out a function for debugging purposes during development (couldn't just pass a flag to the compiler, at least last time I used Go). Aside - I seem to remember a Blog post you wrote on your experience with the Go language and I think it pretty accurately reflected a lot of my own experience with it. edit: found it [0] [0] http://ridiculousfish.com/blog/posts/go_bloviations.html http://ridiculousfish.com/blog/posts/go_bloviations.html

xyproto 10y ago
Commenting out code correctly, in a way that avoids complaints about unused code, should be possible to do in a proper IDE.
- heinrich5991 10y ago
  Go mentality says that you shouldn't need an IDE for coding in a language.
- forgotpwtomain 10y ago
  I upvoted this (apparently it's been downvoted again) -- for the record I totally disagree with the premise but I think it's a serious enough point to merit being addressed rather than down-voted[0]. > Commenting out code correctly, in a way that avoids complaints about unused code, should be possible to do in a proper IDE. First of all, failing to compile, in an of itself should be reserved to a particular class of failures not to linting, I feel pretty strongly about this and I think a lot of other people do. Further, I would say, that the complexity of an IDE that supports this - e.g. suppose you previously declared `uin64_t a, b, c, d;` and someone commented out the only function which uses c ? The editor should than make a new line with `//uint64_t c;` and than contract the old line correctly. That isn't a simple procedure to be sure and it's perfectly reasonable to use nano/vi to write code (you might say it's not effective) but at least in my opinion programtically correct code shouldn't fail because I'm not using super-advanced-ide-X. [0] Aside - I tend to dislike this down-vote on disagree trend lately, imho the discussion would benefit from respecting and responding to disagreeable opinions and downvotes should be reserved for where (exclusively, but I guess subjectively - the comment isn't/worth the time effort to disagree or respond to e.g. blatant spam, highly condescending, personal attacks etc.)
quotemstr 10y ago
Next time I write a Go program, I'm hacking the compiler locally so it stops whining about this "problem".

xyproto 10y ago

Commenting out code correctly, in a way that avoids complaints about unused code, should be possible to do in a proper IDE.

heinrich5991 10y ago
Go mentality says that you shouldn't need an IDE for coding in a language.
forgotpwtomain 10y ago
I upvoted this (apparently it's been downvoted again) -- for the record I totally disagree with the premise but I think it's a serious enough point to merit being addressed rather than down-voted[0]. > Commenting out code correctly, in a way that avoids complaints about unused code, should be possible to do in a proper IDE. First of all, failing to compile, in an of itself should be reserved to a particular class of failures not to linting, I feel pretty strongly about this and I think a lot of other people do. Further, I would say, that the complexity of an IDE that supports this - e.g. suppose you previously declared `uin64_t a, b, c, d;` and someone commented out the only function which uses c ? The editor should than make a new line with `//uint64_t c;` and than contract the old line correctly. That isn't a simple procedure to be sure and it's perfectly reasonable to use nano/vi to write code (you might say it's not effective) but at least in my opinion programtically correct code shouldn't fail because I'm not using super-advanced-ide-X. [0] Aside - I tend to dislike this down-vote on disagree trend lately, imho the discussion would benefit from respecting and responding to disagreeable opinions and downvotes should be reserved for where (exclusively, but I guess subjectively - the comment isn't/worth the time effort to disagree or respond to e.g. blatant spam, highly condescending, personal attacks etc.)

quotemstr 10y ago

Next time I write a Go program, I'm hacking the compiler locally so it stops whining about this "problem".