Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!sun!pitstop!texsun!texbell!sw1e!uucibg From: uucibg@sw1e.UUCP (3929]) Newsgroups: comp.lang.c++ Subject: Re: objective c Message-ID: <1517@sw1e.UUCP> Date: 24 Apr 89 00:15:45 GMT References: <6590095@hplsla.HP.COM> <2240@mister-curious.sw.mcc.com> <820@ethz.UUCP> Reply-To: uucibg@sw1e.UUCP (Brian Gilstrap [5-3929]) Organization: Southwestern Bell Telephone Co Lines: 71 In article <820@ethz.UUCP> marti@ethz.UUCP (Robert Marti) writes: >In article <2240@mister-curious.sw.mcc.com>, loo@mister-curious.sw.mcc.com >(Joel Loo) writes on a comparative benchmark between C++ and Objective-C >presented by Jim Adcock: >> This is not a fair comparison. >Why not? If two programs accomplish the same task, surly this is a >fair comparison?! It all depends on what you're trying to measure. If you want to conclude that language A is better than language B, you'd better be willing to tack on "for the classe of problems meeting criterion: 1) .... 2) ....". Otherwise you're just revealing religious attitudes about languages. >> You might as well compare C with Lisp and publish similar figures. >Indeed. So what? I have compared a Modula-2 with a Lisp implementation >of an application which deals mostly with symbols (in the sense of Lisp) >and found that the Modula-2 implementation was faster than compiled Lisp >by a factor of at least 10. I can certainly believe this. Now, how easy would it be to enhance the Modula-2 version versus the Lisp version? Also, do you really feel that you have an extensive knowledge of the efficiency considerations for both languages? Did you tackle a problem truly well suited to only one of the languages? How much time did it take to write each version (and did you write one version first and therefore have a "leg up" on the second implementation?)? >> Programs in C++ are compiled into runnable codes similar to compiled >> codes of other compiler languages, most of its objectiveness is lost >> after compilation. >Again, so what? Lisp and Smalltalk-80 can be (and often are) compiled >into "codes similar to compiled codes of other compiler languages". >This is an implementation detail. C++ or C might just as well be >interpreted, but that won't make them any more object-oriented. "So what?" depends upon your needs. C++ loses some of the flexibility that Smalltalk-like languages keep (e.g sending an arbitrary message to an arbitrary object; I won't get into advantages/disadvantages here). Similarly, I understand that there Lisp OO implementations that give you runtime multiple inheritance. The question isn't "Which is better?" in my mind, it's "Which is better for the job at hand?", which can be a much more difficult question if you begin to worry about things like: 1) Who's going to use the thing? 2) Who's going to maintain/enhance the thing? (perhaps not everyone will be as skilled a programmer as you. This can be a real shocker when you are suddenly kept in the same job because you become 'indespensible'. If you want to advance in the workplace, you have to write for the least common denominator if you want to be free to go elsewhere within a company. Very bad for code sophistication but... but I digress) 3) How long do they (the powers that be) expect the thing to be needed? 4) How long do you think the thing will *really* hang around :-). 5) How quickly must modifications be available? 6) How soon must it be initially available? Etc.... >(I hope you don't consider this a flame :-) No. But remember that things get very complicated outside of the actual code development. >-- >Robert Marti Phone: +41 1 256 52 36 >Institut fur Informationssysteme >ETH-Zentrum CSNET/ARPA: marti%inf.ethz.ch@relay.cs.net >CH-8092 Zurich, Switzerland UUCP: ...uunet!mcvax!ethz!marti Brian R. Gilstrap Southwestern Bell Telephone One Bell Center Rm 17-G-4 ...!ames!killer!texbell!sw1e!uucibg St. Louis, MO 63101 ...!bellcore!texbell!sw1e!uucibg (314) 235-3929 ...!uunet!swbatl!sw1e!uucibg #include