Browsing Apple's documentation, I come across a tutorial for Objective C, the language that their core UI is written in. How... objective. It actually makes sense. Unlike C++. I can see where Java got some of its sanity from, Java looks sorta like Objective C with C++ syntactic sugar applied.
So why did C++ win out over Objective C, again? Oh wait, that's right, Microsoft decided they liked it better. And what Microsoft wants, Microsoft gets. Never give a Linux penguin an excuse to diss Microsoft, hmm?
-- Badtux the Linux Penguin
I never learned Objective-C. A decade of programming C++ has taught me the truth of that old saying, "C++ is an octopus made by nailing extra legs onto a dog." Except I wouldn't call C a dog: Actually ANSI C is one of the cleanest and most beautiful languages I've ever used. But C++ is a horrendous mess. It has exactly the kind of pointless complexity that MS loves.
ReplyDeleteMy first job was programming customized business applications on the NeXT "pizza boxes" which is where Apple acquired the foundation classes for their UI. The language allows you to do some cool things such as being able to add methods to classes that were in a library and to implement delegate methods which were a cleaner version of call back functions.
ReplyDeleteToo bad nobody took Obj-C seriously.
Actually, M$ ditched C++ fairly quickly when it realized it didn't wholly control it, switching to C#, which it did control.
ReplyDeleteBut my problem is with the whole notion of object orientation. One can spend... many have spent... a large fraction of the total budget of a project getting the object model just right, only to find that someone comes along (e.g., the guy who wasn't your boss when the project began, but is now) who has a different idea that shakes the foundation (pun intended) and requires a hasty rewrite of Every. Damned. Thing. down (up?) to the very root of the class hierarchy.
There are distinct virtues in taking a component approach, creating at least some degree of separation among the pieces so that one idiot's, um, manager's changes don't sink the whole effort.
Actually, Steve, M$ uses C++ for pretty much everything in its operating system, and if you want to write a "real" Windows program that uses the low-level API's directly, you still write it in C++.
ReplyDeleteC# arose because M$ hates Java, not because M$ hates C++. C# is their "better Java". Except it's not. I don't know of anybody but die-hard Microsofties who actually write programs in C#. I mean, Java exists, runs everywhere, is portable, so why use a language that ties you to M$ platforms forever? (Yeah yeah, I know about Mono, but get real, nobody writes Mono-compliant C#, every C# program out there is for M$'s platform and only M$'s platform).
Corner, I am in the process of reading the part of Apple's Objective C manual where they explain how to write classes. So far, so good. Looks sort of Java-ish thus far in that it only has single-inheritance. But if you are correct about adding methods to classes in a library, that makes it sound sort of Ruby-ish (Java isn't that dynamic). In Ruby you can even add methods to built-in classes, for example, I added modular exponentiation as a method to the built-in Int and BigInt classes in order to do a pure-Ruby Diffie-Hellman one day (note that Ruby auto-promotes from int to BigInt when you overflow, so adding it to both does the dirty deed). Was slow as a turd, but I didn't care because the handshake was done only once in a lifetime and if it took 45 seconds to do the handshake, so what, it beat having to link GMP into the program and deal with all the issues that bringing GMP and its finely-honed assembly language code bring when trying to write a cross-platform program...
-- Badtux the Geeky Penguin
Oh, regarding a component approach -- there is nothing preventing using both mechanisms. Over the past ten years I've architected a number of pieces of software. They tend to be highly component-oriented -- e.g., a CLI component talks to a server component which in turn fires up various service components as needed -- but the components themselves are generally quite object-oriented. Some things just "must" be objects if it's going to be done right. Such as, for example, a software license -- a software license and all the various methods to deal with it are an object that no amount of re-factoring of the program will ever make not-right.
ReplyDeleteI don't generally spend a lot of time finely honing an object heirarchy. I'm more interested in component data flow. The objects mostly fall out of that, because the objects end up representing pieces of data that are flowing between the components and all the various methods of operating upon that data.
-- Badtux the Architect Penguin
Alan, "C" is just a fancy assembly language for the PDP-11 processor. Pretty much every feature of "C" maps directly onto the PDP-11 assembly language, e.g., *s++ to walk down a string maps directly upon the PDP-11 auto-increment indirect addressing mode. The PDP-11 is a very clean architecture, thus why "C" is fairly clean.
ReplyDeleteYeah, I have the PDP-11 architecture manual somewhere...
"Oh, regarding a component approach -- there is nothing preventing using both mechanisms."
ReplyDeleteOf course. The last big s/w I worked on had all its critical code, including a queue manager that sat at the center of everything, inside components... each of which was fairly strictly object-oriented internally. But we never changed the object models of those components, other than to add new visible functionality by adding public methods. Changes to the whole, um, I'm running out of words that haven't been already co-opted... contraption? ... we made at the component level. I understand from my former client that a newer version of that s/w is still in use several years later.