About Objective-C, vs. C++, and Java

Posted By: Andy
Date: 2-Jun-2001 11:37 a.m.

In Response To: Re: Objective-C? (Graham Fair)

Objective C is NOT C++ and learning C++ is not the way to learn objective C, mainly because C++ is very much harder than obj-C, and has a set of intrinsic problems (the fragile class issues, and also some very ugly problems in overloaded operator types if you get into that) which obj-C doesn't share.

The really BIG difference between the two is that obj-C uses runtime-binding for objects, where C++ does this statically at compile time. This gives C++ a slight performance edge, at the price of terrible problems when class structures are extended or modified. In this case everything needs to be recompiled. This makes it extremely difficult to maintain application consistency with systemwide object models. Various Unix methods attempt to deal with this, primarily by having libraries have revision numbers etc... which means that you have huge bloated sets of libraries hanging around because apps compiled at different times need different revisions... and then when the libraries start to reference each other .... you get the picture. In C++ there is no way to make an incremental change to much of anything without recompiling EVERYTHING or living with a mess and perpetual subtle bugs.

Java is nothing more than a small, and rather limited, semantic variant of obj-C (using run-time binding almost identical to obj-C's), which (almost always) uses a virtual machine implementation, has "garbage collection," and of course an attempt at a universal cross-platform API model ... which isn't very universal for a variety of reasons not confined to the MS efforts to make it either Wincentric or useless.

If you know Java you have a big leg up to understand obj-C and vice versa.

Obj-C will always have a HUGE performance edge over Java, for a whole variety of reasons, but here are the biggies:

* right now virtually all Java implementations use Virtual Machines running the portable J-codes. There is no intrinsic reason Java can't be "fully compiled" (at which point it truly becomes a limited semantic variant of obj-C) and there are some true compilers available... but the big "selling point" of Java is x-platform use, and for that people want the J-code output. Even with the best dynamic recompilation VMs (e.g. "Hotspot") Java is slow compared to obj-C.

* garbage collection: while a convenience to the programmer, garbage collection eats performance and makes critical-latency issues never-solvable. In Java there is no way to guarantee what the state of the memory collection is. This is in part inevitable in cross-platform, many-different VMs, environment.

* Java doesn't contain ANSI-C; obj-C (and C++) do. Object-oriented programming isn't the solution to every problem. Pure numerical high-performance algorithms SHOULDN'T be object oriented. At present Java doesn't support any floating-point type except double... this alone is a serious hit in many applications. Java 2-D (and greater) matrices are just rows of 1-D vectors referenced by pointer. This indirection SLAYS writing high performance matrix algebra (even if truly compiled). Java doesn't contain any of the standard C speed-tools like registering variables ... let alone the ability to inline assembly when you want to (this of course defeats the whole purpose of x-platform portable code, but if you need speed, it can sometimes buy you alot). Finally the stack-oriented nature of J-code makes it very hard for down-stream optimizers, and causes a fairly serious performance hit. IMO, the biggest thing wrong with Java is that it's J-codes are stack-oriented... a register-oriented portable duple or tuple-code would allow much more efficient code generation at much less overhead on "real" CPUs. The stack-oriented J-codes are a legacy of the fact that Java was originally built with the goal of being scalable downto very limited "toaster oven" CPUs. This hasn't been the reality.

Good objective-oriented programs use object methods for the highest level and most complex synthesis of the program, and to maintain code reuse and extention... but use plain old "crank it, buddy" performance C to do computationally intensive tasks down under. In obj-C (or C++) you are free to do this. The object-oriented code simply becomes a "wrapper" for low-level numerics you want to shield the high-level interfaces from needing to know anything about. The only issue sometimes is that to get performance you need data-structures which aren't "what the obj-code wants." That's life... when you need performance you need performance ... and you make the data structures what achieves that and then figure out how to live with it.

Java is too limiting and restrictive; the ONLY way you can do anything is the object-oriented way ... and this means that large numbers of objects are getting created (and then destroyed) sometimes to do very simple things from a numerical-programmer's POV. All of this creates speed and memory-killing overhead ... compounded by the fact that objects are only destroyed in Java by background garbage collection. Java is just too "object purist." It has some good ideas but carried to the point of zealot extremism, if you are interested in dealing with very large programs, with intensive numerics.

Unlike Graham, I have NO fear that Apple will kill the obj-C interfaces for Cocoa. Apple may kill obj-C interfaces for WebObjects... that's different. I think Graham is confusing the two.

The whole Quartz API model is obj-C, as are all of the other osX (i.e. NexT) APIs. It doesn't cost Apple much of anything to maintain the obj-C interfaces, and killing these interfaces would kill the OS.

The whole gaga "java is going to rule everything" is over. Reality has set in. Imagine building MacOS itself in Java ... done rolling on the floor in laughter? Mach, BSD, Darwin etc are built largely in relatively pure C. osX itself is built in obj-C.

obj-C is a widely available language: gcc supports it. It isn't going to go away. Whether you want to learn it or not is up to you... but if you are going to program for the Mac it is definately the way to go.

Finally, MS is out there with C#. Java is going to have the fight of its life on its hands with C#. If C# came from anywhere but MS I would be a proponent of C#, because it has the potential to solve some of Java's limitations. But I coming from MS I expect it to be nothing more than another MS nightmare.

But guess what? C# is just another minor variant of obj-C semantically ... just that instead of depending on J-codes and runtime VMs it produces a register-oriented duple-code (good idea, or at least much better than stack-oriented) with the intent that local compilers produce true compiled executables, rather than use a VM (you could use a VM to run C#, and for some "apple" kinds of purposes (like simple browser plugins) it would be advantageous).

This is not a new idea in concept... it has been around for a long time, and a great deal is known about the various issues involved in this. Any open-source advocate sneers at this with the response: "gee, why not just let people compile the source..." source is portable, and will yield better optimization and many other benefits. This is true in part (the problem is API model compatibility) but obviously NOT what MS wants. From the MS perspective (the commercial-software-you-are-our-slave-including-your-first-born-child perspective) the whole POINT of an intermediate language/code is that the original code is significantly obfuscated. But in consequence the on-platform compilation can only do very local optimization ... more global optimization (easy if you have the source) then requires a very complex data-flow and reverse engineering analysis to recover the information needed for better optimization (or alternatively dynamic analysis during "watched" execution ... i.e. dynamic recompilation).

What MS is depending on is that it will tune its own C# code generators and subsequent compilers so that they will depend on conventions (and even subtle internal "hints" which will not be evident on inspection) so that C# code generated and then target-compiled with MS will substantially outperform open implementations of same. This will then be used to extend the MS dominance and stick it to Sun and the Java crowd.

The unix open-source crowd is watching C# with a great deal of anxiety and debate about whether to support it, or attempt to ignore it. The answer isn't in yet. But whatever happens the whole Java movement will like fragment (just as is MS's primary goal) into Java and C# camps ... and there is going to be another big epoch of churning incompatibility.

You may note that Apple has made no statement on C# whatsoever. This is smart. Wait until the fat lady sings, and then takes a bow. Then decide whether you want to clap.

Messages in This Thread

| View Thread | Return to Index | Read Prev Msg | Read Next Msg |


Please Note: SPAM (junk mail, advertisements, etc.) of any kind will be immediately deleted and offenders will be barred from further postings. In the same vein, this is not the place to post Web site announcements, press releases, or anything of that nature -- that is what our news pages are for. Please keep your comments limited to the topic of this particular story. If you would like to comment on another topic please use our General Forum area. This forum will be active for seven days, at which time it will become read only -- please continue your discussion in the General Forum area.