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?"
not being a troll but remember "if it's not broken, don't fix it"? Objective-C and the Cocoa Frameworks are an amazing combo, very productive to code using it. I don't think there's much to add. It's not bloated like VisualStudio.NET, it's easy to grasp and understand, code is small... well, I just like the way it is, and XCode is a lot better than Project Builder so I think we're on a nice path, I don't want to see Apple reinventing its development environment every couple years...
-- Por mais que eu ande no vale das trevas e da morte, meu PowerMac G4 Não Travará!!!
What has Apple done recently to wow the developers, and make it fun to code Cocoa components?
When you pull in developers by "wowing" them, you get a certain type of developer. I certainly don't want my buildings and bridges built by engineers who were attracted to pastel concrete and click-and-deploy girders. Having said that, I realize that sometimes, small quirky apps written by "poet coders" can make a platform a lot more interesting, I just doubt that that's what causes innovation or platform acceptance.
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
I've always felt Visual Studio (at least with all the .Net stuff) was turning more into a Visual Basic type of dev platform.
.NET after all - is it really surprising that the drag and drop method of RAD is being further extended?
I'm not entirely sure what that comment means - haven't you *always* been able to use VS as "a Visual Basic type of dev platform", with Visual C++ even ignoring Visual Basic itself? VS.NET does support Visual Basic
It's more for application development than actual (think CS rather than IT) programming.
Application development isn't actual programming? Theory is extremely important, and I'm the first to defend seeking knowledge for knowledge's sake, but to say that application development isn't real programming is to deny the entire point of programming - to automate processes and create applications in order to make tasks easier (or quicker) to perform, and to enable people to do things that previously they could not (eg edit video or audio).
It's official. Most of you are morons.
...I fire back with the almost-certainly-true statement that "You don't know C++ well enough to judge its value as a language."
I have been coding in C++ for about 15 years; I have seen the language evolve over that time; and while there are aspects that I don't like, for the most part I think C++ is wonderful and natural to program in, as long as one takes the time to design API's in an extensible way. This is no different from any other language, though C++ certainly gives you more rope if you are already inclined to hang yourself; but, OTOH, the extra slack makes it possible to type-safely do things that cannot be done in languages without multiple inheritance or parametric polymorphism.
FWIW, the same is true of me for Objective C: I can make only the most shallow, uninformed observations about it, so I generally avoid doing so. Perhaps one day I'll learn it so I can make an informed judgment about it, but until then, I'll keep my mouth shut.
[ home ]
So why don't you use Eclipse then? Objective C isn't wedded to XCode.
.net). Although I like the former, there certainly are items where the latter is ahead - compare .net's media layer with Cocoa's phoned-in Quicktime classes. Or regular expressions. Where are the regular expressions in Cocoa?
The article is about Objective C (and Cocoa) versus C# (and
Objective C is pretty nice to use, but I think Apple really needs to come up with a language that doesn't require memory management. Not everyone is designing more upscale applications where management is essential. Personally, this is a rather large "fault" of Apple's development platform. Give me something that supports Cocoa (not Java) with managed memory and I'd be much happier.
.NETs attraction seems to be that it is very simple to put together GUI-driven applications (that actually look they're Windows programs) quickly.
It would also be nice if they would use something with a more conventional syntax (I'm looking at you, method calls). Wasn't a huge deal, but I think it would make it easier to dive into or attract developers who are more used to the Java/C#/etc way of doing things.
As a side note, much of
This looks all good in theory. Fortunately, the objective C developers have thought about the problem, and they have come up with a solution that is quite fast. So in the real world, and objective C message send is about 2x-3x as slow as a C function call. Which is not too bad. The obvious implementation you hint at, would probably be more like 50x-100x slower. Fortunately, it's not the one that's used in practice, and I doubt you will ever find it in an objective C compiler (unless you were to write one yourself, just to prove your point).
Objective-C was my first object-oriented language (this was back in 93 - 95). I loved the syntax and the integrated vision of the tools and frameworks ... but I hated memory management. The whole retain/release/autorelease thing was always a bug waiting to happen, and I spent many wasted hours tracking those down (basically, retain/release works great for trees but flops around like a dying fish for graphs).
... meaning that its better to combine many small focused objects. In Objective-C, you have a layer-cake approach, where each layer of inheritance mixes in a particular concern. This makes sense when you want to minimize the number of objects allocated, but in a GC language (Java, Ruby, etc.) you end up with better, more testable code when you let the GC do its thing.
Anyway, I simply can't go back to a non-memory managed environment again.
I have seen that, as I've matured as an OO developer, and as I've distanced myself from Objective-C, my style has changed. The Objective-C libraries are heavily based on inheritance, but I've learned that "composition trumps inheritance"
You can see this in Tapestry, where currently (through the 4.0 release) you extend base classes. I'm starting to gear up to break this limitation for 4.1 (where you will use simple objects and have framework dependencies injected into your classes).
ProjectBuilder was great in its time, but compared to Eclipse, it's hopeless. IB still rocks, and I wish Sun had demostrated some intelligence when first designing Swing by investigating IB. That is, Swing treats UIs as a coding problem, IB treats it as a configuration problem.
But, as I said, you can't go home again.
Howard M. Lewis Ship -- Independent J2EE / Open-Source Java Consultant -- Creator, Apache Tapestry and HiveMind
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."
And this says nothing about the ridiculous naming conventions of C++ and Java. Translate the following statements into English.andThe first is C++ and translates to "Assign value to get the value of object". The second is Objective-C and translates to "Assign value to value of object". This is why Objective-C is called a self-documenting language.
As for memory management, yes, it can be a pain. Any Cocoa developer could tell you tales of how he accidentally released an autoreleased object and spent a half-hour trying to figure it out. But Objective-C is a strict superset of C. Being able to work with pointers is absolutely necessary. That's one of the biggest strong-points of Objective-C. Virtually any C library will work with absolutely no modification at all.
I'd love to see garbage collection added, but not as the primary method of managing memory. It should be there to catch what the developer misses, not to be the sole method of memory management. We'll never get rid of pointers. They will always be there.
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.
Nobody gets to be as successful as Jobs without a lot of talent.
The historical lowest common denominator solution has been to define it in C (though C++ has slowly crept up in the last decade) and then use higher-level bindings to make it easy to use. Gnome is a very modern system that has taken this approach. Apple on the other hand has went one step up on the abstraction ladder, they have kept the basic C interface style and linking behaviour but used the OO added by Objective C. The strong point here is that a lot of higher-level languages can now wrap much closer to the interface (getting close to a natural 1:1 mapping) while still retaining most of the possibility to go with C-style to-the-metal stuff. Objective C is even a nice enough language to make taking another step in abstraction unnecessary for a lot of people.
Personally I really like this. Defining the platform in C has aged (though it is still useful for maximum flexibility of implementation, though very archaic to use) but going straight for a high-level garbage-collected language is a step too far still. For example I think it would be a mistake to enforce a garbage collection model on the system level, removes much too many possibilities from the application. Add to this proper function pointer objects, co-routines, "global" reflection, continuations and so on and it becomes clear that too much power at the interface becomes a liability when it has to be fitted into another system.
This extra power is of course then a good thing for Python users on OSX just as for Objective C programmers. A straight wrapper around Cocoa is a lot nicer than say a straight wrapper around GTK+. Some may argue that this is unimportant since a "good" wrapper around GTK+ will be just as good, but personally I find that a wrapper that stays close to the unerlying interface is a very good thing when possible. Less bugs, often much more clarity, more available documentation, the skills one learns carry over if one switches languages and so on.
Man this post is long and rambling. Better push "Submit".
Here are a few ObjC problems off the top of my head.
:-))
1. No proper namespace support. If multiple teams are working on a project, each team is advised to prepend the method names of its classes with a two or three letter abbreviation to avoid name-collision. WTF?? Hence, why all Cocoa methods are prepended with "NS" (short for NextStep). Apple should fix this asap.
2. Horrible constructor support for derived classes. ObjC makes one proclaim one or more of a class's init methods to be "designated initializers", and these are the init methods that derived classes must override, no more, no less. Oh, and the proclamation of "designated initializers" is informal; there's no formal support by the language or runtime.
3. All methods are public. To implement private methods, one must "simulate" them by not declaring them in the interface header file, but they're still accessible. Implementation of protected methods is even more of a hack, where one must create class Categories that are only known internally, and place the "protected" methods in those Categories. But the Categories are still accessible, and there's nothing stopping a third party from implementing a Category of the same name on his own, causing namespace-collision.
4. Lack of proper support for abstract classes. One has to use [self doesNotRecognizeSelector:_cmd] to implement abstract classes (either in the init method or the individual abstract methods), another ugly hack.
(Lack of garbage collection may also be a problem, although refcounting never bothered me and I rather do like autoRelease, by which one can achieve something akin to garbage collection (for objects, at least).
There are some other problems, all of which (and the above) stem from ObjC being an "old" language, having not added any of the advancements in language and runtime design that other languages adopted in the 90's.
-- "I never gave these stories much credence." - HAL 9000
And this, kids, is why you should never ever top-post.
Yaz.
And I'm sure successful people choose to be born into stable, wealthy societies rather than in some God-forsaken African nation wracked by famine and war, yes? No luck involved there, huh?
// This is not a sig.
While I don't know about the motivations of the original poster, I'll answer your question if you want. I've developed in Visual Studio, CodeWarrior, emacs/gcc, CodeGuide, IntelliJ IDEA, and many of the older packages. In my humble opinion, Xcode is the worst development environment out there that's being actively maintained. Worse, it is being touted by Apple as the preferred development environment for Macintoshes. I can't imagine a better way to discourage developers. Combine it with Objective C, which while somewhat elegant has a cryptic, unapproachable syntax and for all practical purposes locks you into the Macintosh, and you have an anchor on your software development community.
But back to the question at hand...
Although it got better with 2.1, XCode suffers seriously from configuration problems. Determining where to go to set something, where a setting is overridden, or what it actually does is insane. A simple comparison with CodeWarrior is enough to show how far development has fallen for the Mac in this respect. Then there's the plist and such files that are an inevitable part of Mac development these days. Why can't there be some better editor for that sort of thing with a nice GUI? ResEdit from the 1980's beats it. Then there's the error window. You click "compile" and you get a "ding!"... then you hunt for what happened. When you find it, you get a difficult to use pane of errors buried below, but in the same pane as, your project. Huh? Then there's the editor... having lots of files open is a pain compared to almost any other IDE. Then search... for the company that produced Spotlight, searching is amazing primitive in XCode. The general layout is a mess, the build outputs are annoying to keep track of, and things like the class browser aren't nearly as helpful as something like IDEA or even CodeWarrior. Then if you compare it to many of the Java development advantages (since we're including the old ObjectiveC language in the rant,) you start to miss out on TONS of refactoring options that Eclipse and IDEA both offer. Those types of things become essential for keeping code maintainable over the long-term. Things like xgrid for distributed compiling are near-useless for most small developers, so I hope they didn't take away any resources to develop those features, either.
In short, I think the Macintosh community would have been much better served if Apple had simply bought CodeWarrior and wrote a gcc4 plug-in for it for PPC/x86 codegen. Then they could start adding some of the intelligent refactoring, assuming such things are possible in Objective C. Alternately, they could start over with Java or even Mono/C# and provide an environment that would let you create Mac apps quickly and efficiently, as well as being able to use the same code on Mac, Win, and Linux.
E pluribus unum