In defence of Objective-C

http://splinter.com.au/in-defence-of-objective-c

by chubs • 15 years ago

107 116 15 years ago

splinter.com.au

chubs5• 15 years 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• 15 years 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

philwelch• 15 years 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• 15 years 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• 15 years 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• 15 years ago

Make no mistake Apple's priorities are: Apple, Users, Developers.

thought_alarm• 15 years 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.

plinkplonk• 15 years ago

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

Derbasti• 15 years 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.

atomicdog2• 15 years ago

[[perhaps [[not] a always] that [readable[though]]]]]

5hoom4• 15 years 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! :)

chubs5• 15 years 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!)

5hoom4• 15 years 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• 15 years 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• 15 years 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).

dfox2• 15 years ago

It's important to realize, that ObjC (and Smalltalk, Self...) does not have named arguments in the conventional sense (ie. like Python, &key arguments in CL...) but mix parts of message name with it's arguments. In essence, it only looks like named arguments - and on the other hand, this syntax essentially precludes support for real named arguments. For why this is bad look at all these #with:, #with:with: ... #withValues: methods in Smalltalk's standard library that are only thin wrappers used to simulate true optional or named arguments.

jinushaun• 15 years ago

I think Objective C is awesome, but I suspect many people have a hard time separating the language from the library. Apple has a pretty unique way of developing frameworks and SDKs. Comparing Android and iOS development, the Android SDK makes sense out of the box because it follows typical Java/C#/C++ style framework design.

fbuilesv• 15 years 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.

stephth3• 15 years ago

you don't need to use XCode. I keep it open to manage, build, etc, but use textmate to do the editing.

5hoom4• 15 years 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• 15 years 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).

tomjen33• 15 years 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• 15 years 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.

n00kie• 15 years ago

xcode - unstable piece of sh*t. Even after so many years it still tends to crash randomly...

tolmasky• 15 years 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.

saurik9• 15 years ago

On #4: personally, I believe it is a mistake to attempt to abstract memory management from developers unless you can abstract all resource management (as there is no fundamental difference between memory mappings, file handles, database connections, or minimum-wage bicycle messengers), and in the attempt to fully abstract memory management (as in, with garbage collection) it usually becomes impossible to abstract arbitrary resource allocation (due to non-deterministic finalization; interestingly, this is a similar tradeoff to CAP).

With this realization, Objective-C is actually really good at this, requiring many fewer (if not actually no) try/catch blocks to get "safe" code than is required on seemingly almost every line of Java (which doesn't even have C#'s "using" to help it out, a primitive that causes its own problems due to lack of contracts), and has conventions that make it quite simple to "locally" (as in, without having to read anything not directly around the area you are analyzing) determine whether code you are looking at is handling things correctly.

Therefore, and I kid you not: when I saw "a defense of Objective-C" I was anticipating an article that was going to start with how awesome the memory management was (listing the auto-release pool paradigm as something that people typically haven't developed into mature C++ memory paradigms), followed by a discussion of the balanced tradeoff between fully dynamic typing and dispatch with low-level performance-oriented code; instead, I read "You’ll have to prise my garbage collecter out of my cold, dead hands!", sigh, and go back to coding. :(

veyron3• 15 years ago

Why don't you expand upon this and your other comments into a full-blown defense of objective C?

for the record: My preference for Smalltalk-style messaging over Simula-style objects is largely historical (having been exposed to the former first)

pvg2• 15 years ago

>as there is no fundamental difference between memory >mappings, file handles, database connections, >or minimum-wage bicycle messengers

The number of programs you can write without file handles, database connections or minimum-wage bicycle messengers is dwarfed by the number of programs that are extremely painful to write without dynamic memory allocation. We can argue all day about how 'fundamental' the difference is but there is a profound practical difference well-recognized in the decades of work that's gone into memory GC. 'It's ok/actually awesome that Obj-C kind of blows at memory management because other languages kind of blow at universal resource management' is a pretty specious argument.

prodigal_erik• 15 years ago

Unlike other resources, dangling references to memory are catastrophic. They generally go undetected (no layer of indirection to invalidate them) and can arbitrarily corrupt any future object, violate any type safety rules of the platform, and make even bug-free code execute incorrectly. "Is this object really dead?" is the kind of mind-numbing but critically important question that computers demonstrably answer much more reliably than people. That's why even objc uses a simple but expensive form of garbage collection (reference counting) rather than making you declare "not only am I not using this, I hereby bet my reputation that nobody else is either" by calling free().

tomjen33• 15 years ago

They could have added garbage collection if they wanted to add as much ram to the iphone as the Android phones have but I guess they already made their choice long before one could develop code for the iphone.

dextorious5• 15 years ago

The Android phones appeared a year or so later. Memory prices weren't the same.

And GC is always less efficient than no GC, even with more memory.

glhaynes• 15 years ago

Arguably far more important than the amount of RAM—which costs in dollars, battery, and sometimes even physical size—is the non-deterministic performance of GC, which directly costs in responsiveness.

masklinn4• 15 years ago

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

"Pragmatic", much like "practical", is utterly worthless for programming language discussions. It means something different to everybody, and it's basically the tool you'll reach for when you have absolutely nothing good to say about the language you're trying to "defend".

Both "pragmatic" and "practical" should be the godwin points of PL discussion. They're complete bull.

> The point is to understand why we have brackets, because they allow for named arguments without colliding with existing C syntax.

Just because there are reasons it's done that way does not mean it's any less ugly, does it?

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

For pretty much all OO PL languages, the distinction is just cutesy, the end result is that you're synchronously calling a method on an object, whether you call it "message" or "method" has little relevance.

> This is because you can do both in Obj-C

Do you mean that in a "function pointer in a struct" sense? This would use the `->` sigil would it not? And obj-c 2.0 managed to include dotted property names, so that could have been used (obviously, it wasn't because obj-c merges Smalltalk syntax into C and Smalltalk's message-send syntax does conflict with C if unbracketed)

> It's possible to take Obj-C without Cocoa, and write a framework that is just as non-verbose as Python

Not quite, Obj-C has structural deficiencies (in part inherited from C) which mean it has boilerplate you can't do without, such as the duplications between header and implementation files.

For much of its history, it also lacked any form of "blocks" (and those added in obj-c 2 are pretty verbose), meaning your Obj-C code would have a harder time with scoped resources than the equivalent Python code.

Other intrinsic verbosity issues of obj-c: iterations pre-Obj-C-2 (and fast iterators), type annotations, retain/release calls (we'll see how ARC fares), ...

I would say embracing Cocoa's chosen verbosity (although I sometimes find it misplaced) is a much better strategy than claiming Obj-C can be as terse as Python.

davedx• 15 years ago

I stopped reading at: "Things like factories, adapters, and other design patterns are all thankfully not there."

Huh? Design patterns are "thankfully not there"? What does that even mean?

veyron3• 15 years ago

I took that to mean that the objective-C community as a whole is not obsessed with the gang of four.

Though, to be fair, my exposure to the community is limited to AP CS AB (why they decided to use java is beyond me ...)

saurik9• 15 years ago

Not that I agree with him, but I do understand what he meant by that, and might be able to explain slightly: many people believe that "design patterns" are something that languages like Java (quite in particular, this language is held up during these conversations) require to work around design deficiencies.

Arguably, this is true: many of the patterns simply "fall away" if you have access to features like multi-method dispatch (Lisp+CLOS), message passing with transparent proxying (as in SmallTalk, and to some extent Objective-C), or continuations (Lisp/Scheme).

However, the argument often goes even further into the realm of complaints against "all kinds of patterns, even those that tend to exist in all abstractions, even mathematical ones", deriding things like factories as "overly-complex" (in the same concept of "overly-complex" that make some people choose NoSQL over RDBMS not for scalability, but due to the common lack of schemas).

zvrba• 15 years ago

Probably that you can get stuff done simply, without writing a lot of boilerplate code.

fleitz• 15 years ago

It means that you type stuff like

  NSArray* array = [NSArray new];

And the implementation changes to suit what you're doing with the array rather than

  CollectionFactory colFactory = new CollectionFactory();
  ICollection array =  colFactory.getArrayOptimizedFor(100);

Java: It's factories, all the way down.

chubs5• 15 years ago

Hi, Thanks very much for your thorough and constructive criticism :)

For me, writing articles like this is as much about learning to be a better communicator as anything, and you've (indirectly) really got me thinking about how i could have written this better.

I'm thinking there should be a single 'theme' to an article, and that every topic/point discussed should be related to that theme. In the case of this blog post, it should have been 'pragmatism' as you identified.

If i had written with that in mind, i could have used every point to illustrate how obj-c really reflects pragmatic principles in so many ways, which would have been a much better article.

flitzwald2• 15 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 };

and

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

freemarketteddy3• 15 years 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.

saurik9• 15 years 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.

chubs5• 15 years ago

There's ConciseKit for precisely this problem: https://github.com/petejkim/ConciseKit

We use it in a lot of our code here. Its quite nice. You'll end up with something like:

myDict = $mdict(val, key, val2, key2);

freemarketteddy3• 15 years ago

wow thts pretty cool!

koenigdavidmj• 15 years ago

And the values and keys are still backwards.

hboon2• 15 years ago

Can't get rid of the issue completely, but at least we can have:

#define MD(val, key, vals...) [NSMutableDictionary dictionaryWithObjectsAndKeys:val, key, ## vals , nil]

then do:

NSMutableDictionary* dict = MD(@"value1", @"key1", @"value2", @"key2")

And so on. Courtesy of http://news.ycombinator.com/item?id=1789839.

5hoom4• 15 years ago

Very nice, thanks for that.

stephth3• 15 years ago

That ## vals syntax is new to me. What's the difference with the following?

  #define MD(...) [NSMutableDictionary dictionaryWithObjectsAndKeys:__VA_ARGS__, nil]

saurik9• 15 years ago

So, languages that have primitives like this typically are designed to be used by people who don't know much about algorithms, or simply don't want to be hassled with it, either now, or ever: they want to write code, they want it to "work", and they want to move on to something else; in essence, we are talking "scripting languages".

Languages that some look at as "real programming languages", in comparison, tend to not have syntax like this, and the reason why is that you often, either now, or at some point later, are going to care whether the data structure you just allocated is a red-black tree, a hash map, a patricia trie, or even an AVL tree (which I include mostly to make a point: there actually are situations where it is preferred to a red-black tree).

When this suddenly matters, you are in the situation where what you want to be able to do is to make a very small modification to areas of your code where you need to select a different algorithm, in order to get the different result; you don't want to be forced to rewrite half your code to use a different syntax just because it was slow (I mean, if you wanted to do that, you'd have written it in Ruby and then recoded it in C).

Therefore, you find that it is normally the case in languages like Java, C++, and Objective-C, that there are no "built-in container types", as you will never find a container type that is actually correct to use in an even fractional majority of the cases; in fact, most of the time, there isn't even a single obvious choice in these languages for what class to use: you find default implementations of multiple algorithms.

Objective-C, here, is no different from this concept: NSDictionary is just an interface, and can be implemented by numerous backends. Apple has a rather good implementation backing the default version, and even attempts to switch between algorithms as the data structure grows, but your code is always just a few identifiers away from choosing a different subclass in that collection hierarchy.

flitzwald2• 15 years ago

Ah, I get it. Convenient container-syntax is only found in toy scripting languages for stupid people like -uh- Haskell? :)

younata• 15 years ago

This is why I do most of my editing with objective-C in xcode, while I do most of my editing with python in vim.

Tab completion of methods is very nice to have, and makes using xcode as fast as using vim for me. (now, if I could have vim keybindings with xcode tab-complete, then I'd rocket through my editing...)

jon6• 15 years 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• 15 years ago

"You’ll soon learn to see through the brackets"

@I @hope @that @also @applies @to @the @the @at-@signs. ;-)

dextorious5• 15 years ago

Huh? Obj-C only uses @ signs at a couple of places, like to denote a native @"dasdasda" string and in compiler instructions...

barumrho• 15 years 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• 15 years 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_• 15 years 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.

dextorious5• 15 years ago

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

Grow some taste?

extension• 15 years 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.

masklinn4• 15 years 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.

dextorious5• 15 years 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• 15 years 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• 15 years 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• 15 years ago

Just curious, for comparison: what would the equivalent be in Ruby?

akmiller2• 15 years ago

Hard to believe anyone would use that as an example. In C# you could do:

filteredArray = allRecords.Find(i => i.someField == filterValue)

EDIT: Not sure why the downvote, I'm simply stating that many other languages have far better syntax for filtering an array so I'm not sure why the author would think the syntax in Obj-c is all that great unless they have never done the same thing in any other language.

philjackson• 15 years 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• 15 years 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• 15 years 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.

DrJokepu• 15 years 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• 15 years 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• 15 years 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

0x09• 15 years ago

About #7: since the last WWDC, it looks like they will be strongly pushing http://lldb.llvm.org/

Once it matures I expect the Xcode debugging experience will become quite a bit different from the current (flimsy) gdb shell-out.

pornel• 15 years ago

7. `[X new]` works.

seanalltogether• 15 years ago

7. Additionally, automated file importing needs to be added to xcode.

8. Global space is polluted with constants and enums

hamidpalo• 15 years 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• 15 years 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• 15 years 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• 15 years 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• 15 years 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• 15 years 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• 15 years 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• 15 years 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• 15 years 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.

bitwize3• 15 years 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• 15 years 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.

In defence of Objective-C

Related Stories