Objective-C's niche: why it survives in a world of alternatives | Hacker News Reader

Objective-C's niche: why it survives in a world of alternatives

cocoawithlove.com

101 pointsstephth116 comments

I find it surprising that there are so many people bashing Objective-C here in the comments. I have been programming in Objective-C for living since the iPhone SDK came public and I came to love both the language and the libraries.

I think that many people who despise Objective-C syntax are simply not programming long enough in the language to overcome the initial knee-jerk reaction. Mostly the issue seems to be the message passing syntax, which I find very readable and self-documenting. What else should matter if not this?

Then there’s comments about speed. I have written two action games for the first-generation iPhones and I have never encountered a performance problem caused by the runtime. Over 99% of the time I could stick to high-level code without resorting to C to gain speed. That says a lot about performance for regular applications.

Block syntax could be better, I can’t use closures with such ease as in Perl (for example). But this is one of the things that have to do with Objective-C being a relatively thin layer atop of C. And that I see as a huge win, because you can very easily and naturally mix higher-level Objective-C code with plain C APIs that are very common on most systems. And if you want some lower-level bit-twiddling trickery for performance reasons, you are free to go. For me, C is a very elegant language and Objective-C takes out most of its rough corners.

Saying that Objective-C could be replaced by something “smarter” like Lisp or Haskell is simply ignoring the reality. Objective-C has very low language complexity, both the building blocks and their interactions are simple and there are few surprises. This is a huge advantage both for the newcomers and for programmers that deal with the stack most of their working hours.

The manual memory management first seemed like a chore to me after coming to Objective-C from Java, but the rules are dead simple and after a few weeks you don’t think about the memory management any more.

Yes, Objective-C is not hip. So what? It’s a pragmatic and reasonably expressive language that gets the job done. I don’t think that replacing it would serve any real purpose – and that’s a very good reason to survive.

My biggest beef with Objective C is that it takes the most retarded feature of C++ -- that you have to write both a header and a implementation file (why oh why can't the compiler compile one?) -- and removes the really nice ability to allocate your object on the stack (which means memory allocation is really, really, cheap and you know when the object is deallocated).

As for the header/implementation split, I might have been brainwashed by the language, but I like it :) I take it as a nice division between the public interface and private implementation. And now that we have purely synthesized properties in the modern runtimes, we can keep the header file really clean:

https://gist.github.com/766381

I have never missed allocating objects on the stack, I am mostly happy with autorelease pools. They are slower and “less deterministic” than stack-based objects, but I don’t mind.

Let's give credit where it's due - the header/source split is a particularity of C, borrowed both by C++ and Objective-C for compatbility.

Well, call me weird but I like the .h/.c split. Header files are awesome for a quick lookup. Big implementation files are not.

About the stack ... well if you care about performance to this degree in your Obj-C code chances are you should implement the stuff in C/C++.

Most of the silliness about Objective is (I think) based on an unwillingness to admit that GUI's written in one's favorite scripting language or Java are still too slow. I think Obj C add just the right amount of sugar to plain C for GUI and OOP, while its cousin C++ has WAY too much sugar (insulin shock!); both of these are screamingly fast after compilation. So saying "I would rather write it in Ruby/Python/Perl/Lua/Java/blah/blah/blah" is just ridiculous, at least with today's tech. Sure -- I would rather write an SS7 switch in Bash, but that just doesn't matter.

Oh -- and the fact that small minded programmers freak out when something is different (brackets, as an OP says, or 0 versus 1 indexing, etc)

(Note -- if you want to max programmer speed (in Lines of Code) for GUI's, you want to use a language even uncooler than Obj C: Tcl/Tk...)

> I find it surprising that there are so many people bashing Objective-C here in the comments. I have been programming in Objective-C for living since the iPhone SDK came public and I came to love both the language and the libraries.

Brackets. People see the brackets and are immediately biased against the language. Yes, many programmers really are that lazy and superficial.

Obj-C survives b/c it is the only real way to write iPhone and iPad apps, plain and simple (ignoring Appcelerator and PhoneGap for the moment). If people had options, it is likely they would use the alternatives.

Look at Linux. The "official" language will always be C, but there are toolkits for building GTK apps in Python, Vala, Mono and other even more obscure languages. Some pretty big apps have been written in each and people will continue to use those as long as they are viable options. If, however, someone big enough and with enough clout basically said "only native C/GTK apps will be accepted on our platform", you would see people migrate to that toolchain. It is simple economics.

Apple has the clout (imo, unfortunately) to do that and have done it with Obj-C. They basically killed Java, which was an option up until I think 2 years ago. I can see Apple's perspective, supporting two toolkits is expensive and takes time, resource, energy and focus. In their mind, what benefit to they gain from supporting multiple toolkits? Developers? They know they are popular enough that the developers will take up Obj-C when Java was dropped. Sure there will be grumbling and moaning, but Apple DOESN'T CARE ABOUT DEVELOPERS except that they make apps to attract the users.

I'm not saying what Apple did is right or wrong, but it does make sense from a strategic point of view. However, there is practically no merit to Obj-c on it's own. There are more compelling alternatives at nearly every turn, but NOT if you want to play in the iphone and ipad ecosystem.

Are you seriously suggesting it would be better for everyone if developers wrote desktop apps for OSX in Java?!

Apple didn't kill Java, Sun did. It was Sun who decided Java apps had to look different (in that special, ugly java kind of way), that they required 5+ seconds to start etc.

Java could have been good for desktop apps if done right, but it wasn't and as a result there's very few desktop Java applications (and even fewer good ones).

Java was also an awkward fit for Cocoa, lacking the dynamic ability required. Java has it's place, and being a language for desktop apps is not it

I think your misremembering. There was a Cocoa Java API that people could use to write native apps. That is what was killed.

Pure Java (Aka. Swing) apps on the desktop is a different thing entirely.

Sorry, I was unclear.

I was referring to Java on the desktop for any OS, and the decisions I was talking about relate to Java almost 10 years ago. If Sun had of done things differently in the late 90's, Java may have been a valid desktop language, but by early 00's it was already a moot point, Apple or no Apple

Some things were later fixed, but by then it was too late

The thing is, nearly nobody used Cocoa from Java. And when they did, it usually sucked.

Except this article is from 2009, and concerns itself with why Apple would stick with Objective-C in the first place...

What would you rather write iOS/Mac applications in if not Objective-C?

Me personally? Lua. That language is as simple and as rugged as a cockroach.

https://github.com/probablycorey/wax

Common Lisp.

Ruby.

C++.

Languages that are not Apple-specific.

Objective-C wasn't created by Apple.

Ruby.

Performance would be a serious issue.

MacRuby has disproven that assertion pretty well. It benchmarks remarkably close to Obj-C.

Well, if you know how Cocoa works, this is unsurprising. It makes it really easy to implement only the important stuff on your own and delegate the plumbing to a highly optimized, generic library.

Objective-C's niche: it's the core of two popular operating systems.

A lot of strange programming languages survive because of inertia. Emacs Lisp exists because Emacs was written by Lisp hackers. It survives because Emacs ships with a few million lines of Lisp. Replacing it would take hundreds of man-years.

Objective-C survives for the same reason; Cocoa was expensive to write and rewriting it would serve no purpose. So it remains. Is anyone using Objective-C for some reason other than writing OS X or iOS apps?

I would if Foundation/{App,UI}Kit were open-source. I personally think it's fantastic.

The thing is, I actually take offense to people who call a language ugly. Just because it doesn't prioritize the kind of expressiveness you desire doesn't mean whining about it makes you cool or a better programmer. What everyone here who says 'Objective-C is ugly and outdated' should be decrying is the relative lack of choice of implementation language for iOS.

I like Objective-C, because I look at it from the point of view of C. It's a systems language with support for OOP that I find completely satisfactory, which prioritizes flexibility, predictability, and maintainability over raw speed and constraints. On the other hand, I love that Java and similar languages in its family can reason a great deal about classes and their interactions, and I love that Python and Ruby step out of the programmer's way when you just want to make something --

-- But to write software for an embedded platform that can be natively fast when needed (the C part of ObjC), but offer a solid OOP abstraction, and to reconcile these two needs as well as expose some of the lower-level workings of the OOP system to the developer when they really know what they're doing and need it? I think Objective-C is hard to beat there. It's a language fitting for projects from small-medium size to very large. It's not the only language that I feel can scale like this, but again; that's a problem (availability of alternatives), not a reflection on Objective-C's language. The language combines the low-level with the high-level, and is many things for many needs, yet is without the rigidity of a Java-style type system, yet is also without the inability or difficulty to deeply reason about high-level language structures as in some more dynamic languages, Objective-C manages to allow sufficient and sloppy "it just works" implementations, for when you just need to bang out code that works well enough, as well as encourages polished and well-engineered APIs (such as Cocoa's).

I think Objective-C balances these concerns - small or big, dynamic or inflexible, as well as the reality of mobile devices' limited memory capacity, particularly well. I would make a more cogent argument were I more awake and if I did not have a splitting headache, but I think it's extremely unfair to call (or imply it) Objective-C strange, or that it survives merely because Cocoa would not be supported if another language were to replace it. Although I may be in the minority (at least amongst those who are posting here in this thread), I think it is a fantastic language.

No, but I'd love to hear about it.

I see a lot of c++ devs complaining about how after 20 years they still haven't found a common ground on how to properly use c++ [1], its complicated memory management or its poor support for strings [2], things that are taken for granted with objc and Core Foundation. On one side I see an incredible amount of developers dealing with high amounts of complexity with C++, and on the other hand this low-level dynamic language with a powerful [3] open-source standard library [4] that is sadly only commonly used to build Cocoa apps. I'd love to hear about objc+CF for things like game development on other platforms than iOS or OSX, or an explanation to why it's not happening.

I really really don't mean to instigate a flame war here -- I'd just love to hear more about this topic.

[1] http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...

[2] http://benjamin.smedbergs.us/blog/2007-11-05/what-if/

[3] http://ridiculousfish.com/blog/archives/2005/12/23/array/

[4] http://en.wikipedia.org/wiki/Core_Foundation

Your references don't support the points that you are trying to make.

[1] is just a link to Google's C++ style guide, a specific guide that makes sense for the very large C++ projects inside Google. Projects should create their own guides based on their requirements.

The common ground is already there, you can read about it in C++ Coding Standards by Sutter and Alexandrescu.

[2] is someone wondering whether they should replace C++ with a mostly-C++-compatible language for Firefox. First of all, they are complaining about memory safety, not management which plagues Obj-C just as much or even more, given the fact that it doesn't improve over C's safety like C++ does. Second of all, there are several libraries that can talk to the STL and effectively solve the UTF8 problem.

[3] This can easily be done by the STL, which besides having an open source implementations is also an ISO standard.

I can't tell if you're saying that examples are not enough to back my points or if those examples just don't back my points at all. If it's the latter:

[1] is an example that illustrates the complexity of C++. Show me a style guide or debates about how to use the core of the language in objc.

[2] is an example of someone unsatisfied with memory management and string support in c++. There are tons of those out there. Show me one for objc. Admittedly memory management is a matter of taste, but I retain/release/autorelease quite simple to use and I haven't found anything quite on a par with that mechanism in c++.

[3] what do you mean "it can easily be done"? There's nothing being done there, the author is just observing how the implementation of arrays changes based on the size of the dataset; it's an example of the details behind CF. Are you saying STL automatically optimizes as well?

No, and if there was an easy way to bind UIKit with out Obj-C I'd use it in a heartbeat. I'm seriously considering WAX for LUA. Obj-C has the flexibility of C with the speed of small talk.

That strikes me as a pretty indefensible statement. Objective-C has an incredibly powerful runtime, which is nearly as flexible as the ruby runtime. It's also much much faster than ruby, and probably every other popular dynamic language.

I'm sure the runtime is great, unfortunately the syntax sucks, there is no GC (on iOS) and it can't curry functions, and you can't put an NSInteger into an NSDictionary with out line noise that would do java proud, it doesn't support passing or currying functions.

Sorry, but passing a selector and an object is atrocious, even MS can figure out how to pass a delegate that can figure out whether it needs to pass a this pointer before passing the rest of the arguments.

It's lambda syntax is also attrocious [[ ^ (int x, int x) { return x+y; } copy] autorelease] , wtf is that garbage?

In ruby I don't need to touch 2 different files and put code in 3 places just to define a property, nor do I have to do this in C# or F#.

I doubt it's much faster than C# or F#, especially if it ever involves something simple like putting an integer in a hashtable.

I'd hardly call a language dynamically typed when it will fuck up adding a long and an int. Seriously, define a type that takes an int, pass it a long and see what happens. This is exactly what I mean by the flexibility of C (attrocious type system) and the speed of small talk (incurring a call to objc_msg_send anytime you do anything)

* Syntax sucks: I think Objective-C is actually pretty beautiful. Maybe I'm crazy.

* NSInvocation should serve the same purpose in most cases.

* I find the block syntax atrocious if compared to Lisp lambdas. It's not that bad. Blocks are objects, so you're creating an object, with all the same predictable retain/release semantics. Maybe a few gotchas if you're not reading the documentation and realize you should avoid retain loops. Hardly different from Java, only it's easier to miss it in Java, because you never release, anywhere.

The lack of namespaces seems silly to me: NSThis, NSThat.

It isn't that Obj. C is a bad language, it's just it doesn't feel like a more modern language, and yet it gets used because of the possibility of $$$. I do understand that you can come to love a language after a period of using (and understanding) it. And I do think a systems-level language should be used for apps on mobile devices, but we don't have to continue to be mired in implementation details that were an artifact of a language from the seventies.

I need to play with it more to get a better feel for it.

> Seriously, define a type that takes an int, pass it a long and see what happens.

I don't understand your problem. Are you calling a C function without prototyping it, or sending a message without prototyping the selector? There are warnings for both of these, and an option to make at least the first an explicit error.

> In ruby I don't need to touch 2 different files and put code in 3 places just to define a property, nor do I have to do this in C# or F#.

I believe @synthesize improves this.

I absolutely agree but just responding to one point - i've played with Lua Wax and the lack of debugging and the fact that any Lua script error causes a segfault makes coding with Lua not worth the pain of losing the XCode editor and debugger and statement completion, etc.

If you're putting in a scripting engine for a game that's one thing. If you want an easier way to write cellForRowAtIndexPath, I don't recommend it...

I spend my days writing an iOS front end and its Ruby backend, and could not agree with you more.

The language is not the runtime. Witness MacRuby. http://www.macruby.org/

"MacRuby is an implementation of Ruby 1.9 directly on top of Mac OS X core technologies such as the Objective-C runtime and garbage collector, the LLVM compiler infrastructure and the Foundation and ICU frameworks. It is the goal of MacRuby to enable the creation of full-fledged Mac OS X applications which do not sacrifice performance in order to enjoy the benefits of using Ruby."

It's a minor issue, but if you frequently add integers to dictionaries you can easily add a category on NSDictionary with your new method. That's a feature I miss in C++.

> Obj-C has the flexibility of C

So I guess you implemented duck typing with some void-pointer acrobatics in C?

> Is anyone using Objective-C for some reason other than writing OS X or iOS apps?

I'd love to. I played with GNUstep but ... it's just light years behind Apple's runtime. Obj-C is a pretty nice language if you like smalltalk OO.

Based on the comments, seems like most people's objections of Objective-C are really objections about C: header files, manual memory management, function pointers, strong type system, too low level, no native string object, etc. I grew up with C, so learning Objective-C took maybe 10 minutes because it's basically C with some extra syntax for OOP. In general, one only encounters the "strange" syntax when dealing with methods. I personally love the method syntax because it's basically self documenting.

Which leads me to wonder, how many programmers both on HN and in general know C? I'm too young to already be a dinosaur in this industry... Where did all the C programmers go? Seems like programmers nowadays started learning how to code with Java or Ruby/Python and expect all other languages to be just as high level. Objective-C is low level, which makes it harder, but doesn't make it suck.

As a language, I think Objective-C is a fine one, but I must admit that it is a "dinosaur". The real problem is OOP paradigm. Remember, back in the late 70s and early 80s, OOP was new and exciting and C was the dominant language. People were trying to figure out what OOP should look like and how to make C more OO. NextStep (Apple) just happened to bet on the wrong horse. Obj-C went with Smalltalk syntax, while the rest of the world went with C++ syntax and ultimately the Java style syntax we know and love today. Seems like some developers can't wrap their heads around a non-Java syntax for OOP.

All that said, Objective-C survives only because Apple hasn't chosen another language to replace it for Mac and iOS programming.

> Obj-C went with Smalltalk syntax, while the rest of the world went with C++ syntax and ultimately the Java style syntax we know and love today.

It's more than just a syntactic difference. Objective-C implements true message passing which is not the same as "method calling". You can send messages to a nil object, or have an object dynamically respond at runtime to a message it didn't declare at compile time etc.

Some seem to think the brackets are just some kind of whimsy, but it's important that sending a message is not to be confused with calling a function.

I know C, but haven't used it in years. I had done a couple of projects in assembly language prior to picking up C and I think that really helped as I had no difficulty with the concepts of allocating and freeing memory, pointers, and the like that seem to be pain points for some.

Why it survives in a world of alternatives? There are no alternatives if you want to distribute on the most popular mobile platform. Personally, I really dislike Obj-C, but since I want to create apps on the iPhone I have no choice. Unfortunately, making a good business decision sometimes means going against your personal feelings. I think that's how a lot of other people approached it too. If the iOS platform changed overnight to Lisp, we would see articles titled "Why Lisp survives in a world of alternatives"

The author is not arguing about how come objc is not dead, but about why Apple hasn't replaced it with a more popular language.

> There are no alternatives if you want to distribute on the most popular mobile platform.

Symbian, Blackberry and Android don't support Objective-C as far as I know. Only iOS does, which is far from the "most popular" mobile platform, especially if you look outside Silicon Valley just for a minute.

[Edit] Also, for the record, you can program in C++ and distribute on iOS with minimal Objective C. I thought I'd point this out given my login name.

I think you both are arguing from different sides of "popular". You are stating popular by sheer numbers while he was stating it from a 3rd party developer prospective. I believe he was right in what he said.

> There are no alternatives if you want to distribute on the most popular mobile platform.

This statement isn't entirely true: http://www.appleoutsider.com/2010/06/10/hello-lua/ Cocoa is extremely strongly encouraged, but it's possible, under the current developer agreement, to distribute non-Cocoa applications on iOS.

> under the current developer agreement

This is what worries me. Objective C is the only safe way to go.

I'm interested to hear why solutions such as this: http://monotouch.net/ aren't an option? Price barrier, or are they not up to scratch?

For me it is the price barrier. Being able to use a language like F# on the iphone would be awesome.

There's already a price barrier in the form of the Mac OS computer you need to develop iOS apps. An extra $400 for dev tools you think would be "awesome" is a show-stopper?

I've been using objective-c since 2001, when I made the switch from BeOS to Mac OS X. It's not horrible. I don't have any real problems with it. But I think its replacement is long overdue.

Given that Apple has a long history of ditching huge swaths of its technology in favor of more modern alternatives, no matter if their userbase screams bloody murder or not, I'm surprised it hasn't happened already. This would be a good project for those billions they've got sitting in the bank.

I think it would be great if they would anoint some successor as their new systems language, then port Cocoa to it. Programmers could use either objective-c or the new systems language for a few years, just as we used to decide between Cocoa and Carbon. Then objective-c could gradually fade into the past.

John Siracusa wrote about this very aptly 5 years ago: Avoiding Copland 2010 http://arstechnica.com/staff/fatbits/2005/09/1372.ars

Then he revisited it 10 months in 2010: http://arstechnica.com/apple/news/2010/06/copland-2010-revis...

And then he talked about it 2 weeks ago in the Hypercritical Podcast: http://5by5.tv/hypercritical/14

Abstract: new language and new API go hand in hand. A memory managed combo trades execution speed for faster program creation. Was already needed 5 years ago. The recent garbage collection additions don't cut it. Microsoft started working on their successor (.net) 10 years ago and now it's starting to look good. Apple gained some leeway when the iPhone happened. With ever improving CPUs on mobile devices, Apple still risks losing ground down the line.

Great podcast episode, I highly recommend it.

You could also argue that, given the current success of iOS and Mac, Cocoa isn't a significant hinderance to Apple's platform's success.

(Not to say I wouldn't mind some significant advancements in Apple's preferred runtime, but there's strong evidence that the current runtime is actually quite suitable. If, as you say, .NET is only now starting to look good after a decade's worth of work, perhaps that wasn't the wisest investment on MS's part. Siracusa's been beating this drum for years and, like many of his crusades, I struggle to see how Apple suffers from not following his advice.)

It's fine to push for a better language, but so far you seem to be saying we should do it just because the current language is too old. What are specific things that are wrong with the language Objective-C 2.0 (and not just Cocoa, which is an API; and not just Mac OS X or iOS, which are platforms)? Why should Objective-C not just evolve into something a bit more interesting?

And when considering any alternative, what are the most costly considerations for any developer, including Apple? The size of a code base is a significant factor. The fact that established code already works (new code may add bugs) is a significant factor. The wealth of knowledge already accumulated by programmers is a significant factor. A new language is very unlikely to win a war in those areas, so it would almost have to solve some other problem that is still costing developers a lot because they're using today's languages.

Good question! I can think of a lot of reasons why Apple should switch to a more modern systems programming language.

We have all read pg's essays where he extols the virtues of Lisp, compared to other languages. His primary argument, as best as I can tell, is you can write programs with far less code than in other languages. Such an advantage would be a big win for the platform, and we may come to a time when Apple is forced to do it, because everybody else has, and they risk being left behind.

Objective-C is becoming a weird frankenlanguage. It already was, arguably: a thin layer of smalltalk-like OO sitting on top of C. Just recently, Apple added blocks, which are like continuations in other languages. Maybe that's a good thing, but I think it would be a better thing if we went with a language that had those types of concepts from the beginning.

It has been mentioned elsewhere in this thread that Microsoft has already had their platform-two-dot-oh epiphany, which was .Net: managed languages with automatic garbage collection, and so on. If this evolves into a big win for programmers, Apple will be forced to follow suit.

The biggest argument I can think of for Apple not to try a new systems language is that their cash cow right now is the iOS platform. Doing this now would no doubt cause serious memory and CPU pressure on small devices which can't afford it. So knowing Apple, their likely answer to that would be to come out with a new generation of devices that are no longer compatible with objc, which you have to rewrite everything for.

I agree with the potential in those 3 things, but consider...

Saving even an hour writing something as a few terse lines means nothing if in 6 months you need days to decipher and debug it. The code has to remain clear somehow. About the only acceptable use of a clever one-liner is when it provably reduces the runtime of the generated machine code by a significant amount...and even then, the hour you saved not writing code had better be spent writing a block of comments to explain your one-liner.

Yes, Objective-C is weird. But put yourself in the seat of a language parser; it's already a very difficult problem to ensure that some languages parse correctly and unambiguously. If you introduce new syntax that is "weird", it's actually safer than doing something that may cause subtle incompatibilities with all the code that's been compiled a certain way for decades. And that code has proven the "weird" language is practical, whereas a brand new language (no matter how perfectly designed it seems to be) may actually have parser corner cases that have not been ironed out yet.

Garbage collection is a benefit in many situations, but Apple has managed to create a very responsive phone where mere milliseconds are just perceptible enough to make a user think "my iPhone feels fast, and this other phone feels slow". Right now, performance matters most, and manual memory management is an edge for Apple. It's important to make programmers happy, but not as important as it is to sell things to users.

Timing is everything. That epiphany has not yet lead to what it promised originally: a consumer OS in managed code, with major applications in C#.

I do not think that will happen soon, either. => Apple will probably be fine with a OS written in C with some added functionality, especially if they manage to build one or more managed environments on top of it. That way, companies can build their in-house stuff in managed languages, while the core stuff remains finely tuned C.

I do not think that is the most beautiful solution, but it may well be the pragmatic approach that wins the race.

I thought the block syntax was an extension of C, not a part of Obj-C/Cocoa runtime.

that's fine, but what would they replace it with?

Java? C#? not likely. C/C++? well, you can use them already

I think MacRuby is the closest we have atm to something being groomed as a successor to Obj-C. It's got a way to go yet, but it's already at the stage where it's viable for smaller projects and there's a (small) number of MacRuby apps available on the OSX app store.

I agree that MacRuby is the most likely 'successor' (or rather, alternative).

Another advantage of MacRuby over some other 'scripting languages' is that it can be compiled to an executable via LLVM bytecode (per macrubyc). This will be appealing to anyone who doesn't want to give away his/her source code.

Any idea how much investment is taking place in MacRuby? If they're really interested in grooming a successor, I'd figure that there would be some serious work going on, behind the scenes.

With the success of the platforms on which Obj-C is used, I don't know if a successor will be another language. An update to Obj-C itself might make perfect sense.

Well apparently, MacRuby is already a private framework in Lion, so it serves some purpose in the eyes of Apple.

http://merbist.com/2011/03/07/hey-apple-please-be-nice-and-s...

why not just smalltalk? or f-script with inline C? either of these would really just be a more convenient syntax for most of the higher level code written now anyway (given my experience). the runtime is sufficiently flexible that a simple change in syntax with a friendlier IDE would get many people raving about how great the platform is in much the same way as those experienced with it do now.

It's rather sad that Apple Dylan went nowhere. It would have been a terrific language to pair with Cocoa.

They did try to replace Objective-c with Java and that showed a lot of areas where a framework built for a dynamic language fails on a static language. I think Objective-C is a decent tradeoff of C and Smalltalk. I like the selector syntax as opposed to the C++ syntax.

They didn't actually try to 'replace' objective-c with java, though. It was just an alternative.

In the early days of Mac OS X, many programmers were seduced by it, but they complained loud and long about having to learn this weird new language that had practically no adoption outside Apple. My guess is that Apple decided to give them java to quell the complaining. It wasn't adopted widely, so that was that.

What they should be replacing objective-c with is something that looks more like, say, Python.

Well, Apple has been funding a lot of the development of MacRuby, possibly as an exploration of what it would take to anoint a popular scripting languages as a "nicer" alternative to Objective-C.

The big push for Java was with WebObjects and Apple's half-hearted push into enterprise systems. Initially Apple's version of Java (they wanted tight integration with Cocoa) was always a couple of revisions behind Sun's so that was always a source of frsutration with developers. With the new focus on consumer devices the enterprise space was left to wither and Java with it. Anything that is going to replace Objective-C must be at least as fast - Apples really cares about the customer experience not the developer experience.

It took years to get (mostly) rid of Carbon. Heck, Cocoa still has the NextStep prefix.

The amount of change Apple is willing to make can be hugely exaggerated, especially if they're able to control the respective technology (which they do mostly, one noticeable exception being desktop CPUs and GPUs).

Correct me if I am wrong, but there is a huge amount of Obj-C in the guts of OSX.

Replacing it with another language would require a large RAM footprint as both older apps and new apps would require a large amount of shared libs to be loaded, for possibly not that much additional benefit.

I am very far from an expert at Mac OS X system internals, but I don't think objective-c is all that ingrained in the kernel. You write device drivers in a restricted subset of C++, as one example. userspace Mac and iOS programs have to link to an obj-c runtime library, but it's not much more onerous than linking to, say, libc or libc++.

The big hit would be that, yes, there are gigabytes of objective-c frameworks installed, which would presumably have to be replicated in the new language. But I could see Apple finding a way to sidestep that issue. Maybe the new systems language and objc could both compile down to similar binaries.

Painful or not, it's going to have to happen sooner or later. Objective-c is, in my opinion, the most outdated thing in Apple's technology stack. There will come a time when it is as big an albatross around their neck as Mac OS 9 was, which they waited far too long to replace.

AFAIK MacRuby already works in this way, using the existing (Obj-C) Cocoa frameworks in conjunction with the MacRuby runtime.

meta tl;dr:

The blog post talks about interesting runtime properties of the Objective-C/Cocoa runtime that differentiate it from C and C++/Java.

Hacker News mostly rants about the Smalltalk-like syntax.

I wish Objective-C were more popular on linux, I like the way I can mix message passing style OO with C code.

There aren't really any good libraries for it. You can compile straight ObjC on linux fairly easily with gcc or clang (use -lobjc), but the thing is without NSString and all of the foundation you'll end up doing a lot of work.

And yes, you can get into GNUStep, but that's a whole nother ballgame.

> Objective-C remains an impediment for many programmers

Really!? If that's such an impediment maybe "many programmers" need to look for a new career. Or, go back to copy pasting PHP / hiding their schlubness amongst the other cogs in some Enterprise Java machine.

Obj-C, at least in the last few generations of mobile hardware, is a competitive advantage for Apple. It makes it easy to write fast, low-level code in C, and then to move transparently up to a much higher level of abstraction for non-critical code. With the relatively underpowered processors of today's mobile devices, this kind of control is important.

However, Obj-C completely falls on its face for anything of real algorithmic complexity. Working with complex, nested data structures and more sophisticated algorithms is very awkward, and manual memory management only clouds things further. In the longer run this may become a liability for Apple.

I fail to see how manual (or, in this context, explicit) memory management could “cloud things”. (It seems to me simply like many programmers can’t be bothered to invest the afternoon it takes to learn Cocoa memory management.) Also, could you elaborate why Objective-C makes it hard to work with nested data structures and sophisticated algorithms? In fact, I am struggling to find an example of at least a single general-purpose language that makes working with ”sophisticated algorithms” hard.

The kinds of algorithms you can express very cleanly in a functional language, like Haskell, for example, are a lot more awkward when you have to worry about managing memory at each intermediate step. Look at all the monkeying around you have to do with __block declarations etc. For typical Obj-C code, where you're just gluing together bits of the Cocoa API, I agree that Obj-C's memory management isn't too bad. When you're trying to work at a higher level of abstraction, it's a distraction.

Writing complex algorithms in Obj-C is a pain because of it's incredibly clumsy syntax for collections and the manual coercion of elemental types back and forth to objects. Look at an implementation of a neural net or something as simple as k-means clustering in Obj-C, then C++, then Scala or Haskell to see how poor Obj-C is for this kind of thing.

For example, imagine how much worse this would be in Obj-C: https://github.com/cageface/brains/blob/scala/src/main/scala...

Admittedly, Scala is particularly nice for this kind of thing, and Java is no better than Obj-C, but even C++ gives you much better tools for abstracting this kind of code.

Thank you, that’s helpful.

The algorithm is a bit above my head to rewrite in Objective-C on Sunday, but from my superficial understanding of it the Objective-C version wouldn’t be really ugly. Yes, it would be wordier and clumsier, but tolerably so (for me). After all, it’s precisely these things where functional languages shine.

I seldom find I have to monkey around with __block. Manual boxing/unboxing sucks, yes. It can be alleviated by a simple macro where this really matters, but I can see such and argument is like pouring petrol into the fire when compared to functional languages :)

Now I understand what was meant by “sophisticated algorithms”. Yes, Objective-C is not perfect for those – first class collections are a great convenience here. But I certainly do not see that as a future “liability for Apple” or a huge drawback for the language ecosystem. It’s a niche.

Its a niche for now. But local intelligence in mobile software is going to matter more and more as ad hoc and sensor networks become more common - otherwise the explosion of data might as well not have happened.

And this is just one domain in which Obj-C falls short. For another example, compare doing linear algebra for graphics in Obj-C vs C++ with a nice matrix library.

So? Then don't write those kinds of things in Objective-C. I wouldn't want to write UI code in Haskell either...

So what do you do when you want to implement a neural net or Bayesian filter, for example, in your iPhone app then? I drop into C++ for this but that's hardly ideal.

I don't have any experience with this, but shouldn't it be possible to compile Haskell code into a static library?

I think it would be difficult. You'd have to get both runtime libraries to play nicely together, but the point is that Obj-C, while quite nice for UI work, isn't good at this kind of thing.

I have never understood what is so difficult about Cocoa/ObjC's memory management. In very very complex projects, it can be like counting blackjack cards, but I've honestly never remembered my retain count for any object hitting over 5, and if it has, I've probably been doing something wrong. Most of the time it will never go above 2. All you do is add or subtract one from a number making sure you're never in the negative.

At least we don't have to declare how much memory to alloc and dealloc manually.

If you just keep to "release what you alloc/new/copy" you'll be golden.

Except for retain cycles. Which are easy to cause with blocks, and even without blocks can make dealing with thread-safety near impossible (think weak referenced delegate and race conditions between its -dealloc and messages that are being sent to it).

With early iOS they were talking about a pretty serious use of JavaScript. I wouldn't be surprised if they pushed that more in the future...

I've heard there is a lot of work being done to make Haskell play nicely with Xcode [1]. I don't know if Apple is experimenting with that, but they're probably kicking a lot of options around.

[1] http://hackage.haskell.org/platform/mac.html

Did you paste the link you intended to? I don't see how it supports the idea that there is work being done to make Haskell place nicely with XCode.

Work being done by Haskell people, if not Apple people.

I'm not even getting that from the link. To me, the link only shows that I can download The Haskell Platform for my Mac.

The only thing there related to XCode is that one needs to have it installed as a prerequisite for running the haskell platform's installer.

This is no surprise because the installer wants to have the "unix development support" package available (it contains gcc, header files, misc command line tools in locations where run-of-the-mill Makefiles can find them...) and it's just incidental that one needs to run the XCode installer in order to get these basic unix amenities on the system.

After starting to read a bunch of objective C, I have to say there are some constructs that are very nice compared to an OO language like java -- for example, selectors and the target action design pattern. There's definitely some nice dynamic properties, but at the same time, some of the basic "methods/messages" for the Foundation APIs aren't very convenient to write and are strangely named. For example, compare NSString to strings in Java, Python, Ruby, etc.

This makes the following situations possible:
1) You want to add a convenience method to someone else's object (a quick search of my own posts reveals that about a dozens of my own posts involve adding convenience methods to Cocoa classes, e.g. Safely fetching an NSManagedObject by URI).
2) You want to change the behavior of a class you didn't (and can't) allocate because it is created by someone else (this is how Key-Value Observing is implemented in Cocoa).
3) You want to treat objects generically and handle potential differences with runtime introspection.

4) You want to substitute an object of a completely different class to the expected class (this is used in Cocoa by NSProxy to turn a regular object into a distributed object).

One can do all of the above with the Go language. In addition, one could also write a reasonably performant compiler in it. (Also JIT dynamic language VMs are good enough now, that I've seen dynamic language parser/compiler implementations perform as well as a naively written Lex/YACC C implementation. And yes, companies paid money for the latter!)

Has anyone used pyobjc or some other interface between objective-C and another language? Thoughts?

I used PyObjC a few years ago, and enjoyed it much more than straight Objective-C. Far less boilerplate, and the transparent mapping between Python lists and dicts and Cocoa's NSArray and NSDictionary is great.

pyobjc is how i got exposed to objective-c. it's a joy to use if you have your app in python, but i've heard complaints about the python-objc bridge leaking memory, so you may end up doing memory management in python (alloc, init, etc.) on pyobjc-wrapped objects if you're not careful.

The title of the post is very misleading: Obj-C would crash and burn if there were native, supported alternatives in OSX, it survives exactly because there are no alternatives.

Ok, that's simply not true. On Mac OS X, you're welcome to use any language and runtime you wish for your application. Hell, if you want to use a non-Objective-C language and still present a native experience, use PyObjC, RubyCocoa, MacRuby, or any other language that shims into the Objective-C runtime and get access to all of Apple's Cocoa frameworks in the language of your choice.

The same is possible on iOS as well, with the (significant) condition that Apple must first explicitly approve your use of a non-Objective-C runtime before your app can be posted to the App Store.

But in direct response to your post, Obj-C has a rather level playing field on OS X and still survives vs. the alternatives.

Welcome to use it, except:

* it's not officially supported by Apple

* it binds to Cocoa (and if you're lucky it's even up to date and doesn't have that many bugs)

* you can't use it on iOS

* you can't get a job doing X instead of Obj-C because almost everyone just uses Obj-C, the Apple supported language

> * it's not officially supported by Apple

MacRuby is an Apple project.

PyObjC isn't, but ships in Mac OS X. That's rather officially supported.

> * it binds to Cocoa (and if you're lucky it's even up to date and doesn't have that many bugs)

Not true. MacRuby is a prime example of a language that taps directly into the Objective-C runtime, eliminating the need for a bridge. And PyObjC is a great example of a mature bridge – it's been around and robust since the NeXT era.

> * you can't use it on iOS

http://mobileorchard.com/announcing-iphone-wax-native-uikit-...

> * you can't get a job doing X instead of Obj-C because almost everyone just uses Obj-C, the Apple supported language

You can't get jobs programming Ruby, Python, C#, Lua or any other language?

Those projects , even macruby are not officially supported - there is not even documentation on apple.com . Who would use it as their main dev platform, knowing that apple has the tendency to ban 3rd party platforms. Obj-c is practically not used outside OSX - there is just no evidence that, when given the choice, developers would prefer objC. Open source developers seem to root for python, ruby etc, but certainly not for objc, unless they have to deal with OSX. GNUStep is not an active project, with practically zero applications, while there are lots of quality apps in c++ frameworks, python, ruby etc. I dont believe OSX developers are just different people who happen to love objc over everything else.

How did you reach that conclusion? There are plenty of alternatives, from C++ to Ruby to Mono.

Let's face it: in 2011, Obj-C has the sex appeal of COBOL.

I think it's primarily a strategic decision: Just like apple likes to lock-in its customers with itunes, so it does with developers, locking them behind an unpopular language with a slow learning curve.

The learning curve of Objective-C is about a day if you know C99. Did you have some specific problem?

that doesn't make even a glimmer of sense

Ignoring the disputable claims that it's unpopular or has a slow learning curve (you can describe Objective-C's additions to C in a single page), there's no evidence to claim that Objective-C is about customer lock-in, especially when you can use so many alternatives including the Apple-funded MacRuby.

Apple uses Objective-C because they have a lot of code written in it, and it has served them very well. iOS is the most popular mobile platform for third-party development. The dynamic nature of the language has enabled the implementation of some useful features like key-value-observing, while the ability to drop to C retains the flexibility of system-level programming.

Even the memory management criticism is overblown. You merely have to follow an easy list of four ownership rules. That's if you're not using the garbage collector that came out four years ago with Leopard.

If you follow those "easy rules," how do you handle race conditions between weak references held to avoid retain cycles and the execution of those weak reference's -dealloc methods? There's nothing to stop the weak reference's -dealloc from racing with messages to that weak reference.

Or, how do you handle the fact that -dealloc can be called on whatever thread calls the last -release, even if you make an effort to only send messages to an object on the main thread (Which will trigger implicit retain/release unless you're incredibly careful). Almost all of the GCD examples out there are subtly broken because of this.

As for GC, I look forward to actually being able to use it on iOS.

I can't address your first point because I haven't used GC yet, but your second seems like a contradiction. If you're releasing from a background thread then you are sending messages from a background thread. You can easily put code in our object's release method to fix that, though. "If not main thread, call self on main thread."

This is a hack, not a general purpose solution, as it requires modifying the class, and and still must be done carefully to avoid accidental retain/release.

Calling retain/release from a background thread will happen simply by using blocks, gcd, or performSelector: APIs, as designed, to attempt to schedule execution on the main thread. Avoiding the issue requires exquisite care, unless you actually want to modify every single class that you may access an instance of from a background thread (such as GCD).

As to the first point, it applies in a NON-GC environment, where you hold weak references to delegates a(nd deregister them in dealloc.)

Sorry, the term "weak reference" threw me. So you mean you have pointers to objects you have not retained, and you "deregister" (set them to nil?) in your dealloc? I don't see how that can trigger a race condition or call anyone else's dealloc.

You may have a valid point but I don't grasp it.

Think delegates, or observers. There is a race condition between calling the delegate and deregistration of the delegate. Once an object's dealloc method has been called, you must not resurrect it, but there is a race between the execution of -dealloc, the de-registration of the delegate, and the dispatch of messages to the delegate.

So you're setting threadedObject.delegate = nil in your delegate object's dealloc, but the threadedObject is sending subsequent messages to your delegate? The doesn't sounds like a retain-release problem. Wouldn't the same thing happen when setting threadedObject.delegate=foo? Messages could still get send to the old delegate if you haven't done your synchronization right.

Missing the forest for the trees. The problem is that the old delegate will be invalidated before it deregisters itself, because it will not deregister itself until it is invalid (during -dealloc)

Reply on news.ycombinator.com