6 ms·

As someone who has been, on and off, writing Objective-C for the past decade, I will unequivocally state that as application programming languages go, it's a te

by ant5 16y ago

As someone who has been, on and off, writing Objective-C for the past decade, I will unequivocally state that as application programming languages go, it's a terrible 1980s jalopy of bad language decisions cobbled on top of more bad language design under which Smalltalk-descendent ideas peek through now and then. Language research has progressed. Microsoft has invested heavily in C# and related technologies. Even Smalltalk research moved on -- strongtalk, newspeak. We have alternative, real-world usable languages running on the JVM, from Scala to Clojure. Yet Objective-C moves forward one slow, stuttering step at a time. There are no namespaces. There are no self types (your init methods all have to return id so that they don't conflict with other init methods that have the same name). There are no private methods. Writing an initializer takes 3 lines of boilerplate, every time, plus the header declaration: if ((self = [super init]) == nil) return nil; return self; The language is obtuse, ridiculously verbose, frustrating to use, and downright paleolithic compared to modern deployed languages. It's a joke compared to everyone else's modern language research. I suffer through it full time because that's what the platform demands, but I would shoot it in the head in a second if I could. Nuke it from orbit. It's the only way to be sure. Anyone who thinks ObjC is a good language either hasn't actually spent significant time outside of C/C++/ObjC, or is still new to the wide, wonderful world of Mac/iPhone development.

city41 16y ago
I pretty much totally agree. I released two apps in the app store (one was a rather elaborate game). I feel I experienced enough to get a feel for what the language is like, and I came away unimpressed. At the most basic level, how verbose the language is is what bugged me the most. You gotta type like crazy to get anything done in Obj-C.
jawngee 16y ago
As someone who does a ton of Objective-C, I challenge the notion that namespaces are even remotely necessary. I've also done development in nearly everything under the sun, in nearly every "popular" language under the sun, which challenges your other assumption that anyone who thinks Objective-C is good hasn't spent time outside of C/C++/Objective-C. I'm guessing you've never written a Windows app with C++ and MFC. Or have done any hardcore UI development in C# or Java - both languages that are easily way more verbose - and require way more boilerplate - than Obj-C. My assumption is that you simply don't grok it, that you haven't learned how to utilize dynamic dispatch, KVO, etc. to greatly simplify and streamline your application designs. Or you are one of those script kids that takes all the low level shit for granted. This isn't python. This isn't ruby. This isn't even smalltalk. It's a high level layer on top of a low level language. You don't get that kind of performance without some sacrifice, but rest assured that sacrifice is significantly less than C/C++ while maintaining similar or the same performance.
- cageface 16y ago
  Obj-C does not have a similar performance profile to C/C++. Method dispatch is far slower than vtables. I've personally witnessed a huge Obj-C dev project fall apart when the team couldn't get performance up to snuff, even with dedicated help from Apple's UI team. The rewrite in C++ is progressing nicely.
  - tptacek 16y ago
    And as someone who is currently writing high-performance ObjC code, and who has written internet-scale packets-per-second-metered code in C and C++, I call bullshit on this. I have no doubt that method dispatch is significantly slower than vtables, but you're ignoring the fact that for performant code, plenty of C++ devs believe that vtables are far too slow as well. Large high-performance C-style projects are always struggling with the tension between the indirection that architects want to keep the system clean and the hardwired directness that the profiler says the system needs to be fast. ObjC didn't introduce this dilemma; function pointers did. It's so well known in C++ code that the MIT Click Modular Router even got distributed with a tool that automated de-virtualizing method calls. In both C++ and ObjC, when dispatch gets scary, you write C code. The difference is that C++ pummels you about the head and shoulders for even considering writing straight C with naked pointers, while ObjC could care less. I would rather avoid ObjC. I would rather build a large system out of any high-level language, from Scala to Ruby to Python to Lisp, and use an FFI to drop into C code. But I'd spend the rest of my career in ObjC without so much as a Bourne shell script to fall back on than I would willingly start another project in C++.
    - ant5 16y ago
      Worth reviewing: http://www.mikeash.com/pyblog/performance-comparisons-of-common-operations-leopard-edition.html http://www.mikeash.com/pyblog/performance-comparisons-of-com...
      - cageface 16y ago
        So on 64-bit architectures Obj-C messages are eight times slower than a vtable lookup. There's no way that could make or break an apps performance, right?
cageface 16y ago
This is exactly why I haven't taken a serious look at cappucino. Why impose that cruft on javascript?
pornel 16y ago
Standard constructor boilerplate is simpler: if (self = [super init]) { /* do the init */ } return self; Huge advantage of this is that you can implement object pools, singletons, etc. transparently.
- ant5 16y ago
  Standard constructor boilerplate is simpler: You just wrote exactly the same thing I did, but in a style that triggers GCC warnings regarding using assignment as a truth value. Huge advantage of this is that you can implement object pools, singletons, etc. transparently. You might consider looking into Newspeak constructors to see how it can be (much) better done, with much less code. In short, treat constructors as class methods, allow them to be used interchangeably, support self-types so that you can't get selector conflicts, enforce calling of the constructor so you don't have to rely on documenting the designated initializer.
gmac 16y ago
I'm otherwise mainly a Rubyist, but I have to say that on the whole I really like the verbosity of Cocoa, because I find it's generally the right sort of verbosity: it's there to clearly and unambiguously describe what's going on. The stringByReplacingOccurencesOfString:withString: method, as mentioned in the article, is a great example of that: three cheers for it!
- ant5 16y ago
  When I speak of verbosity, I'm more referring to the need to repeat yourself and turn simple tasks into heavyweight ones via required boilerplate. The long method names don't bother me.

by ant5 16y ago

city41 16y ago

I pretty much totally agree. I released two apps in the app store (one was a rather elaborate game). I feel I experienced enough to get a feel for what the language is like, and I came away unimpressed. At the most basic level, how verbose the language is is what bugged me the most. You gotta type like crazy to get anything done in Obj-C.

jawngee 16y ago

As someone who does a ton of Objective-C, I challenge the notion that namespaces are even remotely necessary. I've also done development in nearly everything under the sun, in nearly every "popular" language under the sun, which challenges your other assumption that anyone who thinks Objective-C is good hasn't spent time outside of C/C++/Objective-C. I'm guessing you've never written a Windows app with C++ and MFC. Or have done any hardcore UI development in C# or Java - both languages that are easily way more verbose - and require way more boilerplate - than Obj-C. My assumption is that you simply don't grok it, that you haven't learned how to utilize dynamic dispatch, KVO, etc. to greatly simplify and streamline your application designs. Or you are one of those script kids that takes all the low level shit for granted. This isn't python. This isn't ruby. This isn't even smalltalk. It's a high level layer on top of a low level language. You don't get that kind of performance without some sacrifice, but rest assured that sacrifice is significantly less than C/C++ while maintaining similar or the same performance.

cageface 16y ago
Obj-C does not have a similar performance profile to C/C++. Method dispatch is far slower than vtables. I've personally witnessed a huge Obj-C dev project fall apart when the team couldn't get performance up to snuff, even with dedicated help from Apple's UI team. The rewrite in C++ is progressing nicely.
- tptacek 16y ago
  And as someone who is currently writing high-performance ObjC code, and who has written internet-scale packets-per-second-metered code in C and C++, I call bullshit on this. I have no doubt that method dispatch is significantly slower than vtables, but you're ignoring the fact that for performant code, plenty of C++ devs believe that vtables are far too slow as well. Large high-performance C-style projects are always struggling with the tension between the indirection that architects want to keep the system clean and the hardwired directness that the profiler says the system needs to be fast. ObjC didn't introduce this dilemma; function pointers did. It's so well known in C++ code that the MIT Click Modular Router even got distributed with a tool that automated de-virtualizing method calls. In both C++ and ObjC, when dispatch gets scary, you write C code. The difference is that C++ pummels you about the head and shoulders for even considering writing straight C with naked pointers, while ObjC could care less. I would rather avoid ObjC. I would rather build a large system out of any high-level language, from Scala to Ruby to Python to Lisp, and use an FFI to drop into C code. But I'd spend the rest of my career in ObjC without so much as a Bourne shell script to fall back on than I would willingly start another project in C++.
  - ant5 16y ago
    Worth reviewing: http://www.mikeash.com/pyblog/performance-comparisons-of-common-operations-leopard-edition.html http://www.mikeash.com/pyblog/performance-comparisons-of-com...
    - cageface 16y ago
      So on 64-bit architectures Obj-C messages are eight times slower than a vtable lookup. There's no way that could make or break an apps performance, right?

cageface 16y ago

This is exactly why I haven't taken a serious look at cappucino. Why impose that cruft on javascript?

pornel 16y ago

Standard constructor boilerplate is simpler: if (self = [super init]) { /* do the init */ } return self; Huge advantage of this is that you can implement object pools, singletons, etc. transparently.

ant5 16y ago
Standard constructor boilerplate is simpler: You just wrote exactly the same thing I did, but in a style that triggers GCC warnings regarding using assignment as a truth value. Huge advantage of this is that you can implement object pools, singletons, etc. transparently. You might consider looking into Newspeak constructors to see how it can be (much) better done, with much less code. In short, treat constructors as class methods, allow them to be used interchangeably, support self-types so that you can't get selector conflicts, enforce calling of the constructor so you don't have to rely on documenting the designated initializer.

gmac 16y ago

I'm otherwise mainly a Rubyist, but I have to say that on the whole I really like the verbosity of Cocoa, because I find it's generally the right sort of verbosity: it's there to clearly and unambiguously describe what's going on. The stringByReplacingOccurencesOfString:withString: method, as mentioned in the article, is a great example of that: three cheers for it!

ant5 16y ago
When I speak of verbosity, I'm more referring to the need to repeat yourself and turn simple tasks into heavyweight ones via required boilerplate. The long method names don't bother me.