> I am currently VERY READY to migrate an app we wrote in C > with CodeWarrior to anything else. We agree on the benefits > of C, but I think my other comments on High Level Languages > are somewhat correct, and being in business to make money, > and develop quickly, I think it would be the best use of > programming resources to go that way, IF AND ONLY IF, they > provide the expected results.
Just to take this off the list for a bit, since I'm going to include some more specific information than I feel comfortable telling the world at large. What my company has done is to create a generic framework in C++, which we then use to create the applications our clients request from us. It's gotten to the point where two of our developers can create a basic Palm/PocketPC app in a week. That's with 12 or so screens, local and connected modes, and persistent user preferences. If you're going to start over, I highly recommend creating a similar body of code for your own company, since you'll then get some of the benefits of a high level language, and few or none of the costs. It's almost a shame we're not selling the framework yet. ;) The problem with HLLs on the Palm is that they all have hidden costs. Garbage collection takes processor time and memory to implement. As do dynamic types, bounds checking, and all the other things that make programming in high level languages such a joy to do. You can add some of these things to your C++ framework (we've currently got all our classes extending from a class called "Object", which does reference counting, so we don't need to worry as much about memory management. And we've done a couple of other things that would look very familiar to a Java programmer), but the main advantage in using C++ is that you have control over what you are doing. If the reference counting is too expensive, and you know you're only going to have one of the objects, then you don't have to subclass Object. There's no way to do that sort of thing in Java. > I appreciate your comments, as I agree fully with the > approach you took and realize, no matter what development > platform we may choose, it will still have to have device > /OS specific code segments. I hope you are right that > much more than 20% of the code will be common, as that is > when development resources would be used efficiently to > make multiple platform development cost effective. Yeah, I estimate that between 75 and 85% of our code for any given application is common. Like I said, we've got models, views, and controllers, and the only differences are in the sub-classes of views. We've even managed to push some common view methods into the base classes. > So, I take it your vote for this job is C++. Tough call. If it's a one-off job, and you don't know C++, then C++ probably isn't the best choice. If you're going to build a bunch of applications, and want something that will grow with you, and that you can build onto in the coming years, then C++ should suit you just fine. > I also see that David Martin believes that APPFORGE > also could be a candidate, but David doesn't use APPFORGE. I've heard good things about AppForge, but with the caveat that if you want to do things that it doesn't think you should, it's really hard. (For instance, I haven't seen any Palm games written with it. Oh, wait, apparently there is a game written with it. Neat. It's almost a pity I'm not a VB programmer, or I might check it out.) > John Blackman suggested Satellite Forms. Same benefits, same restrictions, only more so, since it really thinks that what you want to do is design applications with screens that get and set data from persistent storage. If that's what you want to do, then it'll be far faster than other things. If not, then you'll be hitting your head against it. > I heard of a company in France who has a dev system that > supports something like 4 dozen platforms. Sounds neat. > I also feel that it is not only important that these dev > systems be able to do the job, but it is important that > the companies that produce them are legitimately willing > to support their product. Support is obviously an important point. I'm not sure how you'ld check for that, other than to go with a company with a history of Palm products. > Anybody have any other suggestions, or is this all that is > worth looking at in today's dev system market? I think you've covered the main ones. There are a few smaller options, which I don't think are relevant to what you're trying to do. You've seen the page at: http://tangentsoft.net/palmfaq/ right? Later, Blake. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
