Hacker News new | ask | show | jobs
by rzwitserloot 948 days ago
Many java editors (notably, eclipse) work the same way, _if_ you configure them to do so_: Just run it, don't worry about the compilation errors. If the code never hits that segment (in java, if there's a syntactical error in source code, that entire class cannot be used, but if it's a semantic error (e.g. a reference to a function that doesn't exist, which is syntactically perfectly valid, that's a semantic error), only that method is 'tainted'. If you hit a tainted area the debugger kicks in, freezes the process, and breakpoints on the spot. You can then fix it if you want and continue, or inspect the stack and state of e.g. local vars and learn something.

What I find surprising is how few programmers I talk to are aware of this, let alone use it. I find it a significant productivity boost.

Extrapolating away from debuggers: Everything should be warning, nothing should be an error. Then adopt a policy that you don't check in warnings. I find it utterly insane that 'unused variable' is treated as an _error_ (in the sense that it prevents compilation). It.. just isn't.

I hear _lots_ of noise in the line of 'well but my dev team will just ignore that rule', but that's a "doctor it hurts when I press here" issue. You don't solve that by just being more beliggerent, you fix that by having a chat with the team.

I wonder what 'friendly' means in the context of 'a programming language', but if its: "Assuming you are not a complete idiot", that's a plus, I guess.

1 comments

>If you hit a tainted area the debugger kicks in, freezes the process, and breakpoints on the spot. You can then fix it if you want and continue, or inspect the stack and state of e.g. local vars and learn something.

>What I find surprising is how few programmers I talk to are aware of this, let alone use it. I find it a significant productivity boost.

Forward to the past, as often is the case.

See:

https://news.ycombinator.com/item?id=37841588

and its parent and child comment.