Here's a fun little challenge I came up with while on my flight back to California: create a simple application that is bug free. This is a demonstration of the fact that "bug free" is a very difficult thing to achieve, if not out-right impossible. I came up with this challenge because I was reading yet another diatribe on the forums from some users who don't seem to reside in the same world as the rest of us. ;-)
So here's the challenge: you are to write an application which calculates arbitrary exponents in pure REALbasic code. It should accept two inputs, and display the output. I don't care how you accept input (EditField, StdIn, etc) or display output (MsgBox, StdOut, etc). We will assume that any form of input and output are considered out of the scope of the challenge. The calculation algorithm should be purely of your own creation (you can't cop out and use the Pow function in REALbasic, or a declare, plugin, etc).
You can submit projects to me via email, or just post a function (or two) in the comments field. But if you enter your submission, please tell me how long it took you to complete this project and your degree of confidence in it being bug-free.
In a future post, I'll discuss common bugs which most people will probably not realize they have in their project, as well as my own submission.
What do you mean by "We will assume that any form of input and output are considered out of the scope of the challenge"? Does that mean you can use whatever input or output as you said before? Does that mean that you don't have to handle bad input? Does that mean you don't have to handle many different forms of input?
@jdiwnab -- no, I mean "I don't care how you get the numbers -- you can hard-code the values, use an EditField, StdIn, etc. "
You certainly have to validate input since the object is to have a bug-free application! I just don't want people to worry about the way the numbers make it into your function. I want people to worry about how the function behaves (does it crash or not?) and the results of the function (are the results correct or not?).
Okay, here's one that does integer exponentiation.
Function Power(x as Integer, n as Integer) As Integer #pragma disableBackgroundTasks if n = 0 then return 1 end if if (n and 1) = 1 then dim p as Integer = Power(x, (n-1)\2) return x*p*p else dim p as Integer = Power(x, n\2) return p*p end if End Function@Aaron - oh you're mean :)
This is an unwinnable challenge for anyone to post "bug free" code. What counts as a "bug" ? CPU & language limitations (ie/ overflow) will induce some "bugs".
Charles code will suffer from that with large values of N and dies with a stackoverflow with negative values of N.
It's possible to write code that behaves under well defined circumstances with known limitations but impossible to write "bug free code" in the generic sense.
@norman -- I like your assessment of the situation. :-) As for your question of what constitutes a bug: things within your control. Register overflows aren't within your control, so that's not a bug (but you could certainly behave nicely if you wanted to). A dog chewing through the power cord is out of your control, etc.
Stack overflows, however, are within your control.
A negative value for n is a bad value, since my function returns an Integer. As Bertrand Meyer said, "correctness is relative to a specification".
Integers are signed :)
I suppose too many years of writing control & monitoring systems for pipelines where "it was a bug" was the phrase that preceded "and the pipeline blew up" :)
Excellent post Aaron. Despite your best intentions, I don't think you're going to change the opinions of the diatribe people.
@Charles -- but you have access to unsigned integers, so if you wanted to limit your function to those values, then you should have declared them as UInt32 instead of Integer. I'd claim it's a bug.
@Bob -- I know I won't. The particular person I had in mind wouldn't hold on to a clue about software quality if it came up and beat him with a brick. But that doesn't mean we can't have fun with the challenge!
I'd tend to agree (sadly)
Overall I think there has been an upswing in bug fixes vs new features (which is good)
I'm hoping the trend to fixing lots of bugs every release continues and that the overall number of bugs goes down.
I think that's what the rant is eventually about ; just couched in terms of "It should be bug free".
if the beta process can identify the bugs early and get them fixed before they get "out in the wild" I think the idea that REALbasic is "just buggy" can be countered effectively. That's an important function of the beta process.
I spend most of my time using the Mac IDE. In my brief forays using the Windows IDE I notice a lot more IDE bugs. I've not been able to reproduce them so it's impossible to report.
YMMV, as they say, and I believe that most of the big complainers are Windows IDE users. To me that's totally representative of the user base being mostly Mac.
Ok. That makes since. I had to write a similar function in assembly for an 8 bit system that only had to deal with integers greater than or equal to zero. Oh, and you could only add. No multiply ;)
Ok, so to be clear, validate input, input of signed integers, and output of doubles? Or unsigned integers with output of integers?
One solution to very large values would be to figure out what values would make the number too big and return an error condition stating such.
@jdiwnab -- well, the specification said "arbitrary exponents", which was me being tricky. I wasn't 100% explicit, but I meant floating-point values as well as integer values for both the base and the exponent.
As far as the software challenge, I'll pass. My brain isn't that big.
As far as 'the diatribe', I stopped reading it after page 2 or 3 or something. Sure, I probably didn't help matters by what I had to say or the contents of my blog posting, but you can count me as one of the more frustrated RB users.
REALbasic is extremely powerful and at the same time still retains a degree of simplicity. Problem is that the IDE and framework have become rife with annoying little bugs. By themselves, these minor bugs aren't too bad, but when taken together, and experienced frequently throughout the day, it can just get on some peoples' nerves...to the point of utter frustration.
Well, I don't know which world you think I live in, but when I have to make a decision to pay a bill or renew an update plan, and the software I've been paying update plans for seems to be getting worse instead of better...it's a bit frustrating.In the world I live in, wasted time dealing with an IDE or framework that has annoying bugs may mean one less sale for me. In the world I live in, the more time I devote to trying to find a workaround for a bug that gets in my way means less time I can spend on adding new features or coming up with new products. For an independent programmer with a micro-sized business such as mine, tools that give me an edge are the ones I choose and the ones I suggest to other programmers. Tools that frustrate and cause me to lose productivity I try to migrate away from and prompt me to warn others.
So far, I've only had one entry! I would have guessed I'd get at least a few more. Did I pick too difficult of a challenge?
@Will
I don't think the comments were necessarily directed at you as you weren't part of the diatribe. I thought your post was relatively benign as far as RB bashing posts go. :)
Actually, this is a fairly difficult problem. While the integer exponent case can be handled quite nicely, the fractional exponent case is a lot harder.
Perhaps you should have posed a binary search or quicksort implementation -- both are notoriously hard to do correctly, but neither relies on previous study of numerical analysis (which I now wish I'd not skipped in college).
Even better, though, would be to ask the person in the forums to offer up some of his bug-free code. Then we could examine it and see how it's done.
@Charles -- you hit the nail right on the head. I'll go ahead and make the follow-up post today.
Dim result as Integer
result = 0/0
MsgBox result
Too easy.. next, please.
@HTML Ninja -- what does that have to do with anything? It just takes the IEEE floating-point representation of NaN and assigns it as an integer into result. No crashes, but also not terribly useful (or relevant).