4 ms·

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 m

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.
- zmj 7y ago
  > Compare that to C# and a dictionary lookup which either returns or throws an exception - and there is no alternative. FYI, there is an alternative: TryGetValue. https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic.dictionary-2.trygetvalue https://docs.microsoft.com/en-us/dotnet/api/system.collectio...

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.

zmj 7y ago
> Compare that to C# and a dictionary lookup which either returns or throws an exception - and there is no alternative. FYI, there is an alternative: TryGetValue. https://docs.microsoft.com/en-us/dotnet/api/system.collections.generic.dictionary-2.trygetvalue https://docs.microsoft.com/en-us/dotnet/api/system.collectio...