Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Interesting article. I do not have much experience in C++ but I am learning Objective-C. Do any of the sentiments mentioned in the article carry over to Objective-C? Or is that comparing apples and oranges? Is Objective-C a better extension/ superset (whatever the formal name) to C?


I would say that Objective-C in itself is a very simple object orientation layer on top of C. If you know C, you can pick up Objective-C in a matter of minutes. It is really simple. What makes Objective-C useful in OSX programming is the framework Cocoa. If you say, you do 'Objective-C programming' you mostly mean 'Cocoa programming'.

In contrast to that, it probably takes years to really understand everything C++ has to offer. And that is talking about the language only, no frameworks or libraries included. Hence, I would say that you can not really compare Obj-C/Cocoa to C++, since the former is a framework and the latter is a language. (This is assuming that most people mean 'Objective-C and Cocoa' when they say 'Obj-C')

If you want to compare Objective-C and C++ on a language level though, you are comparing two very different languages. Objective-C strives for simplicity and readability, which makes some things easy and some things harder. C++ strives for world domination. There is nothing you can't do with C++, but there are just so many things you can do that figuring out how to 'properly' do stuff can be kind of horrid. Really, there are so many different styles and dialects of C++ that you could use and freely intertwine that defining the language proper is a real challenge. Note that this is not necessarily a bad thing. C++ has a lot of strengths and is increadibly malleable for many different applications. But putting all that flexibility in one language certainly makes that language a truly complex beast, where even reading it can be a real challenge even after years of using it.

Personally, I am a sucker for simplicity and elegance and I would take Obj-C over C++ any day. On the other hand, I have seen some situations where Obj-C's message passing was just too slow for my application and I had to drop back to C function calls in some areas. Also, Garbage Collection and even Reference Counting have a certain performance penalty that might make Obj-C unsuitable for, say, embedded applications.


    There is nothing you can't do with C++
That's a tautology for any Turing-complete programming language. C++ may strive for world-domination, but I prefer my languages to be capable of introspection.

Complexity is not always directly proportional to the number of features supported.


    Complexity is not always directly proportional 
    to the number of features supported.
This is the difference between Turing complete and Gosling Complete. ;-)


I agree, Complex does not necessarily mean Complicated. In C++, it does.


They are very different languages with different objectives. Both of them started with the goal to provide OO to the C language because It was used for everything at that time.

C++ was designed with performance in mind. The main goal was to be as efficient as C and It means to not use any runtime.

Objective-C was designed to be source compatible with C and extends the language with a Smalltalk like syntax for OO. It uses a runtime which provides things like reflexion and GC.


Objective-C and C++ are very different apart from their C ancestry. C++ doesn't make an especially good Obj-C replacement, and Obj-C is probably no better at the situations where C++ excels than raw C. Objective-C is a higher-level, dynamic-ish, highly-OO extension to C. (great for GUIs, not so great for writing drivers) C++ is quite low level, not dynamic at all, and not overly OO. C++ is very expressive in many situations due to its generic and automatic resource management features, which Obj-C lacks completely. (GUI code is typically horrendous, driver writing is nicer than in C)


"(great for GUIs, not so great for writing drivers)"

Probably the most succinct description of the relative strengths of Objective C and C++. Objective C for GUIs, C++ for drivers and embedded development.


NeXTStep drivers were written in Objective-C using a framework called DriverKit, and this was on 90s machines.

Objective-C is just C; there is no inherent performance penalty other than the dynamic dispatch of messages. In situations where that would actually be an issue, you'd be avoiding object-oriented features in C++ as well.

However, driver performance bottlenecks are typically in I/O throughput, not the language the driver was compiled in. The fact OS X drivers are written in a C++ subset likely has to do with the demands of device manufacturers coming over from MacOS 9, just like the existence of Carbon was to appease application developers like Adobe.


"great for GUIs, not so great for writing drivers"

NeXTStep had DriverKit, a framework for writing drivers in Objective-C, and this was on 1990s-era PCs. Driver performance is I/O-bound and typically has little to do with the language the driver was compiled in.


Objective-C is a completely different approach to OO C than C++. Obj-C is basically straight C with a very Smalltalk-like OO layer and totally different flavor. Generally speaking I prefer C++ but Obj-C is a better choice if you need to do a lot of metaprogramming. The things you can do with message passing in Obj-C probably make it a better choice for building UIs, for example. Although I really miss the scope-managed resources of C++ when writing iOS apps.


The more dynamic nature of Objective C enables many of the design patterns used in Cocoa development. Delegation, key-value coding, binding targets and actions, the introspection behind Core Data, and many others.

Obviously, C++ being Turing complete these are all technically possible with C++. But in practice it would amount to "Greenspunning" the features of Objective C into C++.

http://en.wikipedia.org/wiki/Greenspuns_Tenth_Rule


the discussion going on here might be relevant: http://news.ycombinator.com/item?id=2221182




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: