Hacker News Reader

Comment by skitter | Hacker News Reader

Neat, looks like the website got an overhaul.

I like Roc's approach of detecting errors statically but still trying to let you run the code. If a snippet is work in progress and has an unused variable, Go or Zig will refuse to compile it. Yes, an unused variable indicates a problem, which is why it's not going to pass any sensible CI setup and make its way into production, but that doesn't mean I should be disallowed from checking whether what I've got so far works. Roc allows¹ running a program with type errors as long as you don't execute a code path affected by them, which I imagine is very useful for refactoring.

The platform approach is also interesting, but I don't know how it will play into code reuse. I guess the different io/platform interfaces might not be quite as big of a problem in a pure functional language? I'm not experienced enough to tell.

¹: I haven't checked how successful it is, given it's immaturity I expect there to be issues

View on HN

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.

>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.