Originally posted by Jukebox Hero
Thanks for the tip, but no thanks for the snotty, greater than thou attitude (Way to bring Windows developers into the fold!!).
Your point about doing interface design in C++ was bizarre, though. You can, if you really want to, but it's not like Apple doesn't offer options with slick tools backed up by rich and mature frameworks.
I browsed around and found the following link, which describes Apples recommended approach:
Heres the exerpt:
Developing a Java Client Application
The essential tasks you need to perform when creating a Java Client application are listed below:
1) Create a model using EOModeler.
2) Create a project using Project Builder.
3) Write source code for enterprise-object classes (if your enterprise objects require custom business logic).
4) Create your applications user interface with Interface Builder (Java Client approach).
5) Customize your applications user interface (Direct to Java Client approach).
6) Write source code for any application-level logic.
The problem with this approach is that alot of business application developers have beened burned by C++ application frameworks.
Where are the C++ application frameworks here? You're looking at WebObjects, which is a client-server application design and deployment suite built 100% in Java. Its frameworks have been stable and mature for years now (dating back to when it was implemented 100% in Objective-C - it's never had anything to do with C++).
The only C++ application frameworks for the Mac that I'm aware of are third party solutions like MetroWerks' PowerPlant.
C++ adds an entire class of bugs that don't exist in languages such as Java (or as MS calls it; managed languages).
Huh? I remember Java back in the 1.x days, and it was so buggy that our class once fixed a bug by changing the name of a local variable
. In other words, there was a bug in the symbol table implementation! I've never even heard of that in a C++ compiler.
If anything, managed languages (or, if you prefer, 4GLs) are more
vulnerable to quality of implementation issues. Another such thing cropped up with a "managed language" we were using at work, called Forte. They'd implemented arrays as hashes, and in one update they borked the hashing algorithm so that every eighth member of an array vanished into the ether. This, in a $50,000 toolset. At least in a 3GL like C++ if some library has a bug I can drop down and roll my own replacement, and expect it to run well. (In Objective-C, I can pose the replacement as the buggy original, and write all my code as if I were using the original framework! Then when the vendor fixes the bug, I can yank out my workaround without changing a single line of code.)
I have to wonder why you're so fixated on C++ on Apple's OS? It's there. It's available if and when you need it. But none of Apple's frameworks use C++, or even target it as a primary development language; nearly all of Apple's frameworks are mature and battle-tested at this point (there are, and will always be, bugs, but the same is true of Java and .NET). You can use Objective-C, Python, Ruby, Java... and C++ when and if it makes sense to. Most people who use C++ on the Mac use the pure language, without any framework dependencies, for cross-platform code, and at that point you're very unlikely to run into bugs in the language implementation (unfortunate caveat: Microsoft's C++ compiler).
For example, I spent about 600 hours on a project that got eventually got canceled because of all the bugs in Borlands Visual Component Library (Sorry for the negative press, Borland. Its been a few years and maybe you've fixed your problems). Sure, tools have gotten better at finding the types of memory bugs that create these hard-to-find, company-destroying bugs. But these same bugs simply do not exist in Java.
I'll be the last person on Earth to defend Borland, as their C++ Builder has given us a world of pain over the last year and a half. But that has nothing to do with C++ (Borland's actual language implementation is quite good, it's just their IDE and frameworks and makefiles that suck...) and everything to do with the crap you're linking it to.
So I rephrase my claim to be more specific; I would highly value a framework that was developed on a managed language.
I'm content to know that the frameworks actually work, and that if they don't, the language will allow me to efficiently route around them - because I will
have to do that at some point on any non-trivial project. And if a particular library or framework sucks (*cough*AWT*cough*) I'd like to have the option of not using it.