4 ms·

> good illustration that the Go designers didn't think their ideas through. This is a real pain in the butt when you are writing code and regularly commenting

by jussij 14y ago

> good illustration that the Go designers didn't think their ideas through. This is a real pain in the butt when you are writing code and regularly commenting in and out sections of code while you are testing things. How could it be that bad? It's as simple as a compile, a click on the error message and adding a one line comment. No worse than the standard practice of making sure your c/c++ code compiles without warnings with the maximimum warning level set.

lobster_johnson 14y ago
People develop at different speeds. For me, anything like this that slows me down and interrupts my flow with 3-4 seconds of "click on the error message and add a one-line comment" is incredibly annoying. Development has several modes. One mode is "hacking", just hashing out what you want until it works and is elegant enough as a solution, perhaps changing your mind frequently when you see how it works in practice. Another is "polishing", carefully annotating, cleaning up, documenting, burning off loose threads, making sure the test coverage is top notch, etc. The problem is that Go's compile-time strictness lends itself to the "polishing" phase, but not to the "hacking" phase.
- redbad 14y ago
  > Development has several modes. One mode is "hacking", > just hashing out what you want until it works and is > elegant enough as a solution, perhaps changing your mind > frequently when you see how it works in practice. > Another is "polishing", carefully annotating, cleaning > up, documenting, burning off loose threads, making sure > the test coverage is top notch, etc. > > The problem is that Go's compile-time strictness lends > itself to the "polishing" phase, but not to the > "hacking" phase. When I write Go, or indeed in any programming language, I generally start with, and stay in, what you call the "polishing" phase. Experimentation occurs in my head, and what makes it through to my fingers is the polished form of that experiment. That Go is not conducive to writing sloppy (or "hacking" phase) code is I think only a good thing.
  - lobster_johnson 14y ago
    Without measuring how productive we (you and I) are as programmers, such a qualitative judgement is largely meaningless. Anecdotally, I have had colleagues who always plan ahead meticulously, using pen and paper and diagrams and plenty of note-taking before ever writing a single line of code, and the first line of code is often a test. And yet those people were terrible programmers. They take a long time to produce working code, and it's often deeply flawed. They will spend half a day or an entire day trying to hunt down a bug that I found to be trivially obvious even without knowing the codebase. Meticulousness does not imply quality.

by jussij 14y ago

lobster_johnson 14y ago

People develop at different speeds. For me, anything like this that slows me down and interrupts my flow with 3-4 seconds of "click on the error message and add a one-line comment" is incredibly annoying. Development has several modes. One mode is "hacking", just hashing out what you want until it works and is elegant enough as a solution, perhaps changing your mind frequently when you see how it works in practice. Another is "polishing", carefully annotating, cleaning up, documenting, burning off loose threads, making sure the test coverage is top notch, etc. The problem is that Go's compile-time strictness lends itself to the "polishing" phase, but not to the "hacking" phase.

redbad 14y ago
> Development has several modes. One mode is "hacking", > just hashing out what you want until it works and is > elegant enough as a solution, perhaps changing your mind > frequently when you see how it works in practice. > Another is "polishing", carefully annotating, cleaning > up, documenting, burning off loose threads, making sure > the test coverage is top notch, etc. > > The problem is that Go's compile-time strictness lends > itself to the "polishing" phase, but not to the > "hacking" phase. When I write Go, or indeed in any programming language, I generally start with, and stay in, what you call the "polishing" phase. Experimentation occurs in my head, and what makes it through to my fingers is the polished form of that experiment. That Go is not conducive to writing sloppy (or "hacking" phase) code is I think only a good thing.
- lobster_johnson 14y ago
  Without measuring how productive we (you and I) are as programmers, such a qualitative judgement is largely meaningless. Anecdotally, I have had colleagues who always plan ahead meticulously, using pen and paper and diagrams and plenty of note-taking before ever writing a single line of code, and the first line of code is often a test. And yet those people were terrible programmers. They take a long time to produce working code, and it's often deeply flawed. They will spend half a day or an entire day trying to hunt down a bug that I found to be trivially obvious even without knowing the codebase. Meticulousness does not imply quality.