4 ms·

> 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

by 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.
  - jodrellblank 7y ago
    I dont know why you're being downvoted, since the core of your idea is valid from a usability perspective. Maybe the same people who dislike the recent movements to mandate niceness see this as the same (it isn't) or maybe it's a dumb and unworkable idea. 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. This sounds nicer, but I wasn't thinking of DWIM (Do What I Mean) systems. I was thinking more that .. when you drive into a car park, and the car park is full, you don't think of that as an error, you don't need an alarm about it, you just drive somewhere else and park. You knew that might happen, you plan for it - the car park being full is a normal state of affairs and dealing with that normal situation shouldn't be a completely separate concept handled in a separate way. You don't try to park, experience an error, bounce back to a control thread, try to park on the street, experience an error, bounce control back to somewhere else, try to park round the corner, get a space. You have a preference of places to park where you go to the car park, the street, round the corner, or you go home. And none of them are "error states". It would be annoying if you employed a delivery driver and told them to park in the car park, and they rang you up to say the car park is full, and waited for instruction, then you told them to park on the street and they rang back and said the street was full. Instead you want a delivery driver who will try reasonable things to park, and if they cannot, they bring the package back to the depot and it goes for delivery tomorrow. If it's urgent, you include that in the original instructions and they try reasonable and unreasonable things to park. The "what to do" is built in. Instead of having 4 states, made of 1 good and 3 errors, there are 4 possibles, 1 completes quickly, 3 require more input or more processing, and none are errors. Have you ever used Python's dict.get(key, fallback) ? You pass in a fallback value which is returned if the key is not in the dictionary. Control moves forwards with the possible states handled in advance. Compare that to C# and a dictionary lookup which either returns or throws an exception - and there is no alternative. You either check yourself whether the key is there first, or you handle an exception. There is no way to inform it what to do if the key is not found, no way to tell the dictionary that's fine, no way to tell it to create a new key, no way to give it any information to work with. All you can do is tiptoe around it like a minefield (check before you step), and if it explodes, pick up the pieces. Simply having a polite compiler error message or IDE sugar papering over the Key Not Found Exception doesn't make that design any nicer to use.

by F-0X 7y ago

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.
- jodrellblank 7y ago
  I dont know why you're being downvoted, since the core of your idea is valid from a usability perspective. Maybe the same people who dislike the recent movements to mandate niceness see this as the same (it isn't) or maybe it's a dumb and unworkable idea. 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. This sounds nicer, but I wasn't thinking of DWIM (Do What I Mean) systems. I was thinking more that .. when you drive into a car park, and the car park is full, you don't think of that as an error, you don't need an alarm about it, you just drive somewhere else and park. You knew that might happen, you plan for it - the car park being full is a normal state of affairs and dealing with that normal situation shouldn't be a completely separate concept handled in a separate way. You don't try to park, experience an error, bounce back to a control thread, try to park on the street, experience an error, bounce control back to somewhere else, try to park round the corner, get a space. You have a preference of places to park where you go to the car park, the street, round the corner, or you go home. And none of them are "error states". It would be annoying if you employed a delivery driver and told them to park in the car park, and they rang you up to say the car park is full, and waited for instruction, then you told them to park on the street and they rang back and said the street was full. Instead you want a delivery driver who will try reasonable things to park, and if they cannot, they bring the package back to the depot and it goes for delivery tomorrow. If it's urgent, you include that in the original instructions and they try reasonable and unreasonable things to park. The "what to do" is built in. Instead of having 4 states, made of 1 good and 3 errors, there are 4 possibles, 1 completes quickly, 3 require more input or more processing, and none are errors. Have you ever used Python's dict.get(key, fallback) ? You pass in a fallback value which is returned if the key is not in the dictionary. Control moves forwards with the possible states handled in advance. Compare that to C# and a dictionary lookup which either returns or throws an exception - and there is no alternative. You either check yourself whether the key is there first, or you handle an exception. There is no way to inform it what to do if the key is not found, no way to tell the dictionary that's fine, no way to tell it to create a new key, no way to give it any information to work with. All you can do is tiptoe around it like a minefield (check before you step), and if it explodes, pick up the pieces. Simply having a polite compiler error message or IDE sugar papering over the Key Not Found Exception doesn't make that design any nicer to use.