Does Objective-C really need defending?

After doing a couple of projects with it I've found it to be a really beautiful language from a code formatting point of view.

The whole 'overly verbose' thing is probably just because you are encouraged to give your methods and arguments good descriptive names, and often when you do need short variable names for some maths calculations or something it will be while inside a method block using good old C style anyway.

I don't know, it's flexible, (arguably) attractive and it runs fast.

Yay Objective-C! :)

For example, to filter an array is lovely:

  filteredArray = [allRecords filteredArrayUsingPredicate:
    [NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]];

I don't think these are the real problems with Objective-C.

To quickly address this issues, before discussing the real problems: "Ugly" - get over it, "Verbose" - get over it, "Memory Management" - Obj-C memory management is in fact super simple as long as you follow some really simple rules, especially with ARC.

Now the real problems I have:

1. Lots of unnecessary code. With the old runtime, you had to modify your code at four (!) places to introduce a new property in a class. With the new runtime, that has decreased to three, with ARC, to only 2, but that's still one more than what should really be necessary (@synthetize should go).

2. The whole header file thing. I know that Obj-C is a descendant and strict superset of C but I still find separating header files from .m files somewhat tedious and unnecessary. This leads to

3. Having to declare methods and properties before you use them. I mean, this is 2011, this shouldn't be necessary.

4. The syntax for having "private" methods and properties is awkward even by Obj-C standards. Basically you have to create an anonymous category in the implementation file.

5. Properties (with ARC) should default to strong for objects, assign for everything else.

6. The [[X alloc] init] way to construct objects; I understand that from a theoretical point of view it's cool to separate allocation from initialisation but I've never ever needed to allocate an object with anything other than the alloc message.

7. The debugger. GDB and Xcode are atrocious. Have a look at the C# debugger in Visual Studio; that's how a debugger should look like.

Overall, while a lot has been improved recently in Obj-C, my main gripes with the language all come from the facts that it's a C superset (which is also a massive advantage) and that it's an almost 30 years old language; the programming world was very different 30 years ago.

There is one thing in Objective-C that still gets my goat, even after 8 years of working with it: it's the lack of syntax for container-types:

[NSMutableDictionary dictionaryWithConstructorIDontWantToType:...]

is just a huge pain in the ass. Other problems with the syntax have been solved by introducing sugar at the right place. Why not

  id hash=@{ @"key" : @"value };

  id array=@[ @"value1", @"value2", @"value3"];

I wonder if I'm the only person that thinks that Xcode is the problem, not ObjC. Having experience with C I feel just fine writing code in Objective-C, but only the thought of trying to use Xcode instead of Emacs is painful.

I'd love to know what Eclipse/VS/NetBeans users think about it, maybe it's easier if you're already used to working inside a huge IDE.

I'm (some what) proficient in many programming languages. Some more than others. I've worked in languages like Python, Eiffel, C#, C++, Prolog, Java, OCaml, F#, Ruby and as of recently, after a long hiatus, Haskell.

I have such a strong dislike for Objective-C, I can't explain it. I mean C++ is insane in a way, and Haskell is a pure Mindbender. But Objective-C's syntax, to me, is indeed so verbose, I'd rather read the EU regulations on "the common organisation of agricultural markets".

I had to create a couple of iPhone apps, and I probably will have to create some more in the future.

Is there any way for me to overcome my unnatural dislike for this language?

And yeah, this article did not work for me, as you would have already guessed.

Go and look at some Lisp, then come back – obj-c will suddenly look better :) ... For example, to filter an array is lovely

  (filter foo? all-records)

As someone who likes Objective-C a lot, I have to say this is a pretty bad defense of it. No offense, clearly we are both fans of the language, I just don't think this will convince anyone on the other side. In fact, I find very little defense of it at all in this post. It seems his fundamental argument is "its a matter of taste", which while true, in no way conveys the many "whys" of the choices made in this language. This is sad because most of the things people are initially turned off by actually have very logical reasons behind them, which over time you do grow to love and miss when you leave.

1. The first major point (which is found at the end of this post) in any "defense of Obj-C" should be that this is a very pragmatic language. It makes a lot of wise tradeoffs and rarely strives for "purity" or "religion". This helps to put a lot of the language choices in context, and actually is the strongest reason its a great language in my opinion.

2. "Ugly" - The point is certainly not that you "see through the brackets", that's a terrible argument! The point is to understand why we have brackets, because they allow for named arguments without colliding with existing C syntax. Additionally, they make it clear to the user that what is about to happen is not a traditional method call, it is a message send. This is because you can do both in Obj-C (not to mention Obj-C++).

3. "Verbose" - First off this is a framework decision. It's possible to take Obj-C without Cocoa, and write a framework that is just as non-verbose as Python (and vice versa). But fine, you could make the argument that the named parameters "encourage" verbosity if you want. The key here is not to hand wave this away as a matter of "taste", but to understand the logic behind this: its very easy to read. I can show lots of non-programmers Obj-C code, and it really reads like english. In fact if you just read aloud many Obj-C snippets, it often sounds very close to English. 80% of coding is reading code, and if you work on a big project, its reading other people's code. You never run into a piece of code that has 4 arguments and have no idea what the last "true" is for. Similarly, you never have appendChild(node1, node2) moments where you're not sure which is the node you're appending and which is the one being appended next to. Apple's SDK's are repeatedly praised and a big part of that is that the frameworks are very friendly. I personally find the opposite trend of terseness incredibly strange: why do we focus so much on shrinking variable names.

4. "Memory Management" - This I will admit was more or less fair. The MM story just isn't that great with Obj-C. I have to admit I thought it wasn't a big deal before spending a lot of time in a dynamic language, but it really is annoying coming back to it. And while I'm not 100% sure yet, ARC is not the be all end all. I have to say I think about memory almost just as much with ARC (perhaps simply because I'm not used to it). At least with explicit management I knew exactly what was going on, with ARC I kind of feel that its half magic and half really hard situations. I really hope I'll eat my words about this soon. Now, the counter argument is that this is why Obj-C is so fast. I honestly don't know if that's true. I know enough smart people on both sides of the argument to say that I simply don't know enough about it.

Is it considered poor form around here to submit your own articles? If so, i'm terribly sorry and will remove, however i feel strongly that a lot of people write off obj-c based on superficial weaknesses, and that it has a lot of strengths that are very underrated, and i wish i'd known a lot of this stuff when i started off in iphone development.

-quote- Go and look at some Lisp, then come back – obj-c will suddenly look better :)

Trust me, it grows on you. You’ll soon learn to see through the brackets – just like the green vertical text in the matrix, it becomes invisible after a while. -end quote-

Its ironic that a Lisp/Scheme person would say the same as to why s-expressions are good (the parens become invisible!) so I don't see why objective-c syntax is better but somehow uses the same reasoning.

If you have worked in smalltalk and C (a somewhat rare combination these days, I must admit) , Objective C is trivially readable.

I really hope Apple promotes MacRuby to first class citizen for both OS X and iOS development. That would make things a whole lot more modern and easier. Who knows, once we have quad core CPUs on even the lowliest of iDevices we could see this happening.

There’s a philosophy here: user happiness is prioritised over developer happiness.

See also the App Store policies. Apple's priorities tend to be it's users, Apple, then any 3rd party developers. I don't tend to think this is a bad thing...

I love it too for its readable and descriptive method names. It is also surprisingly flexible considering its age. (I guess what I am saying is that Apple kept it up-to-date pretty well.)

I love Obj-C message send syntax and I miss it dearly when using any other language. I love that a method implicitly documents itself at the call site, and that the delimiters occur between calls rather than in the middle of them.

And it works great with code completion. You just type '[' and the editor immediately knows what you are doing. Choose a method and the parameters are right in front of you. No documentation required, unless you actually need in-depth information.

Looking at the example given of how lovely obj-c is:

   filteredArray = [allRecords filteredArrayUsingPredicate:[NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]];

   let filteredArray = Seq.filter (fun f -> f = "foo") allRecords

I didn't find this very convincing at all. For starters, the code presentation reinforces the verbosity and difficulty working with it. Don't most languages support named parameters and in an easier to understand way? I'm not qualified to discuss memory management but that point also left me confused.

Remember Smalltalk?

Xerox PARC, GUI, inspired Steve Jobs, all that fun stuff.

Objective-C is a sort of nerfed Smalltalk bolted onto the side of C. Yes you can see the seams and it's clunky-looking, but it works. Smalltalk semantics means it's much easier to build robust and loosely-coupled programs than in C++, and you don't even occur that much runtime overhead.

I do all my game dev in Objective-C, and I don't even have a Mac that I use actively. In fact I defy people to write significant Objective-C programs that don't use or need the Cocoa or NS libraries. I think they will have an easier and more fun time of it than when working in C++.

After having spent a couple years doing embedded OS development in C, Objective C is beautiful. The verbosity makes it much easier to read than typical C code and the memory management is brilliant compared to doing it yourself. It walks the line between static and dynamic types quite well, with most things being static except when dynamic makes things a lot easier. I think Objective C is brilliant considering what they were able to add to C while maintaining great speed and full compatibility with C.

I dislike the NextStep libraries (and all of Apple's subsequent creations) far more than Objective-C itself. The completely unnecessary verboseness is what drives me up the wall.

If the libraries were designed more like C++'s (say what you will about STL, but at least set<> is called set<>), I'd probably have no issues whatsoever.

For me the problem isn't Obj-C. It's cocoa. (Unless things have changed,) if everything was consistent in cocoa from a language perspective i.e. every library / framework is accessible with Obj-C from the start as opposed to being only C. If I remember correctly the Addressbook portion is one of the culprits.

The only argument I'm buying into is this one...

[someInstance doSomethingWithObject:a andAnotherParam:b];

It just reads beautifully. Otherwise working with Objective-C was like pulling teeth at times. It had been a long time since I had to write so much code to get such simple things done.

I guess, the way to defend it would be by demonstrating expressiveness. Syntax hardly matters.

- Closures (I guess blocks might achieve the same, never worked in Obj-C)

- Lambdas

- Dynamic Typing or Type Inference. You need at least one of those.

- Or any other construct that enhances expressiveness.

undefined

Not a fan of the syntax, but my real gripe is with the header files, and all the DRY that entails. If I were Apple that's the first thing I'd aim to fix, rather than giving us ARC.

"Things like factories, adapters, and other design patterns are all thankfully not there."

Not sure I understand this? How does Obj-c enable the developer to avoid factories?