6 ms·

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 u

by 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?
      - tptacek 16y ago
        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.
        cageface 16y ago
        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.
        tptacek 16y ago
        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.
ant5 16y ago
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.
- jawngee 16y ago
  So you work on GCC and are complaining about mostly legacy C things? What?
  - ant5 16y ago
    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.
  - Zev 16y ago
    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.
- Zev 16y ago
  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.)
deleted 16y ago
[deleted]
city41 16y ago
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.
- jawngee 16y ago
  I use it every day.

by jawngee 16y ago

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?
    - tptacek 16y ago
      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.
      - cageface 16y ago
        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.
        tptacek 16y ago
        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.

ant5 16y ago

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.

jawngee 16y ago
So you work on GCC and are complaining about mostly legacy C things? What?
- ant5 16y ago
  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.
- Zev 16y ago
  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.
Zev 16y ago
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.)

deleted 16y ago

[deleted]

city41 16y ago

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.

jawngee 16y ago
I use it every day.