Pepper Author Calls It Quits
gruber writes "Maarten Hekkelman, author of the cross-platform text editor Pepper, has thrown in the towel. He announced last week that he's discontinuing Pepper. He agreed to an interview with me, on topics ranging from the state of Mac OS X to the difficulties of cross-platform development." It's quite an interesting read, even if he does currently prefer Windows XP over Mac OS X and Linux.
While it is not a complete C++ solution, Apple has been persistently working on improving ObjC++ support. With ObjC++ all your GUI code still has to be in ObjC, but your business logic can stay in C++. Since GUI code is platform specific anyway having to use some ObjC should not be that objectionable to non-zealots. Every release it has better support, so obviously Apple knows that this is a priority with some customers. Plus Carbon is still around. If the Pepper guy didn't want to write reentrant code, well, that is a bummer, but the more reentrant code in the world, the better thread support will be, and the faster Mac OS X will be.
Hyperbole is the worst thing ever.
Well first off let me state that I'm not qualified to answer. While I know C++ I don't know Objective C; further my programming for last 5 years has mostly been in Perl and print stream languages. Other than by accident I've had nothing to do with ObjC, not because I don't like it but because I never need to work in that low of a language for anything I do.
Here is what Apple says on the issue
####Start Apple Quote
Moreover, Objective-C is a simple language. Its syntax is small, unambiguous, and easy to learn. Object-oriented programming, with its self-conscious terminology and emphasis on abstract design, often presents a steep learning curve to new recruits. A well-organized language like Objective-C can make becoming a proficient object-oriented programmer that much less difficult. The size of this book is a testament to the simplicity of Objective-C. It's not a big book.
Compared to other object oriented languages based on C, Objective-C is very dynamic. The compiler preserves a great deal of information about the objects themselves for use at runtime. Decisions that otherwise might be made at compile time can be postponed until the program is running. This gives Objective-C programs unusual flexibility and power. For example, Objective-C's dynamism yields two big benefits that are hard to get with other nominally object-oriented languages:
#### End Apple Quote
Almost all Software Engineers agree that most of the software development process can/should be automated. Why let the error prone human do something when a machine could do it with a high rate of success. That's why almost all manufacturing is done by machine today. Why should the computer be any different.
I tend to agree. I'm not sure how that argues for C++ which is appears to be somewhat lower level. Certainly the extremely dynamic typing of Perl is something I make use of very heavily.
C++ is going to allow engineers to develop software that doesn't depend on run time conditions, but more on compile time conditions.
That's true. But OTOH I'm not sure how that helps quality. Again consider Perl; certainly Perl depends a great deal on run time conditions. But on the whole the extra simplicity of the code means that simple programs seem to work better IMHO (again I'm moving away from ObjC due to ignorance on my part).
If the program compiles, we know that all methods exist in the classes.
That's really easy to check with any kind of "lint" like checker. I doubt Objective C code tends to ship with missing classes (except those linking into libraries they expect to be present).
In my almost 15 years of professional software development, from Basic and Fortran on up to Java and Objective C, the number one impactor of quality of code is memory management. Closely followed by error handling.
ObjC and Java have exceptions, and unfortunately exceptions doesn't completely solve the "recovery from all errors well" path... but Cocoa does even better than java in that many things that can happen (such as calling a method on an ojbect that doesn't exist) which cause a java program to crash with an exception are thrown on ObjC but the program keeps running. They become more like warnings-- which has been great in my experience.
But the number one thing is memory management. In C and C++ it just plane sucks. Its a little better with C++, but in my timeline it wasn't "fixed" until Java. Java does it right, but the GC threads can cause issues if performance consistancy is important.
ObjectiveC does it really right-- you can defer freeing of memory when you want, and you can control it explicitly when you want and it all works rather well. The first C style language I've ever worked with where memory wasn't the biggest issue. (And I'm not talking about my code,but the code of all the programmers I've worked with over the years-- even guys who felt they were experts in C or C++ wrote code that cause memory bugs)
Objective C gets memory management right and it does so without being over-bearing about it.
I was dreading going to ObjC from Java, but I have been very pleasently surprised. I can say with confidence that you will write better code and have fewer bugs writing with ObjectiveC than with C++.
Its worth getting "Building cocoa apps" from Orielly and working thru it.
Yeah, and you guys panned the ipod too: http://apple.slashdot.org/article.pl?sid=01/10/23