Hacker News Reader

Comment by notJim | Hacker News Reader

It's pretty hilarious to watch people clambering all over each other in this thread to claim this isn't a problem because [op_is_doing_it_wrong] or [weird_hacky_workaround]. Commenting out bits of code to see what effects it has is one of the most useful ways of not only debugging a program, but learning to program, and “reading” code.

Just because some really smart people made a decision for reasons that are great 99% of the time, but fail badly in a very important 1% case doesn't mean you have to redefine your entire belief system to avoid criticizing them.

View on HN

As someone who works with Go full time I can understand where this criticism is coming from, but in my experience it becomes a non-issue after very short amount of time. The various editor helpers that automatically add/remove imports help.

what editor and plug in you use?

I don't know for Andrew, but I use Sublime Text 2. Cmd-., Cmd-P and type the import name, you're done (it toggles add/remove of the import). You don't have to leave your position in the file.

The :Drop, :Import, :Gofmt and :Godoc statements that allow you to drop packages, import packages, cleanly format what you're working on, and document the targeted function are in the vim extras that come with Go, and work well enough to make this painless for me.

Not using Go here, but I configure my Java IDE to report unused imports as errors; stil not a problem because it's probably been years since I last edited import statements manually -- days can go without I even reading imports because they're usually collapsed by the editor. Non-issue.

I usually read the first couple comments on an article before reading the article itself. I was all set to write a comment disagreeing with you after reading the first couple paragraphs, but by the end I completely agreed. Sounds like it would really disturb my flow while debugging.

I'm sure there's reasons it would be a bad idea, but having the ability to ignore errors like this when building a Debug build seems like it could be a solution.

There are plenty of workarounds. Anyway, like others I work full-time with Go and it has become an absolute non-issue for me. In 80% of the cases fmt is already imported, but in 99% of the cases I have a global variable log defined in every package anyway -- and if not I define it. (Working often test-driven, I avoid the issue totally by doing t.Logf.) So yes, every 2 months (I'm serious) I'm running into the OP's problem and it happens that I'm writing fmt.Printf("") -- but this almost exclusively happens on "Pastebin-projects".

There is great reasoning behind the concept of providing as few exceptions as possible to the users. Sometimes it means adapting your workflow/thinking, but I guess this is the case for every language if you want to become truly productive.

  > It's pretty hilarious to watch people clambering all over each other in this thread to claim this isn't a problem because [op_is_doing_it_wrong] or [weird_hacky_workaround].

"Clambering" may be a bit hyperbolic, given there are only 15 comments (at the time I read this), and a handful of those propose "weird hacky workarounds" or "op is doing it wrong" comments.

Aside from that, I agree with the author that the variable not used errors are certainly irritating during a development or debug cycle. On the other hand, it is nice during a normal compile, or when using go get to pull a lib in from some other author.

There are indeed numerous work arounds, using build constraints (go build tags args) and such. Many (most?) are quite hacky and not very general case or new-developer-friendly.

It would indeed be nice to have a 'debug' compile flag that ignored such errors, if only for a little while. Maybe even make it only usable with "go build" and never "go get" or "go install".

> Clambering" may be a bit hyperbolic, given there are only 15 comments...

Certainly true. Hyperbole is basically my favorite thing in the universe.

It makes me question humanity seeing the opposite. In these comments are many "work-arounds" (this word is so negative; what about workflow-diff?) listed and I bet if you are smart enough, you can even come up with many more, more beautiful work-arounds. Using a language for one week hardly qualifies someone for qualified criticism. :-)

> Commenting out bits of code to see what effects it has is one of the most useful ways of not only debugging a program, but learning to program, and “reading” code.

I was thinking about a command line tool to enable this automatically by generating code based on the source files.

Reply on news.ycombinator.com