Hacker News Reader

> you still can't figure out what methods a class has in the IDE.

Maybe I don't understand what you mean but isn't that just an XCode auto-completion feature? Do you mean you can't see which methods belong to the class and which are inherited?

> It has some kind of 'automatic memory management'

Initially I was not too impressed by the alloc/retain/release/autorelease parts of Obj-C but now that I grok the concept well, I think it's awesome. I'm only coding for iOS devices but my understanding is that for OSX, there is a stable GC system. On iOS, you manage the memory yourself. I would have liked to not worry about memory at all but it's not a big deal after all. If you alloc/copy something, make sure you release it.

I mean the intellisense (autocomplete + docs + method signature) in xcode blows chunks compared to Visual Studio or even Eclipse.

Lots of things individually in Obj-C/Xcode are minor annoyances, but when you add them all together it's a very annoying toolchain. Comparing the UI/Polish in Apple products to Microsoft products, I figured that XCode would be one of the best dev environments ever. I think it's one of the worst.

It's not that any of the issues are insurmountable, I'd just rather not deal with them.

Yes, it currently does suck.

Thankfully the next version will intelligently incorporate Clang/LLVM which will improve the situation vastly.

Completely agree about the autocomplete and documentation in XCode. It's a complete waste and for a company that spends a lot of time focusing on snappy UIs I don't understand why its so slow...and stupid.

The one redeeming quality is that Instruments and the tools package is quite nice. Our company pays good money to get the same level of software for visual studio.

    I mean the intellisense (autocomplete + docs 
    + method signature) in xcode blows chunks 
    compared to Visual Studio or even Eclipse.

That last sentence left me puzzled, seeing as how eclipse has much better "intellisense" for java than VS does for c++ & c# (at least out of the box - resharper brings it close to eclipse-levels with c#).

Agree 100%.

And if for whatever reason Resharper isn't available to you, then check out the Productivity Power Tools. They'll take you in the Eclipse direction. Not all the way, mind you, and they're buggy, but it's helpful nonetheless.

To me, not familiar with ObjC/OSX memory management, the last sentence reads like "...it's not a big deal after all. If you malloc/fopen something, make sure you free/fclose it."

Could you explain the difference?

Rather than being responsible for ultimately disposing of an object, they need only tell the runtime that it is no longer needed.

A retain count (a count on other parties with an interest in an object) is maintained by the runtime. When the retain count reaches zero, the object is freed. When an object is created (using alloc or copy), it has a retain count of 1. Another object can express its interest by calling the "retain" method. When it is done, the "release" method should be called.

If an object is being returned, but shouldn't be freed right away, there is a mechanism called "autorelease" where the call to release is delayed until the end of the current runloop, giving other objects a chance to retain the returned object.

This is almost as prone to failure as malloc/free, you still have to call functions by hand.

Indeed. I've become quite enamoured of late with the automatic reference counting in the Boost C++ library as a happy medium between GC and manual reference counting. Of course, ObjC has no static allocation, so that can't be done here.

If find it much easier than malloc/free.

Cocoa uses autorelease pool for short-lived objects, so most of the time you don't have to free them.

For long-lived objects you can use synthesized properties which handle retain/release for you.

In other cases you "guard" your use of object with retain/release. You can use these in pairs in the same place, rather than having malloc() in one part of the program, and free() in another.

You can freely pass reference to an object without worrying that you might free it while it's still referenced somewhere else. You don't have to think about ownership of an object.

The difference is there is core support for reference counting and cleaning up unreferenced items. Any time you are using an object, you grab a reference; at the end of a call chain (managed as a part of message passing), if an item has no references, it will be deleted automatically.

With C, you are forced to care who actually allocated something and figure out a protocol for dealing with getting it released.

With Objective C, I can allocate something, hold my reference for the duration of the call, release my reference and return it. If the caller wants a reference, they can then grab it; if they don't, it will get deleted.

ObjC on iOS is still memory management but the advantages over C are: reference counting (makes composition easier) and a defined protocol for when references wont be used anymore.

> all the blazing speed of Smalltalk

If you're alluding to cost of message send, then it's pretty low, and can easily be made faster in case it becomes noticeable:

http://www.mikeash.com/pyblog/performance-comparisons-of-com...

According to the link you posted, that's over four times slower than C++ virtual method dispatch (and note that most method calls in ordinary C++ code are not virtual). Also, IMP caching is hardly easy and is quite fiddly: see for example the benchmark code in that link as well as [1].

I highly recommend reading the tour of objc_msgSend [2]. It's very eye opening: for example, there's a cache scanning loop even in the fast case.

[1]: http://www.mulle-kybernetik.com/artikel/Optimization/opti-3-... [2]: http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-th...

>According to the link you posted, that's over four times slower than C++ virtual method dispatch

Hmm, check the results in the same page for the 64bit Cocoa runtime. This is where most optimizations are made, because Apple used the 32->64 bit transition as an opportunity to do most binary compatibility breaking changes to the language.

There, in 64bit, the IMP cached msg send is actually FASTER than C++ virtual method dispatch.

And if your app's performance suffers because of method calls / msg sends, you are doing it wrong. They should be an insignificant amount of time compared to the actual processing stuff done by your app.

The C safety / smalltalk speed quote probably was quite funny when it was relevant --some decades ago.

And all the rest of your "language criticism" is all about the IDE. Coincidentally all solved by Xcode 4: better autocomplete, automatic fixes, relevant error descriptions, etc. The main problem was GCC --it just didnt provide the info and interfaces to use for real time, AST guidance of the IDE. In XCode 4 Apple implemented all that stuff leveraging LLVM.

Apart from that, Xcode < 4 was not a bad IDE by any standard. Worse than Eclipse/VS in several ways, yes. Bad is a stretch. It also has excellent profiling tools, and a great GUI editor (Interface Builder) that gets MVC right.

Also: obj-c has had real GC for years by now. And the old scheme, still used in iOS of retain/release in not "barely" but extremely better and easier than C, while maintaining the performance benefits.