Rép : ObjC++ (and a word about Java, too ;-= 29
Rép : ObjC++ (and a word about Java, too ;-= 29
- Subject: Rép : ObjC++ (and a word about Java, too ;-= 29
- From: Thomas Lachand-Robert <email@hidden>
- Date: Thu, 6 Dec 2001 15:46:24 +0100
First a small note to all who responded:
My main point was to discuss the easier framework for a true beginner to
OS X developpement. The situation for cross-platform is clearly different.
For the comparison, see the message to Chris Thomas before.
Le jeudi 6 dicembre 2001, ` 03:07 , Steven Woolgar a icrit :
Most of these apps will NEVER be ported to Cocoa, and for all of its
glories, there are no Cocoa apps in the same league of importance to
Apple
as the above list. If push came to shove, which Framework do you think
they'd drop?
Matt Gough
Why do you say they will never be ported to Cocoa? Most of them would
highly benefit from Cocoa, and some of them are so buggy that they really
NEED to.
Cocoa will not make apps any less buggy. Now that I have used
Cocoa apps, only to discover that lo and behold they are also buggy
as hell, I have come to the conclusion that Cocoa does not help ANY
in the quantity of bugs in a product. Buggy software can be written
in Smalltalk, Java, C++, C or any other language. Of course, I wasn't
under the impression that language choice did anything for the quantity
of bugs.
Sorry but I strongly disagree. Buggy software can obviously be written in
any language, but some are more error-prone than others (and the same is
true for frameworks). It is well-known that Fortran and standard C for
instance, are more "dangerous" than Pascal or C++. It was one of the
important goal of Java to help reduce bugs, and even though I don't like
Java that mch, I recognize that it is very easy to catch bugs in Java code.
Also some bugs are more important than others. For example I helped a
friend to put a Cocoa interface on a linux/Windoz/Classic app of him
(scientific app). I discovered a number of bugs in his C++ causing crashes,
because of call of methods to null pointers. It was not conceptually an
error because in context, the call was intended to be necessary only if
the pointer were non zero. This is actually a frequent case, and it causes
crashes in C++, not in Obj-C.
Now I have a large number of ps or pdf files which, dragged on Illustrator/
Acrobat just cause them to "unexpectingly quit". THAT'S IRRITATING, even
on OS X (on OS9 the system crashes, too).
For instance AppleWorks needs a lot of work in this field, and this work
would be much simpler using Cocoa.
It would not be simpler in Cocoa. AppleWorks is 4 million lines of code
that runs on MacOS Classic, MacOS X, and Windows off of one source code
base. This is also the case for most of the apps you mentioned.
Sorry I don't understand how the Carbon frameworks helps programming on
Windows. If you are talking about meta-frameworks like PowerPlant, I can't
see any reason it couldn't be based on Cocoa. So the need of Carbon is for
existing apps (which is a very important need, I agree!) and for
compatibility with OS 9. Both needs are likely to disappear. 68k apps
disappeared two or three years after the introduction of the PowerPC; so I
bet that in two or three years, no huge company will bother to have
compatibility with OS 9.
Now I don't do any cross-platform OS X/Windows developement, so maybe it
is easier to do with carbon, but I don't understand why. On the other hand,
I know by personal experience and examples that it is much easier to use
Cocoa while porting Unix apps.
Thomas Lachand-Robert
********************** email@hidden
<< Et le chemin est long du projet ` la chose. >> Molihre, Tartuffe.