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

[Anonymous Coward]

>> Had he not known Wozniak, more than likely he would be manager at Sears or Circuit City or something...
> ...or Pixar.

No. This is offtopic, but what's clear from Jobs' experience at Apple is that he had big dreams and a child^H^H^H^H^H undeveloped set of people-management skills.

If he hadn't been thrust into a leadership role early on, Jobs probably would have been another big talker who never mastered the skills it takes to move up the ladder. A lot of entrepreneurs have this problem when they try to move into established corporate structures.

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

[golgotha007]

Show me a single person on this planet with no ambitions?

The Sears/Circuit City thing was just my attempt at humor. However, he would have no where near the success he's had if he didn't have the right friend at the right time.

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.

If you think that Steve Jobs has any programming talent, then you don't know a single thing about Steve Jobs.

Re:namespaces

[Anonymous Coward]

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

Re:namespaces

[Tedium Unleased]

successful people make their opportunities. the other 99.99% of people tell themselves its luck so they can whine and tell themselves they could have been contenders.
successful people may have some charming story involving luck, but of course luck does not keep them on top, and it's probably not much more luck than anyone else has, just like everyone else, they'll associate random events around good events as having some special meaning, or more likely tell you that.

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

[Gentlewhisper]

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?

Btw Steve Jobs was abandoned by his birth parents. Stable and wealthy family indeed eh?

Re:namespaces

[The Clockwork Troll]

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

Re:namespaces

[mildgift]

This is true, but talent and circumstance are both necessary. I raised the issue because everyone's talking about talent, without thinking much about luck.

Also, it's not like he's be able to have so much luck without the big pile of money that the Apple II generated, back in the 1970s. That cash funded a lot of failures, and one hit: the Mac.

The Mac money was spent on a lot of things, but had one hit: Pixar. NeXT was cool, but it wasn't a financial success.

With that string of success, he came back to Apple, made the iMac, brought back the old NeXT software from the dead, and basically trailed Windows for a while... until the iPod... which was originally a me-too product late to the market until it was mated with the music store (which is also a me-too product).

It takes some talent to be that lucky.

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.

[Anonymous Coward]

I also agree with Steve.

To the best of my knowledge he isn't actually a coder. Yet he has concisely and accurately identified the key weaknesses in comtemporary competing products. (Maybe he has good people working for him?).

Managed code like C# (and Java and maybe Ruby, Python, VB) is slow, and this a problem when developing and deploying apps in a competitive market place.

Also garbage collection is a performance hit and does tend to use CPU at just the wrong time.

Actually wrt memory management garbage collection entirely misses the main memory management problem I have to deal with. Now how can I explain what this is... here we go it is "keeping heap out of virtual memory (e.g. off the disk)" (from http://www.theserverside.com/news/thread.tss?threa d_id=29865 i love google).

No comment on C# vs Objective C libraries. I'm not interested in Objective C or C# as I mainly do cross platform GUI development on code that has to be fast. I need mmap more and more.

(Can you guess who I work for?)

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?

Re:The emails are already gone.

[thallgren]

.Net has been referred to as a skinnable language environment. Without much work you end up with C# with another look.

objective-c is cool

[matt4077]

I develop with both objective-c and c# and while I like the c# syntax and gc better, Interface Builder is the most elegant way of user interface programming out there.

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.

Re:objective-c is cool

[matt4077]

Well you don't HAVE to use Interface Builder. You can easily just init your interface programmatically. Although I don't see a reason to do it.

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.

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

[laffer1]

The visualization group has a next machine at my university. I got to crack the root password on it and work on it for a few hours when it was first donated. Its the best computer i've ever used. There are websites selling used ones for 500-1000 dollars if you look around. I've been half tempted to buy one. They are incredible. It is the best computer i've ever used. It felt very fast and it was one of the 68k models. Apps started like they do on my current ibook. The color reminded me of a computer several years newer. It didn't feel like a 256 color windows 3.x box from the early to mid 90s. I've never found a machine that was designed the way I think until that next box. I just wish OSX was more next like.

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.

Re:Love it

[waxwing]

"...a high-level garbage-collected language is a step too far..." Why not a systems-level statically compiled typesafe garbage-collecting language? There is such a thing, you know. There is even a modern OS running on x86, all without any C at all. (Ugh! Pointer aliasing!) It is called Bluebottle. And -- you can skin the GUI by editing an XML file! Woohoo! http://bluebottle.ethz.ch/

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

Re:well...

[Anonymous Coward]

yeah, sure...not a troll but you throw out "bloated" and the obligatory .NET slam. Don't get me wrong I have some issues with .NET (personally I prefer java to .NET and old school C++ to both but just because I know it better....it's a personal bias not based on the technology itself) but it's not bloated. More important that what I like and to reiterate what someone said above if it doesn't have proper namespace support it isn't anywhere close to perfect. Keep trying, Troll.

Re:well...

[Rew190]

There's things that can be taken away, however; being forced to manage memory being a key one if you want to attract Java/.NET developers.

Re:well...

[Frizzle Fry]

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

Did you just compare a language and framework to an IDE? How can that make sense?

Re:well...

[Overly Critical Guy]

Memory management is pseudo-automatic as it is right now, but requires you to do all the retain/release stuff. That said, you can compile with automatic garbage collection enabled. It's not on by default. Presumably, it will come to the forefront in the next major version of Xcode. Automatic garbage collection can be so slow sometimes, and perhaps Apple wants to get it perfected before really pushing it out the door. But they ARE working on adding it.

As an aside, I don't know what this guy is emailing Steve Jobs about. You can code for a Mac in C, C++, Objective-C, Pascal, Java, all the standard UNIX scripting languages, and any other language GCC supports, really. As for making Cocoa "fun," it already is--interface builder is awesome.

Re:well...

[ceoyoyo]

Use Python. No memory management necessary. With the pyObjC bridge you can do anything you could do in ObjC.

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

I dunno

[log0n]

I've always felt Visual Studio (at least with all the .Net stuff) was turning more into a Visual Basic type of dev platform. A lot of automation, you don't have to know why your doing things the way you are doing, fundementals and such aren't important anymore, etc. It's more for application development than actual (think CS rather than IT) programming.

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

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

[ucahg]

.NET languages generate an intermediate form called IL that is similar to java byte codes but is compiled to native machine code before execution

So, a JIT-based interpreted language then?

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

[Lord Crc]

Just because they're "bytecodes" doesn't tell us whether they're interpreted or compiled.

True, however in this interview with Anders (Chief C# Language Architect), he states that "I think one of the key differences between our IL design and Java byte code specifically, is that we made the decision up-front to not have interpreters". A bit further down he says "When you make the decision up-front to favor execution of native code over interpretation, you are making a decision that strongly influences design of the IL".

Certainly you CAN interpret it, but it was designed to be JITed.

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

[ceoyoyo]

Python. There you go. Have fun! Oh, don't forget to install PyObjC or you may be disappointed.

Note: Apple didn't come up with it. Neither did MS. It's open source. Apple employees have a lot to do with PyObjC though, which is also open source.

Re:Wowing developers...

[mj_1903]

I agree. When programming Obj-C you will rarely see any memory related errors if you know what you are doing. It is not a beast to manage and the memory management is flexible enough to cover nearly all situations from some quick interface code (autorelease) to tight loops or backend components (managed retain/release). As a full time Cocoa programmer I can't really think of anything to change in that regard.

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

Re:.NET is a bit complex

[stripes]

I don't see how this is any better than extending a class and overriding a method or providing a new on as you would in Java

If you use a category add a method to a class in ObjC when someone passes you a object of that class (or I assume a subclass) it has that method and you can use it. If you extend the class in Java and someone passes you an object of the original class you can't use the new method. E.g. even if Java's string class were not final, adding a "encode to UCS-2 and frobnicate any combining marks" method to a subclass wouldn't let you call that method on string people pass you.

In C++ the "way around" that is to use an overloaded non-member function. I don't recall being able to do anything like that in Java though.

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.

Re:the Wow factor.

[mj_1903]

It's not like Obj-C doesn't have a wow factor anyway. For starters you can create basically the entire interface of an application without writing a line of code by using bindings. What's even better is you know you will never see a crash in that code and it acts how a normal Mac OS X app should work removing tons of testing and freeing you up to do cooler things to sell your application. Secondly the ability to rapidly prototype a working application using the above glue code and the already built objects allows you a near unprecedented ability to experiment with the user interface. And finally I guess is what you get for free. Everything from Core Image to threading, it's all there and works perfectly every time. There are so many objects which I guess shows its age... if you need something then quite likely it has already been built or tacked on to an existing object allowing you to continue on and again produced the cooler items that sell your app.

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

[mrsbrisby]

Actually, Safari is largely written in C++ (the KDE rendering engine)

Actually, Safari IS written in Objective-C. So is WebKit. WebCore on the other hand is written in Objective-C++ (KWQ), and yes, includes a significant amount of C++ code (KHTML).

I think this adequately demonstrates the flexibility of Objective-C: to be able to interoperate with C and C++ code on their terms, while C++ code can only interact with Objective-C the same way C can.

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

Re:Objective C is hard to beat

[ceoyoyo]

No language does everything perfectly, but to say Python is just a scripting language is not correct. It is a general purpose language, and a very good one at that. You probably don't want to code your MPEG4 transcoder in it, but it's wonderful for the GUI and general purpose stuff. Do your transcoding on the video card, combine it all using Python and PyObjC and you've got a great system.

You can write apps on Mac OS X using Python that you can't distinguish from ObjC apps without inspecting the contents of the packages. Far better than Java in fact, since the .app is totally self contained -- a copy of the interpreter and all Python modules included.

If you like Python and you have a Mac, try out PyObjC. It's my favourite development environment by far.

application domains

[rheotaxis]

Let your application domain suggest the development tools you need. Listen to art, science, and your own experience before listening to people who own lots of stock in giant corporations. They are motivated by the need to sell their own product first.

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:Learning ObjC/Cocoa (and others) now...

[thogard]

At the end of the day I want a makefile and I'm going to keep using vi (or a good clone). I've recently converted all my last 5 years of documents (that I could still read) into LaTex. I've given up on the glitter and eye candy. I'm going back to the old school and I'm not coming back.

The code I've written in the last 10 or so years thats still in production has been in either C, lex, yacc, perl or assembly. None of the C++, Java, Python, php, Visual Basic, Modula 2, or Pascal is still in production. If I go back back 20 years then I can add in Fortran and APL to the still running pile and an Ada module in the maybe list. I was recently contacted about someone wanting a new feature for a program that I wrote 23 years ago that was a hybrid C and GWBasic.

I used to use computer 100% to get a specific task done. Now it appears that the thing has replaced the TV set as the thing to sit in front of. A modern desktop is too distracting. Email keeps showing up, IM is going off all the time and the calendar is reminding me of stuff that I don't need to pay attention to. The easy solution is turn off email checks but then what happens when the boss needs something urgently? The silly thing needs a "do not disturb" level feature that all programs respect.

I've got programs that watch my every move and record how much time I spend on different projects and the time wasting on OS X is less than time wasting on Windows but its still a long way away from my efficiency on the old Blit terminal. I've been looking for a way to get OS X to tell me what the title is of the window that has focus that won't eat up all the cpu time.

What I'm after is a hook I can build into `make test` that starts by turning on email, im, my todo list, enable /. on the proxy and then when make finishes turns it all off again. It would be even better if thats built into the IDE.

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

[man_of_mr_e]

Indeed. I think there are some kick ass comercial unix debuggers available (or so i've heard, haven't really seen them), but Microsoft's debugger has always been bone simple to use, though not very featureful.

That's really changed with VS 2005, the debugger can be extended in many ways that leave your jaw laying on the ground. You can create custom "visualizers" to visual data structures in memory, and the popup "drilldown" features are a dream come true.

Want to be able to visual your HTML data buffer? XML? Custom document? Images? the visualizers are really cool.

For example, here's a regex visualizer:

http://regex.osherove.com/Articles/RegexKit.html

And here's an XML visualizer:

http://blogs.conchango.com/howardvanrooijen/archiv e/2005/11/24/2424.aspx

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

[squarooticus]

Objective-C does OO much more like Smalltalk: method dispatch is determined at runtime, not a compile time.
So does C++: they're called virtual function tables.

Unless you mean that in ObjC the possible methods for an object are not available at link time, in which case type safety is not available. I don't know enough about ObjC; perhaps you can explain it to me succinctly?

Kyle

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

[Colonel Panic]

So does C++: they're called virtual function tables.

true. However, this sort of dynamic dispatch is limited to objects which are members of a certain inheritance hierarchy. In Obj-C, when a message is sent to an object the determination of whether or not that receiver can respond to the message is determined at runtime. It doesn't matter that the receiver is a member of a particular class which inherits from some class which defined some virtual functions.

With virtual functions in C++ it's sort of a cross between compiletime and runtime: The receiving object must be a member of a certain class hierarchy with the virtual functions defined in a parent somewhere. If you try to pass a class pointer of the wrong class (meaning it's not part of an exclusive hierarchy) then you'll get a compile time error. In Obj-C on the otherhand, we don't care what the class pedigree of an object is as long as it can respond to the message being sent (or to put it another way, as long as it's interface matches the expectations of the user).

Perhaps it could also be said that virtual functions are C++'s hack to allow limited dynamic dispatch. But it's not as dynamic as what is possible in Obj-C (or other very dynamic OO languages like Smalltalk and Ruby).

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:Every time the ObjC/C++ discussion comes up...

[jcr]

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

I gave up on C++ in 1989, when it was far more defensible than it is today. I don't have to stand in line for nine hours to get half a kilo of bread to be able to judge the value of communism, do I?

-jcr

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

[mcc]

Unless you mean that in ObjC the possible methods for an object are not available at link time,

Correct.

in which case type safety is not available. I don't know enough about ObjC; perhaps you can explain it to me succinctly?

You are actually almost right. The way to put it should be that type safety is available but not required. Method type safety is a compile-time warning, not a compile-time error, because while a program which passes the type safety checks is guaranteed to function without type errors at runtime, a program which fails the type safety checks is not guaranteed to encounter type errors at runtime.

If this sounds "bad", consider it in context of what happens when a type safety violation does occur at runtime-- the object is given a chance to deal with the "method not found" error itself, in the form of a forwardInvocation: method call basically saying "hey, I tried to execute the method named 'blah' on you and it didn't work"; if that fails, an exception occurs. The penalty for a type error is not all that bad, especially compared to what happens in this point in C++ (you get a messy crash). Also consider that while compile-time type safety is not totally accurate, there is also run-time type safety available which is much more accurate. All objects accept a respondsToSelector: (methodSelector) method which basically ask, "do you accept this method?", and this method has the ability to determine side-effects of dynamic dispatch that the compiler could not.

These are somewhat advanced techniques within Objective C, and one should not be running programs which emit type safety warnings unless you really know what you're doing. However, when used correctly these things are quite powerful. Performing type safety checks at runtime instead of compile-time allow objective c libraries to leverage the Delegate pattern in a way most languages can only dream of; an objective c object can accept any other object as a delegate, and then simply say "do you accept this method? if so, run it. if not, never mind". In Java, the analogous construct would require a potentially very messy use of interfaces and probably a lot of blank methods to satisfy those interfaces. ForwardInvocation: allows even stranger and more interesting constructs, for example "proxy objects"-- Objective C offers a concept called "distributed objects" which are much like Java RMI, except that distributed objects lack any of the stub hassle and are in fact entirely transparent to any code interacting with the distributed object in question.

(Full disclosure: Absolutely everything I describe above as an advantage in Objective C can be fully implemented in Java by use of the reflection classes. However, people rarely take advantage of this, perhaps partly because the reflection classes are not very fun to use, and perhaps partly because the Java reflection functionality is quite slow.)

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

Mangaged code good | .Net / Mono Bad

[bhima]

The idea that the OS X development environment should include the option of using managed is code is fine (although I shudder to think just how much work this truly encompasses). But I haven't yet seen the real benefit of using .Net or Mono while I have successfully used Objective C.

I think sometimes we get caught up in the tinkering with latest wizbang language and loose sight of the fact that if we simply paid attention and used the languages we already know we could solve whatever we are programming much simpler.

Over the winter break I have run into two miserable examples of this...

ONE the program Autopano-sift (100% managed C# code developed using mono) This program does nothing couldn't be done in C++ and little that couldn't be done in C. I've lost count of the megabytes I've downloaded to access the functionality of a program that has no cause to occupy much over a half meg... it's like having the bloat of windows and the user friendliness of circa '92 Linux all at the same time.

TWO Canon and the "software" that accompanies their cameras, specifically the 350D AKA Digital Rebel XT. I am very interested in controlling that camera by computer (any computer) so I have also signed up for their development program. So I can tell that all of the canon software that came with my camera was developed with the current version of Microsoft Visual Studio and also uses the SDK canon uses to obfuscate the camera's true API. Because of the user interface and some truly bizarre design decisions this is the worst software I have ever installed on any of my computers. With the possible exception being Arcsoft's image management application which was also included. I must admit, I have seen Arcsoft's applications before and while technically they work... the user interface is so poor and has such arbitrary limitations as to make it unusable, so this is not really surprising. Bottom line... sending a few hundreds of kilobyte of data through a USB should be easily accomplished by an 8 bit Microcontroller mounted on a board the size of my thumbnail... and IT IS NOT... thanks to manged code.

Re:No garbage collector

[Svartalf]

Garbage collection is a bad thing in many cases...

GC causes all kinds of load spikes that can bog down end user apps and blow server apps clean out of the water. GC makes things "easier" for the developer at the expense of overall performance. But, with at least C++, there are ways of accomplishing the same thing without needing a GC subsystem spooling up CPU cycles- smart pointers handle most of the same features that GC does in a safe and efficient manner. The code knows when a variable has dropped out of scope (it's compiled into the code itself...) and frees memory as opposed to a separate thread of execution periodically polling all the active objects to see which ones have dropped out of scope.

Python

[truthsearch]

There's also a Python bridge for Obj-C. So for those that prefer a very different language, with its interpreter already distributed with the OS, Python's a great option. You get the native objects exposed by OS X available to Python.

And let's not forget OS X is built on top of BSD. So effectively anything which can be written for BSD can be written for OS X. There are, of course, limited GUI tools, but options are available. Qt libraries, for example, will display native GUI elements when possible.

Jobs doesn't get it

[NutscrapeSucks]

What Jobs is ignoring is that Macintosh customers are primarily non-technical, and have no need or want for a "religious war" around programming languages. Even if Obj-C and Cocoa are perfect, they are still for all intents-and-purposes a proprietary Apple-only environment (please don't pretend GNUStep has any wider importance), and is only used by True Believer devs.

What the Mac platform needs the most is applications, good ones. And if the apps are good, the users simply don't care if the language frameworks are slightly faster or nicer to program with.

ObjC/Cocoa is one set of good tools, but so is the .NET framework and C# and it is considerably more popular as well. Withholding .NET (and Java) from Mac users only hurts the variety of applicaitons, which in turn hurts the strength of the platform.

NeXT was a developer tool company and he could get away with this approach. Mac is a mainstream platform (or trying to be), and there needs to be "more than one way to do it".

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

Did nobody actually READ the emails?

[Trollll]

Steve Jobs never calls Objective-C/Cocoa perfect, he just thinks that it makes for a much better development tool than .NET.

How the hell did that even get posted to Slashdot in the first place? Does anyone actually check anything before these things go live?

Check a few comments up for the incredibly boring emails back and forth, where basically the guy starts off by telling Jobs that Objective-C sucks without giving any reason. Makes me wonder why (and IF) he got a response in the first place.

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.

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.

ObjectiveC good/bad isn't the issue.

[minniger]

The issue for me is how much time and effort is it worth learning a language and framework that only exists on a single minority platform?

I personally feel that OSX is a beautiful combination of unixy goodness and gui usability. So much so that I dropped a load on a quad-g5 last month. And i've been playing with objectivec/cocoa/xcode/ib long enough to develop a few opinions:

1. Cocoa is the best thing going for the mac. It's feature rich and has loads of good documentation and examples. Far nicer (at a code level) to build GUIs in than say... Swing.
2. XCode/IB - Hello? 1992 called and wants it tech back. Once you get the hang of it's not a bad combo. But Delphi showed the way forward to today and not having two way tools is painful.
3. Objective C ditto. As a java guy I-CANT-STAND having to deal with .h files again. Copy and pasting message signatures around sure is a lot of fun. But that's just me. Bigger issue is memory management. It's a pain but it's better than c at least.
4. Libraries - As long as there is a cocoa lib for what you want to do you're good. As soon as you have to start calling c or c++ based libs you're screwed. It's nice an familiar to c/c++ guys. But it's rather jarring to be running along in objc and all of a sudden have a load of pointers hit you in the face, throw in the CoreFoundatiaon and carbon stuff... ech!. Every time I see it i'm just "argh... this is why I prog in java".
5. Deprecated Java-Cocoa bridge - Nice idea but making java behave like objc does in cocoa is pretty messy from a java prospective. Probably is better than they just killed it off.

So, back to the point. ObjC has some good and some bad. If you could hope to even just port your code to another platform I'd be all over it. But without that ability what business is going to let you build an app with it? What business is going to buy an app that is osx only? Given these two constraints what left? Server based apps? Java pretty much has that wrapped up in all but the most fervent windows only shops.

The good news is that the mac market is expanding like crazy. It's only ~4% or so.. but that's millions and millions of users who actually buy software. Dunno if it's enough to make a living off of yet, but perhaps someday.

"What has Apple done recently"

[jcr]

Well, what timeframe are we talking here? In Tiger, they gave us CoreData and Quartz Composer, and Spotlight. In Jaguar, they introduced Cocoa Bindings, Quartz Extreme, the Address Book API, and Rendezvous.

OS X is gaining major capabilities with every release, and they usually come with an Objective-C API to make them very easy to use.

-jcr

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.

ObjectiveC and Cocoa

[macpeep]

I've been programming since I was 7. I've done Basic, Pascal, C, x86 assembly, Modula 2, SML, C++, Java, plus a large bunch of scripting languages. I've programmed for the Java VM (ME, SE and EE), Amiga, DOS, 16 and 32 bit Windows, most UNIX variants and a large number of mobile OS's including Symbian, PalmOS and Windows Mobile.

When I got a Apple PowerBook, my intention was not to use it for programming. ObjectiveC and Cocoa was totally irrelevant for me and I didn't bother to learn it. That is, until one evening when I decided to just take a look at some of the ADC docs included with XCode. After reading for about an hour, I was very surprised. It couldn't possibly be this easy and straightforward. It felt like it Cocoa must be seriously limited in functionality. The API was so easy and so compact, and ObjectiveC was like a halfway mix of Java and C++. I bought a book on Cocoa and read through it in about a week. It covered everything from basic GUI programming to drag and drop, printing with pagination, OpenGL, making custom widgets, data binding and persistence, preferences, making and using frameworks (think DLL's), and so much much more. And all of this was amazingly simple compared to any other OS and language combo I had ever used. And not just easier, but dramatically easier.

As an example, the chapter on drag and drop was something like 5 pages and covered making drag sources, drag targets, controlling the icon you see while you drag, data flavors, and so on. The classes involved were all extremely simple, easy and intuitive. Printing is even easier!

I haven't really had any need to do any apps of my own lately, so admittedly I haven't used Cocoa for anything in particular other than simple test applications, but I'm thoroughly impressed!! I would give about 80% of the credit to Cocoa, and 20% to ObjectiveC. You can use Cocoa with Java too, but it seems a tad bit more compatible and elegant with Cocoa. Also, looking at the more recent API's like CoreImage, it seems there's more and more functionality in the Cocoa family of API's but the simplicity remains. I strongly recommend picking up ObjectiveC if you know C++ or Java!

Peppe

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.

Re:Get this guy off my platform

[penguin-collective]

I hate these fucking developers like this. These people that don't want to write code, but would rather have everything taken care of them in an unpredictable manner. Garbage Collection==excuse for not writing better code and don't give me the excuse that you can write your code faster.

And (to use your language) I hate fucking morons like you: people who don't understand that they can't do memory management as efficiently as a machine, people who don't understand that pointer-based code is usually slower and inhibits optimization opportunities, and people who overestimate their own ability to avoid pointer errors.

After programming in C for nearly 30 years, I can confidently say: I am incapable of writing a substantial C program without memory and pointer error bugs, I don't see the point in doing so, and I have yet to meet anybody who can. And the people who are the ones usually producing the most bugs are usually people like you, people who don't even understand their own limitations.

And also having Sun hide all those pointers behing an extrememly gross hierachy of classes that always seem to hand-off work to another class has its penalties.

Java is a bloated P.O.S., but Java is not representative of garbage collected or safe languages.

Apple blew off Metrowerks. Now they must suffer.

[Animats]

Metrowerks was there for Apple when all Apple had was MPW, which was a clone of the UNIX Programmer's Workbench, circa 1979. Metrowerks made the PowerPC transition possible. And recently, Apple made it hard for users of the Metrowerks environment to convert their programs.

Metrowerks offered a stable, reliable development environment, even as Apple was frantically moving from one development platform to another. (Use Rhapsody! Prepare for Copeland! Use OpenDoc! Dump OpenDoc! Use Carbon! No, use Cocoa! Use OpenStep! Use Objective-C! Switch to XCode!.) Each time Apple pulled one of these stunts, more developers dropped their platform.

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

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

[Alioth]

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

That's highly inaccurate. The ObjC runtime is not as fast as a function call in C, I'll grant you that. However, it isn't that slow - see my signature for a 3D OpenGL game written in Objective C. Objective C overall is certainly faster than Java, and orders of magnitude faster than Javascript.

Ten years ahead of its time seventeen years ago

[blake182]

I characterize Objective C and the Interface Builder integration and a lot of those concepts to have been ten years ahead of its time when it was in its heyday (let's say 1988). So it's a 1998 environment in 2005 -- it's not really getting any younger -- they used up their "ahead of their time" card awhile ago.

As much as everyone loves the warm fuzzy "objects send messages" purity, it all starts falling apart on hardcore refactorings (renaming messages and classes) which I consider to be a Large Problem with maintaining a large codebase. Don't get me wrong, I like Objective C. But man, it was a sad day when I learned that they're not going to keep Java up-to-date. Maybe Cocoa# is my savior.

I programmed in Windows for 15 years before becoming more of a "server guy" and now an "OS X guy". I do agree with the comments that the API is far easier to grasp than the mishmash of shit that Microsoft shovels on you (Win32/COM/WinFX/MFC/ATL/Etc. etc.) But that doesn't have anything to do with Objective C or Xcode. That's just smart API design which isn't language or environment dependent.

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:Resources

[bani]

i hate m$ as much as the next /.'er, but you're wrong on both counts.

MS gives theirs away for free, too.

MSDN membership is comparable to the price of ADC, when you compare the same ADC and MSDN levels. (msdn level 1 costs $500, level 2 costs around $1500).

one really annoying thing about apple -- I can use the latest versions of microsoft visual c on my clunky old W2K installation just fine (no way in hell am i "upgrading" to xp!). however apple's latest xcode requires me to upgrade osx -- it won't install on osx 10.3.9. it will only install on osx 10.4, and i can't see any good reason for it. this means for apple, i have to shell out $130 just to be able to upgrade xcode.

What's wrong with pointers?

[Mr. Underbridge]

I don't understand why people hate pointers. Is it the fear of memory math? What's going on? Because pointers have a ton of advantages. Make it easy to save memory, and also make it easy to allow generic function prototyping through function pointers.

Function pointers are probably my favorite thing about low-level languages (and even a few higher-level languages that provide such support).

Re:What's wrong with pointers?

[bnenning]

I don't understand why people hate pointers. Is it the fear of memory math? What's going on?

It's the nondeterministic bugs when you read or write to invalid pointers, and the risk of security holes via buffer overruns.

Function pointers are probably my favorite thing about low-level languages

Any decent high-level language has equivalent or superior functionality.

100% agree

[bani]

Apple's "our way or the highway" attitude is annoying. carbon is grudgingly provided for "those delusional c++ developers who refuse to walk the enlightened path of objc", but it is a second class citizen compared to cocoa, no matter how much apple waves their hands to the contrary.

the problem here is that apple's obsession with objc means c++ is neglected, and it makes porting applications to osx a major pita (it doesn't help that carbon's api is wildly different from anything unix or win32 either.)

apple is spending all their time and effort preaching to the choir. they aren't doing enough to get new converts. and objc/cocoa simply isn't the way to do it.

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

[IamTheRealMike]

The single selling point with Objective-C / Cocoa is the NSAutoreleasePool mechanism. This mechanism is like a garbage collector finally done right.

I must strongly disagree. In no sense is the auto-release pool equivalent to garbage collection. For one, you still have to think hard about memory management in any complex application - for temporary objects that are just part of the internal works of a function, they work OK, but then stack allocation works better. For actually passing objects around inside a program they don't work at all and you must still manage refcounting and ensure there are no refcount cycles.

For those who have not encountered this particular construct (which is not unique to Cocoa), an NSAutoreleasePool basically keeps memory around until the main loop is reached. So you can allocate objects inside one and not worry about freeing them, as long as they don't have to survive beyond this particular event. It's a bit more involved than that : there are stacks of them, and you can create them and flush them manually outside the context of a GUI thread. But it's a bit of a cludge and not a substitute for full automatic memory management (though I would agree that a language which forces you to use GC for everything is not suitable for implementing desktop applications).

Re:I've used Cocoa, .NET and C++/MFC

[theAtomicFireball]

Great - you can write a specialized application with zero lines. Hey, here's an idea - I'll create a dev tool

You set up the example, not me. I was just correcting your inefficient and exaggerated Cocoa solution to it. Don't compare the two using a simplistic example and then complain about the fact that it's a simplistic example.

(1) The example I gave above was to illustrate the steps it takes to make a button perform a simple action (the action itself isn't the point). So, while I could've done something like have it use a built in action, I chose not to because it's not the point.

How is it a fair comparison if you do it in .net the standard way and then intentionally choose a convoluted, non-standard approach with several unnecessary steps in Cocoa? All methods defined with IBAction can be accessed directly from interface builder without writing code, so I have trouble understanding why you would intentionally choose not to take advantage of such a fundamental feature.

(2) The code I gave was clearly not VB - it was C#

You are absolutely 100% right. Sorry about that.

(3) Even with your solution for a very specific action, it STILL requires more steps

What I suggested was not a solution to a specific problem, it is the standard way of doing the specific task you set up as an illustrative scenario, as you (of course) know. Despite that, how is it possibly more steps? You have to place the button on the window in both environments. It took me one more step to connect the button to the performClose: action method (two if you count each click of the mouse as a separate action) so it's hard to see how it could be more steps, since you have to drop to the code editor and type in a line of code in .net.

I'm willing to bet that if you actually timed the number of seconds it takes to "write" the two apps, .NET would still win out.

I would take that bet. I might just go ahead and do it for grins and giggles since I've got both environments open at the moment.

Great idea, let's compare the sizes!

Interesting. Not the same results I'm seeing, but I'll take your word for it. No point in arguing it, since it's a relatively minor issue.

5) It's called terminate:, not performClose: - at least in Xcode 2.1

No. You said to close the window. On Windows, that's the same as terminating the application, but on the Mac, it's not the same (as I'm sure you know); I was doing what you said - I sent the NSWindow instance a performClose: method, but we could just as easily have sent the application delegate a terminate: message (NSWindow does not have a terminate: method) - it would take no longer. The IDE version we used wouldn't affect which outlets were available in either NSWindow or NSApplication, however.

my "professional" Cocoa work was at Apple so I was on salary, not paid by hours.

Good thing, it would seem.

Even my teammates there admitted that Xcode sucks and Visual Studio is much better. Many people would even use emacs because Xcode was that bad.

I don't doubt that some people even at Apple admit that Visual Studio is a better editor. I wasn't arguing about which one was a better code editor; I was arguing about the flawed comparison you made between how long it takes to build a simple application in the two environments.

You can say what you want about my Cocoa experience,

I don't know anything about your Cocoa experience so have no comment on it; your resume could be absolutely amazing for all I know. The fact that you approached a matter as simple as closing a window in Cocoa by doing a half-dozen unnecessary steps does make me question your competence in Cocoa... but not your experience. If you know better, than it looks like you were intentionally trying to overstate the case to make Cocoa look bad. Neither of the two likely possibilities endears you to me.

Categories

[vandel405]

Categories are *the* best feature of Objective-C. They let you keep problems object orrient when subclassing isn't avaiable. Simple example. Say you're working with a class library that exports a string class, and that string class doesn't have a 'spit/explode' function. In languages without categories you would write a static method some place, or a method on some unrelated 'toolbox' class that takes a string and splits it. In objective-c, you can just put a category on string that is a split method. This way the string is doing the split. If you later hve some subclass of string that can do a more efficent split, well override split, dont' swtich on the class type in your static method. YAY OO.

I hinted on a much more important feature above. When you have to work with many objects that you know little about, categories are awesome. Take GORM for example. GORM should integrate with many flavores of objects but it really only knows a lot about a couple of base-classes. Classes like view, object, and window. GORM might need to know if a view acts as a container. To do this, it might put a category method on view called 'isContainer'. It could return NO by default and be overrided in all containers to return YES. Now when working with a view, GORM just has to say [view isContainer] to find out if the view is a container. This is much better than looking asside in some table, or manually coding up the reflection hack that would be nessecary to ask such a question in other statically bound/typed languages.

Re:Apple blew off Metrowerks. Now they must suffer

[tyrione]

BULLSHIT. Apple gave Carbon to Metrowerks and the rest of the ilk back in 1997 at WWDC and we told them to get ready to transition to Cocoa/ObjC. Seven years was plenty of time. Get over your loss and embrace change.

Best example why top posting just sucks

[gullevek]

I read through this and suddenly I asked myself, do I walk back in time, or is something wrong.

But sadly Top posting is so common nowadays, that managers complain if you don't do. Last time I normaly answered an email to an management person in our office and he complained later why my answer was not on top like "normal" people do ...

oh where there world went thanks to preset outlook settings ...

Doesn't work with programming.

[mcc]

With programming, the correct cliche would be "evolve or die". Yes, it's true that "good enough" systems can stay around forever and ever and ever in programming, but it's also true that this only tends to happen if the system gets established. Apple is not established, they are still in a position of attempting to sell Cocoa to others. Worse, Apple is competing directly against one clearly-thus-inspired platform which attempts to replicate Apple's functionality (Java), and against another clearly-thus-inspired platform which attempts to replicate Java's functionality (.NET). .NET and Java have not learned from the greatest of Cocoa's triumphs. But they have both learned from Cocoa's mistakes, and each offer interesting new triumphs of their own.

And there are definitely mistakes in Cocoa, things that are broken and need fixing. Many things in Objective C feel like they're from a 20 year old language-- because they are. The new features in Java 1.5 (generics, real generics not this C++ template crap, and foreach/iterator support) make the cast-filled use of collections in even a simple Objective C program simply painful to contemplate, and objective c could stand to incorporate a few more of C++'s modern features without requiring you to go whole-hog to objective-c++. "Fix and run" or whatever it's called is a neat nod to dynamism, but ultimately is just part of a tendency within the Objective C language and Cocoa tools to go halfway to a state of perfect python-like dynamism but stop halfway. Cocoa is in some ways even more dynamic than Java, but it must be compiled, which offers a sort of dynamism gap which the tools need to bridge. Right now they don't. The tools, amazing as they were compared to the alternatives two or five years ago, really, really need work. The work you must go through to use a language other than Objective C in a Cocoa program is, frankly, bullshit. PyObjc and Camel Bones are clumsy add-ons; they should be built into the developer tools from the moment I install it. In general XCode is too prone to freaking out if I do something unexpected as opposed to just using the expected interface paths, and after you run into this problem where you're afraid to do anything unpredictable in XCode in case everything stops working. In general meanwhile XCode consistently engages in behavior that I can only describe as "mysterious". The great and interesting features XCode offers-- features which are truly necessary to get the most out of Cocoa-- cease to be of use, because XCode's general unreliability prevents you from making use of them. The worst thing about Cocoa comes in when you have to use any library which is written by one of Apple's Carbon-centric groups instead of one of the Cocoa-centric groups. Leave the little cloystered world of cocoa classes and try to work with, say, Quicktime, or CoreAudio, and suddenly you are in a strange and incoherent land, suddenly needing a crash course in new and interesting types of strings and something called the Component Manager, and suddenly devoid of the high documentation standards common in the Cocoa classes. Spend a few weeks using one of these "alien" APIs, and suddenly you won't care how great the core Cocoa APIs are, you'll be simply yearning for an operating system where the GUI library and the sound library are based on OS APIs which vaguely resemble one another.

Basically, Cocoa was without a doubt the best available developer system five years ago. But that was five years ago. The APIs have received new and interesting additions (KVM and coredata come to mind), but some things have not improved at all, for example the base language (in fact if anything the base language has devolved, thanks to the recent removal of Java as a future-proof coding option), the documentation, in many ways the tools, and the cross-language compatibility. Objective C and Cocoa are in many ways standing still while Java and .NET are constantly on the move, in some ways surpassi

The Real Irony

[Reverend528]

The real irony here is that Steve Jobs is calling Garbage Collection "slow" despite the fact that Apple sells a micro-kernel based OS. I know that microkernel-based OSes can be shown to be just as fast as monolithic kernels, but that takes a LOT of work to achieve (more than just kludging BSD onto Mach).

Most well-designed programming languages allow code that can be optimized to reduce the amount of garbage generated. For the things where speed really matters, it can sometimes be possible to prevent the generation of any garbage.

This isn't meant to be a troll on how slow OS X is. My point is that the advantages/disadvantages of using GC parallel those of using a microkernel. It seems silly that Steve Jobs would endorse one and not the other.

Re:The Real Irony

[oudzeeman]

xnu isn't a microkernel.

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.

I disagree

[FredFnord]

I disagree.

Specifically, I work at a small software house that writes exclusively in java. Our product is a piece of server software, quite large, runs on multiple machines, etc. Now, I won't say that GC isn't nice, but I will say this: it took us over three months to find settings that kept java from seizing up for over three minutes once every half hour or so for full GC, when it's under heavy load. When Java 1.5 came out, all those settings failed and we had to try again. (They're still failed; one of the hidden settings we depended upon has been taken out of 1.5, or at least appears to have no effect when used.) When that happens, our servers get out of sync and we had to write an entire new section of code to handle the fact that the servers regularly go away for minutes at a time. One solution, it turns out, is to load up the machine with 4 gigs of RAM, but we're hesitant to suggest this because even Oracle doesn't require 4 gigs of RAM to run. Another solution could be requiring multiple servers and failover setups... that would be awfully popular.

I agree that situations like this are rare, but they aren't unknown. If we had a choice, it's possible we would, in fact, redo this whole mess in Java Minus GC, despite the headaches. (Unlikely, but possible. I sure know a lot of our customers would like us to.)

-fred

NIH at its finest

[nikster]

I was an intern at Apple in 1997 when Steve came back. We all knew he would save the company and were happy when Amelio left.

This was the time of Windows 95 vs OS 9, pre-OS X. What was a huge problem back then was the Not Invented Here syndrome, which sounds silly until you realize that this is bound to happen at a company like Apple. Apple has the brightest engineers and used to make the best software and hardware. Now, if you are the best, who is going to voluntarily run Windows 3.x (for example) just to keep on top of what's happening on the other side. So at Apple, Win95 was pretty unknown. NT - even more unknown. People had no idea why it was better than OS 9. All they could see was the uglier interface.

The exact same thing happens these days with XCode and Objective-C. Once upon a time, Objective-C and InterfaceBuilder and the predecessor to XCode were light-years ahead of the competition. They were literally about 10 years ahead in NeXT times. Like, two or three generations ahead. Nowadays, they are falling behind. but because no one at Apple even considers to use anything else, they still think they are the best. XCode developers think that XCode is way better than anything else out there, even though VS.NET, Eclipse, and IDEA for Java development are far better. XCode's latest improvement was auto-completion (that works)... Eclipse and IDEA meanwhile are working on ever more refined refactoring mechanisms that automate away days and weeks of development time.

As for Objective-C I don't know it well enough to make a judgement but the syntax is certainly extremely different from anything else. I don't want to lean it if it is just for the sake of writing proprietary OS X-only software.

But since Obj-C is already dynamic and can do "everything" a dynamic programming language can do, why not at least provide wrappers for Ruby and Python? Ruby wrappers should be totally simple to write, and then I could just use my favorite programming language to program my favorite OS. Ruby would really be a perfect fit for OS X - elegance from within.

Developer's ignorance plays a good part in this too. If XCode is better than the previous XCode and works for you, why should you use anything else. I actually run into this problem with colleagues who use CodeWarrior or some other abomination of an IDE, or who use no IDE at all and claim that that's better for them than learning an IDE. Yeah, right. I have not met anybody who wanted to switch back from a modern IDE (IDEA, Eclipse, VS .NET) to a text editor or emacs or some glorified-text-editor-IDE like CW or XCode. Nobody goes back. The productivity gains are not only real, they are also significant.

Re:For the record

[ichigo 2.0]

You must be new here. Go and read some of the comics here, and maybe the meaning behind the words "Fruit Fucker" will present itself.