Ask HN: What do you think of Objective-C?
Like it? Love it? Hate it?
56 comments
Objective-C, the language: it's a nice, thin object-oriented layer on top of vanilla C.
It's super-easy to use to make object-oriented wrappers around vanilla-C libraries, compared to C++, and b/c Objective-C is conceptually simpler than C++ there's fewer ways to shoot yourself in the foot.
There's not much point using it for new development unless your project is very self-contained or you're targeting Mac OS X or the iphone; moreover, Apple's pushed out Objective-C 2.0 recently, and are in the driver's seat for the language's future.
Personally, I prefer Java for the kinds of products Objective-C is supposed to be used for (desktop/mobile software). The tradeoffs:
- objective-c is lighter-weight and very simple to code in; Java is a lot clunkier and tedious to write; winner: obj-c
- java has a huge set of support infrastructure and tooling; obj-c has xcode (which is ok, but not great); winner: java
- java has generics that're mostly type-safe; obj-c doesn't really have any equivalent. I like type-safety when I can get it, so winner is java.
If you're learning objective-c to do Cocoa or UIKit development, you will spend much more time learning your way around Cocoa and/or UIKit than learning Objective-C; objective-c is like a week at the absolute longest, but Cocoa takes months to learn.
The first commandment of Cocoa: always respect convention; there's lots of semi-documented conventions (in terms of naming methods and arguments and ivars and so forth), and you should follow any conventions you see unless you understand what you give up by not following that particular convention.
There are two golden rules for Cocoa:
rule 1: if you're coding up something that seems like something any realistic application would have to include, you should take another look @ the docs b/c apple probably gave it to you already.
rule 2: a lot of functionality you'd expect to be in utility classes is buried in base classes (like NSObject, NSArray, NSDate, etc.).
It's super-easy to use to make object-oriented wrappers around vanilla-C libraries, compared to C++, and b/c Objective-C is conceptually simpler than C++ there's fewer ways to shoot yourself in the foot.
There's not much point using it for new development unless your project is very self-contained or you're targeting Mac OS X or the iphone; moreover, Apple's pushed out Objective-C 2.0 recently, and are in the driver's seat for the language's future.
Personally, I prefer Java for the kinds of products Objective-C is supposed to be used for (desktop/mobile software). The tradeoffs:
- objective-c is lighter-weight and very simple to code in; Java is a lot clunkier and tedious to write; winner: obj-c
- java has a huge set of support infrastructure and tooling; obj-c has xcode (which is ok, but not great); winner: java
- java has generics that're mostly type-safe; obj-c doesn't really have any equivalent. I like type-safety when I can get it, so winner is java.
If you're learning objective-c to do Cocoa or UIKit development, you will spend much more time learning your way around Cocoa and/or UIKit than learning Objective-C; objective-c is like a week at the absolute longest, but Cocoa takes months to learn.
The first commandment of Cocoa: always respect convention; there's lots of semi-documented conventions (in terms of naming methods and arguments and ivars and so forth), and you should follow any conventions you see unless you understand what you give up by not following that particular convention.
There are two golden rules for Cocoa:
rule 1: if you're coding up something that seems like something any realistic application would have to include, you should take another look @ the docs b/c apple probably gave it to you already.
rule 2: a lot of functionality you'd expect to be in utility classes is buried in base classes (like NSObject, NSArray, NSDate, etc.).
I really like Objective-C. I had been using mostly Ruby before I started Obj-C (to make a quick iPhone app), and I liked it so much that I ended up going even further and doing about half of my programming in C++. Obj-C was a nice introduction to using a compiled language in real code that did stuff (as opposed to CS homework, which was my only previous C experience). When I wanted to make real stuff (servers), though, Obj-C wouldn't work since it had few libraries and relied heavily (in practice) on Apple's implementation of NS* classes.
If you have programming experience, you should be able to learn 99% of Objective-C in about 5 hours.
If you have programming experience, you should be able to learn 99% of Objective-C in about 5 hours.
You know, I always wondered why they don't have, as contrasted with the "For Dummies" series, "Yet Another Language: Foo" books: books that assume you already know every language but this one, are already down on all the theory behind the language, and just want to know the syntactic, library-usage, and perhaps semantic (for example, macros in Lisp) transforms to take the code you already know how to write and retool it.
The flagship books of the series would be for Java and PHP, marketed to people that otherwise abhor those languages, but have to whip them out for the requirements of a specific project.
The flagship books of the series would be for Java and PHP, marketed to people that otherwise abhor those languages, but have to whip them out for the requirements of a specific project.
Don't forget idioms, such a book should also include programming idioms, so you don't end up writing Java code in Python, etc.
For C# and Java, I can recommend Peter Sestofts Precisely books. They're short and to the point:
http://www.itu.dk/~sestoft/javaprecisely/
http://www.itu.dk/~sestoft/csharpprecisely/
(Author is my thesis advisor, so beware)
I think there are some website guides out there (Google for 'em) that do a good job of introducing Obj-C to C++ coders.
That's an excellent idea. Why don't you start writing them? I'll be your first customer.
You can learn Objective-C in about 5 hours, true (probably less, if you know C and C++). The point being that Obj-C without NSObject (and cocoa framework) is not a big deal. The "good things" come from cocoa and Interface Builder. And you will need more than a few hour for cocoa.
Obj-C by itself is C with a very thin OOP layer (and an associated frankly strange syntax for calling methods). Cocoa is a very interesting programming framework with wonderful programming tools.
I finally understand MVC! Cocoa makes really good use of Controllers. Even in a lot of the Smalltalks, controllers languish a bit.
The syntax for calling methods is from Smalltalk, BTW. It's just different. It makes the method names document the arguments.
The syntax for calling methods is from Smalltalk, BTW. It's just different. It makes the method names document the arguments.
Objective-C + Cocoa is the most productive GUI application development kit I have ever used.
If you are put off by the syntax, then you are placing a lot of meaning in the arbitrary weight of your existing habits.
If you are put off by the syntax, then you are placing a lot of meaning in the arbitrary weight of your existing habits.
I was extremely put off by the syntax when I first got started, but I was coincidentally at the same time checking out lisp and getting out of my c/c++/java/c# world (thanks school). It only takes time to get used to. And you are right, it is all about your existing habits.
In some ways it's a giant step backwards... you have to deal with pointers and header files. And it repeats itself a lot (declare the same things multiple times). String manipulation is awful in Objective C.
I would say it's a hell of a lot better than C. But kind of irritating compared to Java or Ruby.
I would say it's a hell of a lot better than C. But kind of irritating compared to Java or Ruby.
Its interface is definitely cumbersome by Java standards - but through it you gain a lot of control over performance. String ops are painful because you are cloning your memory over and over, and if you used NSMutableString instead, you'd get a much nicer interface as a result.
If ever in Cocoa you think to yourself "man, this API is really awkward", Google it, you might find that you're not using it right. It certainly worked for me.
If ever in Cocoa you think to yourself "man, this API is really awkward", Google it, you might find that you're not using it right. It certainly worked for me.
You can't really call it a step backwards, since it's been around for 20 years, long before many other dynamic languages like Ruby and Python. But irrespective of time, there are a few annoyances compared to at least Ruby (I wouldn't say it's worse than Java though).
The pointers aren't such a big deal, as long as you don't try to use the math operators on them. You just have to remember the "*" in declarations. Remember, objects in most dynamic languages are "pointers", you just don't have access to the raw bits.
BTW, Objective-J solves the problems you mentioned (no raw pointer access, no header files or needing to declare things multiple times, the "+" operator does string concatenation and regexes are built in). Of course it's mostly for client side web apps, rather than native apps (though Cappuccino works in Adobe AIR...)
The pointers aren't such a big deal, as long as you don't try to use the math operators on them. You just have to remember the "*" in declarations. Remember, objects in most dynamic languages are "pointers", you just don't have access to the raw bits.
BTW, Objective-J solves the problems you mentioned (no raw pointer access, no header files or needing to declare things multiple times, the "+" operator does string concatenation and regexes are built in). Of course it's mostly for client side web apps, rather than native apps (though Cappuccino works in Adobe AIR...)
I consider it a step backwars because Apple is forcing us to use it (again). Why not let a 20 year old language that hasn't aged well rest in peace?
I like how thin the Objective-C layer is above C. All of the language constructs are accessible through pure C method calls, which provide a lot of insight into how the system works.
Any time I sit and think about how something is done in Objective-C, it doesn't take long to work out how I'd implement it and C and most of the time I can be pretty close (or quickly find), how various bits of "magic" are accomplished.
I don't like the overloaded dot operator added in 2.0, and have yet to hear a good reason for its inclusion (attracting developers used to using dots is not a good reason, imho; reducing the number of nested braces is better, but still unnecessary). I could do without garbage collection. Reference counting really isn't that hard.
The other features (namely properties and fast enumeration) are nice additions to the language.
(edit: multiple ideas, one poorly written sentence)
Any time I sit and think about how something is done in Objective-C, it doesn't take long to work out how I'd implement it and C and most of the time I can be pretty close (or quickly find), how various bits of "magic" are accomplished.
I don't like the overloaded dot operator added in 2.0, and have yet to hear a good reason for its inclusion (attracting developers used to using dots is not a good reason, imho; reducing the number of nested braces is better, but still unnecessary). I could do without garbage collection. Reference counting really isn't that hard.
The other features (namely properties and fast enumeration) are nice additions to the language.
(edit: multiple ideas, one poorly written sentence)
I think dot notation was a mistake -- it creates ambiguity between what is an object and what is a struct. There's no way to know without the aid of the documentation or the compiler.
Reference counting isn't that hard, but garbage collection is superior. I used to fall into the same camp as you, but prolonged experience to Objective-J and then going back to Objective-C, I realized that even though I knew how to solve the problems, they weren't worth wasting cycles in my thought processes. All that to say, reference counting works really well, but there's no good argument not to just use garbage collection (at least 99% of the time).
Reference counting isn't that hard, but garbage collection is superior. I used to fall into the same camp as you, but prolonged experience to Objective-J and then going back to Objective-C, I realized that even though I knew how to solve the problems, they weren't worth wasting cycles in my thought processes. All that to say, reference counting works really well, but there's no good argument not to just use garbage collection (at least 99% of the time).
Yeah. One of the advantages of Objective-C over C++, IMO, is that it's clear which syntax is foreign to C and which is the extension. For example, Object-C strings are prefixed with @, so you see stuff like Log(@"Some message").
It looks weird to a C programmer, but it reduces ambiguity once you move up the learning curve.
It looks weird to a C programmer, but it reduces ambiguity once you move up the learning curve.
This is more of a question than a comment, but isn't it the case that sometimes garbage collection will succeed where reference counting will fail?
I've used a kind of reference-counted pointer in C++, but it'll fail if the reference graph isn't basically a DAG, (e.g. if you have some kind of circular reference). Do garbage collectors catch this when reference counting won't?
I've used a kind of reference-counted pointer in C++, but it'll fail if the reference graph isn't basically a DAG, (e.g. if you have some kind of circular reference). Do garbage collectors catch this when reference counting won't?
Yes.
That dot operator took me forever to understand , its highly unintuitive. @synthesize should of just created the setMethod and getMethod that would make sense. Not some weird property light. I'm also a big fan of the parameter descriptions, it makes it really easy to read.
I've been using obj-c for around a year now, and it's growin' on me :)
I didn't like it too much at first (funky syntax, different naming conventions, generally crappy string manipulation), but once I started using it, especially in conjunction with cocoa and ib, I really started liking it.
It has some cool perks, like using '+' (I forget the technical term) to add functionality to an existing class (i.e. adding a method to the NSString class by creating an NSString+Additions.m file, and all classes in your project can call that method on any NSString object). Much easier than having to create an NSString subclass just to add one method, and then having to remember to name all your NSString's something like MyString* str;
I also like that I can just throw a chunk of c or c++ code in there, and call it as a method. Kinda like having native JNI (department of redundancy department). Alright that was a really bad analogy...
Xcode is a decent SDK as well.
I didn't like it too much at first (funky syntax, different naming conventions, generally crappy string manipulation), but once I started using it, especially in conjunction with cocoa and ib, I really started liking it.
It has some cool perks, like using '+' (I forget the technical term) to add functionality to an existing class (i.e. adding a method to the NSString class by creating an NSString+Additions.m file, and all classes in your project can call that method on any NSString object). Much easier than having to create an NSString subclass just to add one method, and then having to remember to name all your NSString's something like MyString* str;
I also like that I can just throw a chunk of c or c++ code in there, and call it as a method. Kinda like having native JNI (department of redundancy department). Alright that was a really bad analogy...
Xcode is a decent SDK as well.
I enjoy it, it's my compiled language of choice. Easier to work with than plain C coming from a dynamic language background.
Personally, I think Objective C is a horrid and butcherous hack that really ought to have died when C++ was standardised. Trying to make C in to some kind of bastard and retarded cousin of smalltalk was never a good idea.
I would have said the exact contrary oppinion... C++ is a horrid and butcherous hack that should have died and let objective C take over the world...
Of course I'm exagerating a bit... but objective c feels a lot cleaner to me than C++
Well, I think the real issue is that C++, C, and Objective C are all bad.
If you want OOP, slapping it on top of assembly language isn't a great idea. Use CL or Smalltalk instead; or any of the dynamic languages. Those are much closer to being good than anything in the C family.
If you want OOP, slapping it on top of assembly language isn't a great idea. Use CL or Smalltalk instead; or any of the dynamic languages. Those are much closer to being good than anything in the C family.
Objective-C is a dynamic language.
Check out MacRuby, which is Ruby implemented on top of the Objective-C runtime: http://www.macruby.org/
The key difference between this and other "bridges" is Ruby classes are implemented as Objective-C classes. This couldn't have been done if Objective-C weren't as dynamic as it is. Objective-C is basically Ruby in C's clothing (which leads to a very different "feel", but in terms of "dynamicism" they're approximately the same).
And "slapping it on top of assembly language"? I'm not sure what that has to do with anything. C compilers are usually written in C. V8 (Chrome's JavaScript engine) generates machine code. What exactly is your argument?
Check out MacRuby, which is Ruby implemented on top of the Objective-C runtime: http://www.macruby.org/
The key difference between this and other "bridges" is Ruby classes are implemented as Objective-C classes. This couldn't have been done if Objective-C weren't as dynamic as it is. Objective-C is basically Ruby in C's clothing (which leads to a very different "feel", but in terms of "dynamicism" they're approximately the same).
And "slapping it on top of assembly language"? I'm not sure what that has to do with anything. C compilers are usually written in C. V8 (Chrome's JavaScript engine) generates machine code. What exactly is your argument?
You consider those three languages bad compared to Lisp/Smalltalk, without asking why C and C++ were vastly more popular.
I see your point about OOP, by the way: I don't think I really got C until I learned assembly language, and then it all fell into place.
Looking only at language aesthetics, Lisp/Smalltalk are excellent at OOP. We now have the benefit of computers that are insanely fast by the standards of the history of computing.
Go back a decade, and you want to get the best performance for a system by taking that awareness of the underlying assembly code. If you're dealing with pointers and structs then you can write sections of your program that you know will convert to a handful of assembly instructions.
You do have a point: trying to do OOP in a fancy version of assembly language is not going to be as seamless as a language with different core concepts. There are some ugly weld marks in C++ and ObjC, although I have come to appreciate the ObjC design approach after some time with it.
I just think it is meaningless to talk about good or bad languages without reference to the goals of the programmer.
I see your point about OOP, by the way: I don't think I really got C until I learned assembly language, and then it all fell into place.
Looking only at language aesthetics, Lisp/Smalltalk are excellent at OOP. We now have the benefit of computers that are insanely fast by the standards of the history of computing.
Go back a decade, and you want to get the best performance for a system by taking that awareness of the underlying assembly code. If you're dealing with pointers and structs then you can write sections of your program that you know will convert to a handful of assembly instructions.
You do have a point: trying to do OOP in a fancy version of assembly language is not going to be as seamless as a language with different core concepts. There are some ugly weld marks in C++ and ObjC, although I have come to appreciate the ObjC design approach after some time with it.
I just think it is meaningless to talk about good or bad languages without reference to the goals of the programmer.
You make zero sense.
I rather like it. The problem is this: make a language that is a strict extension of C and has Smalltalk-style OO.
It's not a bad problem to solve and Objective-C does a nice job. The syntax is odd, but it's to clearly separate the Objective-C parts from the C parts.
C++ on the other hand mushes the syntax together. It might look more C-esque, but it's less dynamic and more difficult to maintain as your project grows, IMO.
Plus XCode is awesome.
It's not a bad problem to solve and Objective-C does a nice job. The syntax is odd, but it's to clearly separate the Objective-C parts from the C parts.
C++ on the other hand mushes the syntax together. It might look more C-esque, but it's less dynamic and more difficult to maintain as your project grows, IMO.
Plus XCode is awesome.
I couldn't disagree more, but I'd be curious to hear your reasons.
horrid and butcherous hack
Obj-C, unlike C++, is a strict superset of C. All C code works in Obj-C (bar the new keywords), unlike with C++. I really think you're missing the point here. Apart from the controversial syntax, Objective-C's elegance sets it apart from C++ more than anything else. Objects and classes are really C structs. It's all introspectable, and it's all admirably simple (2.0 additions aside).
C++ is a convoluted, over-wrought solution to a problem which Objective-C solved with minimal additions to C. And Cocoa is leagues ahead of anything you have in C++.
Obj-C, unlike C++, is a strict superset of C. All C code works in Obj-C (bar the new keywords), unlike with C++. I really think you're missing the point here. Apart from the controversial syntax, Objective-C's elegance sets it apart from C++ more than anything else. Objects and classes are really C structs. It's all introspectable, and it's all admirably simple (2.0 additions aside).
C++ is a convoluted, over-wrought solution to a problem which Objective-C solved with minimal additions to C. And Cocoa is leagues ahead of anything you have in C++.
On the iPhone there are two main problems. First is lack of garbage collection. Not everyone can keep track of their allocations easily and the result if unstable programs for the end users. While there is some notion of allocatin pool it has problems - for once it's scoped to call stack, thus making it little more than extension of on-stack variables. Further, some standard methods that create e.g. strings add-ref strings for you, but some don't. Ther eis no consistency. It shouldn't have been that way.
The second problem is that cocoa touch is very async. By contrast windows forms is very synchronized - when you create a form and pass control to it, control does not return until that form closes, and then result is returned. Even a cavement can understand that. In cocoa/touch you pass control to a form, and then it returns and then you have to return it as well before the form is drawn. If you do something like closing a form in the event where you are supposed to re-draw the form the system blows up on you. If you set background from one callback it goes into infinite requirsion. There is no way to tell upfront - you have to try. It's very unintuitive that way and hard to wrap your head around it.
I'm sure a bunch of c00l haxors will tell you that they have no problem using it and therefore nobody else should have problems, but hey - some people can ride unicile, doesn't make it a good transporation choice.
The second problem is that cocoa touch is very async. By contrast windows forms is very synchronized - when you create a form and pass control to it, control does not return until that form closes, and then result is returned. Even a cavement can understand that. In cocoa/touch you pass control to a form, and then it returns and then you have to return it as well before the form is drawn. If you do something like closing a form in the event where you are supposed to re-draw the form the system blows up on you. If you set background from one callback it goes into infinite requirsion. There is no way to tell upfront - you have to try. It's very unintuitive that way and hard to wrap your head around it.
I'm sure a bunch of c00l haxors will tell you that they have no problem using it and therefore nobody else should have problems, but hey - some people can ride unicile, doesn't make it a good transporation choice.
I vote against designing programming languages for cavemen.
How about the average Joe programmer? Your typical PHP or VB developer?
I care very much about this group of people - they may not be wizards and ninjas, but they can certainly provide for a lot of needs out there.
I care very much about this group of people - they may not be wizards and ninjas, but they can certainly provide for a lot of needs out there.
I'm not very familiar with the language yet, but my first impressions have been favorable. Programming for the iPhone has been a breeze. Also, I really like that you can use C/C++ with it. (Not just exported functions; you can interact with a C++ object directly from within a .m file, for example.)
I like it, very easy to get into. Obj-C and Cocoa are a killer combination. Definitely get Aaron Hillegass' "Cocoa for Programming for Mac OS X" now in 3rd edition.
Objective-C is great - but Cocoa makes it even better. :)
I have summarized my (negative) thoughts here: http://blog.blinker.net/2008/11/11/impressions-from-the-ipho...
I haven't really used it, though, it is just the impression I took away from glancing at the tutorials and listening to the beginnings of the iPhone tech talk.
I haven't really used it, though, it is just the impression I took away from glancing at the tutorials and listening to the beginnings of the iPhone tech talk.
You won't get it until you actually use it for a while.
(That was my experience.)
(That was my experience.)
Behind Lisp, Obj-C/Cocoa is the most fun I have had programming.
Does anyone use Objective C for anything but the iphone?
Yes. It is used in Mac development all the time.
OpenStep and GNUStep developers.
And also http://etoileos.com/ which is based on GNUstep. Very interesting project.
A long time I ago I used to make multi-agent artificial life simulations in a system called Swarm, which was in Objective C:
http://www.swarm.org/wiki/Main_Page
I don't remember much, just that it was a nice language, well fitting for the problem domain. It seems meanwhile they also added Java and C++ support.
http://www.swarm.org/wiki/Main_Page
I don't remember much, just that it was a nice language, well fitting for the problem domain. It seems meanwhile they also added Java and C++ support.
I too used to program in the Swarm platform with Objective-C.
Off-topic, but if you are interested in frameworks like this, also check out the MASON Multiagent Simulation Toolkit (which is based in Java):
http://www.cs.gmu.edu/~eclab/projects/mason/
Off-topic, but if you are interested in frameworks like this, also check out the MASON Multiagent Simulation Toolkit (which is based in Java):
http://www.cs.gmu.edu/~eclab/projects/mason/
I do, I've been doing Mac dev for a while though, so it's just us Mac people...
I played with it some about 10 years ago, but at that time it was really in the wilderness and didn't have much practical application, so I let it be. It seems nice in some ways, but I don't really see it making the jump out of MacOS X territory. Who knows, though.
objective c is fine, its cocoa i find daunting. i am used to object.method() syntax so the [object message] syntax was a little hard to parse at first.... but you get used to it.
i went from writing a lot of python to writing obj-c so the transition to a strongly typed, compiled-and-linked language was a bit frustrating. not surprisingly its not as fluid a language as python..... but you get used to it
i went from writing a lot of python to writing obj-c so the transition to a strongly typed, compiled-and-linked language was a bit frustrating. not surprisingly its not as fluid a language as python..... but you get used to it
actually, objective-c is not strongly typed. it is quite dynamic, despite the fact that you often see types specified. you could replace every declared type with 'id', and your code would still work, and it would be dynamically typed.