4 ms·

So, you're advocating removing the "make compiler happy" step and you think that will lead to greater discipline? If the tool automatically fixed it, you'd hav

So, you're advocating removing the "make compiler happy" step and you think that will lead to greater discipline? If the tool automatically fixed it, you'd have a point, but most if not all of the static analysis tools I've come across simply point to the error and leave it up to the developer to fix, which is the right thing to do, reinforcing good habits.

gregmac 9y ago
Not OP, but I interpreted that as implying your goal should not be "make compiler happy" but "think about and write reasonable code that also of course compiles". If one's assumption is that because of a type system and other built-in protections a successful compile means no bugs, then that person is doomed to fail.
- eradicatethots 9y ago
  I don’t see why we should make this a requirement of every programmer.
  - s73ver_ 9y ago
    I don't see why we shouldn't.
- falcolas 9y ago
  Pretty much exactly this. You can't keep throwing tools at a job and expecting them to compensate for poor developers. You also need to keep with currently good developers to ensure that they don't become lazy, relying on the tooling instead of critical thinking.
  - Chris2048 9y ago
    > relying on the tooling instead of critical thinking If the tool is "type checking" a computerised logic/type-checking will be far more efficient that mentally checking such a thing. Computer type-check logic is a superior form of a subset of "critical thinking".
- Chris2048 9y ago
  > a successful compile means no bugs Isn't that a strawman? Shouldn't we verify to what extent this mentality actually develops (I doubt it) rather than rebuild our methodologies around it - or at least begin by simply educating developers directly about the pitfalls of this assumption. Sometimes it feels like treating developer flaws as unfixable constants that can only be handled by process change, as opposed to developer improvement. Perhaps a symptom of hiring the cheapest devs en-masse?..

gregmac 9y ago

Not OP, but I interpreted that as implying your goal should not be "make compiler happy" but "think about and write reasonable code that also of course compiles". If one's assumption is that because of a type system and other built-in protections a successful compile means no bugs, then that person is doomed to fail.

eradicatethots 9y ago
I don’t see why we should make this a requirement of every programmer.
- s73ver_ 9y ago
  I don't see why we shouldn't.
falcolas 9y ago
Pretty much exactly this. You can't keep throwing tools at a job and expecting them to compensate for poor developers. You also need to keep with currently good developers to ensure that they don't become lazy, relying on the tooling instead of critical thinking.
- Chris2048 9y ago
  > relying on the tooling instead of critical thinking If the tool is "type checking" a computerised logic/type-checking will be far more efficient that mentally checking such a thing. Computer type-check logic is a superior form of a subset of "critical thinking".
Chris2048 9y ago
> a successful compile means no bugs Isn't that a strawman? Shouldn't we verify to what extent this mentality actually develops (I doubt it) rather than rebuild our methodologies around it - or at least begin by simply educating developers directly about the pitfalls of this assumption. Sometimes it feels like treating developer flaws as unfixable constants that can only be handled by process change, as opposed to developer improvement. Perhaps a symptom of hiring the cheapest devs en-masse?..