Computer bugs, or errors in software, can mess up just about anything: They’ve been blamed for missing homework, blackouts, prison breaks and even the loss of multimillion-dollar space probes. Andrew Ko, a computer researcher at Carnegie Mellon University, talks about a new debugging program, Whyline.
Researchers seek simpler software debugging
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
There, I said it. I mean it.
What an utter load of BS.
Give me 1.2 million dollars and I’ll give you something a hell of a lot more functional than a number-parser for some obscure educational language for the pocket-protector crowd.
What a load of hooey. How does this even qualify as news?
I might be misunderstanding the article, but I fail to see the importance of this tool from a users perspective. Wouldn’t solving the actual bugs be better? This is more like saying “Well, we are unable to compete unless we release half finished buggy products, but at least we let the users know what the bugs are.”.
Sure, it’s practically impossible to release a bugfree application, especially when they are as large and complex as many apps are today. But that’s no excuse for the beta-quality applications that we see sold as point releases all the time.
The development is going too fast, and we all know it. Why just not go to the root of the problem and slow it down?
Sadly, companies are afraid of doing so because that could possibly make them look weak compared the competetors. So the only hope seems to be free software, where money isn’t an issue.
because free software is always flawless right?
let’s be honest, what software is bug-free?
– Remove distractions
– Understand the problem (I mean, really)
– Break the problem down in to smaller problems that can be solved in one page of code (if you have 100s of pages, you are trying to do far too much at the same time!)
– Design a solution which solves the problem and only that problem and is a simple as possible (but not simpler)
– Write small routines (e.g. 10 lines is *far* to big)
– Test every routine interactively and thoroughly
– Don’t write lots of code
– Don’t re-use code (libraries, copy-paste)
– Don’t layer code deeply (2 layers is more than sufficient)
– Don’t bind later than necessary (e.g. don’t have runtime conditional execution if this can be resolved in the design)
– Don’t have compile-time conditionals
– Don’t have configuration files!
– Throw it all away and try again, until it works flawlessly and you are aesthetically pleased with it. Do this often.
Notes:
– Doesn’t work if you’re dumb
– Doesn’t work well with most conventional languages
– Doesn’t work if the problem is really a non-problem
– Doesn’t work in most corporate environments
– Doesn’t work with large, legacy pre-existing code
– Debugging megabytes of code is nigh-impossible
Howdy
Doesn’t work well with most conventional languages
I was reading that list thinking about how you came up with such rubbish but then i found that line, honestly if you have no idea about the “real word” don`t post rubbish then add a conditional that basically says “this works in my own little head”.
I`d love to know what qualifications you have Luke because it really sounds like your just another l337 PHP scripting HAX0R trying to give advice that you have no idea of, basically like most trolls online.
Well, I was just throwing in a few ideas I’d picked up here and there. I think the way I presented it was a bit too assertive and bold, with unrealistic black-and-white certainty. Uhh, maybe I could have done that more tactfully…
I guess I don’t exactly have the right to be telling people how to do things, but I am not really trying to. I will be *starting* a Uni CS course this year, never programmed for a company, that might give you an idea of how little experience of the ‘real world’ I have. Never touched PHP.
Yes. I think you’re right. Most of the points won’t work in the real world, so I guess they are useless in that context. I guess if you are in the computer industry you will have to work with the languages that the company uses, and large legacy code bases, and be compatible with the operating systems and file formats that everyone else uses, and so on. Maybe what I am trying to say is that, it is not a good place to write software if bug-free is such a high priority.
If you think those ideas are bullshit, please let me hear if you have any. Certainly current industry practice doesn’t seem to be working very well. I can think of a few points a threw in there that are questionable. For example: “Don’t re-use code” is a pretty stupid idea if you have some very high-quality code just waiting to be used.
How about actually reading my post instead of assuming that I’m a GPL-troll?
I actually said that writing bug-free software is practically impossible, but that the money-factor certainly isn’t helping.
The fact that major open-source software is considered having so many flaws is because most people are using the software before they have reached a point release. I mean, right now Firefox is crashing a lot for me, but I don’t expect it to be stable since it’s v0.9. At v1.0 I would have expected a lot more from it.
During the first 10 minutes I spent with the initial release of Windows XP I found no less than 16 easily discovered GUI-bugs, there weren’t fixed until SP2 and some are still there. How come the largest software company in the world release such crap?
I have yet to discover a bug in Gnome2 though, I’m sure there are a lot of them, but I haven’t found one yet.
GUI-bugs in Windows XP? Maybe I’m just so used to Windows that I don’t notice them, but I have yet to find anything obvious or easily-found. Mind pointing out a few bugs that remain in SP2?