Article:  |
The Objective-C Language | |
| Subject: | dead language revival? | |
| Date: | 2001-10-20 16:22:50 | |
| From: | lookaround | |
|
It's nice to see ObjC coming to the scene again. I considered this language dead. Nobody except Apple actually supports it. And it doesn't seem to be easy for Apple. Look how long it took them to make anything new like Cocoa. I think they've been making it since NeXT project ceased.
|
||
Showing messages 1 through 4 of 4.
-
dead language revival?
2001-11-30 12:47:51 eepstein [Reply | View]
-
dead language revival?
2002-10-23 12:06:43 anonymous2 [Reply | View]
The "old" language of Objective-C is slow? Heh, I can see somebody hasn't worked much with the nice "modern" C# language. Intel had better keep pushing up those clock speeds, because Microsoft is going to need the horsepower one heck of a lot more than Macs!
-
dead language revival?
2001-11-30 12:07:02 eepstein [Reply | View]
I too find this to be a bit on the flame-bait side, but as it re-raises a number of inaccuracies, I'll reply in the hope of addressing these.
First, support. To begin with, that's not true. The GNU compile, yes the one that runs on all Linux boxes and is used by just about everyone porting anything from Un*x to W*ndows, supports Objective-C. But further, let's look at languages. C and C++ came from Bell Labs. As part of the governement granted monopoly to AT&T all Bell Labs inventions (like the transistor) were in the public domain. The original author of Obj-C was still following the proprietary software model as the software market was shaking out it never made as main-stream a splash as C++. Sun was quite smart with Java: they gave it away for free -- as they knew that the days of paying for languages was likely over.
Paragraph 2 is pure flame bait and I'll instead try to address what ar actually very interesting questions that are listed by you as answers.
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.
-
dead language revival?
2001-11-20 11:38:08 gctwnl [Reply | View]
This message is flame bait, but for the people new to Obj-C let me put a few things straight.
1. This is false. Obj-C can be used both strongly typed and weakly typed. A better way to look at this is that Obj-C has both compile-time typing (what you call strong) and run-time typing (dynamic). Take your pick, for some OO-approaches only dynamic typing is feasible.
2. The best data protection is in your head. But aside from that, I cannot easily access the members of a class, they are private. As far as 'protection' goes in a programming environment this is equal to the 'private' members in C++.
3. A matter of taste, but in my (and many other's) opinion, Obj-C is far more elegant than C++. It is also a fundamentally better paradigm than C++ in the sense that even classes are objects in their own right. It is not just OO, but even it's OO is OO (and not, as in C++ 'grafted on'). You experience the difference when you want to do really dynamic stuff.
4. This is somewhat true. But we were talking about Mac Dev, right? (I think that there is a decent foundation framework as part of GNUStep btw).
5. This is absolutely false. Obj-C is not slow at all. First, all the really dynamic stuff is cached, and secondly, for the stuff where you really need speed (a lot of calculations for instance) you will do that in C, after all Obj-C is a superset. It is stupid to write a large calculation using messaging. On Mac OS X, you can even combine C++ and Obj-C (Obj-C++).
The phrase 'industrial strength' is somewhat misleading unless you talk marketing instead of technology.
And lastly: large projects do not suffer from whatever language you choose. You can build beautiful OO programs in just CC. It's a method, not a language.
Programming languages evolve over time. For example, data protection was added to Obj-C in a fashion that borrows the idea from C++. And reflection was added to Java allowing dynamic hooks into the runtime in a fashion similar to Obj-C.
In the hope of exploring what makes for better languages, I want to propose turning your criticisms into questions:
1. ObjC is not strongly typed language.
Q: What are the advantages and disadvantages of both strongly and weakly typed languages? What about a mixed-language that allows compile-time type checking while being lenient about enforcement?
2. ObjC does not support data protection.
Q: What are the uses of data protection? Instance-variable and method levels of protection? Should this be a language feature or something that can be easily implemented within the language?
3. ObjC has horrible syntax.
-- A matter of opinion, and I partly agree. The question: "What are good syntaxes?" seems contrived. Instead I'll just say that as syntax is often a barrier to learning a language, and as some are easier to learn than others, we may wonder: What qualities should be sought in a language's syntax? I for one think that if a general syntax for most O-O technologies could be developed that would be a big help. The syntax of Java seems to be the fore-runner.
4. ObjC development framework is very poor (except on Mac platforms). No standard framework exists.
The need for multi-vendor support. I'm increasingly a fan of open-source. So maybe that's a criteria: that you can get a standard development package as open-source.
5. ObjC is pure dynamical like SmallTalk. Thus it’s extremely slow
Q5a: What are the advantages and disadavantages of a dynamic languages.
Q5b: How should speed/performance be measured? What about measuring the actual time to do real-world execution, i.e., measure the system performance. In that context is a nominal (.7) overhead at the invocation level an issue?
And I'd like to add a different question as well. One of the ways I like to think of languages/compilers is in terms of information. When one write code (be it in C++, Java, Obj-C, or any other language) much of the information is the design of the class hierarchies: their interelation, their names, what methods they have, etc. This information is the real intelligence of the system's design. If we look at a C++ compiler and compare the input to the output what we see is a great loss of information. After compiling a class "knows" nothing about itself. There's no way to ask for even the most basic information, like what's the name of the class or it's parent(s). (I understand that as of 5 years ago there was a push to correct much of this, so it might be dated. The issue here isn't a slight on one language or another, per se, but a comparison of features and values to see what collectively might be the best parts of diverse langauges.) So (again, as of 5 years ago) you were stuck writing silly little "getClassName()" methods that made available (usually via a hard-coded string of char) the information you'd just typed into your editor when defining the class. What this means, in short, is that the compiler loses a lot of information.
So the rule that I started to develop when looking at languages had to do with the basic question: how much information am I putting into my code that I'm not getting out from the compiler? For a procedural language this doesn't matter so much. In an O-O language, this type of information is generally very useful. And if, you want the power of a dynamic language this information is essential. At the end of the day I find that one does have good need of this "meta-information" and that access to it makes a language trully powerful.
I imagine this chain of discussion is as good as dead, but these long-un-experssed thoughts have been triggered by your comments. Thanks for that and perhaps if this is read it might start a fruitful discussion.