11 ms·

In defence of Objective-C

107 points by chubs 15y ago

chubs 15y ago
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.
- makecheck 15y ago
  The guidelines[1] just say to submit something interesting/relevant, and this is. Besides, no one knows better than you where to find your content. :) [1] http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html
- philwelch 15y ago
  I don't know anymore, but traditionally it's quite acceptable. That's why self-posts are in gray text and hard to read--if you have a lot of things to say about a subject, post it to your blog and submit the blog here, don't make a long self-post.
- mooism2 15y ago
  Don't worry, it's on-topic. Your first two code samples are about twice as wide as the space allowed for them, so they are hard to read (horizontal scrolling on text is bad).
zdw 15y ago
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...
- Bdennyw 15y ago
  Make no mistake Apple's priorities are: Apple, Users, Developers.
  - thought_alarm 15y ago
    If you're a developer (or a business), what's your priority? If it's not your users (or your customers) then you're doing it wrong.
    - Androsynth 15y ago
      late comment that will probably never get read: This is overly simplistic. In their heyday MS catered to developers first and their users second. You can make some snarky comment about this, but at the time it allowed them to become one of the largest and most powerful tech companies out there. Google catered to it's own engineers first. The point is there are different ways of building a business; don't blindly choose the Apple path just because they're currently at the top of the heap.
plinkplonk 15y ago
If you have worked in smalltalk and C (a somewhat rare combination these days, I must admit) , Objective C is trivially readable.
- Derbasti 15y ago
  And even if you haven't, you can learn how to read it in ten minutes. Say what you want about Obj-C, but I think its readability is really outstanding.
  - atomicdog 15y ago
    [[perhaps [[not] a always] that [readable[though]]]]]
5hoom 15y ago
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! :)
- chubs 15y ago
  Wow - this is fantastic! I'm glad i submitted this now, just reading the comments here is very heartening. I was beginning to think i was the only guy in the world who liked obj-c :) (i work in a c#/java predominaated environment where most people troll me about obj-c all day!)
  - 5hoom 15y ago
    I'd always considered myself a C++ guy before picking up obj-C, but looking at the result I get from the two I'm finding I'm just a lot faster with obj-C. Now I have no desire to incite a language flamewar (to each their own blub!), so I will leave it at that ;)
  - matwood 15y ago
    I like obj-c, and never really found it hard. IMHO, the real challenge with Apple development is not the language but learning all the frameworks and the Apple way of doing things. The learning curve is a bit steep at first, but quite powerful (and intuitive) once you get over the hump.
- wisty 15y ago
  99% of the people who use it have no choice, so not really. But it's nice to see a semi-tutorial wrapped in an argument. Arguments are more fun to read than tutorials, so I picked up a few factoids (named args) without having to read Apple's documentation (which is a little dry).
fbuilesv 15y ago
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.
- stephth 15y ago
  you don't need to use XCode. I keep it open to manage, build, etc, but use textmate to do the editing.
- 5hoom 15y ago
  No, you're not the only one. Most of the problems I've hit with iOS development are Xcode-isms. I've recently been sent on a merry hunt to get the built-in git integration from imploding, and the project groups vs folders ambiguity has caused mistakes of the "what actual file is this name pointing too again?" variety (and this in turn leads back to the git integration issues when a file is not where you think it is). It would also be nice if Objective-C++ was a first class citizen with regards to refactoring tools (I understand this might be hard to implement however). Rarely has it been a problem with the actual language itself.
  - dbattaglia 15y ago
    I believe JetBrains have an Obj-C IDE now. Haven't tried it yet but I know they are pretty good at the whole refactoring thing (I use ReSharper at work all the time).
- tomjen3 15y ago
  I am a fan of Eclipse, but I hate xcode - it hasn't got half of the features it should have and the code completion is just horribly bad.
  - glaurent 15y ago
    Code completion in XCode 4.2 using llvm/clang has improved a whole lot. I'd say it's on par with Eclipse now.
tolmasky 15y ago
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.
flitzwald 15y 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 }; and id array=@[ @"value1", @"value2", @"value3"];
- freemarketteddy 15y ago
  Please understand that to do anything in Objective C you must pass a message to an object.So when we write. MyArray *array = [[MyArray alloc] initWithObjects:@"string1",@"string2",...]; Lets understand this in two steps: Step 1) You first allocate an object of type NSArray by passing a message "alloc" to the NSArray Class object.Yes every class in objective C is really a class object in the Objective C runtime.Now this class object may allocate data or it may not.It may also return you a pointer to a previously allocated object(Yes that is a cool way of implementing the singleton pattern.In any case it will return you a pointer to an allocated memory space or nil. Step 2) Now you tell the allocated object how to initialize itself.The allocated object may have been already initialized and it might just append the strings.The allocated object might be nil. What I am trying to point out is that there is a lot of dynamism involved in writing an initialization in a two step message passing.It almost feels like the objects are alive.My opinion is that this is real object oriented programming.
  - saurik 15y ago
    The poster seems to be complaining that there is not similar syntax to many scripting languages, where you can do [@"string1", @"string2"], not about two-phase message allocation; he wasn't complaining for "dictionaryWithConstructorIDontWantToType:", he was complaining against it. In this specific case, you actually can usually use "arrayWithObjects:" (yes, the syntax that the poster didn't like), and it is frankly preferred. If you are doing alloc/init, and (as in your example) storing to a local variable, you should also send an autorelease in the same statement, so as to guarantee exception safety of allocation for subsequent code; "arrayWithObjects:" takes care of all three steps for you.
jon6 15y ago
-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.
- Luyt 15y ago
  "You’ll soon learn to see through the brackets" @I @hope @that @also @applies @to @the @the @at-@signs. ;-)
  - dextorious 15y ago
    Huh? Obj-C only uses @ signs at a couple of places, like to denote a native @"dasdasda" string and in compiler instructions...
barumrho 15y ago
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.)
pbreit 15y ago
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.
kitsune_ 15y ago
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.
- dextorious 15y ago
  > Is there any way for me to overcome my unnatural dislike for this language? Grow some taste?
  - deleted 15y ago
    [deleted]
extension 15y ago
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.
- masklinn 15y ago
  > And it works great with code completion. You just type '[' and the editor immediately knows what you are doing. Whereas in other languages you'd have to write... "."? > Choose a method and the parameters are right in front of you. No documentation required, unless you actually need in-depth information. Pretty much every somewhat advanced IDE does that, especially for mostly-statically-analyzable languages.
  - dextorious 15y ago
    > Whereas in other languages you'd have to write... "."? You write "." AFTER you've written the method name. In ObjC "[" immediately tells that you want a method/class name for autocompletion.
mquander 15y ago
For example, to filter an array is lovely: filteredArray = [allRecords filteredArrayUsingPredicate: [NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]]; A four-word name for filter and filtering for equality by using a string formatting DSL are not really on my list of lovely things. I'm sure Objective-C does something well but this guy is not pointing it out.
- glenra 15y ago
  Yeah, I found that line hideous - ridiculously unintuitive and hard to read compared to the equivalent in say, ruby. Maybe the whole essay would have been better framed something like: "Objective C: not quite as bad as Java!"
  - jasonlotito 15y ago
    Just curious, for comparison: what would the equivalent be in Ruby?
    - akmiller 15y ago
      my_array.select { |item| item == somefiltervalue } At least that's one way to do it in ruby.
    - rbxbx 15y ago
      filteredArray = [allRecords filteredArrayUsingPredicate: [NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]]; in ruby: all_records.select {|r| r.some_field == some_field_filter_value} in clojure: (filter #(= % some-filter-value) all-records) in haskell: filter (\someField -> x == someFilterValue) allRecords
      - icodestuff 15y ago
        Let's be fair, in Objective-C, this could be actually more like NSIndexSet *indicies = [allRecords indexesOfObjectsPassingTest:^ (id obj, NSUInteger idx, BOOL *stop) { return [obj someField] == someFieldFilterValue; }]; filteredArray = [allRecords objectsAtIndexes:indicies]; rather than what the article had in mind. EDIT: oh, someFieldFilterValue was an integer, wasn't it. Fixed.
deleted 15y ago
[deleted]
philjackson 15y ago
"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?
- toadkick 15y ago
  Agreed. I've had to use factories in Obj-C plenty. I guess the argument that I would make is that they are much easier to implement in Obj-C and require less boilerplate (especially if you use blocks), not that the pattern doesn't exist in Obj-C.
ataggart 15y ago
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) Yeah, maybe not so much.
- deleted 15y ago
  [deleted]
DrJokepu 15y ago
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.
- chriseidhof 15y ago
  Very true, all of this would improve the language a lot. I have often thought about writing a language that does these kind of things and compiles to Obj-C. Also, I would love to be able to do some kind of metaprogramming without resorting to strings.
  - domhofmann 15y ago
    I'm trying to do just that with a project I started a few days ago called Khaki. It's a bit of a learning exercise and quite early, but you might find it useful in a month or two. https://github.com/dominikhofmann/khaki https://github.com/dominikhofmann/khaki
hamidpalo 15y ago
Looking at the example given of how lovely obj-c is: filteredArray = [allRecords filteredArrayUsingPredicate:[NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]]; Makes me wonder if the author has ever seen languages that do this like so: let filteredArray = Seq.filter (fun f -> f = "foo") allRecords
jeswin 15y ago
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.
kaffeinecoma 15y ago
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.
smweber 15y ago
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.
super_mario 15y ago
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.
Aloisius 15y ago
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.
- Toady 15y ago
  You may dislike the verbosity, but it's hardly "completely unnecessary." A typical Objective-C program is inherently self-documenting. It's nice knowing what a group of arguments is used for without having to look up the method prototype.
jtmille3 15y ago
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.
- equalarrow 15y ago
  Exactly. I once worked with a very smart Obj-C guy. I asked him if he could document all the method calls so I knew what they did. He said: there is no need. In Obj-C the selectors should document themselves.
bitwize 15y ago
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++.
chaostheory 15y ago
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.

107 points by chubs 15y ago

chubs 15y ago

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.

makecheck 15y ago
The guidelines[1] just say to submit something interesting/relevant, and this is. Besides, no one knows better than you where to find your content. :) [1] http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html
philwelch 15y ago
I don't know anymore, but traditionally it's quite acceptable. That's why self-posts are in gray text and hard to read--if you have a lot of things to say about a subject, post it to your blog and submit the blog here, don't make a long self-post.
mooism2 15y ago
Don't worry, it's on-topic. Your first two code samples are about twice as wide as the space allowed for them, so they are hard to read (horizontal scrolling on text is bad).

zdw 15y ago

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

Bdennyw 15y ago
Make no mistake Apple's priorities are: Apple, Users, Developers.
- thought_alarm 15y ago
  If you're a developer (or a business), what's your priority? If it's not your users (or your customers) then you're doing it wrong.
  - Androsynth 15y ago
    late comment that will probably never get read: This is overly simplistic. In their heyday MS catered to developers first and their users second. You can make some snarky comment about this, but at the time it allowed them to become one of the largest and most powerful tech companies out there. Google catered to it's own engineers first. The point is there are different ways of building a business; don't blindly choose the Apple path just because they're currently at the top of the heap.

plinkplonk 15y ago

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

Derbasti 15y ago
And even if you haven't, you can learn how to read it in ten minutes. Say what you want about Obj-C, but I think its readability is really outstanding.
- atomicdog 15y ago
  [[perhaps [[not] a always] that [readable[though]]]]]

5hoom 15y ago

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! :)

chubs 15y ago
Wow - this is fantastic! I'm glad i submitted this now, just reading the comments here is very heartening. I was beginning to think i was the only guy in the world who liked obj-c :) (i work in a c#/java predominaated environment where most people troll me about obj-c all day!)
- 5hoom 15y ago
  I'd always considered myself a C++ guy before picking up obj-C, but looking at the result I get from the two I'm finding I'm just a lot faster with obj-C. Now I have no desire to incite a language flamewar (to each their own blub!), so I will leave it at that ;)
- matwood 15y ago
  I like obj-c, and never really found it hard. IMHO, the real challenge with Apple development is not the language but learning all the frameworks and the Apple way of doing things. The learning curve is a bit steep at first, but quite powerful (and intuitive) once you get over the hump.
wisty 15y ago
99% of the people who use it have no choice, so not really. But it's nice to see a semi-tutorial wrapped in an argument. Arguments are more fun to read than tutorials, so I picked up a few factoids (named args) without having to read Apple's documentation (which is a little dry).

fbuilesv 15y ago

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.

stephth 15y ago
you don't need to use XCode. I keep it open to manage, build, etc, but use textmate to do the editing.
5hoom 15y ago
No, you're not the only one. Most of the problems I've hit with iOS development are Xcode-isms. I've recently been sent on a merry hunt to get the built-in git integration from imploding, and the project groups vs folders ambiguity has caused mistakes of the "what actual file is this name pointing too again?" variety (and this in turn leads back to the git integration issues when a file is not where you think it is). It would also be nice if Objective-C++ was a first class citizen with regards to refactoring tools (I understand this might be hard to implement however). Rarely has it been a problem with the actual language itself.
- dbattaglia 15y ago
  I believe JetBrains have an Obj-C IDE now. Haven't tried it yet but I know they are pretty good at the whole refactoring thing (I use ReSharper at work all the time).
tomjen3 15y ago
I am a fan of Eclipse, but I hate xcode - it hasn't got half of the features it should have and the code completion is just horribly bad.
- glaurent 15y ago
  Code completion in XCode 4.2 using llvm/clang has improved a whole lot. I'd say it's on par with Eclipse now.

tolmasky 15y ago

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.

flitzwald 15y 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 }; and id array=@[ @"value1", @"value2", @"value3"];

freemarketteddy 15y ago
Please understand that to do anything in Objective C you must pass a message to an object.So when we write. MyArray *array = [[MyArray alloc] initWithObjects:@"string1",@"string2",...]; Lets understand this in two steps: Step 1) You first allocate an object of type NSArray by passing a message "alloc" to the NSArray Class object.Yes every class in objective C is really a class object in the Objective C runtime.Now this class object may allocate data or it may not.It may also return you a pointer to a previously allocated object(Yes that is a cool way of implementing the singleton pattern.In any case it will return you a pointer to an allocated memory space or nil. Step 2) Now you tell the allocated object how to initialize itself.The allocated object may have been already initialized and it might just append the strings.The allocated object might be nil. What I am trying to point out is that there is a lot of dynamism involved in writing an initialization in a two step message passing.It almost feels like the objects are alive.My opinion is that this is real object oriented programming.
- saurik 15y ago
  The poster seems to be complaining that there is not similar syntax to many scripting languages, where you can do [@"string1", @"string2"], not about two-phase message allocation; he wasn't complaining for "dictionaryWithConstructorIDontWantToType:", he was complaining against it. In this specific case, you actually can usually use "arrayWithObjects:" (yes, the syntax that the poster didn't like), and it is frankly preferred. If you are doing alloc/init, and (as in your example) storing to a local variable, you should also send an autorelease in the same statement, so as to guarantee exception safety of allocation for subsequent code; "arrayWithObjects:" takes care of all three steps for you.

jon6 15y ago

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

Luyt 15y ago
"You’ll soon learn to see through the brackets" @I @hope @that @also @applies @to @the @the @at-@signs. ;-)
- dextorious 15y ago
  Huh? Obj-C only uses @ signs at a couple of places, like to denote a native @"dasdasda" string and in compiler instructions...

barumrho 15y ago

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

pbreit 15y ago

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.

kitsune_ 15y ago

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.

dextorious 15y ago
> Is there any way for me to overcome my unnatural dislike for this language? Grow some taste?
- deleted 15y ago
  [deleted]

extension 15y ago

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.

masklinn 15y ago
> And it works great with code completion. You just type '[' and the editor immediately knows what you are doing. Whereas in other languages you'd have to write... "."? > Choose a method and the parameters are right in front of you. No documentation required, unless you actually need in-depth information. Pretty much every somewhat advanced IDE does that, especially for mostly-statically-analyzable languages.
- dextorious 15y ago
  > Whereas in other languages you'd have to write... "."? You write "." AFTER you've written the method name. In ObjC "[" immediately tells that you want a method/class name for autocompletion.

mquander 15y ago

For example, to filter an array is lovely: filteredArray = [allRecords filteredArrayUsingPredicate: [NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]]; A four-word name for filter and filtering for equality by using a string formatting DSL are not really on my list of lovely things. I'm sure Objective-C does something well but this guy is not pointing it out.

glenra 15y ago
Yeah, I found that line hideous - ridiculously unintuitive and hard to read compared to the equivalent in say, ruby. Maybe the whole essay would have been better framed something like: "Objective C: not quite as bad as Java!"
- jasonlotito 15y ago
  Just curious, for comparison: what would the equivalent be in Ruby?
  - akmiller 15y ago
    my_array.select { |item| item == somefiltervalue } At least that's one way to do it in ruby.
  - rbxbx 15y ago
    filteredArray = [allRecords filteredArrayUsingPredicate: [NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]]; in ruby: all_records.select {|r| r.some_field == some_field_filter_value} in clojure: (filter #(= % some-filter-value) all-records) in haskell: filter (\someField -> x == someFilterValue) allRecords
    - icodestuff 15y ago
      Let's be fair, in Objective-C, this could be actually more like NSIndexSet *indicies = [allRecords indexesOfObjectsPassingTest:^ (id obj, NSUInteger idx, BOOL *stop) { return [obj someField] == someFieldFilterValue; }]; filteredArray = [allRecords objectsAtIndexes:indicies]; rather than what the article had in mind. EDIT: oh, someFieldFilterValue was an integer, wasn't it. Fixed.

deleted 15y ago

[deleted]

philjackson 15y ago

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

toadkick 15y ago
Agreed. I've had to use factories in Obj-C plenty. I guess the argument that I would make is that they are much easier to implement in Obj-C and require less boilerplate (especially if you use blocks), not that the pattern doesn't exist in Obj-C.

ataggart 15y ago

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) Yeah, maybe not so much.

deleted 15y ago
[deleted]

DrJokepu 15y ago

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.

chriseidhof 15y ago
Very true, all of this would improve the language a lot. I have often thought about writing a language that does these kind of things and compiles to Obj-C. Also, I would love to be able to do some kind of metaprogramming without resorting to strings.
- domhofmann 15y ago
  I'm trying to do just that with a project I started a few days ago called Khaki. It's a bit of a learning exercise and quite early, but you might find it useful in a month or two. https://github.com/dominikhofmann/khaki https://github.com/dominikhofmann/khaki

hamidpalo 15y ago

Looking at the example given of how lovely obj-c is: filteredArray = [allRecords filteredArrayUsingPredicate:[NSPredicate predicateWithFormat:@"someField == %d", someFieldFilterValue]]; Makes me wonder if the author has ever seen languages that do this like so: let filteredArray = Seq.filter (fun f -> f = "foo") allRecords

jeswin 15y ago

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.

kaffeinecoma 15y ago

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.

smweber 15y ago

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.

super_mario 15y ago

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.

Aloisius 15y ago

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.

Toady 15y ago
You may dislike the verbosity, but it's hardly "completely unnecessary." A typical Objective-C program is inherently self-documenting. It's nice knowing what a group of arguments is used for without having to look up the method prototype.

jtmille3 15y ago

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.

equalarrow 15y ago
Exactly. I once worked with a very smart Obj-C guy. I asked him if he could document all the method calls so I knew what they did. He said: there is no need. In Obj-C the selectors should document themselves.

bitwize 15y ago

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

chaostheory 15y ago

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.