David Chisnall takes a look behind the scenes at Apple’s upcoming revamp of the Objective-C language. As with any new language, some things are good, some are ugly, and some are both.
Behind the Scenes of Objective-C 2.0
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This will most likely have a bright future, i myself know that ill use it and i think many resons in my manner.
Looks interesting. I’m not a fan of C or C++ nor will I love this, but it does seem like something that I should at least check-out. My biggest question is Apple going to create a standard for it or let the implementation define the standard (like Perl < 6). If so is the standard going to be published, publicly, without fee, or patent worries?
Objective-C is the zombie of the C derived languages. It was a bad idea to start with, based on Brad’s naive notion of “software ICs” and not Smalltalk as this article claims.
Whatever Apple does will create a standard for Objective-C, because the only real users for the language are the poor souls stuck having to use it to develop for OS/X.
Whatever Apple does will create a standard for Objective-C, because the only real users for the language are the poor souls stuck having to use it to develop for OS/X.
This is nonsense. Do you know how many source lines of code (SLOC) OpenGroupware.org have?
And OpenGroupware.org is all written in Objective C, as you can find out here: http://opengroupware.org/en/about/ — It is also to be installed on Linux, Solaris, Windows, and Mac OS, as you can see here: http://opengroupware.org/en/install/
And OGo is not even close to the only big objective C codebase.
I think the real question here was along the lines of whether Objective-C was going to be submitted to ECMA the way C# was, or remain a non-committee, non-reviewed language with no solid application outside OS X.
…or remain a non-committee, non-reviewed language with no solid application outside OS X.
So OpenGroupware.org is not a solid application? Please read the comment before replying.
Edited 2006-11-06 01:42
Really? Those “poor souls” seem to like using Obj-C. I know my friend who does OSX programming (and NeXT before that) swears by it.
You might not like it but a lot of other people do.
From wikipedia:
Objective-C is a very “thin” layer on top of C. Objective-C is a strict superset of C. That is, it is possible to compile any C program with an Objective-C compiler. Objective-C derives its syntax from both C and Smalltalk. Most of the syntax (including preprocessing, expressions, function declarations and function calls) is inherited from C, while the syntax for object-oriented features was created to enable Smalltalk-style message passing.
The syntax of Objective-C has about one thing that’s similar to the syntax of Smalltalk. It is a single-inheritance message-based language and has that in common with Smalltalk, but it’s really more of C with a simple object system bolted onto the side that looks completely alien from both the C and Smalltalk perspective. All of the mediocrity of programming with C with less than half of what’s interesting about any Smalltalk environment. Now with garbage collection and foreach!
the only real users for the language are the poor souls stuck having to use it to develop for OS/X.
You can develop for OS/X using C++ and Qt. There’s nothing in Apple’s user interface guidelines that demands the use of a particular language or framework. Qt gives you the ability to easily write an OSX application with a truly native look and feel.
C ==> Carbon
ObjC ==> Cocoa
C++ ==> Qt
Qt/Mac is actually a wrapper around Carbon, and unlike Cocoa and Carbon, you have to pay a four-figure sum (per developer) to build commercial applications with it.
In my own experience, there are two big problems with Qt as a platform for serious Mac applications. One is that Qt apps don’t behave like normal Mac apps: for example, the menu bar is tied to the main window, and if you shut the window, the application dies. Cocoa and (normal) Carbon applications don’t behave like that. It doesn’t use all the Carbon widgets either, although this has improved in recent years (supporting drawers and sheets, for example).
Second, I’ve found that there are speed deficits. Widgets take about a second to “awaken” after you raise a Qt window on the Mac – they don’t on normal Mac apps – and certain classes are sluggish, notably the text editor widget class when you write a few paragraphs with it.
Much as I love its API and I think it’s fantastic on X11 and Windows, if you’re looking mainly to develop Mac apps you should give Qt a miss.
Much as I love its API and I think it’s fantastic on X11 and Windows, if you’re looking mainly to develop Mac apps you should give Qt a miss.
Qt is probably the best toolkit available if you want to do crossplatform programming in C++.
Your only other option is Java, which can look native when you use SWT or a proper look and feel like Quaqua. However, Java isn’t suitable for tiny applications due to the overhead it introduces.
Edited 2006-11-06 15:37
<em>…you have to pay a four-figure sum (per developer) to build commercial applications with it.</em>
s a professional Qt consultant, I can say from direct experience as a Qt consultant that this isn’t an issue for professional developers. Shareware developers quibble about it, but they don’t count. If you’re making six figures for your software, a four figure price is peanuts.
And it’s also available Open Source, so if you’re only making three figures a year on your software, deduct your failed business attempt on your taxes and go Open Source yourself.
<em>One is that Qt apps don’t behave like normal Mac apps…</em>
Most people can’t tell the difference. In fact, many rabid Mac advocates can’t tell the difference either unless they’re specifically looking for it. What most people see as un-Mac-ness are merely Windows/Qt programs ported to Mac/Qt with no additional work. And it’s certainly a heck of a lot closer in look and feel that Java/SWT!
Of course it’s not perfect. Since it isn’t pure Cocoa, it doesn’t feel like pure Cocoa. But so what? Users don’t care about little stuff like this. Over in the Windows world Microsoft can’t even manage to get .NET apps to look like Windows apps, but no one cares.
One is that Qt apps don’t behave like normal Mac apps: for example, the menu bar is tied to the main window, and if you shut the window, the application dies.
Not true with Qt 4 – you can have a QMenuBar without a window.
Widgets take about a second to “awaken” after you raise a Qt window on the Mac – they don’t on normal Mac apps – and certain classes are sluggish, notably the text editor widget class when you write a few paragraphs with it.
Have you used Qt 4.1 or later?
BTW: I wouldn’t call Qt a “wrapper” as such around Carbon. Instead, it uses the “Carbon” / low-level system APIs to interface with the Mac OS. Cocoa, which is another high-level toolkit also has to use many of the same APIs underneath.
I too get frustrated when Qt widgets don’t minic Cocoa properly, but they’re definitely getting better! Speed is also no longer a concern either.
Objective-C is the zombie of the C derived languages. It was a bad idea to start with, based on Brad’s naive notion of “software ICs” and not Smalltalk as this article claims.
Yes, Brad’s original idea was to promote software ICs — but that does not mean it’s not *heavily* influenced by Smalltalk, come on 🙂 — it’s quite obvious it is. It shares the same concepts of what OOP should be, it’s dynamic, classes are objects, it sends messages (and has the equivalent of the doesNotUnderstand), even share the “in-message” paramaters syntax.
Objective-C is the simplest modification of C to add _proper_ object orientation, modelled after the Smalltalk paradigm. Much, much better than C++ 😉 and extremely far from “a bad idea”, to the contrary.
Whatever Apple does will create a standard for Objective-C, because the only real users for the language are the poor souls stuck having to use it to develop for OS/X.
I guess GNUstep ( http://www.gnustep.org ), the free, cross-platform OpenStep implementation, OpenGroupware.org ( http://www.opengroupware.org ), Swarm ( http://www.swarm.org ), Étoilé ( http://www.etoile-project.org/ ), etc. … in fact only exist in my mind then.
Edited 2006-11-06 13:16
Objective-C is the simplest modification of C to add _proper_ object orientation, modelled after the Smalltalk paradigm. Much, much better than C++ 😉 and extremely far from “a bad idea”, to the contrary.
I argued with Brad about this at the time and no one has convinced me differently since: The primary basis of SmallTalk as an object oriented system is that every “thing” is an object.
Objective-C fails rather completely as a proper object oriented system on that basic criteria.
It grafts the less important aspects of object-orientation onto C without making the language an object oriented language. (C++ has the same failing as an OO language.)
The primary basis of SmallTalk as an object oriented system is that every “thing” is an object.
Objective-C fails rather completely as a proper object oriented system on that basic criteria.
Academically, yes, I would agree with you. Objective-C is a compromise language: it’s not as beautiful or clean as Smalltalk, but it lets you work properly with existing C code, is dynamic, and fairly fast (and can be as fast as needed by using C methods/caching imp). Certainly it’s a very useful language. Beside, one of the great thing with Objective-C is, strangely enough, the OpenStep framework (Cocoa or GNUstep). Between developing a gui application in Smalltalk and in Objective-C, I will take Objective-C + OpenStep every day, even if, as a language, I prefer Smalltalk. But my point is, while Objective-C is not as nice as Smalltalk, it’s the next best thing if you want to use C.
It grafts the less important aspects of object-orientation onto C without making the language an object oriented language. (C++ has the same failing as an OO language.)
Less important aspects ??? To the contrary, it embodies all the important ones 🙂 — particularly, it considers objects as “living entities” sending/receiving messages. To me, it’s much more important to have a dynamic language with introspection/reflexion than having everything as objects. Don’t get me wrong — I agree with you, having everything as objects is wonderful, and extremely handy (and actually impact the introspection capacities, of course). But I’m very happy with the compromise Objective-C reached.
Edited 2006-11-06 19:53
The primary basis of SmallTalk as an object oriented system is that every “thing” is an object.
I understand that you’d prefer a complete “everything is an object” language but please tell me one thing…
– How can a superset of C (an ESSENTIAL aspect of ObjC) could treat everything as an object ?
The primary basis of SmallTalk as an object oriented system is that every “thing” is an object.
I understand that you’d prefer a complete “everything is an object” language but please tell me one thing…
– How can a superset of C (an ESSENTIAL aspect of ObjC) could treat everything as an object ?
It can’t, which is why Objective-C can’t really be described as derived from SmallTalk.
Hey, I know you…
You’re our french Objective-C specialist, tight ?
I would mod you up I you didn’t reach 5…..
Just to wanted to thank you as you made me discover ObjC, NeXT… in your article in Linux mag FR few years ago …..
Thank you !!!
Just to wanted to thank you as you made me discover ObjC, NeXT… in your article in Linux mag FR few years ago …..
Thanks, happy to see someone that liked the articles 😉
Edited 2006-11-07 17:25
Whatever Apple does will create a standard for Objective-C, because the only real users for the language are the poor souls stuck having to use it to develop for OS/X.
Nothing special within Obj-C, but the Cocoa Framework is. You should read “Cocoa Programming for Mac OS X” by Aaron Hillegass to know how great Cocoa Framework is.
Here we are again, talking about yet another language that tries to be ST like.
Just use ST!
Squeak is a damn good ST system, download it and give it a try – http://www.squeak.org/
Also, take a look at what Sun has done with StrongTalk
http://strongtalk.org/index.html
Here we are again, talking about yet another language that tries to be ST like.
Just use ST!
Objective-C is not a “new” language. It has the nice advantage over Smalltalk of beeing a strict superset of C — therefore it’s damn easy to integrate or reuse C (or C++) code with Objective-C. And create components. And be fast.
Beside, you’re talking about Squeak, which I happened to like *a lot*
but still, it’s not the panacea, in particular for developping desktop applications (I know, there’s the WxWorks bridge..), Objective-C with Cocoa+InterfaceBuilder (or GNUstep+Gorm on the rest of the world) is _so much_ better for that task…
Give me a working bridge between Squeak and the Objective-C runtime (so we could transparently use Cocoa/GNUstep from Squeak) and things will be different (to be fair there is an existing Squeak/Cocoa bridge, but callbacks aren’t possible, hence making it nearly useless, sadly).
If you want to use Smalltalk, Ambrai is coming out with that.
If you want to use Smalltalk, Ambrai is coming out with that.
Ambrai uses Carbon.. bof.
This may be a long shot, but…
Is there a decent IDE/Compiler for Obj-C for Windows? It doesn’t even need to produce Mac readable binaries, though that would be a nice plus…
::Disclaimer:: I’m 100% .Net, but looking to broaden my horizons a bit.
jGrasp is the only IDE I know that works for it, outside of the NeXT/Apple tools. jGrasp runs on any Java-enabled platform, meeting the requirements, of course. Combine that with gcc to complete the environment.
I’m not sure why people are against Objective-C. It’s quite nice and allows convenient syntax combining Smalltalk’s idealism and C’s directness.
C++ is on its way to becoming another Ada and Smalltalk is needy when it comes to execution. It seems as though Objective-C and Java have a lot to offer.
By the way, doesn’t gnustep count as an example of Objective-C development anymore?
It’s quite nice and allows convenient syntax combining Smalltalk’s idealism and C’s directness.
Now if that isn’t a statement that skirts around every possible concrete issue!
Idealism? Well I have no idea what that was meant to mean, but Objective-C does not embody the simplicity of Smalltalk, the purity of Smalltalk, or even the interesting design methodology of Smalltalk.
Objective-C wishes it was as dead as C++, becuase then you could at least put it into the same sentence as Java without looking ridiculous.
MinGW and Cygwin both provide an Objective-C compiler for win32. You can you any number of ide’s that work with either of those. Codeblocks and Dev-C++ come to mind, but there’s probably several more that i’m not aware of.
Besides GCC there’s also POC, but I don’t know if David Stes still develops it, and it is not compatible with NeXT’s extensions to Objective-C AFAIR.
Finding anything resembling a decent IDE for fringe languages is never easy. If you want to dick around with something you could always download the trial of Dolphin Smalltalk–it won’t do much to broaden your horizons to the Mac world, but it would hardly be the worst use of curiosity and spare time.
Now I really feel iffy about this feature, unless Apple stipulates single inheritance for class/concrete protocol (In which case it will be equivalent to Java’s Abstract class).
The thing is, if you are allowed to inherit more than 1 class/concrete protocol, then you run the risk of running into the infamous diamond problem.
This is used in languages like Scala (where it’s called a “trait”), and there was talk of using it in C#.
Basically, think of it as a partially implemented interface. Implementations cannot refer to any variables, they can only refer to things declared in the interface itself (i.e. methods and properties). This helps avoid the diamond problem that occurs with traditional multiple inheritance.
As it turns out, this is a good thing. When a framework designer is creating an interface, they have to accommodate two groups, those who have to implement the interface (who will want the minimum number of methods) and those who will use the interface (who will want a lot of convenience methods). Traits (aka partially implemented interfaces, aka concrete protocols) help provide this: consider this hypothetical declaration of a list interface
public interface IList<T> {
public int numElements
{ get;
set;
}
public T this (int pos)
{ get;
set;
}
public void addElement (T item);
public void removeElement (T item);
public boolean isEmpty()
{ return numElements == 0;
}
}
This provides the useful isEmpty() method for interface users while relieving interface implementators of the job of implementing this (though they may if they want).
As regards the issue of multiple competing implementations, as far as I know, Scala uses the implementation in the last interface in the list.
Note, as far as I know, C# 3 will not support this and I’m pretty convinced I’ve made more mistakes, C# not being a language in which I’m 100% fluent.
Edited 2006-11-06 17:40