3 ms·

This seems to have a weird personification of a compiler/linter's error messages as a telling off, an insult, or a put-down. It's just a message to highlight w

by F-0X 7y ago

This seems to have a weird personification of a compiler/linter's error messages as a telling off, an insult, or a put-down. It's just a message to highlight what is wrong. Red doesn't equate to bad, red equates to "this is a compilation blocker", just as yellow is typically used for "this will work but it isn't a good idea". The compiler _already is_ guiding the user to success. If somebody is taking compiler errors personally, they are going to struggle in a lot more areas in life than writing code, and the issue is their frame of mind.

jodrellblank 7y ago
And this is a dismissal of the idea that words have effects on people. Do you think a manager's choice of words has no effect on their subordinates? Do you think a book's choice of words has no effect on the reader? Do you think ALL CAPS IS NOT SHOUTING AND IS PERFECTLY NORMAL? Are all software tools the same experience for you - you never find one frustrating and another pleasant, one neutral and another you curse at? It's just a message to highlight what is wrong. Nothing is wrong. That's the point. Unfinished code doesn't work, that's normal, not erroneous. (Almost tautologically so - of course it doesn't work, it's unfinished).
- F-0X 7y ago
  > And this is a dismissal of the idea that words have effects on people. No. Context is important. A manager, a human being with authority, is very different to a standard, unchanging message baked into a program. Your claim and comparison (to me right now, correct me if I'm wrong) seems to be that IDE error messages are just as effective on the programmers feelings as the manager coming up to look at your code and pointing a finger while bluntly saying "this is incorrect". I don't believe this at all. > Are all software tools the same experience for you - you never find one frustrating and another pleasant, one neutral and another you curse at? They are not. Ironically it is the ones that don't produce direct error messages (especially css) that anger me the most. > Nothing is wrong. That's the point. Unfinished code doesn't work, that's normal, not erroneous. (Almost tautologically so - of course it doesn't work, it's unfinished). There's more than one state code can be in while incomplete. It can be incomplete because it doesn't accomplish the task it is being written for yet, but all the same it will still compile. If it is syntactically incorrect, it doesn't even matter if the logic attempted to be expressed is correct, the program is broken. But these errors are easy for a computer to expose - so they should, so problems are fixed as early as possible.
  - jodrellblank 7y ago
    Ironically it is the ones that don't produce direct error messages (especially css) that anger me the most. [..] But these errors are easy for a computer to expose - so they should, so problems are fixed as early as possible. Yes, they should. As I said elsewhere, I'm not suggesting silencing errors or having no feedback at all. That would not be the computer assisting the user in writing correct code, that would be another way of hindering it. Your claim and comparison (to me right now, correct me if I'm wrong) seems to be that IDE error messages are just as effective on the programmers feelings as the manager coming up to look at your code and pointing a finger while bluntly saying "this is incorrect". I don't believe this at all. Not "just as effective", but effective nonetheless. Has an effect on. A compiler is not there to reject "broken" code, it's there to run a state machine over some text and report where it got to. Reporting that state with words that humans use to describe unpleasant situations and problems turns that neutral comparison into an unpleasant state and a problem. It becomes a problem because that's how we describe it. It need not be that.
    - vinodkd 7y ago
      I dont know why you're being downvoted, since the core of your idea is valid from a usability perspective. F0-X,think about the way Google Maps (or any other map app for that matter) "corrects" you vs other programs/apps that throw up an error message. When you make a wrong turn, the map software re-routes you based on that choice instead of telling you you're not following its instructions. It assumes your choice is not mistake and goes with it, while still trying to get you to you destination. Now imagine your compiler (and by extension, IDE) doing that, and you get what I think jodrelblank is getting at. Two problems, however: 1. Our interaction with language interpreters/compilers is less conversational and more episodic: we submit what we think is "cooked" code, and it tells us where it isnt. If instead it were a conversation, then we'd see more of an "I think you meant this, not that" type of error message. Go and other newer languages are trying to do this with more descriptive error messages that propose alternatives, as are features like incremental compilation. 2. We really cannot specify the goal with a general program. How do you translate "I want an app that plays sudoku" into something a compiler can understand and guide you with? Or even something seemingly simple like "Convert celsius to fahrenheit"? Since the problem space is unbounded, language tools use the bounds setup by their syntax.

by F-0X 7y ago

jodrellblank 7y ago

And this is a dismissal of the idea that words have effects on people. Do you think a manager's choice of words has no effect on their subordinates? Do you think a book's choice of words has no effect on the reader? Do you think ALL CAPS IS NOT SHOUTING AND IS PERFECTLY NORMAL? Are all software tools the same experience for you - you never find one frustrating and another pleasant, one neutral and another you curse at? It's just a message to highlight what is wrong. Nothing is wrong. That's the point. Unfinished code doesn't work, that's normal, not erroneous. (Almost tautologically so - of course it doesn't work, it's unfinished).

F-0X 7y ago
> And this is a dismissal of the idea that words have effects on people. No. Context is important. A manager, a human being with authority, is very different to a standard, unchanging message baked into a program. Your claim and comparison (to me right now, correct me if I'm wrong) seems to be that IDE error messages are just as effective on the programmers feelings as the manager coming up to look at your code and pointing a finger while bluntly saying "this is incorrect". I don't believe this at all. > Are all software tools the same experience for you - you never find one frustrating and another pleasant, one neutral and another you curse at? They are not. Ironically it is the ones that don't produce direct error messages (especially css) that anger me the most. > Nothing is wrong. That's the point. Unfinished code doesn't work, that's normal, not erroneous. (Almost tautologically so - of course it doesn't work, it's unfinished). There's more than one state code can be in while incomplete. It can be incomplete because it doesn't accomplish the task it is being written for yet, but all the same it will still compile. If it is syntactically incorrect, it doesn't even matter if the logic attempted to be expressed is correct, the program is broken. But these errors are easy for a computer to expose - so they should, so problems are fixed as early as possible.
- jodrellblank 7y ago
  Ironically it is the ones that don't produce direct error messages (especially css) that anger me the most. [..] But these errors are easy for a computer to expose - so they should, so problems are fixed as early as possible. Yes, they should. As I said elsewhere, I'm not suggesting silencing errors or having no feedback at all. That would not be the computer assisting the user in writing correct code, that would be another way of hindering it. Your claim and comparison (to me right now, correct me if I'm wrong) seems to be that IDE error messages are just as effective on the programmers feelings as the manager coming up to look at your code and pointing a finger while bluntly saying "this is incorrect". I don't believe this at all. Not "just as effective", but effective nonetheless. Has an effect on. A compiler is not there to reject "broken" code, it's there to run a state machine over some text and report where it got to. Reporting that state with words that humans use to describe unpleasant situations and problems turns that neutral comparison into an unpleasant state and a problem. It becomes a problem because that's how we describe it. It need not be that.
  - vinodkd 7y ago
    I dont know why you're being downvoted, since the core of your idea is valid from a usability perspective. F0-X,think about the way Google Maps (or any other map app for that matter) "corrects" you vs other programs/apps that throw up an error message. When you make a wrong turn, the map software re-routes you based on that choice instead of telling you you're not following its instructions. It assumes your choice is not mistake and goes with it, while still trying to get you to you destination. Now imagine your compiler (and by extension, IDE) doing that, and you get what I think jodrelblank is getting at. Two problems, however: 1. Our interaction with language interpreters/compilers is less conversational and more episodic: we submit what we think is "cooked" code, and it tells us where it isnt. If instead it were a conversation, then we'd see more of an "I think you meant this, not that" type of error message. Go and other newer languages are trying to do this with more descriptive error messages that propose alternatives, as are features like incremental compilation. 2. We really cannot specify the goal with a general program. How do you translate "I want an app that plays sudoku" into something a compiler can understand and guide you with? Or even something seemingly simple like "Convert celsius to fahrenheit"? Since the problem space is unbounded, language tools use the bounds setup by their syntax.