Hacker News Reader

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.

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.