Objective C : Excelent Post!

http://www.oreillynet.com/pub/a/mac/2001/05/04/cocoa.html?page=3

Great post! I totally agree!

dead language revival?
2001-11-30 12:07:02 eepstein [Reply | View]

1. ObjC is not strongly typed. Yup. Thank goodness! You can do type enforcing in Obj-C (indeed that's the recommended approach for most APIs), but you don't have to. That means a simple revolution: software that is MODELLING the real world, remains software: that is, flexible. In C++ (and to a less extent in Java) you are wed to a class hierarchy once it's been created. In Obj-C you are not. You can have Rectangle objects in the same list as Elephant objects and still get ALL the functionality of each object instance (without knowing a-priori the object's type and doing a cast) AND you can still treat all objects generally -- invoking say, a -size method on all objects in the list. I.e., a software model remains a software model: fluid, not rigid. One other "feature" of strongly typed languages: they assume the programmer is stupid and terribly error prone and so programmers are not allowed to do anything beyong the limits of types. This is often a self-fulfilling prophecy: producing bad programmers. Weakly typed means you get the warnings if you want, but you don't have to fight with the language and build endless case or if-then-else statements to cast an object "back" to the type it already is. In short: the language never forgot the type of the object. Not so in C++. (In Java this is remembered, but -- at least before reflection was added -- the language won't tell you.)

5. Not so. Because the language is dynamic, it is actually faster. YES. Believe it or not, if you are doing any sort of non-embedded system Obj-C will be faster than C++. (remember, C++ was designed for light-weight hardware level programming to control the switches of a telephone network). Why? Because all GUI and database-driven applications end up having to implement a much weaker version of dynamism in code and this turns out to be slow. Take a simple example: the GUI "callback". A button is clicked and your application gets a call-back. Leaving aside the fact that this is actually a proceduraly hang-over from C and is NOT O-O in any way at all, let's just look at performance. The call-back's first job is to figure out what UI component (button, say) got clicked. That takes 2 things: code and processing time. The time to figure that out is more than it takes to do a simple method invocation in Obj-C. Moreover in Obj-C you have a true O-O language so you don't write procedural call-backs. The button has a settable target (ANY object, remember that weakly typed feature!) and a settable METHOD! (yes, any method on ANY object that has a signature of taking one parameter). In terms of code, you didn't have to write any. In terms of speed for a UI with 100 components you have an O(1) implementation in Obj-C -- add as many components as you like, the target-action paradigm means: one event, one function call. That's it. In C++ (and for that matter the way that Swing is built, uggh!) you have an O(N) problem : on average you evaluate 50 if-then-else statements per call-back. And you had to write the code. Dumb. Oh yes, and slow. Oh, and by the way, you have the same problem when fetching from DBs (it's what still sucks about EJBs : they are really slow). Having said all that, UIs in C++ don't appear slow. Let's put it in perspective: compared to the speed of a mouse click, or a round-trip to a DB, interpreted Perl is fast, so it's not like we run into a speed problem. And Obj-C is clever about the nominal per method overhead, it caches the methods as they are used. With "warmed up caches" a method invocation is about equivalent to 1.7 function calls. (On the first hit, before a method is cached it's about 2.5 function calls). I.e., negligible. Where speed matters, like writing an embedded Fast-Fourier Transform, you're going to do it in assembler.

So #5 is not only a non-issue in Obj-C it's a non-issue. With GHz chips the issue is development time, amount of code, maintenance, etc. I've been a developer for 16 years. 10 years ago I got religion with Obj-C. I since found myself writing C++ code for 3 years because that's what the non-technical decision makers at various clients had decided upon. (Hey, marketing does work.) The experience there is common industry-wide: without an object hierarchy everyone rolls their own. This re-invention of the wheel means the promise of component re-use is almost never realized. Without dynamism everyone implements a makeshift version of it: every class in C++ ends up having a "className()" or "get_class_name()" method tacked onto it.