5 ms·

I think that Objective-C is pretty sweet. The problem is that you can’t cherry-pick language features. Each of them has implications for the rest of the langua

by zoul 14y ago

I think that Objective-C is pretty sweet. 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.

nevster 14y ago
Also, any Objective-C developers should definitely try out AppCode from JetBrains - http://www.jetbrains.com/objc/ http://www.jetbrains.com/objc/
- cageface 14y ago
  AppCode definitely makes things a little less painful. Unlike XCode, it even gives you pretty decent refactoring, which is impressive considering how hard that is in a language with a preprocessor.
- terhechte 14y ago
  Agreed, I use it for all my Objective-C stuff. And it has fantastic VIM bindings. Being able to code Objective-C with VIM bindings and full auto completion is just awesome.
cageface 14y ago
Langauge preference is always subjective. That said, IMO: 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.
notinfinland 14y ago
No it's not. After the major Obj-C hype on HN I decided to learn it and was very disappointed. 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#.
- 14y ago

by zoul 14y ago

nevster 14y ago

Also, any Objective-C developers should definitely try out AppCode from JetBrains - http://www.jetbrains.com/objc/ http://www.jetbrains.com/objc/

cageface 14y ago
AppCode definitely makes things a little less painful. Unlike XCode, it even gives you pretty decent refactoring, which is impressive considering how hard that is in a language with a preprocessor.
terhechte 14y ago
Agreed, I use it for all my Objective-C stuff. And it has fantastic VIM bindings. Being able to code Objective-C with VIM bindings and full auto completion is just awesome.

cageface 14y ago

Langauge preference is always subjective. That said, IMO: 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.

notinfinland 14y ago

No it's not. After the major Obj-C hype on HN I decided to learn it and was very disappointed. 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#.

14y ago