Malcolm: Usability improvements in GCC 8
Malcolm: Usability improvements in GCC 8
Posted Mar 16, 2018 14:15 UTC (Fri) by ledow (guest, #11753)Parent article: Malcolm: Usability improvements in GCC 8
It was understandable back in the day for things like "Syntax error on line 3". That was enough to go on, a decent human could track the error down, and your compiler was tiny and efficient.
Nowadays? Sorry, but there's no excuse. Let's spend some of that precious time and deep tree-making analysis to actually pinpoint the problem, why it's there, and take a stab at the most likely fix (e.g. if(a = b) should suggest correction to ==, etc.)
My favourite GCC error that I've received in real life was this:
expected 'struct Player *' but argument is of type 'struct Player *'
Nope. Don't spend ages looking for the wrong space or fancy Unicode or something. It complained because one file defined struct Player one way, and another another way. And because of the way it was done, there were no compilation errors until you get this, because it only sees the wrong definition (so it doesn't warn you of a double-definition anyway). And obviously, in any IDE, when you click on the struct it takes you to the definition that you expect and you're baffled why it does that. Maybe only for a minute or two, or only if you have certain flags turned on (I think it was -Wall -Werror, but whatever), but I loved that message so much I screenshot it.
I'm still waiting for the day when the compiler / application / OS not only flags errors but YOU TELL IT what was wrong and it tries to correct in future from that. Imagine that. An application does something you don't want. You click on the little ? button in the window. You point it at the thing that's wrong (the button that isn't enabled, the field that's greyed out, the wrong size listed for a file, the inaccessible path on the filesystem, etc.) It asks you what's wrong, you select from some options and tell it what you EXPECT to have happened. And then it tells you why. "That button is disabled because this checkbox isn't ticked." "You can't press submit because the two password fields don't match".
In a way, you could make an entire programming language based on that. Start with a blank sheet. Query it. When it asks what you expect, draw a button on the screen. It now knows to draw a button. Now click the button. Nothing happens. Click the ? and point at the button. Scroll back through all the mouse moves and clicks it detected. What were you expecting on the button click? The *dropdown select* colour of this *click* window to turn *click* this colour. Now it does it.
Of course, it would be limited but I'm honestly waiting for a system that's based more on what the user wants/expects than what the designer intended. Where you say "No, you did that wrong" and then correct it.
It would make a nice basis for AI training (if you believe that'll be viable this century) but also it should be possible to say "Well, this bit of code says no, and the reason it says no is because of this condition, and the user obviously isn't aware of the condition".
