Comment by ant5 | Hacker News Reader

Comment by ant5 | Hacker News Reader

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.

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.

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.

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.

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

Worth reviewing:

http://www.mikeash.com/pyblog/performance-comparisons-of-com...

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?

No, there isn't. Because in any application where that code path was at the top of your profile, you'd code around it with direct function invocation, just like people do in C++ with expensive chains of vtable calls (which you end up with in GoF-style code).

Nice try, though.

In many real world apps there just isn't a single chokepoint but overhead distributed over your entire object model. C++ gives you 8x the breathing room that Obj-C does before you have to start tearing your abstractions apart and coding direct. For a codebase of any real size that can easily be a dealbreaker.

This is why it's easy enough for advocates of python/php/ruby to say "just code the slow parts in c" but often far harder to actually do this without losing any advantage the higher level language bought you in the first place.

Comparing the amount of time it takes to refactor an expensive (inner-loop) series of message invocations into a direct function call to the amount of time it takes to recode Ruby in C and bridge it with an FFI is specious.

Dodging the point that often you don't have a bottleneck reducible to a few slow inner loops is more specious.

There's a huge difference between the overhead of a dynamic function call and a vtable lookup. No doubt there are some cases where even a vtable lookup is too expensive but there are millions upon millions of lines of production C++ in high-performance apps that use C++'s vtable dispatch.

What language would you choose to write something like Protools, Photoshop, Maya, Visual Studio etc in? Definitely not C and definitely not Obj-C.

There's millions upon millions of lines of production code, some of it (for instance, at the financial exchanges) millisecond-optimized, running in Java. What's your point?

Again, I simply call bullshit on the idea that you couldn't write ProTools or Photoshop in ObjC. The portions of those systems where you care deeply about performance can be written most effectively in bare-metal C anyways; it's a delusion of C++ programmers that all the shellac and geritol that C++ offers is giving them a major performance benefit. It's C++ that forces you to make a lifestyle decision by pretending that pointers are anything other than register-sized integers. ObjC is just enough object goop layered over straight C to make large programs maintainable.

I hate C++ as much as the next guy but the idea that the people behind essentially all the performance-critical desktop apps on the planet are just too dumb to move on is quite strange.

Again, I've seen first hand a big, native UI project crash and burn on Obj-C dispatch overhead that is now trucking happily along in C++. Have you?

I have never seen an ObjC program crash and burn under the weight of ObjC. I have seen two major C++ projects get rewritten, once to straight C and once to new flavor-of-the-month C++ (from ACE-style objecty GoF-y C++ to Alexandrescu-y template-y C++).

You talk like adoption of C++ is a testimonial to C++'s power. The fact is, the market picked C++. Your realistic choices for bare metal app dev are straight C, which you can use anywhere, or C++, which you can use anywhere. If you want native objects, you're going to use C++.

There are two places where ObjC is even an option:

* On Apple stacks.

* In SaaS/ASP/service backend code.

In both of those places, ObjC is better than C++. If you care about portability, write in C or JVM+C.

I don't understand the comparison you're drawing. On most platforms, they don't have the option of using Objective-C (support outside the Apple ecosystem could charitably be called "anemic"), and on Apple platforms, most native development is done using Objective-C.

As someone who does a ton of Objective-C, I challenge the notion that namespaces are even remotely necessary ...

Apple is now suggesting that you use three-character class name prefixes, since they claim all the two character ones. I had my two character prefix claimed by a new private framework Apple added to iOS, and now one of my class names conflict with one of theirs. Kaboom.

If you go the no-prefix route, your code isn't library-reusable since other people will do the same thing, and you will still get screwed -- Apple regularly claims non-prefixed classes in their code, too.

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.

Seeing as you're writing ObjC using a compiler I've worked on, I think that probably understand the "low level shit" better than you do.

So you work on GCC and are complaining about mostly legacy C things?

What?

Just because I have the perspective to understand what's wrong with a language doesn't mean I can't or won't use it when it is the correct solution in a specific problem domain.

If Apple developed a first-class alternative to ObjC I would switch in a heartbeat. In the meantime -- to write Mac/iPhone apps -- I will continue to use it.

The best way to hate a language is to implement it. It forces you to learn all the ins and outs of the language, every nook and obscure corner that something, somewhere, depends on.

Apple is now suggesting that you use three-character class name prefixes, since they claim all the two character ones.

So you saw that talk at WWDC as well? Every engineer from Apple that I've spoken to and asked about this has gone "What?! Did he really say that? Ignore it. We don't recommend that. Not at all."

Seeing as you're writing ObjC using a compiler I've worked on, I think that probably understand the "low level shit" better than you do.

You work on LLVM? Props to you, if so. Thats an awesome project. However, if you work on gcc, I haven't used that in over a year :-)

(I kid. Props to you, either way. I can't do what I do without what you do.)

So you saw that talk at WWDC as well? Every engineer from Apple that I've spoken to and asked about this has gone "What?! Did he really say that? Ignore it. We don't recommend that. Not at all."

Regardless of what they say, Apple is still claiming new two-character prefixes, including the one I've been using for years.

You work on LLVM? Props to you, if so. Thats an awesome project. However, if you work on gcc, I haven't used that in over a year :-)

I'm a big fan of LLVM, but no, I've done nothing with it. That said, if you're using clang for your production builds, you're a much braver soul than me.

There are still plenty of codegen issues, especially in the new iPhone/ARM support. There's a reason Apple is still using GCC.

That said, if you're using clang for your production builds, you're a much braver soul than me.

Hardly brave; I only use it personal projects (which target 10.6/64-bit Mac) and debug builds. Release/Ad Hoc/Distribution builds for what I work on uses llvm-gcc. But, I'm not responsible for those builds.

When was the last time you've used C#? The fact you are lumping it in with Java already suggests your C# skills are very out of date. C# is by far the fastest growing mainstream language. C# 3 and now C# 4 require very little boilerplate code. I'm often amazed at how clean and succinct my C# code can become nowadays.

As for UI programming in C#, give WPF and/or Silverlight a try. They both have their downsides, but in the end they offer a far more pleasant experience than Cocoa Touch. I haven't written an MFC app in about 1.5 decades or so.

I use it every day.

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!

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.

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.

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.

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

Reply on news.ycombinator.com