-
-
A “Debugging Eliza” idea from BOBHYTAPb
Here is a bomb of an idea: A Debugging Eliza.
After a long and fruitless session of debugging a programmer reaches a certain dead end, where he has already glossed over the problem, has not found it, but noted subconsciously that that venue has been checked – or simply didn’t think about it. At this point he needs to talk to someone about this problem – a sort of a psychiatrist, which doesn’t even have to be human – it could be a slightly tweaked version of Eliza.
“What are you doing?”
“I am debugging Blah-Blah Industrial Application.”
“What was the last thing you tried?”
“I checked that the configuration file corresponds to the Blah-Blah…”
“And how is the Blah-Blah?”
“It’s perfectly fine.”
“And how does that make you feel?”
“It means the problem is somewhere else.”
“Where else could it be?”
etc.
Obviously, this is where a lot of problems are found — when you are asking someone for help, and in the process of explaining the problem realize your error.
-
A “Debugging Eliza” idea from BOBHYTAPb
- Eclipse, for all its cool pluggable architecture, lacks a basic thing — macros, which should be easy given the above. That is, a way to record (or write by hand, fine) a series of steps to instruct the Eclipse workbench to do something, and then play it back. Where’s AppleScript when you need it?
For example, instead of creating a walkthrough. Yes, part of the pain in this particular case can be solved by, for example, checking in dot-files into the source control, and then telling everyone to “Import existing projects into a workspace” after checking out the tree. But I can’t do that — there are dot-files of a “competing” approach checked into the repository, which suit some of us fine, but lack the things others want. but that’s in this particular example, and I cannot come up with another case right now, but trust me, they exist.
DEBEDb 