Why did Apple decide to use Objective-C for the iPhone SDK and not C++?
It seems strange to me that they would not have chosen a language more popular than Objective-C. Is it because wanted to have something unique in their application which is not otherwise in general use?
Apple merged with NeXT in the '90s and Mac OS X was made from NeXT's operating system, NeXTSTEP. Objective-C was the official language of NeXTSTEP's application frameworks, which became Mac OS X's Cocoa. Mac OS X was then adapted into the iPhone OS, and Cocoa was made into Cocoa Touch. Objective-C has held up pretty well all along the way, and a lot of Cocoa's features would be difficult to translate into C++.
So essentially, it all comes from NeXT.
Objective C began life in 1983 I believe, created by Brad Cox and Tom Love. The idea of Objective-C was to take the purity and low-level control of C and merge that with true object-oriented features that would allow companies to customize system libraries that could communicate with the OOP layer of Obj-C. Essentially, it worked. Obj-C is a strict superset of C, unlike C++ which is most of C, but with many differences.
When Steve Jobs founded NeXT Computer (1985), he brought in some of his former Apple team and others. His best programmers were interested in using a language that expanded on C with the same speed benefits and system control. They chose Objective-C. NeXT eventually wrote many libraries and methods for the base language. These all begin with NS for Next Step. This was the name of the NeXT OS. By 1989 the Next Step OS was considered to be vastly superior to MS Windows or Mac OS, and many computer companies wanted to license it badly. Jobs simply didn't want to go in that direction.
Once Apple wised up and brought Steve Jobs back into the fold (1996), the infusion of Next Step OS into the new Mac OS X was really the key to Apple reviving its software and its programming strategy.
While C++ remains a truly excellent and powerful language, I find that Objective C has less flaws (just my opinion), and Apple's continued work on Cocoa libraries has made the Obj-C language a truly modern power with C underpinnings. Is it better than Java? Not sure. But for what it is primarily designed for (Mac OS, iOS) it is astonishingly good, if a bit overly verbose.
The greatest criticism of Obj-C is the syntactical styling, but any programmer that truly learns the language will quickly learn of its amazing power and seemless fit with all things Mac, iPhone, iPad.
Will any other platforms ultimately adopt Obj-C? not sure, but doubtful. But the Cocoa libraries are truly wonderful.
It's because Objective C has been the de facto language for Mac OS X development before it was Mac OS X. When Jobs left Apple to set up NeXT, the language Objective C was developed as a specific language that wasn't C++ and avoided many of its pitfalls. It therefore makes sense that any portable or consumer equipment (including Apple TV) use Objective C as their primary development language, and dropping down to the underlying C layer when needed for performance or interface issues.
Objective-C adds object oriented programming to C. It was used for NeXT, upon which a lot of OSX is derived. It supports all of C, and is simpler than C++.
http://discussions.apple.com/thread.jspa?threadID=2091191
Note that Objective-C is not a new language. It's been around since 1986 - well before Java or C#!
It has been in general use ever since NeXT, many real-world applications are around that make use of it.
Apple answered this very question here in 2010:
The Objective-C language was chosen for a variety of reasons. First
and foremost, it’s an object-oriented language. The kind of
functionality that’s packaged in the Cocoa frameworks can only be
delivered through object-oriented techniques. Second, because
Objective-C is an extension of standard ANSI C, existing C programs
can be adapted to use the software frameworks without losing any of
the work that went into their original development. Because
Objective-C incorporates C, you get all the benefits of C when working
within Objective-C. You can choose when to do something in an
object-oriented way (define a new class, for example) and when to
stick to procedural programming techniques (define a structure and
some functions instead of a class).
Moreover, Objective-C is a fundamentally simple language. Its syntax
is small, unambiguous, and easy to learn. Object-oriented programming,
with its self-conscious terminology and emphasis on abstract design,
often presents a steep learning curve to new recruits. A
well-organized language like Objective-C can make becoming a
proficient object-oriented programmer that much less difficult.
Compared to other object-oriented languages based on C, Objective-C is
very dynamic. The compiler preserves a great deal of information about
the objects themselves for use at runtime. Decisions that otherwise
might be made at compile time can be postponed until the program is
running. Dynamism gives Objective-C programs unusual flexibility and
power. For example, it yields two big benefits that are hard to get
with other nominally object-oriented languages:
Objective-C supports an open style of dynamic binding, a style that
can accommodate a simple architecture for interactive user interfaces.
Messages are not necessarily constrained by either the class of the
receiver or even the method name, so a software framework can allow
for user choices at runtime and permit developers freedom of
expression in their design. (Terminology such as dynamic binding,
message, class, and receiver are explained in due course in this
document.) Dynamism enables the construction of sophisticated
development tools. An interface to the runtime system provides access
to information about running applications, so it’s possible to develop
tools that monitor, intervene, and reveal the underlying structure and
activity of Objective-C applications.
Historical note: As a language, Objective-C has a long history. It was
created at the Stepstone company in the early 1980s by Brad Cox and
Tom Love. It was licensed by NeXT Computer Inc. in the late 1980s to
develop the NeXTStep frameworks that preceded Cocoa. NeXT extended the
language in several ways, for example, with the addition of protocols.
Related
I have integrated Lua with my ObjC code (iphone game). The setup was pretty easy, but now, I have a little problem with the bridging. I have googled for results, etc... and it seems there isn't anything that could work without modifications. I mean, I have checked luaobjc bridge (it seems pretty old and dicontinued), I heard about LuaCocoa but it seems not to work on iphone, and wax is too thick.
My needs are pretty spare, I just need to be able to call objc methods from lua and don't mind having to do extra work to make it work (I don't need a totally authomatic bridging system).
So, I have decided to build a little bridge myself based on this page http://anti-alias.me/?p=36. It has key information about how to accomplish what I need, but the tutorial is not completed and I have some doubts about how to deal with method overloading when called from lua, etc...
Do anybody know if there exist any working bridge between objc and lua on the iphone or if it could be so hard to complete the bridge the above site offers?
Any information will be welcomed.
Don't reinvent the wheel!
First, you are correct that luaobjc and some other variants are outdated. A good overview can be found on the LuaCocoa page. LuaCocoa is fine but apparently doesn't support iPhone development, so the only other choice is Wax. Both LuaCocoa and Wax are runtime bridges, which means that you can (in theory) access every Objective-C class and method in Lua at the expense of runtime performance.
For games and from my experience the runtime performance overhead is so significant that it doesn't warrant the use of any runtime binding library. From a perspective of why one would use a scripting language, both libraries defy the purpose of favoring a scripting language over a lower-level language: they don't provide a DSL solution - which means you're still going to write what is essentially Objective-C code but with a slightly different syntax, no runtime debugging support, and no code editing support in Xcode. In other words: runtime Lua binding is a questionable solution at best, and has lots of cons going against it. Runtime Lua bindings are particularly unsuited for fast-paced action games aiming at a constantly high framerate.
What you want is a static binding. Static bindings at a minimum require you to declare what kind of methods will be available in Lua code. Some binding libraries scan your header files, others require you to provide a special declaration file similar to a header file. Most binding libraries can use both approaches. The benefit is optimal runtime performance, and being able to actually design what classes, methods and variables Lua scripts have access to.
There are but 3 candidates to bind Lua code to an iPhone app. To be fair, there are a lot more but most have one or more crucial flaws or are simply not stable or for special purposes only, or simply don't work for iPhone apps. The candidates are:
tolua and tolua++
luabind
SWIG
Big disadvantage shared by all Lua static binding libraries: none of them can bind directly to Objective-C code. All require to have an additional C or C++ layer available that ultimately interfaces with your Objective-C code. This has to do with how Objective-C works as a language and how small a role it has played (so far) when it comes to embedding Lua in Objective-C apps.
I recently evaluated all three binding libraries and came to enjoy SWIG. It is very well documented but has a bit of a learning curve. But I believe that learning curve is warranted because SWIG can be used to combine nearly any programming and scripting language, it can be advantageous to know how to use SWIG for future projects. Plus, once you understand their definition file implementation it turns out to be very easy (especially when compared to luabind) and considerably more flexible than tolua.
OK, bit late to the party but in case others come late also to this post here's another approach to add to the choices available: hand-code your LUA APIs.
I did a lecture on this topic where I live coded some basic LUA bindings in an hour. Its not hard. From the lecture I made a set of video tutorials that shows how to get started.
The approach of using a bindings generation tool like SWIG is a good one if you already have exactly the APIs that you need to call written in Objective-C and it makes sense to bring all those same API's over into LUA.
The pros of the hand-coding approach:
your project just compiles with one standard Xcode target
your project is all C & Obj-C
the LUA is just data shipped along with your images
no fiddling with "do I check in generated code" to Git
you create LUA functions for just the things you want
you can easily have hosted scripts that live inside an object
the API is under your control and is well known
dont expose engine APIs to level building team/tools
The last point is just that if you have detail functions that only make sense at the engine level and you don't want to see those when coding the game play you'll need to tell SWIG not to bind those.
Steffens answer is perfect and this approach is just another option, that may suit some folks better depending on the project.
When and especially why should I switch from Objective-C to C or C++ when I develop on iOS platform. I'm sure I'm missing something but as far as I can see Apple wants developers to use Objective-C everywhere in Mac/iOS environment so why would I go with C/C++?
One note, though, I'm NOT talking about GAME DEVELOPMENT. In case of games I realize what are the advantages. I just don't get when I want to use C if I develop, for example, a client for a server or something like that (once again, not a game). All the classes I need already there and all of them in Objective-C.
Objective C is a strict superset of ANSI C, so an Objective C programmer is very likely already doing a significant amount of programming in C. In fact, many Mac and iOS APIs (audio, graphics, etc.) are C interfaces and/or use C data types.
A few of the reasons to do something in C, of things that are possible in both the superset and subset languages, might include performance and portability. There is a small amount of runtime overhead to Objective C messaging that is completely unsuitable for the inner loops of real-time audio or video image processing, etc. For portability, one can often use well encapsulated C code in iOS, Linux, Android NDKs, WebOS PDKs, & etc. And occasionally the Objective C wrappers for an OS service won't offer all the flexibility of some underlying C API.
The only reason I can see to use C++ for an iOS app might be to use some legacy C++ code and maintain some consistency of style with that code for readability, maintainability, etc.
For an iOS app where performance, or any portable code reuse is not important, there are few reasons to not just use Objective C (with its included C language), as that is what the most current documentation, tools, frameworks, and APIs for iOS are supported on.
The main advantage is portability. A chunk of code written in C++ or C can, when appropriate measures are taken, be very easily wrapped up and used in iOS or Android, or Blackberry, etc... Many 3rd party libraries go this route for that reason (Zebra Crossing and OpenCV come to mind immediately).
Another reason (and I would argue bad reason) is simply that a developer is comfortable in C or C++ and wants to avoid learning Objective-C as much as possible.
The only reasons I can think of are (a) you have an existing C++ codebase that you want to re-use (and don't want to have to rewrite it all in Objective C), or (b) you really like C++ and/or really don't like Objective C.
Why not mix and match as you like. The compiler supports "objective c++". Not sure that it supports C++11 features in such a mode, but it should support C++98 well. I think all that is required is that you change the naming of your source files from ".m" to ".mm". (This is all from memory and could be inaccurate).
As to the "why". Some apple APIs had more features in one language than the other. For example it used to be (and may still be) that a bunch of the graphics / quicktime functionality was only available through the cocoa interfaces, and not the objective C interfaces.
It is even more likely that some third party libraries may only be available in one language.
I am in possession of a dictionary application (takes in text as input, outputs definitions + grammar analysis). I have all the source files (about 50 pages of code), written in Ada, as well as Windows and Unix executables. I want to be able to use this dictionary in an iOS app.
I'm not at all familiar with Ada, so my question is, in a nutshell—are there any shortcuts to somehow wrap the application and use it on iOS? Or is the only way just re-writing the entire application in C/Objective-C?
Shark8 mentioned JVM-targeted Ada. ACT sells a version of Gnat that targets the JVM. However, I do not believe iOS devices currently run Java. Apple does not want to lose control of the platform, so they do not allow any development environments other than their own, which is Objective C based. I understand the Java folks are working to fix this, but even if they do Apple will probably refuse to allow any such app into their online store. Note that this is not a problem unique to Ada. Any app written in any language other than C or Objective C has the same problem with iOS. (This is one of the many reasons why developers tend to prefer to target Android platforms than iOS).
So what you really need is something that can get your code compilable with Apple's Objective C compiler. Supposedly Objective C is a strict superset of C. If this is true for Apple's implementation, then an Ada compiler that outputs compilable C sources should do the job for you.
Fortunately, there is such an Ada compiler (or at least there used to be). AdaMagic at one point had C available as a "target". It is now sold by SofCheck. When last I saw a discussion of it years and years ago, they referred to it as a "service" as much as a compiler, so it may not be cheap. But if you have a real business need, it would certainly be cheaper than spending man-years rewriting a working app.
Your other option of course would be to say "Screw Apple and their facist OS", and shoot for Android instead. Sadly, for business reasons, that may not be feasible. :-(
Update (2016/2012): The assets of SofCheck have become available from AdaCore, as the two companies have merged in early 2012.
I want to be able to use this dictionary in an iOS app.
Well, if there is an Ada compiler that targets iOS -- and there probably is considering that GCC has an Ada front-end -- then re-using the packages should be straight-forward so long as the source isn't compiler- (for a different compiler) or architecture-specific.
The most experience I have with porting Ada to other architectures was to port some code I had compiling to the native machine to the JVM (there's an Ada compiler which targets the JVM); the "gotchas" were more along the line of the JVM's case-sensitivity interacting with Ada's case insensitivity for naming classes and packages.
As chip makers add new functions, instructions etc to new chips, do we need newer versions of the compilers accordingly to use those new instructions and features of the chip? Also does it mean that programming language also needs new opcodes,syntax etc to use the new features of the chip?
Yes, new hardware features are reflected in language extensions and in new languages. For example, see the various vector extensions for C and C++ that reflects the availability of SIMD instructions, and the new derived data-parallel languages like CUDA and OpenCL.
If the hardware is significantly different from the others, it is likely that it will require its own, different programming language, see the late Transputers and their Occam language.
Compilers that compile to machine code (not to a VM) might need to change any time its target architecture changes (although ideally all changes would be backward compatible, so that additions just mean there's new optimizations possible, but that old compilers would still work).
Programming languages don't need to change, but might if a desirable feature is made newly possible by a change in the machine's capabilities. Unless, by "programming languges" you mean assembly/machine language, in which case a one to one chip-instruction to assembly/machine instruction probably ought to be (but doesn't have to be) be added.
Notice all the "might"s. Chances are that these changes are invisible to you unless you're working in Assembly, Machine code, compiler design, or programming language design. If you're not, then worrying yourself about these things is a waste of your time.
This question is related to one of my others about C: What can you do in C without “std” includes? Are they part of “C,” or just libraries?
I've become curious lately as to what is really contained the the core Objective-C language, and what parts of the Objective-C I've done for iPhone/OS X development is specific to Apple platforms.
I know that things like syntax are the same, but for instance, is NSObject and its torrent of NS-subclasses actually part of "standard" Objective-C? Could I use them in, say, Windows?
What parts are universal for the most part, and what parts would I only find on an Apple platform?
If you want, giving an example of Objective-C used elsewhere as an example of what is more "universal" would help me as well.
Thanks! =)
There are only two current implementations of the core Objective-C libraries, previously known as the NextStep (hence NS prefixes) and OPENSTEP: GNUStep and Apple's OS X. On Linux, if you maintain compatibility with the OPENSTEP specification, GNUStep works very well. However, the specification is ancient, and modern code for OS X will likely not work correctly (especially in the UI area). The situation on Windows is even worse.
You can use the Objective-C language anywhere GCC supports the build target. The "NS" classes are not part of the language proper.
If you're trying to maintain compatibility across platforms in your code base, stick to C or C++, only move UI specific behavior to Objective-C.
Objective-c is C plus these keywords:
#interface, #implementation, #protocol, #end, #private, #protected, #public, #try,
#throw, #catch, #finally, #class, #selector, #encode, #"string", #synchronized,
#property, #synthesized
Plus the message sending syntax: [anObject aMessage];
EDIT
Given that you have an objective-c compiler such as GCC you still need an Objective-c runtime in order to make the above stuff work. e.g. [anObject aMessage] is actually compiled to
objc_msgSend( anObject, #selector(aMessage));
...therefore the symbol objc_msgSend is one of several that must exist at runtime. In theory this could be provided by a compiler intrinsic but in practice you are probably going to link to an Objective-c runtime library - a quick search of my hard drive shows i have three installed:- Apple's, GNUStep, and Cocotron - there are more but Apple's (open source) is without doubt the most important and influential.
With an Objective-c compiler and runtime - but without any Apple Objective-c frameworks (NSObject, etc.) - you have a fabulous and very useful C-with-Classses that is much simpler (where simpler means 'better for me') than C++.
You can a lot on Windows using Cocotron, which is a free implementation of Apple's frameworks. It's not complete, and you may run into bugs, but if you're lucky, you can compile your Xcode project as a Windows app without too many changes.
None of the class library is part of the language itself. If you want to see the core Objective-C types, look in include/objc. The core language itself, without any added library, is really scant and not particularly useful.
In practice, however, Objective-C is just about never used outside of the context of an OpenStep framework like Cocoa or GNUstep. So you could view that as the de facto standard library, in which case Foundation is almost universal. (Not 100% of Foundation is that way, but the majority is.)