5 ms·

> We've found a bug for you I must admit that if my compiler reported errors like this it would start to grate pretty quickly. Besides, isn't a bug exclusively

by DC-3 9y ago

> We've found a bug for you I must admit that if my compiler reported errors like this it would start to grate pretty quickly. Besides, isn't a bug exclusively something that breaks at runtime? E: s/big/bug/

Latty 9y ago
As a new user, it is way more useful. As an old user, you skip right past it. Every Python exception tells you > Traceback (most recent call last): Which is a similar boilerplate statement. Except less useful to newcomers. And if you doubt the need for newcomers to understand that stack traces and compiler errors are useful, then take a look at new user questions on StackOverflow - it's incredible how many of them flat out don't include that information. This kind of thing makes it way more likely the user recognises this is something useful, and better than that - makes it way more likely they can apply that information and solve their own problem. > Besides, isn't a bug exclusively something that breaks at runtime? I mean, it would be a bug if the type checker hadn't caught it. The runtime distinction seems completely arbitrary when we are talking about tools take take runtime errors and make them impossible.
- abecedarius 9y ago
  Technically "we've found a bug" ought to be "we couldn't prove there's no bug of this sort" and it can be grating, in the same way Clippy helpfully popping up was grating, to have the latter announced as the former.
- alphaalpha101 9y ago
  Programming languages shouldn't be designed around what is best for complete newbies. They should be designed around experienced users. Why design around a stage you're in for 15 minutes instead of the stage you're in for 15 years?
girvo 9y ago
You would think so, but personally when I picked up Elm it was extremely handy, and then faded into the background. I expected it to be annoying as an experienced dev, but I actually appreciated it initially and then it wasn’t annoying or even on my radar: my brain skipped right over it. Once you’re more experienced with the language, you’re typically using your editor to handle the error checking, so the extra “noise” is ignored in the parsing of it.
dmitriid 9y ago
Nope, it wouldn't. People get used to useless stacktraces and incomprehnsible warnings filling the screen with rubbish, and dismiss them out of hand. Elm's and Reason's approach let even the experienced dev get to the root of the problem immediately.

by DC-3 9y ago

Latty 9y ago

As a new user, it is way more useful. As an old user, you skip right past it. Every Python exception tells you > Traceback (most recent call last): Which is a similar boilerplate statement. Except less useful to newcomers. And if you doubt the need for newcomers to understand that stack traces and compiler errors are useful, then take a look at new user questions on StackOverflow - it's incredible how many of them flat out don't include that information. This kind of thing makes it way more likely the user recognises this is something useful, and better than that - makes it way more likely they can apply that information and solve their own problem. > Besides, isn't a bug exclusively something that breaks at runtime? I mean, it would be a bug if the type checker hadn't caught it. The runtime distinction seems completely arbitrary when we are talking about tools take take runtime errors and make them impossible.

abecedarius 9y ago
Technically "we've found a bug" ought to be "we couldn't prove there's no bug of this sort" and it can be grating, in the same way Clippy helpfully popping up was grating, to have the latter announced as the former.
alphaalpha101 9y ago
Programming languages shouldn't be designed around what is best for complete newbies. They should be designed around experienced users. Why design around a stage you're in for 15 minutes instead of the stage you're in for 15 years?

girvo 9y ago

You would think so, but personally when I picked up Elm it was extremely handy, and then faded into the background. I expected it to be annoying as an experienced dev, but I actually appreciated it initially and then it wasn’t annoying or even on my radar: my brain skipped right over it. Once you’re more experienced with the language, you’re typically using your editor to handle the error checking, so the extra “noise” is ignored in the parsing of it.

dmitriid 9y ago

Nope, it wouldn't. People get used to useless stacktraces and incomprehnsible warnings filling the screen with rubbish, and dismiss them out of hand. Elm's and Reason's approach let even the experienced dev get to the root of the problem immediately.