Objective-C overtakes C++ to become 3rd most popular language
tiobe.com
tiobe.com
After a year of working almost exclusively in Obj-C I still haven't come to enjoy its verbosity and awkward and incomplete collection classes. The lack of namespaces and inadvertent selector overloading are a regular nuisance. And the Cocoa frameworks are more dynamic than they need to be and heavy use of notifications and KVO make code a rat's nest of indirect jumps that are very hard to follow.
It's ok as a widget glue language, I suppose, but really a lot of other languages could serve that purpose just as well without standing over the flaming pit of C all the time.
The new collection literals and operator overloads for the collection classes will help, of course. And you have to give Cox some credit for a design that was, in its time, quite visionary. But language design has caught up to and passed Obj-C by in the meantime. If it weren't for my reservations about having one more software layer between me and the machine I would have moved to MonoTouch/C# a long time ago.
The problem is that you can’t cherry-pick language features. Each of them has implications for the rest of the language, forcing you into some compromise. As an example, when Objective-C picked great compatibility with C, it picked some great strengths (using existing C libraries, language familiarity, being close to the metal) along with some downsides. For me, the Objective-C strengths are worth the downsides.
Some of your points are purely subjective. I would pick Objective-C verbosity again, because it makes me think less. I can generally parse long words at a glance and code completion saves me typing. Some identifiers are too long indeed, but the consistency is a win. For me.
I don’t see what’s so awkward about collection classes and you don’t say what is that you miss. Granted, the collection literals are too verbose, but that will get much better with the upcoming Xcode release, just as you said. And even the older, verbose syntax is not a language deal-breaker for me.
KVO and notifications are not always roses, but can you give an example of what bugs you along with a solution in a different language that you consider superior?
Again, my main point is that each language design is a compromise and I quite like the compromise represented by Objective-C. Namely, the simplicity of the language, the balance between the metal and a higher-level language, the readable syntax and the standard libraries.
Unlike XCode, it even gives you pretty decent refactoring, which is impressive considering how hard that is in a language with a preprocessor.
C compatibility is a double-edged sword. For most apps it's more of a liability than a benefit. Always being one pointer error away from writing all over memory is not a good thing. Being forced to manually deal with headers and include directives in 2012 makes me sad. Not necessary in Java/C#/etc.
ARC makes memory management a lot less of a pain but you really still need to understand retain/release and weird issues pop in things like blocks, complicating their already ugly (compared to C#/Java lambda, Ruby, Python etc) syntax.
Picking apart a long selector invocation takes a lot more effort than just parsing a typical function call. In languages like Python or C# you can use explicit argument labels if you really need them instead of all the time.
Collections are going to be less painful with the new literals and autoboxing but they're still really crude compared to C++ stl, for example.
Most of what you can accomplish with KVO and notifications can be done with more explicit listener/delegate arrangements and that kind of code is a lot easier to understand too. There's nothing keeping you from doing that in Obj-C but the KVO way is pretty ingrained in Cocoa, just like informal protocols used to be.
1. C compatibility is a liability, not a benefit. Every language that has build on C is full of corner-cases, warts and undefined behavior. Obj-C is the worst since it didn't fix anything about C, it just nailed objects on top of it.
2. The syntax is horrible. People rush to say that this is not important, but it's HUGELY important since it's the only way that you interface with the machine, the text that you read and modify for the entire lifetime of the software - which could be years or even decades. Brad Cox failed to anticipate how object orientation would look like in future programming languages. Most languages either extended the C syntax for the object oriented part or got rid of the baggage. B.C brought us the e-mail symbol and writing + and - in front of all your member functions. e.g:
* You have to write @interface and @implementation and @end because apparently it was too much work to write a decent contextual parser.
* @"char" instead of automatic conversion
* @ as placeholder in string formatters. I see a pattern here...
* You must use () around return types. This is piss poor programming language design: thanks to the +'s and -'s you already know you're looking at a non-C function, but let's make the programmer dance around like a little monkey.
* Must use pointer syntax even though you're forced to use pointers to objects anyway. Java and C# got this right.
* No operator overloading. Where is your Smalltalk now?
* Namespaces?
* many other examples
Obj-C assumes that it can offload the boring tasks to the programmer because such was the fashion in the 70s and 80s.
3. Verbosity does not help at all. You have to spend more time reading code, understanding code, writing code. If it has more LOC, it's harder to maintain, this is a proven fact.
4. The type system is as weak as C's, but dynamic typing makes it even more fragile.
5. Memory management in iOS is too complicated. Even with ARC you still have to do manual memory management in some cases. The fact that I call retain and release is not much better than calling malloc and free. Heck, it's easy to do similar reference counting in C. Several studies (please Google) have reported that iOS dev is more time consuming than Android and this matches the reports that I got from companies/people doing cross-platform dev. Obj-C is more complicated to program in than Java, in no small part due to memory management.
The final nail in the coffin is that this programming language is all but owned by Apple. The only reason to use it is if you're doing iOS development, but even there we're thankfully starting to see some alternatives such as Ruby and C#.
You seem to forget that it was created in the 80s.
You also seem to forget that it was picked in part because of it's performance characteristics, including the ability to drop down to pure C, for stuff like OpenGL etc.
In general, your complain is an repeat of "it's not high level enough as the languages I normally use".
Its a proven fact that given 2 programs, the one with more LOC will be harder to maintain?
This assumes that the code bases are of similar quality.
So... not a proven fact at all. More like a vague correlation with assumptions tacked to the end.
Although I agree that a lot of people underestimate perl generally speaking.
Objective-C is high on the list because it's trendy to write iPhone apps, so people blog about it and write a million "How to get started with objective-C" tutorials for it.
Outside of that niche, and a really small group of OSX developers, there's zero Objective-C development. It's barely even possible to write Objective-C on Windows or Linux.
People use objective-C when programming for iOS or iPhone. These are popular, not the programming language.
I find it hard to believe that it actually _increased_ in ranking though.
I have a hard time buying this. What cases have you found where Python is comparable to C++?
If your program spends most of its time actually executing code in Python then a comparable C++ implementation will probably be two or more orders of magnitude faster.
Although at that point, C is easier to work with ...
It's an interesting language, worth a look.