Objective-C Comes of Age 437
New submitter IdleThoughts writes "Sometimes it takes a long time to spark a revolution. Long the ugly duckling of programming languages, iOS' Objective-C passed C# in the 'TIOBE Programming Community Index this month and seems on a trajectory to overtake C++ in the next few. It was invented in the early 1980s by Brad Cox and Tom Love, with the idea of creating 'Software Integrated Circuits' and heavily influenced by Smalltalk — yet another legacy from Xerox PARC, along with desktop GUIs, ethernet and laser printers. It was adopted early on by Steve Jobs' NeXTStep, the grand-daddy of all that is now OS X. It had to wait, however, for the mobile device revolution to have its day, being ideally suited to the limited resources on portable devices. It's still being actively developed by Apple and others, sporting the new automatic reference counting and static analysis in the Clang compiler. It turns out it has supported dynamic patching of code in applications all along. What more surprises does this venerable language have up its sleeve?"
New features (Score:5, Informative)
Clang recently added literal syntax for collections and boxed numbers:
NSArray *array = [NSArray arrayWithObjects:@"one", @"two", @"three", nil];
NSDictionary *dict = [NSDictionary dictionaryWithObjectsAndKeys:
@"bar", @"foo",
@"post", @"first",
nil];
NSNumber *num = [NSNumber numberWithInteger:42];
NSArray *array = @[ @"one", @"two", @"three" ];
NSDictionary *dict = @{
@"foo" : @"bar",
@"first": @"post"
};
NSNumber *num = @42;
Properties will also be synthesized by default, so you won't have to write @synthesize statements anymore, and corresponding ivars will be synthesized with an underscore prefixed name.
Objective-C is interesting to follow because it's a language that was once considered totally niche and almost completely irrelevant, but the frameworks were beloved by developers, and the language's keepers kept at it long enough for the world to see how useful the language is. It also has historical significance as the tools used for creation of the original WorldWideWeb program as well as the development of Doom and Quake. John Romero wrote [rome.ro] about he and Carmack simultaneously editing the same map in DoomEd thanks to distributed objects.
It's still verbose and Smalltalk-ish, but the language as a whole has improved drastically since the transition to Clang. According to the mailing list, Apple has more engineers allocated to the language than ever before, and a lot of it has to do with the move away from GCC.
I hear that GCC is working toward being easier to modify, so the competition from Clang has been good for everybody, and it's all open source.
Re:New features (Score:4, Informative)
Ignorant comment. You don't need Apple to do objc. The compilers are open source. (Both gcc and clang.) There is also the GNUstep project, which implements many of the NS* classes.
BARF! (Score:0, Informative)
And I mean extreme barfing! A terrible language with terrible syntax, semantics, and protocols.
What a waste of time for programmers everywhere!
Re:New features (Score:5, Informative)
If you haven't used Obj-C, at least not on an Apple platform, then that's why you don't know that Apple provides excellent frameworks very much like MS provides
Re:New features (Score:3, Informative)
STFU whippersnapper, when I was a kid we cut punchcards out of coke boxes and punched them with our teeth -- and we liked it.
But seriously -- if you don't have a computer to run your programs on, it doesn't much matter whether you have one to write them on or not. There was a day when every computer came with the usual set of programming tools (granted, for much of this period the programming tools, at least on home machines, were rather minimal and essential to using the computer as well). So even if you only ever ran other people's programs, you had a BASIC interpreter right there if/when you took up programming. I understand why few people have any use for development tools these days, but you'll note all the main consumer OSes/OS vendors provide a free development environment for that platform, even if it's not installed with the OS -- almost every Linux distro packs GCC, Apple offers Xcode, and Microsoft offers a stripped-down version of Visual Studio. Lucky for GP, there's also free Objective-C compilers for pretty much all platforms -- it seems more likely that he didn't know of them (due to everyone's retarded focus on Objective-C only w/r/t iOS) than that he's trolling.
ObjC sucks (Score:5, Informative)
I dev in ObjC on iOS almost every day, and the language sucks. I think it sucks less than C++, but I'm not sure that says much. The Xcode IDE (which also sucks) and the bolted-on features help, but overall the language hasn't aged as well as plain old C - i.e. while coding in it, you are constantly reminded that it is not a modern programming language. Anytime a language gets in your way, it's a bad thing, and that happens an awful lot with ObjC.
(And before the flames start: yes, I fully recognize that nobody is forcing me to dev for the iOS platform, it's a choice I've made because I make gobs of money off of it. But that doesn't make ObjC suck any less, it just makes me willing to tolerate the suck and grumble about it on /.)
Re:NeXTStep the grand-daddy of all that is now OS (Score:4, Informative)
OSX is NOT the NeXT OS with the Mac GUI. That would be much better.
In fact it can be claimed to be a lineal descendent of NeXT, but it's been greatly modified, and the new UI is a regression from either the Mac or NeXT GUIs.
Also iOS - Obj C is obviously referring to the proprietary dialect of ObjC used in Apple mobie devices. (Nothing to do with Cisco iOS either, why cant they think of their own names for this stuff?) There are other dialects, notably the GCC version, which is much more widely applicable.
Objective-c only required for user interface code (Score:5, Informative)
Its recent success has obviously been tied to one gigantic hit platform, for which it is the only natively supported PL.
To be clear, objective-c is only required for iOS user interface code. An iOS developer is free to use c/c++ elsewhere, free to use posix rather than iOS for many operating system services, etc.
Re:New features (Score:1, Informative)
Objective-C literally looks like vomit.
The last time I looked at Objective-C code, I didn't see any partially-digested bits of dinner in it, so I don't think that's true [theoatmeal.com].
Re:Yes but (Score:4, Informative)
Uhh, C, C++ and Javascript are all supported on iOS... notably, one of those is below Obj-C on the list, and another is looking like it'll soon fall below obj-c.
Re:Seems like Mac is a win ... (Score:3, Informative)
You know, or get the Express version that does everything a hobbyist needs for free.
Emphasize hobbyist, actually only some hobbyists. No 64-bit code for Express. No Microsoft Foundation Classes, MFC really simplifies Windows use interface coding and it is very commonly used in Windows apps. No profile guided optimization. No remote debugging. No resource editors.
Re:ObjC sucks (Score:5, Informative)
Here's a few off the top of my head. Some of them may be specific to Cocoa, but I'm pretty sure that even those are rooted in ObjC's "features":
Method signatures are often ridiculously long (see NSBitmapRep's initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel: method)
Parameter names in method calls are /always/ named. You can't just say obj.someMethod(x,y). It's always [obj someMethodForX:x y:y].
The above combine to make even the most basic operations tedious. Want to trim leading/trailing whitespace off a string? Enjoy [someString stringByTrimmingCharactersInSet:[NSCharacterSet whitespaceCharacterSet]]
Immutable arrays, dictionaries, sets, strings. I get it, it can be useful for performance to know something is immutable (maybe, I'm not that convinced). But the common use case is most certainly mutable, so /that/ should be the default, e.g. NSArray should be mutable and then if needed there can exist some NSImmutableArray or something. But no, they did it the other way around.
Memory management (up until recently) was neither fully manual nor fully automatic and ownership was based on naming conventions
Being a superset of C, they couldn't provide an object-oriented array class using the normal array syntax, so instead you have tedium like [myArray objectAtIndex:2]
Ditto for strings. Also, you have to prefix string constants with '@'.
Similarly, you can't put "plain" objects into arrays, e.g. [myArray addObject:5] won't work, but [myArray addObject:[NSNumber numberWithInt:5]] will.
And of course you can't just create an array with ['a', 'b', 'c'] but instead have to do [NSArray arrayWithObjects:@"a", @"b", @"c", nil].
Backwards conventions like [NSDictionary dictionaryWithObjectsAndKeys:@"value0", @"key0", @"value1", @"key1", nil];
If I'm going to pay the dev cycle price of a compiled language, it should catch stuff like non-existent selectors at compile time instead of blowing up at runtime
Stack traces from delayed selector calls have zero contextual information
The single inheritance model and a strict class hierarchy discourages writing reusable code. For example, if I have an app that runs on iPad and iPhone and they share a common screen (from the user's perspective although the layout/design might be significantly different), it's a real task to write a common parent class holds the common code.
Many violations of don't-repeat-yourself: if you want to have an object with properties like Foo.title, then the code is roughly:
@interface Foo
{
NSString *title;
}
@property (nonatomic, retain) NSString *title;
@end
@implementation Foo
@synthesize title
-(void)dealloc
{
[title release];
[super dealloc];
}
Similarly, there's no way to have a truly dynamic object with a clean syntax, e.g. in Python/ruby/js/and a host of others you could have a quick little object you use to pass state around, kind of like a struct that has its members added on the fly, e.g.: x = new Object() ; x.name = 'dave' ; x.age = 3. There is literally no way to do that in ObjC - the best you can do is create mutable dictionary and use its verbose syntax.
We could have a whole extra thread about the toolchain (Interface Builder is an abomination, Xcode often pegs multiple CPUs when it's just sitting there, if you kill the simulator instead of stopping the app via Xcode then you often have to reboot your host machine before you can run the simulator again) but I digress.
Re:Method Syntax (Score:4, Informative)
Objective-C is a strict superset of C. Anything it adds over C has its own special syntax and notation, possibly to help reduce confusion. Properties didn't always use dot-notation--you used to have to do [object ivar] in order to access a member variable, and [object setIvar:ivar] to change it. The (relatively new) dot-notation and @property syntax is just shorthand for this functionality, and a welcome thing (though you can still use the old style).
Objective-C used to have a lot of irritating things about it, but I think the language has really improved over the past couple years. Properties, auto-synthesizing, automatic garbage collection, fast enumeration, etc. have all made the language much better. Once I got past the odd messaging syntax, I really came to like it, and I have to wonder how much recent experience some of these vocal haters have with the language.
Re:ObjC sucks (Score:5, Informative)
About half of these have been fixed (and were actually new problems that didn't exist in Objc-1.0). Obj-C 2.0 introduced some of the "don't repeat yourself" issues with things like properties and consistency issues between the new property syntax and the existing syntax, but with the new LLVM you can just declare properties and not have to synthesize. In addition, ARC takes care of the memory management code. New LLVM also has Obj-C constants which take care of things like your dictionary example. You haven't needed a backing ivar, so that NSString *title; line in the interface can go.
(Your code is also in bad form. You shouldn't do [title release]. It should be self.title=nil. Much cleaner, and you get the same thing without doing a roundabout around the property. You also clear the reference to reduce any chance of accidentally hitting a dealloc'd object.)
As far as complaining about method names... That seems like a personal taste thing... And honestly, it's considered good form to have long method names these days, because the method names themselves become the comments, and it makes extremely clear exactly what the method does. And autocomplete should keep you from having to type out the entire method. There's been a lot of coding standards material written on why this is a good thing. You may not like it, but it seems like a majority of people actually do, and if you're writing APIs or classes, people aren't going to like short method names very much. Writing long method and variable names that describe exactly what they do was one of the first pieces of advice I got in my programming career, and it's served me very well.
It's actually one of my biggest pet peeves when a C developer starts writing Obj-C stuff. They use these short, truncated method names for no apparent reason, when a longer name will reduce confusion when the code is shared. (And making your code reusable is one of the tenants of Obj-C for very good efficiency reasons.)
As far as XCode, yeah, it sucks. We all know it. But every IDE has it's quarks. Eclipse is slow and also somewhat unstable, and Visual Studio has it's own quarks. There has been a lot of pressure on Apple to make XCode better, and indeed each release seems to be more and more stable, with 4.0 being the low point.
Honestly, from your example code, it certainly looks like you've worked with Obj-C, but it doesn't look like you really had a strong understanding of it. Not that I don't blame you, with Obj-C 2.0 it became a little harder to understand, but Apple is cleaning that up.
Comment removed (Score:3, Informative)
Wrong, you can use other languages for iOS (Score:5, Informative)
Not only that, but if you want to develop on iOS, you have the choice of... Obj-C.
That is not at all true, you can use C#, Ruby, Javascript, and other languages also...