Slashdot Mirror
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.
The most interesting thing about the article for me is that Tucows let you buy a higher rating!
no sig.
Like someone else said, the most interesting factoid was that you can buy rating stars on Tucows. Also, I had to laugh at:
I think this guy is crying out to be a Qt developer....
What I'm listening to now on Pandora...
Maarten Hekkelman doesn't like Mac OS X. He also doesn't seem to me to know much about it, nor does he seem to want to know much about it. He disliked the operating system offered on the platform on which it had developed a following, that is the simple reason why Pepper is no longer a viable option.
;-)
To justify my statements, amongst other thing, he says:
Mac OS X, however, loses on all fronts. It claims to be a Unix but it doesn't support much of the more advanced Unix features, since it is using such an old kernel.
For someone who is writing a text editor to blame the limitations of the kernel of the operating system on which it runs for lack of functionality is simply looking for excuses and is, in reality, a case of barking up the wrong tree (though he does mention a reference to a very old misfeature with regard 'piping', though there are/were very easy other ways to do the very same thing).
Though not exclusively based on FreeBSD 4.4, MacOS X 10.2 is based very heavily around a FreeBSD 4.4 core and, of course, GCC 3.1. Neither of these are 'old' by any practical definition.
Though the kernel has a certain level of maturity, the Mach layer currently acts primarily only as an abstraction layer for developers and has been very heavily hacked at since it's use in NeXT. The kernel is not 'old' nor 'krufty', despite the distinct impression given.
Maarten Hekkelman also says:
Did you ever consider dropping support for the old Mac OS, and making Pepper only for Mac OS X?
No.
I can understand not wanting to be locked in to Coca, but refusing to drop OS 9 (at the very least apart from bug fixes) was a mistake. More effort should have been spent on the Mac OS X (and Windows) versions.
Part of being a good developer is being able to make smart decisions. To keep supporting an out-dated operating system when it is clear that are other badly needed new features that need to be addressed (features needed to keep the product viable) is foolish.
Though I don't know him, the fact that he has now left development and gone to 'Database Administrator' speaks volumes to me about his ability to strategically plan product development, and his proficiency as a developer. I don't like to be critical of someone I haven't met, but that is the distinct impression I get.
I fail to see why a truly good developer would want to do this, as database administration is tedious at best and mind numbing at worse (and 1.5 TB systems are really not that interesting quite frankly, a Network Appliance Filer installation will do the job for you and is easily maintained part time by any administrator, with multiple redundant disks, multiple network connections, multiple power supplies, multiple controllers, the ability to roll back to previous versions (snapshots) and the ability to use Snap Mirror to keep a up-to-date version running off site which you can simply switch over to if the system goes FUBAR - makes it a no-brainer of a solution). I should point out, in the interest of fairness that they are not the only ones that make such a product (there are many cheaper competitors more suitable for smaller scale installations), but theirs is the best IME
Another thing I find telling is that he seems to dislike and find it hard to adjust to many things in Mac OS X and to dislike them quite passionately. I personally dislike little in most operating systems, other than crashes. IMO true hackers (as-in-the-coder-sence-of-the-word) never find it difficult to adjust and I have always believed this ability it to be innate in good hackers.
For example, I have never sat in front of something like Project Builder and bemoaned it's single window behavior (as Maarten Hekkelman does in this interview), I found it quite intuitive. I found it equally intuitive to have multiple windows, I've never had a problem with either. I also have no major problems with the Dock or with the Windows taskbar.
Of course I expect *users* to get confused over this sort of thing, but not developers!
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.
No surprise there. He's an old Be bigot, and Apple's decision to buy NeXT instead of Be is probably the #1 reason why his favorite operating system is dead and gone. Nobody hates OS X with greater blind passion than a hard-core Be fan.
Whatever Avi Tevanian and/or Steve Jobs does over the next 10 years, for any company, I guarantee that this guy will hate it.
If you asked an Amiga or Atari user what he thought about Macintosh System 7 back in 1987 or so, the shrill of his whines would have been at about the same pitch.
Oddly enough, when an unpopular OS dies, the former users never seem to blame the most popular OS for killing it (Windows), but instead lay the corpse at the feet of the #2 player (Apple). Probably because these also-ran companies (Commodore, Atari, Be), having failed to get traction with general users, tried to shoulder their way into niche markets that Apple is known for (media, music production, publishing, etc.) and rapidly went out of business in the attempt. Just a theory, anyway.
Information wants to be anthropomorphized.
Primarily, a dynamic runtime. Want to know if an object implements a method? Ask it with -respondsToSelector:. Want to get a class object given its name? NSClassFromString(). Want to set a property of an object, when both the property name and value are determined at runtime? Use -takeValue:forKey:. C++ has none of these capabilities (at least last time I checked), and they are very useful in a variety of areas.
Almost all Software Engineers agree that most of the software development process can/should be automated.
Which is another argument for Objective-C, since programs using it tend to be much shorter than C++ programs. The line you don't have to write doesn't have a bug.
C++ is going to allow engineers to develop software that doesn't depend on run time conditions, but more on compile time conditions.
And you can write static code in ObjC if you want to. But in C++ as soon as you want dynamic behavior, you end up writing tons of code (and therefore bugs) to reproduce the features that more dynamic languages give you for free.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
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