Slashdot Mirror
Steve Jobs thinks Objective C is Perfect?
josht writes "Nitesh Dhanjani has posted an e-mail thread between Steve Jobs and himself. Dhanjani argues "I'd like to see Apple developers gain more choice. With every iteration of OSX, there seems to be so much effort put into innovation of desktop components, but the development environment is age old." I agree with Dhanjani. What has Apple done recently to wow the developers, and make it fun to code Cocoa components? I've looked into the Objective C and Xcode environment but compared to Microsoft's .NET solutions, it doesn't impress me at all. I think Apple can do a lot better. Steve Jobs disagrees. What do the readers think about Objective C and Xcode?"
He's already taken down the emails in question, apparently having had second thoughts about the appropriateness of posting private emails.
Sure, Xcode could do with a little bit of work to add features missing, but I truely find Cocoa a dream to work with. One year ago I only developed for the web, then I bought a Mac and was introduced to Cocoa by a friend. I havent looked back since, and have produced several 'scratch the itch' applications that otherwise wouldnt have been made.
posted an e-mail thread between Steve Jobs and himself.
I always knew Steve Jobs was just a little bit crazy.
The development environment is hardly static. Key-value-observing and bindings, Core Data; we get more toys for every system version and they are working on adding garbage collection to Objective C.
Objective C is a very good language. I has a lot of the atractive OO features and still it lets you get as close to the machine as you'd like. For example you can drop into C and do your own memory management for parts of the code where you are allocating and deallocating lots memory. You can also code in assembly if you feel the performance gain is necessary.
.Net to use any language is kind of sexy, but I'm not sure you are going to gann anything in the long run.
Objective C appears to be a good development environment. Apple for example, has developed a lot of software in a short amount of time that is of very good quality: Safari, ITunes, Page, Keynote, mail...
The ability of
-b
As an old-school programmer (20+ years of Fortran, C, various assembly languages, C++ many many years ago), who's spent the last dozen years or so focused almost exclusively on server-side high-performance networking systems (in other words, heavy-duty C/Unix/threading), I've taken my 'spare time' in the last few months to teach myself ObjC/Cocoa, Java, and some of the .NET technologies. I found it unfortunate that Apple deprecated Java + Cocoa in the last XCode release -- not because I particularly enjoyed Java but because it was easier to learn both Java and ObjC at the same time when I could be doing the same things with it.
... and I'm guessing the set of people who have is extremely small nowadays.
Comparing ObjC to what MSFT offers nowadays seems to be apples and oranges (no pun intended) and the learning curve is much different -- coming from straight C, ObjC is much cleaner, and I can slide more extensive Cocoaization in as I go. On the other hand, the ObjC syntax is a mess and weird for people who've never done Smalltalk
As for development environments, so far I've _hated_ everything to do with visual * -- it seems to be a monster to use, to customize, and to work with efficiently, at least for this old Unix hack. XCode is far far far from perfect -- I wish the SCM integration were better, that the whole thing were a _lot_ faster, and that they'd release incremental documentation updates rather than 250M batches every couple weeks -- but since it's all wrapped on gcc/g++/gdb/make at the back end, you can entirely do your stuff with vi/emacs/whatever at the command line and never use the GUI much at all, if that's your preference...
Actually, if you pronounce the word "Cocoa" a certain way, with the accent on the second 'o,' it sounds like a Portuguese word meaning, well, to be polite, "excrement." You should have seen the look on my wife's aunt's face (they are from Angola) when we were walking through the cereal aisle of the supermarket and she saw "Cocoa Puffs." :-)
A dumb developer will write bad code in ANY language. And of course, he'll blame the language
he gives the inside story on Steve Jobs:
No, Raskin gives his opinion of Steve Jobs. Read Andy Hertzfeld's book for some perspective on Raskin.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Jeff Raskin was NOT the creator of the Mac. He was the originator (IIRC) of the Macintosh project, and its first manager, but his vision of the Macintosh was so at odds with Jobs', that to give Jef any credit for what the Macintosh became is unfair and incorrect. If you want to see Jeff's vision, go look at the Canon Cat, which he designed after being asked to leave teh Macintosh project.
Raskin was a smart guy, but he wanted to design interfaces for smart people; interfaces that had a learning curve associated with them due to all sorts of key combinations to remember. Though he backed away from this a little later in his life, when he saw how successful GUIs were (and, perhaps, wanting to claim an unfair amount of credit for that), all his interfaces were designed to be incredibly efficient for the intelligent geek who wanted to take the time to learn how to use them.
That doesn't really go along with the Mac's tagline "The computer for the rest of us."
Remember that history and fact are not the same thing. Jef & Steve both have (well, in Jef's case, had) their versions of what happened; neither is fact, and the real truth, if there is one, probably lies somewhere in the middle, probably a touch closer to Jobs' version, that is, if you know how to interpret the Jobsian language and make sure to read it outside of the RDF.
The one thing I really like about Steve Jobs... well there are lots of things. The thing I like most about Steve Jobs is that he's unusually candid in email. I have written him a few times in the past from everything about OS X to vegan recipes and he's replied, often with expressed interest and candidness. This is something not to be abused. When this kind of stuff is publicized, I worry about two things:
1. Steve gets inundated with tons of dumb emails just to get a "response from steve" to hang on the wall. End effect is that Steve stops reading his email.
2. Steve stops being so personable because he figures anything he says will end up splattered all over the web. Within a few days, this simple "Dear Steve, I don't like Objective-C" thing will be blown out of proportion by cnet, dvorak, and other journalists who are entirely too clueless, et al. Remember, what Steve says could affect stock prices, etc. And Steve will just sigh and stop responding.
It's really, really nice having a CEO that doesn't just communicate through press releases, folks. Don't ruin it. It was my hope that those few who knew Steve responded to his email would keep it on the down low.
Well, Copeland and OpenDoc are pre-Jobs Apple, so go yell at Amelio or Sculley about those two.
On the rest of it, Apple never made a blanket "use Carbon", or "use Cocoa" claim. They said, consistently, to use Carbon if you have a lot of legacy toolbox code, and to use Cocoa if you were starting a project from scratch or were bringing things over from NextStep. OpenStep is just the old name for Cocoa and Rhapsody is just the old name for OS X, so you're kinda overstating your point just to make it look more schizophrenic than it really was.
Metrowerks was in it for the money just as much as anyone else; they weren't "there" for anybody but themselves (and later, their shareholders). Once Metrowerks released a Windows version, they stopped giving the Mac priority and the tools stagnated. Apple inherited a perfectly good IDE from NeXT and Metrowerks gave no indication that they were chomping at the bit to upgrade their tools in a urry so that developers could be ready when OS X came out. Metrowerks wanted to play it cautious and didn't want to gamble on Apple's transition to OS X, so what else was Apple to do? I've met relatively few people except a few cranky old Toolbox guys who didn't want to make the transition to OS X, who aren't happy with Apple Developer support compared with what it was historically. The Inside Macintosh books used to cost an arm and a leg and weren't available in soft editions, MPW was a nightmare, as you stated, and the only other way to create applications was to buy third party IDE.
Life has been pretty good (not perfect, but pretty good) since Apple bought NeXT. It's been tumultous at times, but has steadily been heading in the right direction, and as a matter of fact, developers have not been leaving the platform in droves; there has been a well-documented and steady increase in the number of developers using OS X as their primary platform.
I'd hardly say they're "suffering".
Many of your complaints with the language seem to be much more a "it's different from other things, therefore wrong."
Namespaces is the one I see foisted around the most. I can see some value to adding namespace, but not enough to muck up the language. Objective-C was designed to be the simplest wrapper around C as possible while enabling an OO approach. With the much flatter hierarchies Objective-C's weak-binding and dynamicism encourage, the lack of namespaces is a relatively minor thing. Some people want them, but there's really no compelling need for them. I, for one, am glad that Objective-C has avoided the "throw in everything but the kitch sink" approach that has caused C++ to bloat in recent years.
Abstract class support? Again, why? The language doesn't need this. Objective-C's approach is to trust that the developer knows that he or she is doing. It doesn't take the paranoid approach that C++ and Java and the other Modula-3 inspired languages do, but that's not a flaw, it's a design choice. Objective-C is bad for stupid programmers, that I'll readily admit.
All methods are public, but they don't have to be advertised in your header file. Again, it's the nature of the language, and the result of a conscious design choice, not a flaw. You don't need this, even though many programmers have been indoctrinated into thinking they do.
I give you some points on the constructor issue. A language-level support for the DI or an official "constructor" method would be a good addition and add relatively little to the language and runtime. Garbage Collection is not something I personally want, but I know many people do; it's in the works. GCC 4.0 has support for it, it just hasn't been fully integrated into Cococa yet. Probably with the next release (is it Puma? I can't even remember all the cat names any more).
The interface can exist as separate code, though. All the stuff that IB serialises is available through the Cocoa API (check out the docs on NSView and NSControl, for example), and can be instantiated directly with programming statements if you wish. Using IB to keep the UI code separate from the stuff that interacts with it is however a better way to work, as it allows modifications to be to made the UI without having to recompile the application (separation of concerns).
MS recognise the above, and will themselves be following a similar route in the future with XAML, which is set to replace WinForms as the UI-building methodology of choice once Vista is launched (XAML will be one of the Vista technologies back-ported to XP). WinForms is thus in life-support mode at the moment: they will fix bugs, but not add more features to it because it is considered to be a deprecated technology.
NB: I've adopted a mixed-mode approach to Mac programming that seems to work very well from a productivity viewpoint. I do a lot of the main stuff in AppleScript or F-Script, and "drop down" to Objective-C for performance-critical stuff, custom Cocoa sub-classes, Darwin-related tasks, and other things that AppleScript or F-Script either isn't good at, or does too slowly. One could of course do this equally well using (for example) Python with the PyObjC bridge, and I believe that there is something similar for Ruby (don't quote me on that, though!), so the scripting languages I use are just one of the options available to Mac developers. And XCode happily manages all the different language files from a single project, ensuring that Obj-C code is compiled before running the interpreted stuff, managing CVS repositories, and generally making the experience pretty holistic.
I'm not going to change your sheets again, Mr. Hastings.