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.

Comments

Re:Leaving OS X Because of Cocoa

[moof1138]

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.

Re:Bitter and Twisted

[Anonymous Coward]

Say what you want about Microsoft and Bill Gates and all that, but MSDN does in fact fall all over itself to give you everything you could possibly want when developing. Tons of cds full of documents, example code, tools, resources, etc. MSDN *want* you to write lots of programs. More programs means more things people want Windows for.

Sure, Apple does that too, but it's also possible that he started on the Windows side of programming. Anyone who's coded a lot for one platform can attest that you get 'familiar' with the way that OS works inside. Then when you start doing things for other platforms you always end up re-interpreting the question "Given that I want to do (X) and I know how to do it on OS (Y) how do I do the same thing on OS (Z)?" (I always used to do this with Str255 types on the classic MacOS, thinking of everything in terms of C strings and then having to 'fix' everything to be Str255's). If you've done a lot of Qt work, Cocoa looks pretty weird. If you've done a lot of MFC work, just about everything looks weird. I know people who are MFC geniuses though, and I wish I could work with MFC the way they can. It's not just they program in it, it's like they manage to move their internal brain operations to think exactly like MFC does, so they know what MFC wants.

(You may now make your obligatory MFC jokes, I gave you lots of good stuff to quote)

XEmacs??? BBEdit???

[GreenKiwi]

If you want a good free text editor, get xemacs/emacs!

If you want to pay for an excellent editor, get BBEdit!

'Nuf said!

Re:Leaving OS X Because of Cocoa

[jbolden]

What makes ObjC a better language? Is it because there are less compile time restrictions or because you can manipulate classes without making things ugly?

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:

• Objective-C supports an open style of dynamic binding, a style than can accommodate a simple architecture for interactive user interfaces. Messages are not necessarily constrained by either the class of the receiver or the method selector, so a software framework can allow for user choices at runtime and permit developers freedom of expression in their design. (Terminology like "dynamic binding," "message," "class," "receiver," and "selector" will be explained in due course in this book.)
  
  
• Objective-C's dynamism enables the construction of sophisticated development tools. An interface to the runtime system provides access to information about running applications, so it's possible to develop tools that monitor, intervene, and reveal the underlying structure and activity of Objective-C applications.

#### 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).

Re:Leaving OS X Because of Cocoa

[BitGeek]

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.