Slashdot Mirror


Objective-C Comes of Age

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

77 of 437 comments (clear)

  1. New features by bonch · · Score: 5, Informative

    What more surprises does this venerable language have up its sleeve?

    Clang recently added literal syntax for collections and boxed numbers:

    // Old way.
    NSArray *array = [NSArray arrayWithObjects:@"one", @"two", @"three", nil];
    NSDictionary *dict = [NSDictionary dictionaryWithObjectsAndKeys:
                                                @"bar", @"foo",
                                                @"post", @"first",
                                                nil];
    NSNumber *num = [NSNumber numberWithInteger:42]; // New way.
    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 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.

    1. Re:New features by flakas · · Score: 4, Interesting

      Sad sad day. Objective-C sucks! C# rocks!

      In many ways this is true, but then again, they aren't the same kind of languages. I absolutely love C# syntax and the easy readability of the code. .NET libraries are also wonderful, and in general I would rather use C# than Objective-C because of this.

      But Objective-C is closer to C and C++ than C#. I would however hope that Apple brings something like C# to OS X and iOS. I would start developing with them right away.

    2. Re:New features by Anonymous Coward · · 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.

    3. Re:New features by gwking · · Score: 5, Informative

      The readability is a bit clearer in C#, but Apple is already fixing that in Obj-C with changes like auto synthesizing properties and making the declarations of common objects simpler like the initial poster showed (with code examples). But aside from simple things like that, the readability of the code depends a lot more on the programmer than on the language.

      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 .NET. Check out: https://developer.apple.com/library/mac/navigation/#section=Frameworks Almost anything you want to do, Apple provides the foundational building blocks to help you build the application, and not waste time implementing a queue, list, or talk to a webserver.

    4. Re:New features by gwking · · Score: 5, Insightful

      You don't need Xcode to use Obj-C. Clang and gcc are open source and you can use them on Linux and Windows. You can even use clang in Visual Studio! If you mean that you want to develop OS X or iOS applications then yes, you should at least have one of those around to test on. And please hold any more complaints about Xcode being Mac-only until MS releases Visual Studio that isn't Win-only.

    5. Re:New features by Sarten-X · · Score: 5, Funny

      I'm sure someone just handed you a free PC when you decided to program for Windows or Linux.

      My last Linux dev box was pulled from a dumpster by a friend, and was handed to me. I wiped the Windows XP installation off, installed Debian, and happily started coding, so, um... yes.

      --
      You do not have a moral or legal right to do absolutely anything you want.
    6. Re:New features by Anonymous Coward · · 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.

    7. Re:New features by aceboomblain · · Score: 2

      What you are referring to has been around longer that C#, it's called Java.

    8. Re:New features by Dishevel · · Score: 5, Funny

      Let me guess, a Windows developer killed your dog, slept with your wife, read your Sports Illustrated and ruined your birthday party?

      Worse.
      A Windows developer developed Norton.
      Another Windows developer got drunk one night and had all of his humanity removed and wrote Mcafee.
      Then there was the infamous Windows developer that did Internet Explorer. I heard he started his career of terror by writing THIS program.

      --
      Why is it so hard to only have politicians for a few years, then have them go away?
    9. Re:New features by ColdWetDog · · Score: 5, Funny

      That's nothing!

      I built my last dev box from parts that I picked up off the side of the road as the electronic recycling trucks drove past.

      The case comes from old cardboard boxes stolen from underneath the bridge where the homeless folks congregate.

      It's powered by making extension cords unwound from burnt out vacuum cleaner motors and running them under high voltage power lines.

      I got the software by painstakingly gluing a pile of old AOL CDs back together.

      --
      Faster! Faster! Faster would be better!
    10. Re:New features by WrongSizeGlass · · Score: 4, Funny

      Sounds a lot like the Mono vs .NET debacle. There's absolutely nothing that says that Apple won't just come around and sue everybody elses buts off for unlicensed use of Objective-C and Apple's copyrighted APIs.

      Oh, come on, Apple isn't going to sue you for using Objective-C. They send you a sympathy card and a case of aspirin.

    11. Re:New features by skids · · Score: 2

      My last Linux dev box was pulled from a dumpster by a friend, and was handed to me. I wiped the Windows XP installation off...

      Yes it's a shame how people throw away things that other people might want, and then other people throw garbage on top of it. I've had to wipe egg salad off a few things I've salvaged, but Windows XP? Yeauchk! I hope you burned the towelettes afterwards.

    12. Re:New features by Yold · · Score: 2

      It's still too verbose

      Fixed that for you. For the uninitiated, trimming a string is as simple as

      NSString *s = [stringToTrim stringByTrimmingCharactersInSet: [NSCharacterSet whitespaceCharacterSet]];

      The way the language functions is beautiful, but they seriously need to get rid of stuff like this.

    13. Re:New features by Nerdfest · · Score: 2

      I've spent all afternoon fighting the urge to make a joke about Apple forcing the use of a language that was written by Love/Cox. I think I've done surprisingly well.

    14. Re:New features by ChipMonk · · Score: 2

      Sadly, given the fact that Oracle has sued Google over nine lines of standard library code for the Java language (developed by Sun, bought out by Oracle), it wouldn't shock me at all to hear that Apple has sued over Objective-C.

      I know, the parent comment is funny, but the best humor has a grain of truth. In this case, it's a grain of sand in a shoe.

    15. Re:New features by TheRaven64 · · Score: 2

      Why? Anyone can look at that line and understand exactly what it does without any knowledge of the APIs (although those of us that are familiar with them will suspect that you probably meant +whitespaceAndNewlineCharacterSet). It's more to type, but given that even vim with the clang plugin can autocomplete from a couple of characters that's not really an issue. Most code spends a lot more time being read than being written, and Objective-C is very easy to read.

      --
      I am TheRaven on Soylent News
    16. Re:New features by Jane+Q.+Public · · Score: 2

      "But aside from simple things like that, the readability of the code depends a lot more on the programmer than on the language."

      I would dispute this. In fact I think it is a rather bizarre statement. Take the example I gave earlier. Here's the Obj-C:

      NSString *s = [stringToTrim stringByTrimmingCharactersInSet: [NSCharacterSet whitespaceCharacterSet]];

      Here's the same functionality in MacRuby (a Ruby wrapper for Obj-C):

      my_string.strip

      Which one is easier to read? While I don't claim that MacRuby compiles to code that is quite as fast as native Obj-C, which one is easier to read is hardly in question. And that's mostly a matter of the language, not the programmer.

    17. Re:New features by Kalriath · · Score: 2

      Dear god, how the fuck did I write that console application with no UI?!?

      --
      For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
    18. Re:New features by tyrione · · Score: 2

      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.

      Yes and No. GNUStep has a long way to go before it completely supports AppKit, Foundation Kit, missing Core Data and more.

    19. Re:New features by am+2k · · Score: 2

      I just think its a bit of a shame they went with objective-C which is a bit strange, they might have been better off with C++ which has as many quirks as obj-C but is more widely known and is just as performant.

      C++ doesn't support the dynamic dispatching needed for what makes Cocoa so great to write. Apple tried to switch to Java (which has reflecrion), but it was too slow, so they abandoned that attempt.

    20. Re:New features by rthille · · Score: 2

      Well, it's been years and years since I wrote Objective-C (I worked for AppSoft, doing NeXTStep Productivity Apps), and have never touched ruby, but to me, the Obj-C code is clearer. A hell of a lot more to type, but I know it's stripping the whitespace characters from 'stringToTrim' and creating a new string.

      my_string.strip looks like a call to a non-standard (project specific, locally developed) bit of code that could do anything. If I knew Ruby, I might totally know it _was_ standard and what it did. But if you can get past the Smalltalk syntax (which I think is a benefit, allowing/forcing documentation inline of the code), Obj-C is much more readable, and thereby more maintainable.

      --
      Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
  2. Yes but by Anonymous Coward · · Score: 2, Insightful

    Its recent success has obviously been tied to one gigantic hit platform, for which it is the only natively supported PL.

    1. Re:Yes but by Galestar · · Score: 2, Interesting

      Similar to C#/VB and the other .NET languages...

      Not in the least. Windows is not tied to a language (you can use whatever you like), where iOS is. Now I can't comment on what languages are available for Windows Phone 7, or Windows 8 has/will have, but they do not have the platform adoption that iOS does. C# usage is based on its merits, where Objective-C usage is based on Vendor lock-in.

      --
      AccountKiller
    2. Re:Yes but by maccodemonkey · · Score: 5, Insightful

      And just like iOS, it's impossible to do an Android app without using Java. Sure, just like iOS, there are abstraction toolkits, support for C/C++, etc. But you can't do an Android app without Java.

      Yet I didn't see any complaining about Google forcing "Java vendor lock in" in your posts, and complaining about that being unfair.

    3. Re:Yes but by beelsebob · · Score: 3, 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.

  3. Method Syntax by Jackmon · · Score: 2

    Fine language in many ways but I call 'Boo' on the method syntax.

    1. Re:Method Syntax by kthreadd · · Score: 2

      I'm not doing anything in Objective-C but I actually like the method name syntax. Code becomes much easier to read and hardly any harder to write if written in a somewhat modern IDE with code completion.

    2. Re:Method Syntax by Jackmon · · Score: 3

      Here's my problem with it:

              -(void) what: (int) kind of: (int) bullshit isThis;

      IMO, that is very difficult to read. And try doing a multi-file search for calls to it.

      IDEs can overcome the search problem, but the readability problem remains.

    3. Re:Method Syntax by spongman · · Score: 3, Interesting

      agreed. when i look at obj-c code it feels like someone's pushing hot pins into my eyes.

      seriously.

      why have (c-style) syntax for declaring and accessing variables and functions, and a completely different syntax for declaring and accessing bound methods?

      it makes no sense. it doesn't add anything semantically to the language. it adds another syntax construct just for the sake of it. completely unnecessary.

      and why are properties accessed using c-style syntax, and not methods?

    4. Re:Method Syntax by spongman · · Score: 2

      but is it really that much worse than

      it's not really better or worse, it's just unnecessary.

      C already has a syntax for declaring and invoking functions, and it already has a syntax for accessing variables bound to instances of structs. why did they have to invent a completely new syntax for declaring and invoking functions bound to structs?

      if "struct.field" is ALREADY a way or accessing a struct's field, and "function()" is ALREADY a way of invoking a function, then why can't "struct.field()" be a way of invoking a function that is a field of a struct? it's not that much of a stretch.

    5. Re:Method Syntax by Cinder6 · · Score: 3, 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.

      --
      If you can't convince them, convict them.
  4. Just another extension by aaaaaaargh! · · Score: 5, Insightful

    Look, I understand that people who use their tools daily want to advertise them and it's a goosd thing if you like what you're using, but let's face it: Objective-C is just another unsafe, hopelessly outdated extension of C as C++. It's great to get things done and sucks less than C++, but it's not in any way a modern language nor is it based on a great language design.

    Before people start flaming me, please consider that programming languages are tools and you choose the right tool for the right purpose and platform, and the availability of libraries is often more important than the language itself. There is no doubt that Objective-C has its place and is useful, just don't try to sell it as the latest great new thingy. Even Apple's own old Dylan was a more interesting and innovative as a language than Objective-C.

    My 2 cents. Now let the language flamewars commence.

    1. Re:Just another extension by Maury+Markowitz · · Score: 4, Interesting

      "Even Apple's own old Dylan was a more interesting and innovative as a language than Objective-C."

      Agreed. I loved the multi-interface stuff. Why doesn't anyone else pick that up? It would be particularly easy to implement in Bundles. But...

      "the availability of libraries is often more important than the language itself"

      Bingo. Lets be honest, is any native library set even *remotely* as good as Cocoa out of the box? With the exception of Delphi I've fiddled with them all, and the answer is a resounding "no!". All you have to do is compare the basic text editing widget across libraries and you can draw your own conclusions.

    2. Re:Just another extension by maccodemonkey · · Score: 4, Insightful

      Before people start flaming me, please consider that programming languages are tools and you choose the right tool for the right purpose and platform, and the availability of libraries is often more important than the language itself.

      Not only does Objective C have an extremely rich set of libraries from both Apple and the community (UIKit and Foundation are arguably the best mobile development APIs out there), but Objective C is compatible with all C and C++ libraries.

      So I'm not exactly sure what the point is. I suppose if you have to use a C library one could say "Well see, you have to use C anyway!". But at least for me, the important part is while I'm using C, I'm still encapsulating that code in Obj-C.

    3. Re:Just another extension by Arker · · Score: 2

      MMM Delphi.

      Now that brings back memories. Objective Pascal with Borland libraries. I hated high level languages back in those days, until I met Delphi.

      Borland is long gone, it would be cool if there were a free software clone out there to use though. It might even inspire me to try programming again sometime.

      --
      =-=-=-=-=-=-=-=-=-=-=-=-=-=-
      Friends don't let friends enable ecmascript.
    4. Re:Just another extension by phoenix_rizzen · · Score: 2

      You can still download Delphi and Kylix (the Linux/cross-platform version of Delphi) from various places around the Internet.

    5. Re:Just another extension by spongman · · Score: 2

      I read somewhere that .NET and C# were developed by the guy that developed Delphi.

      you mean Anders Hejlsberg?

    6. Re:Just another extension by scot4875 · · Score: 2

      Delphi lives on. It switched its base syntax from Pascal to C++, and is called C# now.

      --Jeremy

      --
      Jesus was a liberal
    7. Re:Just another extension by aaaaaaargh! · · Score: 2

      My main point was basically yours, but in contrast to you I didn't really get my message across without waking up a bunch of programming language trolls. Wrong choice of words I guess. :-/

  5. TIOBE Index by PCM2 · · Score: 5, Insightful

    Seems like every few weeks someone writes another story about the amazing "trends" in the TIOBE Index. As far as I can see, the real trend is: Languages go up in popularity, they go down, they move around, one month it's the First! Time! Ever! that a language has made the list, the next month it's gone again, and C, C++, and Java are always at the top (in varying order). Such variable results suggest that TIOBE's sampling method isn't all that reliable or accurate to begin with, but I think we all have a pretty good idea what languages people are really using and for what.

    --
    Breakfast served all day!
    1. Re:TIOBE Index by cpu6502 · · Score: 2

      Thanks for giving clarity. If we went by popularity, we'd all be listening to Rihanna or Gotye (both hit #1) or watching FOX (#1 on cable, #2 on broadcast) or reading Alex Jones infowars.com (routinely 1 or 2 in the webnews index). Popularity is interesting to note but doesn't mean much otherwise.

      --
      My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
  6. FTFY by mveloso · · Score: 2

    Look, I understand that people who use their tools daily want to advertise them and it's a good thing if you like what you're using, but let's face it: C is just another unsafe, hopelessly outdated extension of assembly. It's great to get things done and sucks less than fortran, but it's not in any way a modern language nor is it based on a great language design.

  7. Re:This Trend is Interesting by Electricity+Likes+Me · · Score: 4, Insightful

    This seems more likely to be due to the easy money currently seeming to be in iOS apps. It's a big installed base, there's a delivery system, and the consumers have been trained to expect to pay some money for just about everything on it (whereas the usefulness of free 'droid apps generally seems to be way higher - in my, admittedly limited, experience).

    I mean, if you have an idea, then the thing you want to do is try and get a few hundred thousand people to buy it for a $1, so that's what everyone is currently doing. I don't think it really says anything beyond that.

  8. Re:Comes of age? by MightyYar · · Score: 4, Funny

    In software years, one does not come of age until his 30s, and only then because he finally accepts prostitution.

    --
    W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
  9. How is it not modern? Obj-C has modern libs... by SuperKendall · · Score: 5, Insightful

    Objective-C is just another unsafe, hopelessly outdated extension of C as C++.

    Why do you claim it is "unsafe"? Almost all work done in Objective-C is very "safe", by any measure - mostly you are never using C arrays or the like. Just because they are there does not make the language inherently "unsafe" if that's not how real people use the language.

    consider that programming languages are tools and you choose the right tool for the right purpose and platform, and the availability of libraries is often more important than the language itself.

    Objective-C currently has some of the most advanced libraries for any platform. It already had great string support and other strong frameworks even before iOS, but with iOS and the Mac taking off the framework support for really advanced animations, database work, networking, etc. as good as or better than any other platform. I came from a Java world and am missing nothing for libraries... not to mention a really good set of open source libraries that offer other abilities in addition to the core frameworks.

    In fact, I would go so far as to say the range and quality of design of the frameworks are THE reason to use Objective-C.

    People like you just look at when Objective-C was developed and think because of its age it cannot be "modern". What you don't realize is that Objective-C was developing over all that time, just in a fairly parallel path to other languages - I like to refer to it as a "Steampunk" language. It is modern but just not quite the same as other things you are used to, coming from an alternate reality.

    You're going to have to come up with real reasons for Objective-C not being "modern", most of which are probably quite out of date by now. Before we can flame you, there need to be specifics which we can skewer...

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  10. ObjC sucks by dbrueck · · 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 /.)

    1. Re:ObjC sucks by pauljlucas · · Score: 2

      I dev in ObjC on iOS almost every day, and the language sucks.

      Please give examples why.

      --
      If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
    2. Re:ObjC sucks by dbrueck · · 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.

    3. Re:ObjC sucks by maccodemonkey · · 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.

    4. Re:ObjC sucks by Thinine · · Score: 2

      Method signatures are often ridiculously long (see NSBitmapRep's initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel: method)

      That's rather the point. It make code easier to read and understand when you can see, in the method invocation itself, what all of the parameters are for.

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

      Again, rather the point. Otherwise your above example would endue as initWithBitmapData(p,w,h,b,s,a,p,c,f,r,b).

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

      Autocomplete makes this rather irrelevant, no? Especially the much improved autocomplete in Xcode4+.

      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.

      That you don't actually understand this point is pretty telling. Performance isn't the only reason to make arrays and such immutable by default. It also makes such structures safer to pass around, especially to outside code, without having to worry about the data getting modified unexpectedly.

      Memory management (up until recently) was neither fully manual nor fully automatic and ownership was based on naming conventions

      Ownership is always based on naming conventions, or else there would be no predictability and the language would be unusable.

      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]

      "Fixed" in enhancements coming with Xcode 4.4.

      Ditto for strings. Also, you have to prefix string constants with '@'.

      Oh no, a single extra character!

      Similarly, you can't put "plain" objects into arrays, e.g. [myArray addObject:5] won't work, but [myArray addObject:[NSNumber numberWithInt:5]] will.

      Perhaps you one valid complaint, rendered nearly irrelevant by enhancements again coming in Xcode4.4.

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

      Oh hey, same thing.

      Backwards conventions like [NSDictionary dictionaryWithObjectsAndKeys:@"value0", @"key0", @"value1", @"key1", nil];

      And again, a solved issue.

      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

      It does. Unless you turned off those warnings. I always build with -Wall -Wextra -Wno-unused-parameter

      Stack traces from delayed selector calls have zero contextual information

      They have the same information as that selector normally does.

      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.

      You're doing it wrong. Reusing code is trivial as long as y

    5. Re:ObjC sucks by macshome · · Score: 2

      Ditto for strings. Also, you have to prefix string constants with '@'.

      Oh no, a single extra character!

      The '@' isn't how you define a constant. It's shorthand for creating a NSString, since most everything in Obj-C needs objects to function.

  11. Surprise by StikyPad · · Score: 4, Funny

    What more surprises does this venerable language have up its sleeve?

    Theres only one way to find out, and it involves wading through extraordinarily long, unintuitive, and overly verbose object, property, and method names until, Surprise!, you find yet another feature of limited utility.

  12. Re:NeXTStep the grand-daddy of all that is now OS by Arker · · Score: 3, 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.

    --
    =-=-=-=-=-=-=-=-=-=-=-=-=-=-
    Friends don't let friends enable ecmascript.
  13. Unobjective remarks on objective c by Anonymous Coward · · Score: 5, Insightful

    When I evaluate a language the first thing I do is look at a random block of code and say to myself is this what I really want to be writing?

    When I look at lisp all I see is endless streams of ()()())))) and my brain instantly reboots in a violent seizure.

    jquery would be a decent system if only I could get over the rediculous hackish syntax needed to workaround underlying JS environment.

    ASP and close neighbors were always a turnoff due to the weird escape sequences you needed to plaster absoultely everywhere more recently razor cleaned that up somewhat.

    Objective c has too many perlish @ symbols and a rediculous number of [] [][][ ][][][] [] contraptions all over the place. I know this sounds and is shallow but when I look at code I really need to see the code not have to look under layers of syntatic nonsense existing only for convenience or compatibility/interop purposes.

    Give me a capable clean language not hacks upon hacks.

    Given enough time any language can be made useful... this does not mean I would ever willingly choose to use it. I'm instantly wary of languages with only one killer app (iphone) unless it is heavily domain specific.

    1. Re:Unobjective remarks on objective c by Arker · · Score: 4, Funny

      When I look at lisp all I see is endless streams of ()()())))) and my brain instantly reboots in a violent seizure.

      Sounds like a hardware problem to me. I advise getting a professional neurologist on the job ASAP.

      --
      =-=-=-=-=-=-=-=-=-=-=-=-=-=-
      Friends don't let friends enable ecmascript.
  14. Re:NeXTStep the grand-daddy of all that is now OS by dan325 · · Score: 2

    Not entirely limited to Apple:

    http://www.gnustep.org/

  15. Re:bonch is a corporate shill for Apple by Anonymous Coward · · Score: 2, Insightful

    Notice how bonch, a notorious shill for corporations such as Apple and Microsoft and with an openly anti-google agenda, happens to post a verbose comment, with source code examples and all, right at the exact same time this piece of Apple propaganda is published on slashdot.

    The asterisk next to his name means he's a subscriber, dumbass. Subscribers see articles before non-subscribers. You can write a reply in the box and submit it when the story goes live.

  16. Re:NeXTStep the grand-daddy of all that is now OS by kthreadd · · Score: 2

    Objective-C is not exclusive to Apple platforms, they just happen to be one of it's most prominent supporters. As a matter of fact the GNU project has actually for long time been a supporter of the language due to its use in GCC and through the Gnustep project.

  17. Objective-c only required for user interface code by perpenso · · Score: 4, 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.

  18. Obj-C is up because Apple devices are up by gestalt_n_pepper · · Score: 4, Insightful

    I mean, that's the simple explanation. If Apple wasn't having a resurgence, would anyone be paying attention to Ojective-C?

    --
    Please do not read this sig. Thank you.
    1. Re:Obj-C is up because Apple devices are up by kthreadd · · Score: 2

      If Apple wasn't having a resurgence, would anyone be paying attention to Ojective-C?

      You mean like the GNU project?

      http://www.gnu.org/software/gnustep/resources/ObjCFun.html

    2. Re:Obj-C is up because Apple devices are up by dbrueck · · Score: 2

      I can't tell if you're citing that as an example that confirms or disputes his point. :)

      GNUstep has been around for ages, but honestly I'd be very surprised if non-iOS use of ObjC accounts for even 1% of the total usage. 0.1% maybe? 0.01%?

    3. Re:Obj-C is up because Apple devices are up by dbrueck · · Score: 2

      (replying to myself) By iOS I should have said iOS and Mac OS X of course.

  19. Re:How is it not modern? Obj-C has modern libs... by Anonymous Coward · · Score: 3, Insightful

    Why do you claim it is "unsafe"? Almost all work done in Objective-C is very "safe", by any measure - mostly you are never using C arrays or the like. Just because they are there does not make the language inherently "unsafe" if that's not how real people use the language.

    There is a common consensus in the CS community that pointers as opposed to references, pointer arithmetics, direct type conversion ("memory overlays") etc. are unsafe, and a language that makes it easy to use them is "inherently unsafe". (That doesn't have anything to do with actual programming practise. Obviously, you can write "safe" programs in any language, even in machine code, as long as you're very careful.) As a comparison, take Ada, Eifel, Java, Haskell -- these are all much safer.

    As for "modern": Perhaps you haven't seen any modern programming languages yet? Because otherwise you should know what I mean. Relatively modern features are e.g. automatic type inference, automatic parallelism, contracts, a concurrent garbage collector -- things like that.

  20. Re:Seems like Mac is a win ... by Anonymous Coward · · 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.

  21. Re:This Trend is Interesting by gwking · · Score: 3, Interesting

    I find Android apps are not nearly as useful as similar iOS apps. They are usually slower, uglier, and buggier - free or not.

    Given the choice between a free Android app that is a turd, and a great iOS app that costs $1, I'll gladly pay the $1.

    Also, for developers, I think there is more to it than just the money. With iOS you can test a reasonable amount of the devices on the market and the screen sizes they use. With Android? Not unless you happen to have a few hundred Android devices kicking around and a few months to test your app on all of them. Take into account the absolutely terrible hardware on the currently selling low end Androids that can barely keep up with the iPhone 3GS, the problems with having an app on the SD card instead of on the builtin memory, and then all screen sizes and aspect rations. Ugh.

  22. Re:How is it not modern? Obj-C has modern libs... by Sponge+Bath · · Score: 2

    Why do you claim it is "unsafe"?

    He may be using unsafe in the same way as Microsoft. See this.

    From that page:
    ... code that makes low-level API calls, uses pointer arithmetic, or carries out some other unsavory operation, has to be placed inside blocks marked with the unsafe keyword.

    Heh, "unsavory". Personally, I think pointer arithmetic is delicious!

  23. That's not what the data is saying by sl4shd0rk · · Score: 2

    Tiobe's data is an indicator of how active internet based discussions on each programming language. Even Tiobe says it themselves:

    "What programming languages are hot in the Internet discussions? "

    and

    " Observe that the TIOBE index is not about the best programming language or the language in which most lines of code have been written." (http://www.tiobe.com/content/paperinfo/tpci/index.html)

    All the graph on that link above shows is there's been an increase in the amount of discussion on Objective C. You can say it's due to an increase in adoption, or you could say it's due to people being absolutely fitful with learning it. There's no way to tell what the data means. You may as well google " sucks" and count the results.

    I think the author/submitter is being very hopeful in the way they have construed the data.

    --
    Join the Slashcott! Feb 10 thru Feb 17!
  24. No I will not get off your lawn by SuperKendall · · Score: 4, Insightful

    There is a common consensus in the CS community that pointers as opposed to references, pointer arithmetics, direct type conversion ("memory overlays") etc. are unsafe

    In ObjectiveC we are really using objects more as references than as pointers.

    Basically you come off here as just being afraid of something because you've been told it's scary, not because you've seen real issues.

    As a comparison, take Ada, Eifel, Java, Haskell -- these are all much safer.

    Exactly my point, As I said, I was a Java programmer (for almost a decade) - Objective-C is not really less safe at this point in practice. I say that in terms of stability and in terms of memory use (since you still do not say what you mean by "safe" and the world offers many perils).

    As for "modern": Perhaps you haven't seen any modern programming languages yet?

    Snark alert. As I said, I used Java for a LONG time. Before that I knew better languages still, Scheme and other things... Perhaps you have not worked with enough different languages to know what is really "safe" and what is not.

    Because otherwise you should know what I mean.

    I don't automatically agree with snobs.

    Relatively modern features are e.g. automatic type inference, automatic parallelism, contracts, a concurrent garbage collector -- things like that.

    You're still using a garbage collector? Do you watch that operate while gnawing on woolly mammoth bones or what? ARC is a far superior approach as it involves no overhead.

    As for contracts... you really don't know Objective-C at all, do you?

    You just come off as some ancient CS grad-school twat totally removed from real world programming. I've worked on large systems for multi-national corporations, and now on mobile applications used by millions of people. I don't automatically assume anything anymore, as experience I have found teaches you a lot more than mere theory or some summary of a language you have read on a blog.

    Don't judge any language until you've tried to solve real problems with it.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  25. Re:Seems like Mac is a win ... by ulski · · Score: 3, Informative

    you are not 100% correct there. 64-bit tools are not available on Visual C++ Express by default. To enable 64-bit tools on Visual C++ Express, install the Windows Software Development Kit (SDK) in addition to Visual C++ Express.

  26. Wrong, you can use other languages for iOS by SuperKendall · · Score: 4, 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...

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
    1. Re:Wrong, you can use other languages for iOS by drkstr1 · · Score: 2

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

      Indeed. We develop for iOS in Actionscript even. True story.

      Language choice is becoming largely irrelevant. It's all about the end build target these days. IMHO, It's better to build your core architecture in a platform agnostic way, and then extend it into specific UI / hardware implementations as needed.

      --
      Fanboy Status: Apache Flex, C#, Eclipse, KDE, Pirate Party, Ron Paul, Slackware, Windows 7
  27. Re:How is it not modern? Obj-C has modern libs... by IamTheRealMike · · Score: 2

    Why do you claim it is "unsafe"? Almost all work done in Objective-C is very "safe", by any measure

    Objective C, at least as used on iOS, is not a safe language. I don't see how anyone with serious programming experience could believe that.

    Here are some things about it that are unsafe. Firstly, it's not garbage collected (on the phone). Manual memory management has a long history of resulting in memory corruptions, leaks, and even security vulnerabilities. Yes, on MacOS X there is GC available, so Apple clearly recognize this. They appear to believe that it's not OK on a phone.

    Secondly, and this is just crazy to my mind, dereferencing a null pointer (ok, rephrase it in terms of sending messages to nil if you like) ..... does not terminate the application. It's actually a "defined" operation in the sense that it's defined to return garbage or another nil. Sending a message to nil has no useful purpose so it is guaranteed to reflect a bug in your application, unless (worse) you have some "clever" programmer who decided to rely on this obscure behavior. The nonsense of accessing NULL is why it is defined to result in an application crash on any sane platform - you want to stop the app at that point to avoid possible data corruption. But Objective C apps will happily continue their merry way, overwriting internal state with garbage or more nils until it auto-saves your now hopelessly corrupted data to disk.

    This is a specific instance of a more general problem with Objective-C, which is that despite being based on C it turns a lot of failures that would be compile failures in any modern language into runtime failures or heuristically driven compiler warnings. Most research into programming languages for the last 10-15 years has been about how to catch more errors earlier, mostly through better type systems (a lot of functional research is in this direction). Objective-C takes a massive step backwards in this regard, converting errors even C++ compilers can catch ahead of time into issues you may not even notice unless you have extremely thorough testing plans. Example: typos in method names.

    Thirdly, Objective-C does not have any kind of real namespacing support. The Cocoa libraries use the convention of an API prefix, but there's no language support for it, meaning "namespaces" such as they are tend to be very short or non-existant. Combined with the way symbols can mishmash together in the same binary can lead to awkward to solve linking issues.

    There are a lot of problems with Objective-C that make it difficult to consistently write correct code and flatly contradict how modern languages are designed (no surprise, as it's not modern).

  28. You received what you asked for by SuperKendall · · Score: 2

    Let me summarize. You chose to ignore almost everything of what I've said

    That summarizes your position. I corrected almost all of your points. You responded to only one of mine, and there not even a point on the language but a meta issue of languages and platforms that any third rate philosophy student could offer up as a supposedly "informed" opinion on computing.

    have personally insulted me (makes you wonder who's the real snob?) made all kinds of presumptions about my background...

    I only responded in kind. You started out insulting me first (and assuming I knew nothing about higher level languages even when I first stated I knew Java in my original post), giving me free range to question anything and everything about you.

    The responses I type are a mirror on those who I am responding to. You came off as an arrogant elitist ivory-tower prick with little in the way of practical experience (that last item mostly based on the few concrete items you offered).

    Furthermore you never even said what you DO know anything about, a very curious omission indeed! You can claim I got "everything wrong" all day long, while never revealing even a portion of what you do know while at the same time complaining we are guessing at it.

    Perhaps you should try a different writing style if you would like more pleasant responses. Perhaps if you don't want people to get your background wrong you should provide some instead of poorly thought out complaints that illuminate only your area of ignorance and not your field of understanding.

    The main disadvantage of Objective-C in practice is, of course, that you have to write the whole fucking program again if you want to have it run on Android or any other non-Apple platform.

    In the end to have the best application for any platform you have to tailor it specifically for that platform; in REAL LIFE very little code can be reused even if the platforms share a similar language. The code itself matters so little compared to the conceptual model of how the program fits together.... and the parts of the code that really matter, in specific UI interactions have to be totally customized to a different platform anyway.

    But I guess if you are OK with simply dumping bad applications out that annoy users I suppose I could see where you would have the opposite feelings and write drek that will run "anywhere".

    In the end, it sounds like you are a typical ivory tower prick as I had you pegged at the start. You have only reenforced that vision with your later writings, abrasive and rude and pretending you know everything while illustrating how little real world understanding you have.

    I'll let you have the last response, since you have nothing real to write but simply further fling insults while claiming you are above me. The readers know the truth, know how much you really know and exactly the tone of responses you drew out. I have already unmasked you, so my work with you is done.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  29. Re:Seems like Mac is a win ... by shutdown+-p+now · · Score: 2

    No Microsoft Foundation Classes, MFC really simplifies Windows use interface coding

    As someone with past MFC experience (years ago, thankfully), there's precisely one thing that it really simplifies, and that's gouging one's eyes out - you'll be adept at it after a few months.

    Anyway, the OP was talking about C#, not C++, so MFC is largely irrelevant.

  30. Corrections by SuperKendall · · Score: 2

    Objective C, at least as used on iOS, is not a safe language. I don't see how anyone with serious programming experience could believe that.

    Some people with experience know better.

    Here are some things about it that are unsafe. Firstly, it's not garbage collected (on the phone).

    No, it uses ARC, which is superior, since there is no run time overhead.

    Manual memory management has a long history of resulting in memory corruptions, leaks, and even security vulnerabilities.

    Even under the old regime memory management was mostly automatic. You simply signaled when you wanted an object, and then when you were no longer interested. That is a strike against Objective-C many raise but I just never found to be an issue in practice.

    Yes, on MacOS X there is GC available, so Apple clearly recognize this. They appear to believe that it's not OK on a phone.

    You clearly are not keeping up on year old iPhone development practices.

    Secondly, and this is just crazy to my mind, dereferencing a null pointer (ok, rephrase it in terms of sending messages to nil if you like) ..... does not terminate the application

    I thought you just said you disliked memory corruption.

    Sending a message to nil has no useful purpose so it is guaranteed to reflect a bug in your application,

    if ( myString > 0 )

    Nope, not a bug, and very useful compared to:

    if ( myString != nil && myString > 0)

    That alone, if you have done any Java programming, would make it all worthwhile. Basically it safeguards against all kinds of horrible bugs if sending a message to nil means nothing. Would you prefer shouting into the void rip off your arms? Why would you prefer that an accidental sending to an obviously un-initialized space break the program? Madness!

    despite being based on C it turns a lot of failures that would be compile failures in any modern language

    Poor Objective-C, choosing a different path. DIFFERENT IS TEH EVILS!

    They have made different choices but they are not bad ones. They are along the age old lines of deciding where they sat on the sliders of things like dynamic vs. static, and then making the best of where they landed.

    Most research into programming languages for the last 10-15 years has been about how to catch more errors earlier,

    Meet CLANG. Objective-C development is NOT hurting for early warnings you have problems, and in fact is probably ahead of just about any other language right now. "modern" or otherwise.

    Example: typos in method names.

    You have got to be kidding me, there were compiler warnings about that as far back as I remember. Just because you CAN send any message to an object does not render you doing so any less an error a compiler can easily flag, just as mis-typing a function name would raise an error.

    Thirdly, Objective-C does not have any kind of real namespacing support.

    That is very annoying at first coming from other languages. That is the one thing I would like them to resolve, as you say it can raise overlap issues. But in the end it's really a minor thing as the naming convention (mostly a class prefix), works OK. The main problem with it though is not the one you raise - overlap with other classes in fact raises a linker error, so it's not like that really happens for whole classes. No, the problem with lack of namespaces is the inability to easily include a large number of header files at once by simply declaring you want to use a namespace.

    There are a lot of problems with Objective-C that make it difficult to consistently write correct code and flatly contradict how modern languages are designed (no surprise, as it's not modern).

    Funny how Objective-C has now leapfrogged ahead of other "modern" languages in terms of library support and language features like ARC. I programmed Java for over a decade and would b

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  31. Re:ObjC is plainly clearer. by spongman · · Score: 2

    you have got to be kidding.

    right?