1) RB is not stable and reliable enough. It's mostly the controls and windows which aren't stable enough, the raw data processing (objects, arrays, methods, etc) are totally stable in my experience.
I'm not sure I agree with that statement, but I can't say without an example of what led you to this.
2) RB does not give you enough control! All professional apps ultimately need to take fine control over everything, even if they rarely use it. No company can risk a product being killed because of a buggy control, instead they'd just fix the control's code themselves.
I don't know if whatever framework Delphi uses is open or not so that developers can see and edit the source. Cocoa is not, so what do you do with a "buggy control" in Xcode? Do you risk your product being killed? .NET is not either, so why are so many corporations using it? Hitting a problem in an API, framework, or library and not being able to fix it directly sucks. Trust me, *I know.* But the worst, most financially damaging problem I ever hit was not in a developer tool but in Mac OS itself. Apple fixed it once, it came back, and Apple refused to fix it. Granted, this was compounded by issues on the developer tool side, but I lay the blame squarely at Apple's feet. While we're at it, there are a ton of products killed by 68K -> PPC, Toolbox -> Carbon, and OS classic -> OS X. You think Apple cared? This hits on a conversation I recently had with another developer where I said that I'm tired of building my house on sand, I want rock: standards and API's so stable that code I write today will run 20 years from now, and not in "emulation" or "classic layers". We don't need new and more interesting ways to tell an OS "open window here, put button there, execute this code on click". We don't need to reinvent the wheel and reintroduce bugs squashed over years of use in the old code. You can base your product on an Apple API or tool and have that API or tool ripped away from you without notice. Microsoft has been a little better about this, but not much. Ask any VB6 user. Give me a buggy control in RB any day! RB is fairly responsive with bug fixes, and if they don't respond I can roll my own. It's the OS changes that are truly killer.
The fact that RB's controls are not suited to high demand situations does not help. If the controls were perfect but can't be altered, that might be OK. But right now RB's editfield is the biggest problem with RB. It's just slow, and awkward to program with, and limited. 3) RB does not offer enough low-level speed. I've asked for pointers time and time again, but RB does not give it.
This idea pops up every so often on this list, i.e. that RB is not "high performance" or suitable to "high demand". I disagree. I'm hard pressed to think of a single API/framework control (Toolbox, Carbon, Cocoa, Win32, ..NET) that is high demand/high performance enough for every conceivable use. When you find that your definition of those terms is beyond the framework control you would normally use, you take a long, hard look at the problem you're tackling and you roll your own. Performance is not easy, and is more often than not related to architecture rather than language (though C will admittedly bury RB on certain types of tasks; fortunately you can build a C library and call it from RB). I speak from first hand experience on this. I've had a recent situation where an RB control just couldn't cut it. The Apple control did better but still couldn't cut it, so Xcode was no help either. So I rolled my own *in RB*, with a couple C functions for a little extra boost, and that control effectively buries what's available prefab in Carbon, Cocoa, Win32, .NET, etc (oh yeah...for chosing an RB solution I got Windows thrown in as a bonus). Not that you couldn't do it in something other than RB, you could. But RB can do it to. As is often the case high demand/high performance means a custom, optimized architecture. (And if I ever get a breather from my clients to finish the product, you can all see what I'm referring to.)
There has been now two programs I *could* have used REALbasic on, but decided against it, to use Xcode instead. I'd really loved to have given RB a chance, but I'd really look stupid in front of the boss if I recommended to him a tool that broke down sometimes, and meant we were delivering a flawed app, that we could not fix because RB is a closed environment.
I just can't help but laugh at this. Wait until Apple burns you on an issue. It doesn't happen too often. Let's see: QuickDrawGX, OpenDoc, Newton OS, 68K, Copland, anything involving telephone API's, extensions, MPW, numerous Toolbox API's that are now dust, Carbon slipping behind Cocoa, PPC, AltiVec.... I remember a very successful consultant telling me that he admired Mac OS but wouldn't touch Apple because they had no commitment to legacy code and he didn't want to get burned, and this was BEFORE the Copland fiasco! If anything I feel a bit more secure building a product on top of RB. They've shown a commitment to a stable framework interface that is cross platform and cross generation. With any luck they'll be in business for decades and I'll have the rock I want to build my software on. Daniel L. Taylor Taylor Design Computer Consulting & Software Development [EMAIL PROTECTED] www.taylor-design.com _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
