Re: Georg looks at that Georg! ;-)
Re: Georg looks at that Georg! ;-)
- Subject: Re: Georg looks at that Georg! ;-)
- From: Georg Tuparev <email@hidden>
- Date: Mon, 3 Mar 2003 23:56:27 +0100
Pascal & others,
I had really great fun reading all these replays. I really did so!
I do not want to start yet another language war - we had enough
battles in the past. Just would like to clear some misconceptions and
replay several questions.
0. Please repeat slowly after me: C++ is not an Object-Oriented
language! C++ is not an Object-Oriented language! C++ is not an
Object-Oriented language!....
This reminds me on a talk Simson Garfinkel gave on OO languages at
OOCNS'94. He called C++ the "assembler of the nineties". Boy, I never
seen so many pissed off faces. Great fun ;-)
I am not saying that being the "assembler of the nineties" is a bad
thing. Love is also not object-oriented (though at least two objects
has to be involved), but few will claim it is a bad thing. So, if you
are making case studies on performance (or anything), please compare
similar things. I would be very interested on comparing ObjC with
Smalltalk or Self, but I would not spend any time studying performance
of ObjC vs. Assembler or C++ because they are not in the same category.
1. When talking about performance most people star counting
milliseconds. My definition is very different one:
- The time and human resources to finish a software project, and
- the end product runs fast enough so that the users are happy.
Nine out of ten people who tried both languages will tell you that ObjC
"performs" better for the first criteria, and both languages are good
enough for the second. Actually, I strongly believe that good design is
extremely important performance factor, and it is soooo much simpler to
produce good ObjC design.
2. Although C++ shows some impressive results on its own, there are
many suggestions that this is not always the case when one stars mixing
it with Altivec, OpenGL, etc.
On Monday, Mar 3, 2003, at 14:23 Europe/Amsterdam, Pascal Goguey wrote:
[C++ explanations are happily removed]
--------------------
Now a few comments on your reply:
On Sunday, Mar 2, 2003, at 19:31 Asia/Tokyo, Georg Tuparev wrote:
1. Because it is very bad design practice to surround static data
structures with objects.
Where did you get this "rule" from? I mean, is there a computer science
theory that proves it or is it your taste? And why is it bad design?
I am ready to believe you, but you have to prove why it is
inefficient, why
it takes space in memory and how much, etc... You have to prove it
for Obj-C of course, because I proved it is wrong for C++.
The closest published materials I know are Kent Beck's best practices
in Smalltalk. and Martin Fowler's Analysis patterns. But again, it is
matter of granularity. Once you wrote about a million of lines in any
OO language you will learn that in most cases 100 lines class just
fills better then 10 lines class. Although this is not an absolute rule
(Simon gives an example where Point might be a valid class), having
many tiny classes just adds extra design complexity [remember, one can
always write a #define macro that makes the access of the Point
structure compact and elegant].
It is like 95% of all text books giving class inheritance examples
like Mammal->Cat->Tiger.
Then the students are let into the real life and start creating
separate classes for each of the
4 500 000 or so species. As absurd as it may sound there are many
frameworks/applications
out there based on this insane design principle. Over 50% of all
Talignet classes and the
Java exception handling are prominent examples ...
2. Because it is slow and inefficient.
Back to the NSPoint example:
How slow would it be? 15% slower? Speed divided by 2? By 10000?
Did you write a small test program before saying it is slow?
It depends on what you would like to achieve. But I think many already
explained that C++ has no dispatched method calls (just staticly linked
function calls - in many cases converted by the compiler to inline
functions).
Imagine you are writing a protein modeling program with millions of
vectors
(chemical bonds) and billions of points (electron density clouds). If
each vector
and dot is an object, you will need gigabytes of ram just to run the
program.
How many people are writing protein modeling or nuclear
simulation programs on MacOS? As it is a computer with fair media
capabilities, the worst case you can have is a few video streams
at 30 fps each.
I have proved that you can assign values for 100 millions points,
(which must
be in the order of computation of a few frames of video) within
the exact same time and it uses the exact same memory so what are you
using your "Gigabytes of ram" for? Just curious...
Wrong. Even for the simplest things like edge smoothing, convolution,
image filters etc. you will need many additional CPU cycles. This is a
perfect example where fast assignment along will not help. Good and
simple design might. And this is easier to achieve with Obj-C (with
some help of C) ...
-- georg --
"More Trees, less Bushes!"
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.