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?"

Comments

namespaces

[Anonymous Coward]

Anyone claiming a language lacking proper namespace support is "perfect" is nothing short of delusional.

Re:namespaces

[Anonymous Coward]

...or Pixar.

Re:namespaces

[kongjie]

All you have to do is look at Jobs' history to see that being a "manager at Sears or Circuit City or something..." would not have satisfied his ambitions. If you're seriously suggesting that, you've misjudged the man.

You may be right about his programming talent (I'm not saying you are) but clearly you don't know a single thing about human nature.

Re:namespaces

[jcr]

Steve Jobs doesn't know a single thing about programming.

Yes he does, he just hasn't done it for quite a while.

-jcr

Re:namespaces

[Anonymous Coward]

Nobody gets to be as successful as Jobs without a lot of talent.

Re:namespaces

[saltydogdesign]

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?

Re:namespaces

[The Clockwork Troll]

I'm guessing your voice has changed a lot in the last few years.

The emails are already gone.

[CapnRob]

He's already taken down the emails in question, apparently having had second thoughts about the appropriateness of posting private emails.

Re:The emails are already gone.

[Knytefall]

Here are the emails:

From: Nitesh Dhanjani
Subject: Re: Will XCode+ObjC ever suck less?
Date: December 25, 2005 5:27:02 PM CST
To: sjobs@apple.com

I look forward to the improvements! Thanks,

Nitesh.

On Dec 25, 2005, at 5:10 PM, Steve Jobs wrote:

I guess we disagree. First of all, .NET with CLI and managed code runs SLOW, so most serious developers can't use it because of performance. Second, the libraries in C# are FAR less mature and elegant than those in Cocoa. We are working on a better implementation for garbage collection than we've seen out there so far, but in the end its a performance hit and an unpredictable time that is not good for some kinds of apps.

Steve

On Dec 25, 2005, at 2:36 PM, Nitesh Dhanjani wrote:

Objective C is old and clunky. Its almost 2006, and I _still_ have to look out for yucky pointers? I'd love to be able to write native apps with Ruby (or even C#!.) There are open community projects in progress that are trying to bind ruby and C# (mono) with Cocoa, but I'd love for Apple to step in and make this happen faster. Today, Microsoft seems to be _way_ ahead of the development curve - with their .NET implementation, you are allowed to code using a plethora of languages (C#, Python, VB, etc), as long as the interpreter/compiler follows the IL specification - pointers don't matter, garbage collection is done for you - ah the beautiful world of managed code.

Having said that, most native OSX apps are still beautiful and well designed. Imagine how much better we could do if the developers had a more flexible choice of languages? I can _bet_ you a lot of OSX app developers use Objective C because they have no other choice.

Nitesh.

On Dec 25, 2005, at 3:11 PM, Steve Jobs wrote:

Actually, Objective C is pretty great. Its far nicer than most other ways of writing apps. What don't you like about it? What do you like better?

Steve

On Dec 25, 2005, at 11:59 AM, Nitesh Dhanjani wrote:

Hi Steve

Will it ever be easy to write native OSX GUI apps? Objective C sucks.

Thanks,
Nitesh.

Re:The emails are already gone.

[Yaztromo]

And this, kids, is why you should never ever top-post.

Yaz.

Re:The emails are already gone.

[soft_guy]

I'm sorry, but I have to agree with Steve and completely disagree with Mr. Dhanjani. I think that the language "choice" on .NET is silly - you can use whatever language you want so long as the language has exactly the same features as C#. For example, look at the feature set of "managed C++". No multiple inheritance and other non-C# features have been removed. Same for other languages.

I program with Objective-C and Cocoa all the time. I am mostly happy with it and in fact I will not be using the Garbage Collection feature for my apps.

I have complaints about Cocoa, but not being able to program in Ruby or Python is NOT one of them.

Re:The emails are already gone.

[noidentity]

A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Making it "fun"

[Rude Turnip]

"I agree with Dhanjani. What has Apple done recently to wow the developers, and make it fun to code Cocoa components?"

What, a fun and whimsical name like "Cocoa" isn't enough for you? Perhaps you'd prefer to code in puppies and rainbows?

Re:Making it "fun"

[tomcres]

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." :-)

Re:Making it "fun"

[RobNich]

"I'm caca for Cocoa P--"
"Damn it! Take 47!"

Love it

[Richard_at_work]

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.

Re:Love it

[rplacd]

On the other hand, after several years of writing code in mostly python and other similar languages, the thought of going back to something like C (pointers!) doesn't really motivate me to write code for my mac. It's a good thing there are bridges like py-objc and such.

(Disclaimer: I first became aware of Objective-C about a decade ago, and have used IB/etc on Openstep -- on a NeXT slab, even).

Re:Love it

[jiushao]

This is an interesting point, a lot of people will stick on a higher level no matter what you define the interface in. On the other hand it would clearly be bad to define the platform interfaces in Python, sure it would perform fine for 95% of all tasks (these are system calls and such to a great extent after all), but it would still be too inflexible in implementation. It is troublesome trying to wrap a powerful Python interface in a lot of languages and systems, even when not considering the language and call model features Python still has a lot of runtime features that show through (garbage collection is already in itself very troublesome at the system interface level).

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".

Re:Love it

[Yaztromo]

On the other hand, after several years of writing code in mostly python and other similar languages, the thought of going back to something like C (pointers!)

If this is what is keeping you from developing with Objective-C, then you've picked a poor reason to avoid learning it.

Pointers are as easy to avoid in Objective-C as they are in Java. In Java, all reference types are in fact a pointer, but simply a pointer which you don't need to think about. There is no pass-by-value for reference types, and no pointer arithmetic is allowed.

In Objective-C, everything is again passed by reference (as opposed to by value). Pointer arithmetic is generally completely unnecessary (although it is technically permitted).

I recently finished v1.0 of a decent sized Objective-C application, and the "&" operator isn't used once. The '*' operator is only used when defining a variable, return type, or parameter.

I don't even think of pointers when coding in Objective-C. I tend to think of it as no different than Java. Extra capabilities to do pointer arithmetic are there, but I simply don't typically feel the need to use any of them.

Yaz.

well...

[soapdog]

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

between himself and Steve Jobs

[Dachannien]

posted an e-mail thread between Steve Jobs and himself.

I always knew Steve Jobs was just a little bit crazy.

Re:between himself and Steve Jobs

[gotem]

yes, I totally agree with you on that one!

It's not like they're not doing anything

[Anonymous Coward]

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.

Re:It's not like they're not doing anything

[am 2k]

Agreed. I just started using CoreData, and it's a pretty amazing technology. For instance, take a look at this tutorial. It's a whole working database-based app without writing a single line of code! If you want custom behavior, enhancing is very easy, too.

Key-Value Observing has revolutionized Cocoa development, most developers just didn't notice (b/c it takes some time to get used to it).

Re:It's not like they're not doing anything

[jcr]

If you think CoreData is cool, check out what you can do with Quartz Composer. Every value in the composition is reachable through keypaths.

-jcr

Wowing developers...

[Svartalf]

While wowing the developers is important, also providing them with a high performance, high reliability, and easy to use framework is important as well- moreso than wowing them. It does no good if it's "cool" to develop for a programming language, etc. if I'm spending 2-3 times the coding time for the other one or 2-3 times the debugging time, etc.

C#, for all of the claims of performance, is a a JIT based interpretive language. Ditto Java.

C#, for all of it's nicety, is little more than Java taken in MS' desired direction. If it weren't for Mono, C# wouldn't even be a subject of discussion as it'd been an MS only tool for use only on Windows (or whatever MS ends up calling thier stuff in the future...)

C, C++, and Objective-C are stable, robust languages that have been around for some time now. C# has not been around all that long, but since it's got all the "buzz" about it, people keep trying to deploy it everywhere.

Objective-C is actually a fairly clean OO language, moreso than C++. C++, while it's really good, has been muddied up with a bunch of conflicting design ideas that make for some...fun...with your coding if you're not paying attention to what you're doing.

All in all, I'd say that it's decent enough for doing Apple development- if you want to adapt Mono to that interface (Which, I believe, can be done...) knock yourself out.

Re:Wowing developers...

[Rew190]

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.

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 .NETs attraction seems to be that it is very simple to put together GUI-driven applications (that actually look they're Windows programs) quickly.

Re:Wowing developers...

[coolgeek]

Memory management in Obj-C is really simple, and making issue of it is an extreme exaggeration. You merely have to follow the rule of "if you allocate it, you're responsible for it", and make sure to either send it [obj autorelease] upon allocation or [obj release] in the [parent dealloc] routine. It really is that simple. Maybe that's too much to ask of the sissy programmers coming out of school these days.

Re:Wowing developers...

[Durandal64]

I'm sorry, but I have to disagree. Objective-C has the most intelligent syntax of any language I've ever worked with. Just because none of the latest "miracle" languages, like C# and Java, have adopted a new function calling syntax doesn't mean there aren't problems with it. Frankly, the constructor naming for C++, Java and C# is brain-dead. What makes more sense?

color = NSColor(128, 128, 64, 0);

or

color = [NSColor colorWithRed:128 Green:128 Blue:64 Alpha:0];

I would much rather have an idea of what parameters are without having to refer to a header file. And being able to have initializers that are of different names is a HUGE plus. In C++ et al, all your constructors are forced to have the same name, varying only among their parameters. I could do a

color = [NSColor redColor];

call and still get a new color object. In C++, you'd have to pass in some sort of enumerated constant or something.

And this says nothing about the ridiculous naming conventions of C++ and Java. Translate the following statements into English.

value = object.getValue();

and

value = [object value];

The 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.

Re:Wowing developers...

[Leimy]

Non-sissy programmers make mistakes that can let in all sorts of problems with buffer-overruns and other fun vulnerabilities. C is a terrible language for trying to write "secure" or "safe" code.

I'm not saying C is bad for all situations. I just wouldn't use a saw to drive a nail.

By the same token I try not to find problems for my solution.

It may be very simple to do the refernce counting by hand, I'm just saying that it's possible to do a lot of this stuff automatically in a language design. See Limbo. It even has a way to get out of dreaded cycles that cause reference counting to leak memory [a cyclic keyword]. It's a shame Limbo only really works with the Inferno OS.

Also C++ has libraries of things like shared_ptr that do the reference counting in the constructors and destructors of the object. It also can suffer from the cyclic reference leaks of course but the need to double check code or even suspect it of being wrong at the "use" level is greatly diminished.

At the end of the day it's worth noting that no language is perfect, and just knowing the syntax doesn't make you a good coder. It takes practice... and just having a degree in CS isn't gonna make you great.

.NET is a bit complex

[netwiz]

Personally, I prefer Obj-C to .NET, mostly due to the (IMO) superior organization and layout of the object model. It's simpler than .NET's API, which tends toward "everything and the kitchen sink." Not that Cocoa doesn't have it's problems. It's probably more difficult to write big projects using it, but for quick development, I find it faster to just throw something together in Xcode. Besides, it doesn't hurt that Xcode and it's related dev tools are free on OSX, whereas it's a $600 investement on Windows for the equivalent software.

A good example of the complexity is the file access models for both APIs. .NET has something like three different objects to deal with different types of file access. Cocoa implements these in a single object with multiple methods for the data access style (streaming, read the whole thing once, etc.) Now, it's probably just personal preference on my part, but why invent multiple objects when you could just roll them up as separate methods for what is essentially the same data structure? There's probably a reason, and I'd be interested in learning why this is so, but it just seems to me that Cocoa did it right in the first place.

Re:.NET is a bit complex

[rplacd]

Actually, that points to another place where objective-c trumps Java or .Net: you can add (your own) methods to classes you don't necessarily have the source code for; see this bit on categories.

Re:.NET is a bit complex

[jcr]

You can accomplish the same things with inheritance

No, you can't.

If you add methods to a class with an Obj-C category, all instances of that class gain those methods. This is not the same thing as inheritance, where only instances of the subclass have the new capabilities.

-jcr

the Wow factor.

[revery]

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 hard to beat

[brindle]

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.

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 .Net to use any language is kind of sexy, but I'm not sure you are going to gann anything in the long run.

-b

Re:Objective C is hard to beat

[jcr]

Actually, Safari is largely written in C++ (the KDE rendering engine), and iTunes isn't an Obj-C app at all.

For some better examples, there's Xcode itself, Aperture, iPhoto, Quartz Composer, iChat, Address Book, and so on.

-jcr

Re:Objective C is hard to beat

[jcr]

You're splitting hairs, here. Safari is factored into an App and a couple of frameworks. The bulk of Safari is webcore.

-jcr

Learning ObjC/Cocoa (and others) now...

[piyamaradus]

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.

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 ... and I'm guessing the set of people who have is extremely small nowadays.

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

Re:I dunno

[Tim C]

I've always felt Visual Studio (at least with all the .Net stuff) was turning more into a Visual Basic type of dev platform.

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 .NET after all - is it really surprising that the drag and drop method of RAD is being further extended?

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

Network Mirror

[BushCheney08]

Network mirror still has the original blog post up.

Dev tools plus/minus

[boatboy]

As a .NET developer, I haven't looked too hard at Mac dev tools, but I will say I could see an argument that Microsoft's rich development environment has some unexcpected consequences. Microsoft has made it easy for just about anybody to pick up software development, and as a result, just about anybody has picked up software development. =)

This can be good, but a downside is that some of the emphasis on design, best practices, etc. is lost. An office nerd who happens to get into VB is not traditionally pushed to think about things like standard UI guidelines. So in a sense the rich toolset can detract from good software. MS seems to be aware of this, and you can see a definite push for more guidance from them. Still, they have a ways to go IMO, and finding the balance between making development easy and making it "good" is difficult.

Xcode rocks.

[wangmaster]

There are legions of NeXT fans that would disagree with your statement regarding .NET. The Interface Builder component has always been considered one of the most elegant, easy to use, intuitive UI constructing tools out there. It does what it needs to do, is well integrated into the rest of the tool (and the language) and just plain rocks. I have yet to use a UI layout tool that comes near the ease of use and effectiveness of InterfaceBuilder.app. When it comes to Xcode (or ProjectBuilder.app as the old NeXT fans were used to), it's also an intuitive, easy to use project management system. I don't like IDEs, I hate IDEs. I prefer vi/vim to do all my code editing. The nice thing about ProjectBuilder in old days (I'm not sure about Xcode, I haven't had the opportunity to do much with my mac mini yet) was that it did what I needed (collect all my files in a nice visual fashion, manage my building and integration with UI components, and built skeleton files). It does all those things well, without forcing the user to be hampered by some built in editor components. There are legions and legions of developers out there that consider the NeXT development tools to be the ultimate developer toolkit (and objective c is a pretty nice language). It's nice to see it didn't disappear into history :)

Every time the ObjC/C++ discussion comes up...

[squarooticus]

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

Re:Every time the ObjC/C++ discussion comes up...

[penguin-collective]

"You don't know C++ well enough to judge its value as a language."

Ease of learning is an important part of language design.

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

The amount of effort a language forces you to invest up-front in design decisions is also an important factor to consider.

Personally, I think C++ is a great language--but only for specialty applications and very skilled programmers.

For most mainstream desktop applications, people are better served with Python, Visual Basic, or Smalltalk, precisely because those languages are easier to learn and require less experience to use well.

Re:Compared to Intellij IDEA, XCode sucks

[cosmo7]

So why don't you use Eclipse then? Objective C isn't wedded to XCode.

The article is about Objective C (and Cocoa) versus C# (and .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?

Re:Compared to Intellij IDEA, XCode sucks

[morcheeba]

Why was this modded insightful? It's just namecalling and has no information.

Honestly, I would like to know why you think IntelliJ IDEA and the other IDEs are better than XCode. What features do you find important that are missing, or was there some unliveable annoyance? What language do you code in, and what level of debugger support are you expecting? IDEA doesn't seem to support C, so while I would get the benefit of less suckage compared to Xcode, I would have to switch programming languages.

Your post had potential...

Re:Objective C was a neat idea in the 80's BUT...

[joto]

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

Can't go home again

[TapestryDude]

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

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" ... 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.

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.

Re:Objective C was a neat idea in the 80's BUT...

[caerwyn]

"Now, of course you can just call C functions, but then what is the point of objective C?"

The point of any programming language is to give the developer the tools they need to efficiently (programmer time + machine resources) accomplish the goal they set out to do. No more, no less.

Not using C functions simply because objective-C has methods is ridiculous; the language has the direct functional call built in for *exactly* the reason you're discussing. I write performance code for simulation data display in Objective-C; it simply requires a little thought into what functions require absolute maximum performance (and can therefore tolerate the lack of flexibility) and what functions (such as GUI functions) are better off with the dynamism that Obj-C methods provide.

I don't care what language you're programming in, but if you completely ignore one of the tools that the language provides you and then claim that the language sucks, it's difficult to lend any credence to your opinion.

Re:Objective C was a neat idea in the 80's BUT...

[fpillet]

Overall, objective c message call performance is comparable to Javascript.

You haven't written any real code with Objective-C, have you ? I have a couple commercial apps written in full Obj-C and I can tell you that what you're saying is plain wrong. The message dispatcher is fast, uses caching techniques, and in case you have a really tight algorithm that neeeds to send millions of messages to perform some computation, you can always get the IMP pointer to the final address instead of going through the dispatcher. But I certainly never felt the need for that.

A dumb developer will write bad code in ANY language. And of course, he'll blame the language ;-)

Now, of course you can just call C functions, but then what is the point of objective C?

... or what's the point in any OO language, when you can code in straight C? Exactly the same: designing and structuring your code. The single selling point with Objective-C / Cocoa is the NSAutoreleasePool mechanism. This mechanism is like a garbage collector finally done right.

Modern languages like Java, C# provide all the dynamsism of objective C, but do it effciently thougth vtables and reflection.

Reflection is insanely costly to use. Actually MS recommends to avoid it if you can, especially on mobile platforms. Besides, are you saying that Java or C#, both JITted languages, are faster than Objective-C ? Think twice. Microsoft itself says that C# is slower than the less optimized C compiled code you can find. And I have yet to see a Java app doing anything significant that is not slow as molasses.

Re:objective-c is cool

[spectre_240sx]

I hear that constantly, but actually it's the biggest thing that turned me away from Cocoa programming. I'm far from a professional coder, but I just can't get my head around building interfaces and connecting them to the code with all of these menus. I'd much rather just write the code myself. Maybe after working with it for a while I'd learn to like it, but it made it hard for me to get into it and I ended up going for Java instead.

Notes from a Cocoa AND .NET developer

[hkb]

I code various C#/.NET things at work, and code Cocoa stuff at home for fun. I'm well-versed in both environments.

- The environments are apples and oranges (no pun intended). The languages, the workflow, everything is much different.

- Moving away from ObjC would require some significant reworkings of Cocoa, as its workflow is based on the "ObjC way". Take a look at the mess that is the Cocoa/Java bridge, or Cocoa#.

- Objective C is WAY more descriptive than other languages (take a look at how you pass arguments in functions, for example).

- Objective C is easy to learn. Yeah, it's a lot different than the usual paradigms, but when you learn it, you'll enjoy its simplicity.

Things I hate about Cocoa:

- It's not managed code. Why should application developers in this day and age have to worry about memory management? (autorelease doesnt count)

- Having to keep two different programming paradigms in my head. I never even learned C#, I learned Java and jumped right into C#, because they were so similar.

- Practically no one else in the world uses Objective C, so it's not a very valuable (salary-wise) skill to have.

- The X-Code/Interface Builder dance is quite clunky. It was cool back in the day, but Microsoft has a much better system developed.

- VS.NET 2005 > Xcode

Jef Raskin on Steve Jobs

[Savantissimo]

Jef Raskin, the creator of the Mac, wrote a piece, Holes In The Histories in which he gives the inside story on Steve Jobs:

Another cause for inaccuracy is the deliberate misleading of reporters, coupled with some reporters' tendency to believe an apparently sincere and/or famous source. Levy's book gives prominent thanks to Apple's PR department, which learned the history of the Mac from Steve Jobs, whose well-deserved sobriquet at Apple (and later at NeXT) was "reality distortion field." Many times I had seen him baldly tell a lie to suppliers, reporters, employees, investors, and to me; Stross's book provides many examples of this. When caught, Jobs's tactic was to apologize profusely and appear contrite; then he'd do it again. His charm and apparent sincerity took in nearly everybody he dealt with, even after they'd been burnt a few times. For those who didn't know him he seemed utterly credible. In his defense it should be pointed out that some reality distortion is necessary when you are pioneering: when I am conveying my vision of the future I create a non-existent world in the minds of listeners and try to convince them that it is desirable and even inevitable. I'm pretty good at this, but Jobs is a master, unconstrained by "maybe" and "probably." His attractive creation-myth--swallowed whole by susceptible reporters--wherein Apple's computers were invented exclusively by college drop-outs and intuitive engineers flying by the seats of their pants became legend. To hear him tell it, the Macintosh had practically been born, homespun, in Abe Lincoln's log cabin. That it had been spawned by an ex-professor and computer-center director with an advanced degree in computer science would have blown the myth away. A good story will often beat out the dull facts into print.

Re:Jef Raskin on Steve Jobs

[jcr]

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

Re:Jef Raskin on Steve Jobs

[theAtomicFireball]

Jef Raskin, the creator of the Mac,

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.

Re:Objective C was a neat idea in the 80's BUT...

[metamatic]

If you look closly to objective C, it is really not a language, it is just C with a enhanced macro pre processor.

C++ started out as C with a special preprocessor. So what?

Performance is ABYSMAL compared to any modern language because message sends (the objective C equiv of a method call) has to go through a dispatch map.

I'd be interested to see some up-to-date figures to back up your assertion. GCC 3.1 gave a 2x speed increase in method dispatch, and GCC 4.0 has -fobjc-direct-dispatch.

msgc_ObjSend without the GCC 4.0 optimization is 22 cycles. Somehow I doubt that's really your big performance issue.

Modern languages like Java, C# provide all the dynamsism of objective C, but do it effciently thougth vtables and reflection.

This is the usual Java/C++ argument of 'There is no value in dynamic typing, because I can write a program that does the same thing using static typing'. Well, yes, and I can write a program that does the same thing in machine code, but that doesn't mean high level languages have no value.

Some of us like having introspection, metaclasses, true parametric polymorphism and so on, without having to implement ugly workarounds. Personally, I think that ubiquitous (implicit) dynamic typing is a major aid to code reuse and software development agility.

Re:Compared to Intellij IDEA, XCode sucks

[diegocgteleline.es]

YOU suckf

Re:No garbage collector

[the eric conspiracy]

GC does not necessarily cause load spikes - as modern Java collectors have proven it is possible to to do GC without machine pauses.

On the other hand, smart pointers fall well short of what Java offers - since smart pointer based software typically suffer from reference count bugs, and don't handle references loops. And doing the memory collection inline rather than in a seperate thread is a real disadvantage - but then it isn't like C++ has a threading model anyway.

C++ really suffers in many ways by not having modern GC and threading support. It is really starting to look like modern technology is passing it by. THis is becommng more and more of a problem as processors become increasingly parallel.

better solution

[penguin-collective]

The next generation Objective C and Xcode already exist: Smalltalk and Smalltalk programming environments.

Smalltalk is a language with Objective C's object model, but runtime safety, garbage collection, and reflection. Objective C was an attempt to create a very low overhead version of Smalltalk that would interoperate more easily with C code, but most of the technical reasons for making the compromises that were made in the design of Objective C are gone.

The only thing that would need to be done would be to extend Smalltalk with a notion of "native" or "unsafe" methods; that has been done multiple times before, and it can be done either by permitting C code to be embedded in Smalltalk (reversing the Smalltalk/C situation from Objective C) or by defining a Smalltalk subset that's close to the machine (as Squeak has done).

Re:Objective C was a neat idea in the 80's BUT...

[uwmurray]

Dude you're nuts. Have you even *looked* at gcc's objective C support and the runtime or are you just pulling this out of your ass? Obj-C messages are highly optimized and incur about 2x-3x the overhead of C function calls.

Objective-C / Cocoa has it's warts, speed is not one of them.

As slow as javascript my ass. I doubt you've ever coded in obj-c. Please study a bit before you spread this kind of FUD.

Re:Compared to Intellij IDEA, XCode sucks

[laffer1]

You don't get why people use regular expressions obviously. They are extremely useful for input validation. You do validate your input don't you? Desktop apps require it just as much as scripting or web applications. One of the joys of .NET is how easy you can create a regular expression or use built in ones (visual studio). Microsoft started pushing them for input validation because it can offer a quick way to sanitize input from sql injection and other attacks. I don't think apple developers have the same mindset about security that a MS developer has. Think about it, using a mac you forget about security. I don't run antivirus on my mac, or spyware tools and i dont' worry when i open my email or surf. On my windows machine, I worry if my virus defs and anti spyware are current or when my last scan occured. Every time I open IE, I remember that i can only go to trusted websites.

Nothing stops you from using a third party regular expression library like pcre. Or simply use the java - objective c bridge in cocoa to use java's regex stuff. Although java is a second class citizen, it is supported to some degree with cocoa.

As for xcode vs intellij, I would never use xcode for java after trying intellij. I use xcode for c/c++ programming all the time though. Its a great ide. I like the debugger interface as it reminds me of microsoft's vb.net debugger in some ways. One thing microsoft doesn't do is add a decent spell check library to .net. Apple's got that covered. Its also incredibly easy to create an opengl window from what i've seen. Menus look better in cocoa than vb or c# as well.

I don't think its fair to compare cocoa and .net. Cocoa is more like MFC and its obvious apple's winning there. .NET is more like java. Now maybe one could argue apple should beef up their cocoa to java bridge and document it better to compete with microsoft. Maybe they should add a third easier language to cocoa, i.e the vb for apple machines.

Objective c vs C++ is what people should be comparing here. I can see objections to syntax with objective C. It is much different than modern languages using the "." notation and so forth. My wife and I both have trouble remembering the syntax for objective C, but I haven't tried that hard to use it yet either.

If you think cocoa is so bad, try to write a .NET app in managed C++ sometime. C# is java and vb is easier c#. Its like comparing real basic to C and declaring real basic easier to write a graphical text editor in.

Apple could add more libraries to cocoa. That would be helpful. I personally found it confusing to connect buttons and objects in interface builder to backend code compared to .NET. Coming from a windows background its weird and feels like extra steps.

Don't ruin Steve, please

[hkb]

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.

Re:Apple blew off Metrowerks. Now they must suffer

[theAtomicFireball]

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".

ObjC problems are many

[I'm Don Giovanni]

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.

Re:ObjC problems are many

[theAtomicFireball]

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

Re:objective-c is cool

[Weedlekin]

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.

Re:Compared to Intellij IDEA, XCode sucks

[samkass]

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.