Why I wouldn't use REALbasic

Aaron Ballman just posted a Warning about some undocumented limits in REALbasic for Windows. Now at first you might think: Good that he posted this warning. People could have screwed up their apps this way. My thought is: How can he calmly say this? This is a bug! If a compiler can be caused to generate invalid output files just by specifying a string over a certain known and fixed length, without a warning on output, it is simply defective. This should be a warning along with a mention that they're working on fixing this, not tell the programmers as if this was intended.

Update: Aaron just e-mailed me telling me that this is a bug to him, too, and he updated his blog accordingly. That's better. Still, I didn't jump to this conclusion because of this one posting; While Aaron posts lots of interesting things in his blog and I love to read them, many postings mention the most complicated workarounds for certain problems caused by the design of the language itself.

Note that this post was named Why I won't use REALbasic, not Why you shouldn't use REALbasic. This is simply a personal preference, and not a slam on RB. In my opinion, a language needs a certain level of elegance, which comes from a design that takes into account interactions between certain features and thus avoids the nastiest surprises. Like Transcript, REALbasic just doesn't seem to have been designed with that in mind. It just gained new features.

And in addition, Aaron forgot to make it clear in his postings that he's posting about bugs. This reflected badly on the development process of RB. It has lots of features, a convoluted design that needs lots of workarounds, and now it seemed to have people working on the program who thought it's okay to have the programmer account for what turned out to simply be unfinished parts of the software.

So, I may have done Aaron himself wrong, and I apologize for that. Instead, I'm going to complain about the programmer who actually coded this limit, which Aaron pointed out was fairly arbitrary. Not for coding in that limit, but rather for not placing a guard on the inputs, and for apparently not commenting and documenting it well enough that the IDE authors could limit their entry fields. And no matter how much you are in a hurry to meet a deadline, you should always be able to turn on input validation for a field and set it to allow no more than 39 chars...

A similar issue just reared its head yesterday at work, BTW. We are refactoring a huge CMS that's been in use for ages, and I'm one of the guys tasked with making sense of it. "Software archaeology" is fun, and I have the advantage that Jens, the guy working on another project next to me, has past experience with that system and will readily answer any questions. But I was a little shocked how little all the special cases the system historically acquired are documented. I would have at least expected a comment next to the wackier calls saying "Special case #14, as per customer's request". Oh well, it has several now that actually say why this special case is there, and what it does.

Reader Comments: (RSS Feed)

No comments yet

Or E-Mail Uli privately.