How viable is Cocoa development?
-
Hi,
Not so long ago (Oct 2001) Apple ended MacApp development which has
caused us to loose a lot of time. We are now looking for an
alternative application framework for Mac OS X development and are
faced with a choice between Carbon based PowerPlant and Cocoa.
We have worked a lot of with PowerPlant but always felt that it takes
too long before new OS developments are incorporated. Cocoa in that
sense seems very attractive. However, we are concerned that Apple
will pull the plug out of Carbon or Cocoa at some point to reduced
development costs. It did so with MacApp so why not with either
Carbon or Cocoa. As the majority of the large software companies seem
to go for and depend on Carbon it does not seem very likely that that
plug will be pulled any time soon. While Apple would like us all to
move to Cocoa we have the impression that there are very few major
vendors building Cocoa applications, so it seems that plug may be a
lot less firmly fixed despites Apple's current rhetorics.
So my questions to you as Cocoa developers are:
1) Whether there are any "big names" depending on Cocoa right now?
2) Why we should move to Cocoa if we want to do OS X only development
and optimally exploit the potential of OS X?
3) Why Apple will "never" unplug Cocoa
Thank you for your time,
david. -
On Friday, January 25, 2002, at 08:09 , David Niemeijer wrote:> So my questions to you as Cocoa developers are:
>
> 3) Why Apple will "never" unplug Cocoa
iDVD and iPhoto are both written in Cocoa/ObjC. Why would Apple begin
developing its apps using a dead framework?
andy -
> We have worked a lot of with PowerPlant but always felt that it takes
> too long before new OS developments are incorporated. Cocoa in that
> sense seems very attractive. However, we are concerned that Apple
Cocoa is not particularly attractive here. New features are primarily added
to Carbon and only exposed to Cocoa if and when Apple gets around to it and
it is very low priority for them.> will pull the plug out of Carbon or Cocoa at some point to reduced
> development costs. It did so with MacApp so why not with either
I am not sure, but I think that MacApp is still available as source code
from Apple. You may be able to maintain it and bring it forward yourself.
I might add that Apple has abandoned many more APIs than just MacApp. They
have stranded many developers over the years. Don't even start on QuickDraw
GX...> Carbon or Cocoa. As the majority of the large software companies seem
> to go for and depend on Carbon it does not seem very likely that that
> plug will be pulled any time soon. While Apple would like us all to
Carbon will exist as long as Apple exists.> move to Cocoa we have the impression that there are very few major
> vendors building Cocoa applications, so it seems that plug may be a
> lot less firmly fixed despites Apple's current rhetorics.
I think the odds that Apple will abandon Cocoa before they abandon Carbon
approach 100%.>
> So my questions to you as Cocoa developers are:
>
> 1) Whether there are any "big names" depending on Cocoa right now?
Apple themselves are doing a little bit of Cocoa development. There are
many small companies including mine that do Cocoa development. Our
applications may be "big", but NeXT and Apple have seemingly done everything
they could to keep our companies small. Dropping proven cross platform
support was unforgivable.>
> 2) Why we should move to Cocoa if we want to do OS X only development
> and optimally exploit the potential of OS X?
Using Cocoa is a joy. Cocoa is technologically far superior to almost
anything else I have seen. Carbon is the stone age of programming compared
to Cocoa (IMHO). Cocoa/Openstep/NeXTstep have existed for > 12 years and
are well proven. There are many stories of applications that would not
exist without Cocoa and its predecessors including Improv,
Virtuoso/Freehand, Diagram/Visio/Glyphix, and my company's high end
animation development tools. Cocoa is the best technology available for
building Mac OS-X applications as long as you only consider technical
issues. I would not start a large new Cocoa project today. The
non-technical aspects and risks are too great.>
> 3) Why Apple will "never" unplug Cocoa
Ha. Ha. The next time Apple has the slightest crisis, Cocoa will be gone.
Look at their history. After Apple drops public support of Cocoa, they will
continue to use it for a while internally until they abandon any of their
own applications that need it, but they will screw any outside developers
without the slightest twinge of conscience.
Here is an exercise: List all of the technologies that Apple has SHIPPED to
developers and claimed that they were the future of the Mac OS and would be
supported "forever". Now list the ones still available from Apple. It
gives a reasonable person a bit of doubt why they develop for Apple at all.
Many of the abandoned technologies were used more extensively within Apple
and consumed more of Apple's marketing and development budgets than Cocoa.
How many times do developers have to be screwed by a company before that
stop going back and asking for another ?
My bottom line advice is to not ask Carbon vs. Cocoa. Ask Apple at all vs.
other platforms. -
On Friday, January 25, 2002, at 08:03 PM, Andreas Monitzer wrote:> On Friday, January 25, 2002, at 08:09 , David Niemeijer wrote:
>
>> So my questions to you as Cocoa developers are:
>>
>> 3) Why Apple will "never" unplug Cocoa
>
> iDVD and iPhoto are both written in Cocoa/ObjC. Why would Apple begin
> developing its apps using a dead framework?
Not to mention other fundamental bits of the operating system...
loginwindow and System Preferences, Mail, AddressBook, and lookupd is
written in Obj-C although it doesn't use Cocoa.
-- Finlay -
On Friday, January 25, 2002, at 11:09 AM, David Niemeijer wrote:> So my questions to you as Cocoa developers are:
>
> 1) Whether there are any "big names" depending on Cocoa right now?
Does Apple count? ;-)
iPhoto, iDVD2, all of our development tools, and a bunch of the
apps you'll find under /Applications on an OS X system are Cocoa
apps.
-jcr
John C. Randolph <jcr...> (408) 974-8819
Sr. Software Engineer, Cocoa Evangelism
Apple Worldwide Developer Relations -
On Friday, January 25, 2002, at 12:29 PM, Erik M. Buck wrote:>> 1) Whether there are any "big names" depending on Cocoa right now?
>
> Apple themselves are doing a little bit of Cocoa development.
Actually, Apple is doing a *lot* of Cocoa development. Come and
hear about it at WWDC ;-)
-jcr
John C. Randolph <jcr...> (408) 974-8819
Sr. Software Engineer, Cocoa Evangelism
Apple Worldwide Developer Relations -
What except the Apps in OS-X Dev-Tools and iApps? Just interested...
Cheers, Thilo
Am Freitag den, 25. Januar 2002, um 21:47, schrieb John C. Randolph:> Actually, Apple is doing a *lot* of Cocoa development. Come and hear
> about it at WWDC ;-) -
At 8:09 PM +0100 1/25/02, David Niemeijer wrote:> So my questions to you as Cocoa developers are:
>
> 1) Whether there are any "big names" depending on Cocoa right now?
Apple Computer
Some former NeXT developers (OMNI Group and Stone Design)
Beyond that it's hard to say since any "big name" developer
with a lot of existing code is unlikely to have shipped much
in Cocoa yet.> 2) Why we should move to Cocoa if we want to do OS X only
> development and optimally exploit the potential of OS X?
To save time. Cocoa really does save a lot of time compared
to PowerPlant or other more traditional Mac environments for
new Mac OS X development. Your code will be significantly
smaller and more elegant in Cocoa.
Cocoa is OS X native allowing you to call all the other
OS X APIs directly.
The trade off is portability. Cocoa is a relatively thin
extension on top of C which could be widely ported but it
hasn't been. The more you use it, the more your code becomes
tied to the Mac or where Apple wants you to go. There's also
the learning curve for Cocoa itself and finding developers.> 3) Why Apple will "never" unplug Cocoa
"Never" is a long time. Right now, Cocoa is one of
the best modern development frameworks available.
Apple sees this as a strength to be exploited.
Someday, it too could be retired, but only after
being replaced by other more effective tools that
don't exist yet.
Judging by how long it has taken the main stream to
grudgingly adopt OO programming, Cocoa should be
around for a while.
- Peter
-- -
On Friday, January 25, 2002, at 03:29 PM, Erik M. Buck wrote:> Here is an exercise: List all of the technologies that Apple has
> SHIPPED to
> developers and claimed that they were the future of the Mac OS and
> would be
> supported "forever".
OpenDoc. That abandonment was my pinnacle of disbelief.> It
> gives a reasonable person a bit of doubt why they develop for Apple at
> all.
In Canada, we elect despicable politicians, but before condemning the
practice one has to examine who else was on the ballot. :-) -
Erik,>>>>>> Erik M. Buck (EMB) wrote at Fri, 25 Jan 2002 14:29:55 -0600:EMB> My bottom line advice is to not ask Carbon vs. Cocoa. Ask Apple at all
EMB> vs. other platforms.
Agreed. Which is where GNUStep comes into the picture. The Foundation part
is quite portable for some years; I haven't tried AppKit, but somebody
written not so long ago it approaches maturity quite well.
If it is so indeed -- and to make sure, I repeat I HAVEN'T checked myself!
--, anything you write in Cocoa/BSD API without polluting the code by Carbon
nonsenses is the nearest thing to full portability possible, if you want
full-featured complete API (perhaps C++/X.windows and Java/SWING are
_slightly_ better from the portability point of view, but lose so much in the
full-featured part that it more than makes for the difference).
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
2K Development: <o.cada...> http://www.2kdevelopment.cz
private <ondra...> http://www.ocs.cz/oc -
On Friday, January 25, 2002, at 04:10 PM, Phillip Mills wrote:> OpenDoc. That abandonment was my pinnacle of disbelief.
Just to give another data point...
we've been programming and selling in [essentially] Cocoa for 10 years
in the commercial arena. Hardly an OpenDoc story.
-lance
_______________________________________________
Lance Bland
System Administrator at VVI
mailto:<lance.bland...>
http://www.vvi.com
Realtime, bulk and web data reporting and visualization -
On Friday, January 25, 2002, at 01:05 PM, Thilo Ettelt wrote:> What except the Apps in OS-X Dev-Tools and iApps? Just interested...
>
> Cheers, Thilo
>
> Am Freitag den, 25. Januar 2002, um 21:47, schrieb John C. Randolph:
>
>> Actually, Apple is doing a *lot* of Cocoa development. Come
>> and hear about it at WWDC ;-)
Sorry, I can't go into that... I'll just say that a whole lot
of people here have gone through Cocoa training in the last year.
-jcr
John C. Randolph <jcr...> (408) 974-8819
Sr. Software Engineer, Cocoa Evangelism
Apple Worldwide Developer Relations -
On Friday, January 25, 2002, at 09:14 PM, Ondra Cada wrote:> without polluting the code by Carbon nonsenses
-1 Troll.
-- Finlay -
Finlay,>>>>>> Finlay Dobbie (FD) wrote at Fri, 25 Jan 2002 22:41:20 +0000:FD> >without polluting the code by Carbon nonsenses
FD>
FD> -1 Troll.
Troll or not, in the context it is, I guess, quite right: whilst almost
complete Cocoa (but some news like sheets or drawers) is totally portable to
anywhere GNUStep is available, *NO* Carbon-specific service is available
outside of Mac.
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
2K Development: <o.cada...> http://www.2kdevelopment.cz
private <ondra...> http://www.ocs.cz/oc -
> Actually, Apple is doing a *lot* of Cocoa development. Come and
> hear about it at WWDC ;-)
Apple does Cocoa development, but the additional interface widgets and
bug fixes they add to Cocoa have not been released to third party
developers. We should be seeing new versions of Cocoa on a monthly
schedule, every 6 months to a year isn't going to cut it. My
development is extremely hampered by either Cocoa bugs or lack of
features. Look at the NSToolbar, or NSBrowser, they both need serious
subclassing to be included in a professional product.
Look at iPhoto. Every button they use is non standard Cocoa, why can't
I have access to those buttons. Why can't I have brushed steel windows?
Also I doubt iPhoto is using NSImageView to draw it's images. The built
in jpg/tiff imaging engines are very slow, too slow to create something
like iPhoto. Why don't we have access to this imaging code.
I still love Cocoa, but developer need more, and they need it now. Cocoa
is still beta in some respects. New objects should be continually
released and old ones should be continually enhanced.
--
Steve Gehrman
CocoaTech
<sgehrman...>
http://www.cocoatech.com -
On Friday, January 25, 2002, at 02:45 PM, Ondra Cada wrote:> Finlay,
>
>>>>>>> Finlay Dobbie (FD) wrote at Fri, 25 Jan 2002 22:41:20 +0000:
> FD> >without polluting the code by Carbon nonsenses
> FD>
> FD> -1 Troll.
>
> Troll or not, in the context it is, I guess, quite right: whilst almost
> complete Cocoa (but some news like sheets or drawers) is
> totally portable to
> anywhere GNUStep is available, *NO* Carbon-specific service is
> available
> outside of Mac.
AFAIK, the GNUStep folks haven't tried yet to implement the
window-morphing that we do for the sheets.
-jcr
"The problem with trying to child-proof the world, is that it
makes people neglect the far more important task of
world-proofing the child." -- Hugh Daniel -
On Friday, January 25, 2002, at 10:45 PM, Ondra Cada wrote:> Troll or not, in the context it is, I guess, quite right: whilst almost
> complete Cocoa (but some news like sheets or drawers) is totally
> portable to
> anywhere GNUStep is available, *NO* Carbon-specific service is available
> outside of Mac.
Neither is AppleScript, not to mention Quartz, NetInfo,
DirectoryService, IOKit, QuickTime... The list goes on. These are all
very nice technologies specific to OS X... Is that a reason not to use
them? Or do you group anything with a non-Obj-C API that is part of OS X
as "Carbon"? :-P
-- Finlay -
On Friday, January 25, 2002, at 10:55 PM, John C. Randolph wrote:>> Troll or not, in the context it is, I guess, quite right: whilst almost
>> complete Cocoa (but some news like sheets or drawers) is
>> totally portable to
>> anywhere GNUStep is available, *NO* Carbon-specific service is
>> available
>> outside of Mac.
>
> AFAIK, the GNUStep folks haven't tried yet to implement the
> window-morphing that we do for the sheets.
As Ondra said... Even so, when (if?) GNUstep ports the sheets API, who
says they have to make them squoosh out in such a silly way? I mean, I'd
be perfectly happy if Apple spent more time fixing bugs than
implementing all their window squooshing effects.
-- Finlay -
Just because Apple uses something in one of their signature applications
doesn't mean it *must* appear in Cocoa as well. There's a difference
between what's generally useful, like System-standard controls, and
what's narrowly useful, like iPhoto's controls. Cocoa would be
cluttered unnecessarily were Apple to include everything it uses in its
own applications.
And surely mature, rather than monthly, updates to Cocoa are
preferable. Quality over quantity any day.
j o h n
On Friday, January 25, 2002, at 02:45 PM, Steve Gehrman wrote:>> Actually, Apple is doing a *lot* of Cocoa development. Come and
>> hear about it at WWDC ;-)
>
> Apple does Cocoa development, but the additional interface widgets and
> bug fixes they add to Cocoa have not been released to third party
> developers. We should be seeing new versions of Cocoa on a monthly
> schedule, every 6 months to a year isn't going to cut it. My
> development is extremely hampered by either Cocoa bugs or lack of
> features. Look at the NSToolbar, or NSBrowser, they both need serious
> subclassing to be included in a professional product.
>
> Look at iPhoto. Every button they use is non standard Cocoa, why can't
> I have access to those buttons. Why can't I have brushed steel windows?
>
> Also I doubt iPhoto is using NSImageView to draw it's images. The
> built in jpg/tiff imaging engines are very slow, too slow to create
> something like iPhoto. Why don't we have access to this imaging code.
>
> I still love Cocoa, but developer need more, and they need it now.
> Cocoa is still beta in some respects. New objects should be
> continually released and old ones should be continually enhanced.
>
> --
> Steve Gehrman
> CocoaTech
> <sgehrman...>
> http://www.cocoatech.com
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored. -
On Friday, January 25, 2002, at 03:09 PM, Finlay Dobbie wrote:>
> On Friday, January 25, 2002, at 10:55 PM, John C. Randolph wrote:
>
>>> Troll or not, in the context it is, I guess, quite right:
>>> whilst almost
>>> complete Cocoa (but some news like sheets or drawers) is
>>> totally portable to
>>> anywhere GNUStep is available, *NO* Carbon-specific service is
>>> available
>>> outside of Mac.
>>
>> AFAIK, the GNUStep folks haven't tried yet to implement the
>> window-morphing that we do for the sheets.
>
> As Ondra said... Even so, when (if?) GNUstep ports the sheets
> API, who says they have to make them squoosh out in such a
> silly way? I mean, I'd be perfectly happy if Apple spent more
> time fixing bugs than implementing all their window squooshing
> effects.
The window morphing effect was *done* by the time that Steve
first demonstrated it. We don't have a bunch of people
re-implementing it every month.
-jcr
John C. Randolph <jcr...> (408) 974-8819
Sr. Software Engineer, Cocoa Evangelism
Apple Worldwide Developer Relations -
On Friday, January 25, 2002, at 02:45 PM, Steve Gehrman wrote:>> Actually, Apple is doing a *lot* of Cocoa development. Come and
>> hear about it at WWDC ;-)
>
> Apple does Cocoa development, but the additional interface
> widgets and bug fixes they add to Cocoa have not been released
> to third party developers.
Actually, bug fixes get released with every developer seed.
Check the release notes if you want to see which ones.> We should be seeing new versions of Cocoa on a monthly
> schedule, every 6 months to a year isn't going to cut it.
That wouldn't work unless we were also releasing the OS every
month. Imagine having to distribute the latest version of the
Cocoa frameworks with your products.> My development is extremely hampered by either Cocoa bugs or
> lack of features. Look at the NSToolbar, or NSBrowser, they
> both need serious subclassing to be included in a professional
> product.
The Toolbar is new, and may not be entirely finished, but
NSBrowser has been around for a long time, and it should be
quite solid. What trouble are you having with it?> Look at iPhoto. Every button they use is non standard Cocoa,
> why can't I have access to those buttons. Why can't I have
> brushed steel windows?
Well, you can, but you'd have to do the same thing that the
iPhoto team did (like Don Yacktman and I did when I was with
IllumineX.) IOW, the brushed-steel window isn't part of the
framework. You might note that iTunes did it too, and iTunes
isn't a cocoa app (no, I don't know which group did it first.)> Also I doubt iPhoto is using NSImageView to draw it's images.
> The built in jpg/tiff imaging engines are very slow, too slow
> to create something like iPhoto. Why don't we have access to
> this imaging code.
You do. Just use OpenGL, and let the hardware help you. If you
look closely at iPhoto, you'll realize that it's not an image
editor, it's an image *organizer*. The trickiest bit of image
processing in there is the red-eye removal.> I still love Cocoa, but developer need more, and they need it
> now. Cocoa is still beta in some respects. New objects should
> be continually released and old ones should be continually
> enhanced.
I'm always glad to hear that people want more Cocoa ;-)
-jcr
John C. Randolph <jcr...> (408) 974-8819
Sr. Software Engineer, Cocoa Evangelism
Apple Worldwide Developer Relations -
Practically everything with a non-Objective-C or Java API in OS-X IS Carbon.
That is sort of the definition.
Ok, Quicktime is its own beast. The BSD/POSIX APIs are not Carbon and the
kernel services are not Carbon. Open-GL is not Carbon.
In your list, AppleScript, Quartz, NetInfo, DirectoryService, IOKit, are all
Carbon.
Netinfo used to be Objective-C but is not any more.
IOKit is part of Darwin, but it is clearly designed in the Carbon spirit,
but we can disagree.
I will add to the Carbon list to include ATSUI, Preferences, security,
speach, sound, music, what remains of game sprockets, and all of Core
Foundation.
From Apple's own documentation, Carbon includes the following: (Which have
Cocoa wrappers ? )
Screen savers
Preference panes
All system services that are available to all application environments
Security services: keychain...
Network Service Location
Open Transport
URL Access manager
Internet Config
Component Manager
Code Fragment Manager
Sherlock
Power manager
XML services
All of Core Foundation
Translation Manager
Resource Manager
Navigation services
Folder Manager
Finer Interface
File Manager
Device manager
Alias Manager
Tool Box
Apple Events
Apple Scripting
Scrap Manager
Speech Synthesis
Speech Recognition
Sound Manager
QuickTime
Game Sprockets
Thread manager
Carbon event manager
Apple Type
Unicode
ATS Type
Language Manager
QuickDraw
ScriptManager
Text Encoding and Conversion
ATSUI
HTML Rendering Library
Display Manager
ColorSync Manager
Color Picker
Carbon Printing
and more...
----- Original Message ----- -
On Friday, January 25, 2002, at 11:42 PM, Erik M. Buck wrote:>> From Apple's own documentation, Carbon includes the following: (Which
>> have
> Cocoa wrappers ? )
What documentation are you referring to?> Screen savers
> Preference panes
These 2 are definitely not Carbon, they are Obj-C and are implemented in
Cocoa. They are documented under "Additional Technologies" or something,
and not Carbon.> All system services that are available to all application environments
Aren't these, by definition, "Core Services", and not "Carbon"? :-P
I personally would have thought of Carbon as being everything in
CarbonCore.framework and Carbon.framework, but then, hey, whatever.
And I don't see how you can call Quartz Carbon... Is xnu Carbon too?
-- Finlay -
John,>>>>>> John C. Randolph (JCR) wrote at Fri, 25 Jan 2002 14:55:30 -0800:JCR> complete Cocoa (but some news like sheets or drawers) is totally
JCR> portable...
JCR>
JCR> AFAIK, the GNUStep folks haven't tried yet to implement the
JCR> window-morphing that we do for the sheets.
Yep, that's more or less what I said, is it not?
Incidentally, I guess that fully-functional sheets could be relatively
easily implemented without any morphing; whilst they won't be as nice to look
at by far, they might be even somewhat more pleasable usage-like, for they
would be faster ;)
That's quite irrelevant though, since -- AFAIK -- there is currently no
sheet API in GNUStep, so there's no reason to guess how its implementation
might look ;))) (Or am I wrong and GNUstep does include the API now?)
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
2K Development: <o.cada...> http://www.2kdevelopment.cz
private <ondra...> http://www.ocs.cz/oc -
Finlay Dobbie wrote:> Neither is AppleScript, not to mention Quartz, NetInfo,
> DirectoryService, IOKit, QuickTime... The list goes on. These are all
> very nice technologies specific to OS X... Is that a reason not to use
> them? Or do you group anything with a non-Obj-C API that is part of OS X
> as "Carbon"? :-P
NetInfo and IOKit are both available in Darwin, which runs just fine on
Intel hardware. Check out /System/Library/Frameworks in an i386 Darwin
install.
--Matt Judy -
Finlay,>>>>>> Finlay Dobbie (FD) wrote at Fri, 25 Jan 2002 23:04:37 +0000:FD> >Troll or not, in the context it is, I guess, quite right: whilst almost
FD> >complete Cocoa (but some news like sheets or drawers) is totally
FD> >portable to
FD> >anywhere GNUStep is available, *NO* Carbon-specific service is available
FD> >outside of Mac.
FD>
FD> Neither is AppleScript, not to mention Quartz, NetInfo,
FD> DirectoryService, IOKit, QuickTime... The list goes on. These are all
FD> very nice technologies specific to OS X... Is that a reason not to use
FD> them?
For _portable_ products? Try to guess ;)
FD> Or do you group anything with a non-Obj-C API that is part of OS X
FD> as "Carbon"? :-P
In a sense, yep: the vast majority of that API is "carbon" in the sense that
it is here just for compatibility with Classic stuff, otherwise it could
(and should!) be implemented quite by a different way: there would be
NeXTTime instead of QuickTime, DriverKit instead of the non-OO hell of IOKit,
... well, as you said, the list goes on. And the actual Carbon, of course,
would not exist at all.
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
2K Development: <o.cada...> http://www.2kdevelopment.cz
private <ondra...> http://www.ocs.cz/oc -
> What documentation are you referring to?http://developer.apple.com/techpubs/macosx/Carbon/carbon.html
-
On Friday, January 25, 2002, at 03:42 PM, Erik M. Buck wrote:> Practically everything with a non-Objective-C or Java API in
> OS-X IS Carbon.
> That is sort of the definition.
No. By definition, Carbon is that set of capabilities which we
can offer up on *both* OS 9, and OS X. Not all of the C API
published on OS X is part of Carbon, nor is every C API that
existed on OS 9.
Keep in mind, there's C API that's part of Cocoa as well. (See
"Foundation Functions" and "AppKit Functions".)
-jcr
John C. Randolph <jcr...> (408) 974-8819
Sr. Software Engineer, Cocoa Evangelism
Apple Worldwide Developer Relations -
On Friday, January 25, 2002, at 03:49 PM, Ondra Cada wrote:> , DriverKit instead of the non-OO hell of IOKit,
I get the impression that you haven't actually looked at IOKit.
It certainly is OO code, and the IOKit team was very careful to
define "Kernal C++", just like the DriverKit team had once
defined "Kernal Obj-C". They didn't make the switch to C++
without careful consideration and design. FYI, the IOKit team
is led by an ex-NeXT engineer.
-jcr
John C. Randolph <jcr...> (408) 974-8819
Sr. Software Engineer, Cocoa Evangelism
Apple Worldwide Developer Relations -
John,>>>>>> John C. Randolph (JCR) wrote at Fri, 25 Jan 2002 16:22:08 -0800:JCR> >, DriverKit instead of the non-OO hell of IOKit,
JCR>
JCR> I get the impression that you haven't actually looked at IOKit.
Quite the contrary -- I've done some trickery about USB. Those things like
result=(*device)->CreateInterfaceIterator(device,&request,&iterator);
are pretty wild, from the perspective of the ol' nice NSEnumerator...
Agreed though that this is the *only* part of IOKit I've ever used, and it's
not C++ even.
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
2K Development: <o.cada...> http://www.2kdevelopment.cz
private <ondra...> http://www.ocs.cz/oc -
Actually, I have had to use IOKit quite a bit recently, and it _is_
intelligently laid out, and not quite a 'non-OO hell'.
But it is NOWHERE close to the ease of DriverKit. C++, no matter how
well laid out, is always a pain, and never truly object oriented. With
DriverKit, I was able to get a driver together for "X" piece of hardware
in around an hour. IOKit will never match this.
--Matt
John C. Randolph wrote:> On Friday, January 25, 2002, at 03:49 PM, Ondra Cada wrote:
>
>> , DriverKit instead of the non-OO hell of IOKit,
>
>
> I get the impression that you haven't actually looked at IOKit. It
> certainly is OO code, and the IOKit team was very careful to define
> "Kernal C++", just like the DriverKit team had once defined "Kernal
> Obj-C". They didn't make the switch to C++ without careful
> consideration and design. FYI, the IOKit team is led by an ex-NeXT
> engineer.
>
> -jcr
>
>
> John C. Randolph <jcr...> (408) 974-8819
> Sr. Software Engineer, Cocoa Evangelism
> Apple Worldwide Developer Relations
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored. -
On Friday, January 25, 2002, at 04:45 PM, Steve Gehrman wrote:> Apple does Cocoa development, but the additional interface widgets and
> bug fixes they add to Cocoa have not been released to third party
> developers.
Well, not to add fuel to the fire, but what ever happened to that
statement (somewhere, can't recall where unfortunately!) that every
control/widget/etc used or developed internally by Apple would be made
available to third party developers? I don't think this has been the
case...
-----------------------
- Steven M. Palm
- Ham Radio Call: N9YTY
----------------------- -
Erik M. Buck" <embassociates...> comments:> I might add that Apple has abandoned many more APIs than just MacApp. They
> have stranded many developers over the years. Don't even start on QuickDraw
> GX...
and Phillip Mills <phillipm...> adds:> OpenDoc. That abandonment was my pinnacle of disbelief.
I have to comment on these. I've been a Mac OS (as well as other platforms)
developer since well before either of those technologies were offered, and I
boggle every time I hear someone trot either of them out as an example of how
Apple abandons developers after getting them hooked on some hot new technology.
The truth is that both QDGX and OpenDoc were available for years with
essentially no adoption before Apple pulled the plug on them.
I know of one commercial GX product that shipped. It came out simultaneously
with a Classic QD version of the same program. The GX version was faster and
offered more features, and it was a dismal failure in the market. I never saw
another GX-centric product hit the shelves. The most significant OpenDoc product
to come out (despite years of hype from both Apple and - of all organizations to
promote an Apple technology - Ziff-Davis' columnists) was a technology demo from
Apple. Lots of stuff announced. Virtually none of it made it to the consumer.
A pertinent question, which noone who complains about GX and OD seems willing to
answer, is exactly how long a company is expected to put their resources and
credibility into products that aren't seeing enough adoption to pay for the
people supporting them. Did Apple abandon these technologies? Yes. Did they
strand developers by doing so? You'd have to do some pretty fancy arguing to
show that.
In the same thread, Steve Gehrman <sgehrman...> asks:> Look at iPhoto. Every button they use is non standard Cocoa, why can't
> I have access to those buttons. Why can't I have brushed steel windows?
For good or ill, the brushed steel windows are a branding strategy. I would
suspect it's not really in Apple's best interests as a system vendor _or_ an
application vendor to help third parties dilute their branding and destabilize
the user experience (which, I might argue, Apple does well enough on their own).
G -
on 1/25/02 8:09 PM, Gregory Weston at <gweston...> wrote:>
> I know of one commercial GX product that shipped. It came out simultaneously
> with a Classic QD version of the same program.
I owned two commercial GX products. Both were excellent and had features
(due to their GX adoption) that *NO* other program could match. I sorely
miss both of them, but the fact that I was able to do things with GX that
I'll likely never be able to do again is not the sad part about its passing
away.> A pertinent question, which noone who complains about GX and OD seems willing
> to answer, is exactly how long a company is expected to put their resources
> and credibility into products that aren't seeing enough adoption to pay for
> the people supporting them.
Apple can do anything they feel is necessary to save the company -- that is
what was on the table at the time. However, their right to kill the
technologies doesn't mean that it is not sad, or that the computing world
would not have been better if 3rd party developers had adopted those
technologies.
Specifically, GX had the opportunity to enable people in parts of the world
(e.g. Ethiopia) where text systems designed for English are just not
applicable, to participate in the digital revolution. This is not a business
case for keeping GX alive, but its a damned shame that the human race
couldn't pull it off. The technology was there. It could have really helped
to bridge the digital divide. But it won't.
It is sad, but the right solution does not always make it in the market
place. That being said, the problem with GX, as Gregory mentions above, was
not that GX was lousy technology, it was that developers didn't adopt the
new technology. That is what killed GX.
Bob -
> From: Ondra Cada <ocs...>
> Date: Sat, 26 Jan 2002 00:49:37 +0100
>
>>>>>>> Finlay Dobbie (FD) wrote at Fri, 25 Jan 2002 23:04:37 +0000:
> FD> Or do you group anything with a non-Obj-C API that is part of OS X
> FD> as "Carbon"? :-P
>
> In a sense, yep: the vast majority of that API is "carbon" in the sense that
> it is here just for compatibility with Classic stuff, otherwise it could
> (and should!) be implemented quite by a different way:
I may be mistaken here, since I haven't done a systematic examination... but I had occasion to trace into the machine code of several Cocoa implementations (notably in file handling), and they appear to call Carbon File Manager routines often. Quite a few parts of Cocoa seem to be just a thin shell over the equivalent Carbon calls.
You might argue that this is a consequence of HFS+ support, I suppose...
--
Rainer Brockerhoff <rainer...>
Belo Horizonte, Brazil
"I love deadlines. I love the whooshing noise they make as they go by" (Douglas Adams)
http://www.brockerhoff.net/ (updated Jan. 2002) -
> It is sad, but the right solution does not always make it in the marketwas
> place. That being said, the problem with GX, as Gregory mentions above,> not that GX was lousy technology, it was that developers didn't adopt the
> new technology. That is what killed GX.
>
And how is that different from Cocoa within Apple ?
I love Cocoa. I want Cocoa to survive and thrive. I would love it
everybody used Cocoa.
The reality is that "nobody" that Apple cares about uses Cocoa just like
nobody that Apple cared about used OpenDoc or GX. A certain OpenDoc
application once won Apple choice awards in the same category as a certain
Cocoa application... Apple spent years saying that OpenDoc was THE future.
They said GX was THE future. Apple used OpenDoc and GX internally to the
extent possible. Apple spent much more money on OpenDoc and GX than on
Cocoa. Apple made stronger public commitments to OpenDoc and GX than to
Cocoa. Hell, until the most recent Mac world, (and to a lesser extent the
last WWDC) Apple hardly mentioned Cocoa let alone advocated it. And OpenDoc
and GX are just two of the many things Apple has dropped.
Apple has already reneged on Cocoa related promises:
Where is cross platform Cocoa/YellowBox (after years of promisses) ?
Where are the free or inexpensive runtimes for Windows ?
Where is Objective-C EOF ?
Where in NeXTtime ?
You get the idea. Apple is already dropping parts of Cocoa. Is it such a
stretch to see them drop it all (at least publicly ?)
There is a trust and credibility issue with Apple regardless of any
technical merit of any technology that Apple might be half heartedly pushing
this year. -
on 1/25/02 10:50 PM, Erik M. Buck at <embassociates...> wrote:>> the problem with GX, as Gregory mentions above, was not that GX
>> was lousy technology, it was that developers didn't adopt the
>> new technology. That is what killed GX.
>
> And how is that different from Cocoa within Apple ?
Yes. That was my point. It is not up to Apple to make Cocoa a success any
more; it is up to developers to adopt it.
One big difference between Cocoa and OpenDoc and GX, that your comment
obscures, however, is that Cocoa is an integrated part of MacoSX. OpenDoc
and GX were always an optional install. They were going to become required
in the Copland time frame. Apple would have a much harder time simply
dropping Cocoa from the next release of MacOSX.
Bob -
On 1/25/02 at 10:14 PM, "Erik M. Buck" <embassociates...> wrote:>> It is sad, but the right solution does not always make it in the market
>> place. That being said, the problem with GX, as Gregory mentions above,
>> was not that GX was lousy technology, it was that developers didn't adopt
>> the new technology. That is what killed GX.
>>
>
> And how is that different from Cocoa within Apple ?> From what I can see, Cocoa already has more support and interest in theMacintosh developer community than QDGX or OD ever did.> You get the idea. Apple is already dropping parts of Cocoa. Is it such a
> stretch to see them drop it all (at least publicly ?)
So you're advocating a death spiral. Nobody rational should use technology FOO
because Apple is likely to drop it, but Apple is most likely to drop it
specifically _because_ nobody uses it. Self-fulfilling prophecy, no? If we want
Apple to keep Cocoa the most viable solution is to work to make it expensive, in
some way, for them to drop it.
G -
> Yes. That was my point. It is not up to Apple to make Cocoa a success any
> more; it is up to developers to adopt it.
>
An important difference between Cocoa and GX/OpenDoc is this:
GX and OpenDoc is dead and buried, of the past, while Cocoa is alive and
now. When and how Cocoa dies is in our hands as developers, and it will
be too late to complain if the day comes when Apple drops Cocoa for lack
of interest.
-Thomas Jahnsen -
On Friday, January 25, 2002, at 11:54 PM, Erik M. Buck wrote:>> What documentation are you referring to?
> http://developer.apple.com/techpubs/macosx/Carbon/carbon.html
This doesn't say that all of the stuff you mentioned before is part of
Carbon.
CoreFoundation is semi-Carbon, because it's in CarbonLib on OS 9 but is
in a lower layer than Carbon on OS X (it's even partly in Darwin, and
some other low-level parts of the system depend on it).
Everything on the Core Technologies page is just that, a "Core
Technology", and not Carbon. Same goes for Additional Technologies,
they're not Carbon either. In fact, the main Mac OS X Developer
Documentation page groups the technologies under these headers:
"Carbon", "Cocoa", "Core Technologies", "Additional Technologies",
"Networking" and "Darwin".
So, it looks like they're classified as:
Carbon
- all the OS 9 Managers plus some new ones to support extra
functionality in OS X (Carbon Event Manager, Dock Manager, etc)
Core Technologies:
- CoreFoundation
- Quartz
- Printing
- OpenGL
- Velocity Engine
- AppleScript (this is actually dodgy, it has hooks in Cocoa and
Carbon, and is probably mostly Carbon-based)
Additional Technologies:
- Preference Panes (sits on top of Cocoa)
- Screen Savers (sits on top of Cocoa)
Networking Services:
- AFP
- CFNetwork
- Directory Services
- NSL
- SystemConfiguration
Darwin Kernel Environment:
- IOKit
- Kernel API
Of course, for many of these, the definitions aren't clean cut, many of
them interdepend, but I'm merely saying that nowhere near all C APIs in
OS X are "Carbon".
-- Finlay -
on 02-01-25 5:29 PM, John C. Randolph at <jcr...> wrote:> I'll just say that a whole lot
> of people here have gone through Cocoa training in the last year.
And Apple even recently hired a well-known NextStep/Cocoa programmer to add
to the team....
--
Bill Cheeseman - <wjcheeseman...>
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont - http://members.valley.net/croquetvermont -
OK. My comment.
Cocoa is cool, but there only a few people out there that buy a
computer, because it offers a cool technology. Most people buy computers
to solve some problems. To do that they need application software. There
is already a lot of applications available/buyable. A lot of knowledge
and work was put into this software. Starting from zero is a big effort
for a really big application, because away from the straight road there
lots of little paths to go. These little paths you have to go to solve
very specific problems, are the really big effort that was invested in
the very large applications. And while the straight road is a really
broad and comfortable highway in Cocoa it is very hard to guess if the
smaller paths are equally comfortable. Why? Because applications like
Photoshop are really really big and also no one (I haven't counted it)
in this/these companies has lots of experience with Cocoa. Result: No
big applications were ported to Cocoa. Apple had to create Carbon or
suffer all major application software suppliers. To make something
useful out of this they had to make Cocoa and Carbon work together, for
example the clipboard, but there is much more. To make it work they
created the Corefoundation and IOKit frameworks. ObjC code is not
callable from a C++ or C program (now we have ObjC++ though) so it was
necessary to change that. The Carbon programs like Finder and ITunes
were made to show "Yes, Carbon is mature, start porting" and "Were are
comitted to Carbon for a long time, because we surely won't deliver
MacOS X without a GUI". So I think Apple had not that much of a choice.
Why exactly they dropped EOF...? I don't no, but conclude from that that
there must be a little man (maybe Steve Jobs) at Apple that rolls a dice
to see what technology is killed next... come on.
Stefan Jung -
on 02-01-25 11:50 PM, Erik M. Buck at <embassociates...> wrote:> You get the idea. Apple is already dropping parts of Cocoa. Is it such a
> stretch to see them drop it all (at least publicly ?)
I have had the impression that the "dropping parts of Cocoa" phenomenon is
in part a temporary artifact of the ongoing process of Carbonizing Cocoa. It
makes sense to me that Cocoa should be Carbonized wherever possible, because
it reduces duplication of effort for Apple and therefore expense over the
long haul. It also makes sense to me that at least some of the "dropped"
parts of Cocoa will return as time allows the Carbonization process (and
Carbon itself) to catch up. One step backward to prepare the groundwork for
two steps forward.
From this point of view, the Cocoa of the future can be thought of as Carbon
on steroids. Cocoa as the preferred application framework for development of
Carbon applications. One OS technology combining both, not two separate
technologies. Who cares what's under Cocoa's hood as long as it works and
remains the wonderful OO development environment that it is?
This surely makes business sense for Apple, and it's consistent with the
evidence to date (which is, of course, incomplete, since there hasn't yet
been time to get to the verdict).
I have no inside information. Nor does Erik, as far as I know. So I feel
justified in speculating optimistically, as he is speculating
pessimistically.
--
Bill Cheeseman - <wjcheeseman...>
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont - http://members.valley.net/croquetvermont -
on 02-01-25 9:09 PM, Gregory Weston at <gweston...> wrote:> The truth is that both QDGX and OpenDoc were available for years with
> essentially no adoption before Apple pulled the plug on them.
It was refreshing to read this very important point. And the reason for the
lack of adoption should also be noted. Apple didn't make these and other
failed technologies an automatic-install part of the OS. They were optional
installs. There was an awful lot of complaining from developers at that time
that there was no money in developing for a technology that customers had to
be asked to install separately. LightningDraw GX proved it.
Cocoa is automatically installed as part of Mac OS X, so this particular
issue of developer economics need not trouble us. And Cocoa will obviously
continue to be an automatic install as long as applications which Apple
believes are important to its future are written in Cocoa -- iPhoto and so
on.
I am more concerned about the repeated assertion that Apple won't release
new Carbon technology in the form of Cocoa frameworks. Erik Buck, whose
pessimistic views are well known, isn't the only one who says so. I
certainly would hope that Apple will turn to producing more Cocoa frameworks
for Carbon technologies, like speech recognition and speech synthesis, just
as they did finally get around to producing improved Cocoa documentation.
But assuming they won't, I suggest that all Cocoa developers who need to
implement Carbon functionality in their Cocoa applications do so in the form
of general-purpose frameworks, then market the frameworks separately to the
rest of us as an additional source of revenue. Under licensing terms that
allow us to include the frameworks in our own application bundles, in order
to overcome the customer adoption problem for custom frameworks. The
versioning issues for frameworks in multiple application bundles are already
accounted for in the OS, according to the System Overview book. The marginal
costs of developing the frameworks ought to be modest for anybody who needs
to bring the functionality in from Carbon for their products, anyway, and I
would think the additional revenue would therefore be mostly gravy, even if
not a lot of it.
Waiting for Erik to call me naove....
--
Bill Cheeseman - <wjcheeseman...>
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont - http://members.valley.net/croquetvermont -
Rainer,>>>>>> Rainer Brockerhoff (RB) wrote at Sat, 26 Jan 2002 02:30:35 -0200:RB> I may be mistaken here, since I haven't done a systematic examination...
RB> but I had occasion to trace into the machine code of several Cocoa
RB> implementations (notably in file handling), and they appear to call
RB> Carbon File Manager routines often. Quite a few parts of Cocoa seem to be
RB> just a thin shell over the equivalent Carbon calls.
RB>
RB> You might argue that this is a consequence of HFS+ support, I suppose...
I would argue it is a consequence of a bad design. I would argue it should
have been done the very opposite way:
(i) extend Cocoa to cope properly with HFS+ and other news, and...
(ii) make Carbon a thin compatibility shell over it!
That way the application consistency would be *WAYS* better, there would be
no problem of APIs lacking in Cocoa, and what seems to me to be the MOST
important, the applications would be also runtime-consistent: things like
Mike Ferris' TextExtras or my OCSmart Hacks would properly work system-wide
(but Classic of course, but Classic is explicitly an emulator).
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
2K Development: <o.cada...> http://www.2kdevelopment.cz
private <ondra...> http://www.ocs.cz/oc -
Bill,>>>>>> Bill Cheeseman (BC) wrote at Sat, 26 Jan 2002 08:02:14 -0500:BC> Who cares what's under Cocoa's hood as long as it works and
BC> remains the wonderful OO development environment that it is?
The problem is the "as long as". The more Cocoa gets carbonized, the less it
works. The problem is that if you put the engine of a Mini into your
Lamborghini, the latter would look like the same, but you can hardly suppose
the drive would stay unaffected!
Just two concrete examples I'm bumping into myself quite often:
- menus are quite messed up; for example, supporting tearoffs -- always
designed-in and therefore quite easy -- is problematic as hell;
- problems with incorrect Unicode support -- just try to use the
spellchecker, and "Learn" a word which contains non-MacOSRoman-characters!
The list could go on (and I've sent much longer ones previously), but I
guess it has no sense anyway :(
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
2K Development: <o.cada...> http://www.2kdevelopment.cz
private <ondra...> http://www.ocs.cz/oc -
On Freitag, Januar 25, 2002, at 09:29 Uhr, Erik M. Buck wrote:>
>>
>> 2) Why we should move to Cocoa if we want to do OS X only development
>> and optimally exploit the potential of OS X?
>
> Using Cocoa is a joy. Cocoa is technologically far superior to almost
> anything else I have seen. Carbon is the stone age of programming
> compared
> to Cocoa (IMHO). Cocoa/Openstep/NeXTstep have existed for > 12
> years and
> are well proven.
Well, what does "well proven" mean in this context (excuse me for
not looking it up in Google). Does it mean that it is known that
you can complete an application with it ? Probably not.
Does it mean well tested with very few bugs and optimized
performance ? Not the Cocoa I know of late.
I still like it, but actually sometimes I think it is showing its age.
IMO Cocoa only really shines together with EOF/Obj-C, alas those
days are gone...
As to the original question, my view is that as long as Java is
unsuitable for writing something like iPhoto, Cocoa-Obj-C will live
and prosper, which should be the next five years at least.
Nat!
------------------------------------------------------
Some people drink deep from the fountains of life, and
some just gargle. -- DLR -
At 14:35 +0100 26/01/2002, Ondra Cada wrote:>>>>>>> Rainer Brockerhoff (RB) wrote at Sat, 26 Jan 2002 02:30:35 -0200:
> RB> ... Quite a few parts of Cocoa seem to be
> RB> just a thin shell over the equivalent Carbon calls.
> RB>
> RB> You might argue that this is a consequence of HFS+ support, I suppose...
>
> I would argue it is a consequence of a bad design. I would argue it should
> have been done the very opposite way:
>
> (i) extend Cocoa to cope properly with HFS+ and other news, and...
> (ii) make Carbon a thin compatibility shell over it!
>
> That way the application consistency would be *WAYS* better, there would be
> no problem of APIs lacking in Cocoa, and what seems to me to be the MOST
> important, the applications would be also runtime-consistent: things like
> Mike Ferris' TextExtras or my OCSmart Hacks would properly work system-wide
> (but Classic of course, but Classic is explicitly an emulator).
Well, that's of course a basic design decision made when the order of the layers was decided upon, and no amount of lamenting will change that now. :-)
I agree with you that implementing Carbon on top of Cocoa (instead of the other way around) would have had advantages such as those you list. However, one could also argue that this would have made Carbonized apps even slower than they are now, with all that dynamic-dispatching stuff going on underneath, and no way to get around it...
That said, I certainly like Cocoa a lot, and I won't write a Classic or Carbon app (meaning, built around the Carbon event model) ever again. However I still prefer to call non-Cocoa APIs whenever I need to get closer to the metal.
--
Rainer Brockerhoff <rainer...>
Belo Horizonte, Brazil
"I love deadlines. I love the whooshing noise they make as they go by" (Douglas Adams)
http://www.brockerhoff.net/ (updated Jan. 2002) -
On Saturday, January 26, 2002, at 01:35 PM, Ondra Cada wrote:> (but Classic of course, but Classic is explicitly an emulator).
Classic is *NOT* an emulator.
-- Finlay -
Rainer,>>>>>> Rainer Brockerhoff (RB) wrote at Sat, 26 Jan 2002 12:32:40 -0200:RB> However, one could also argue that this would have made Carbonized apps
RB> even slower than they are now, with all that dynamic-dispatching stuff
RB> going on underneath, and no way to get around it
Since I have first-hand experience with "all that dynamic-dispatching stuff"
on MC68040/25/32MB and even i486/66/20MB, I can be pretty positive it is
*NOT* the cause of the slowness of something on a G4/733/0.5GB RAM machine...
I do agree that OS X _is_ slow, even on those supercomputers. "All that
dynamic-dispatching stuff" can't be blamed though, the problem is elsewhere.
I have some suspicions, but since they are not proven, I won't go into
details... well, one thing's proven: check archives for the thread "Ways
Apple COULD optimize -setNeedsDisplay"!
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
2K Development: <o.cada...> http://www.2kdevelopment.cz
private <ondra...> http://www.ocs.cz/oc -
Finlay,>>>>>> Finlay Dobbie (FD) wrote at Sat, 26 Jan 2002 15:40:35 +0000:FD> >(but Classic of course, but Classic is explicitly an emulator).
FD>
FD> Classic is *NOT* an emulator.
Please. Unless you use a *very* different vocabulary, this should be quite
unambigous.
It is set of tools aimed to be able to run apps created for an utterly
different environment. Such a set is generally called an emulator. Another
nice example of the very same thing is Virtual PC.
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
2K Development: <o.cada...> http://www.2kdevelopment.cz
private <ondra...> http://www.ocs.cz/oc -
On Saturday, January 26, 2002, at 03:48 PM, Ondra Cada wrote:> It is set of tools aimed to be able to run apps created for an utterly
> different environment. Such a set is generally called an emulator.
> Another
> nice example of the very same thing is Virtual PC.
Virtual PC is most definitely an emulator. Classic is akin to WINE on
Linux, and WINE stands for "Wine Is Not an Emulator".
Emulation is taken to imply emulation of a different chip architecture,
whereas Classic is generally termed a "compatibility layer" or something
like that.
-- Finlay -
Finlay,>>>>>> Finlay Dobbie (FD) wrote at Sat, 26 Jan 2002 15:56:30 +0000:FD> Emulation is taken to imply emulation of a different chip architecture
Well, I'd argue that the overall system architecture is much more important
than the CPU. It is quite imaginable to have multiple-CPU system with more
_different_ chips, still running quite natively the code and even supporting
SMP ;)
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
2K Development: <o.cada...> http://www.2kdevelopment.cz
private <ondra...> http://www.ocs.cz/oc -
On Saturday, January 26, 2002, at 08:42 AM, cocoa-dev-
<request...> wrote:> (but Classic of course, but Classic is explicitly an emulator).
Runtime environment, not emulator. :) -
At 16:44 +0100 26/01/2002, Ondra Cada wrote:>>>>>>> Rainer Brockerhoff (RB) wrote at Sat, 26 Jan 2002 12:32:40 -0200:
> RB> However, one could also argue that this would have made Carbonized apps
> RB> even slower than they are now, with all that dynamic-dispatching stuff
> RB> going on underneath, and no way to get around it
>
> Since I have first-hand experience with "all that dynamic-dispatching stuff"
> on MC68040/25/32MB and even i486/66/20MB, I can be pretty positive it is
> *NOT* the cause of the slowness of something on a G4/733/0.5GB RAM machine...
Agreed that dynamic dispatching can work quite well even on slow CPUs if not overdone. I've done a medical monitor which did dynamic dispatching on a 4Mhz Z80 (assembly language, however), just to top your experience :-)> I do agree that OS X _is_ slow, even on those supercomputers. "All that
> dynamic-dispatching stuff" can't be blamed though, the problem is elsewhere.
> I have some suspicions, but since they are not proven, I won't go into
> details... well, one thing's proven: check archives for the thread "Ways
> Apple COULD optimize -setNeedsDisplay"!
Well, I too have heard that text drawing is slow. However, the more Cocoa APIs I use in my application to get file data and such, the slower it gets, in the sense that it takes much longer _before_ displaying something than if I collect the information with Carbon or BSD calls.
My suspicion is that NSFileManager and NSWorkspace do lots of wasteful stuff like creating temporary arrays, strings, arrays of strings, dictionaries and so forth inside loops... that's why I try not to use them if I need speed.
--
Rainer Brockerhoff <rainer...>
Belo Horizonte, Brazil
"I love deadlines. I love the whooshing noise they make as they go by" (Douglas Adams)
http://www.brockerhoff.net/ (updated Jan. 2002) -
>> I'll just say that a whole lotadd
>> of people here have gone through Cocoa training in the last year.
>
> And Apple even recently hired a well-known NextStep/Cocoa programmer to> to the team....
>
Yes. This is the best news. When Apple was not even training their own
people in Cocoa, what message did that send to third parties ? John is
turning me around, and I am seeing light at the end of the tunnel. Believe
it or not, I am a very optimistic person. However, how many times does a
developer have to get screwed and how much money has to be lost before the
developer will stop going back for more broken promises ? -
on 02-01-26 8:43 AM, Ondra Cada at <ocs...> wrote:> The problem is the "as long as". The more Cocoa gets carbonized, the less it
> works. The problem is that if you put the engine of a Mini into your
> Lamborghini, the latter would look like the same, but you can hardly suppose
> the drive would stay unaffected!
These are implementation details. Of course I would rather have a Ferrari
engine in my Lamborghini, and I'm hopeful that Apple will eventually put one
there.
--
Bill Cheeseman - <wjcheeseman...>
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont - http://members.valley.net/croquetvermont -
Rainer,>>>>>> Rainer Brockerhoff (RB) wrote at Sat, 26 Jan 2002 14:37:50 -0200:RB> >Since I have first-hand experience with "all that dynamic-dispatching
RB> >stuff" on MC68040/25/32MB and even i486/66/20MB, I can be pretty
RB> >positive it is *NOT* the cause of the slowness of something on a
RB> >G4/733/0.5GB RAM machine...
RB>
RB> Agreed that dynamic dispatching can work quite well even on slow CPUs if
RB> not overdone. I've done a medical monitor which did dynamic dispatching
RB> on a 4Mhz Z80 (assembly language, however), just to top your experience
RB> :-)
Haha, let's play on -- though you still have en edge!
Ever have seen a handheld of Psion "Epoc/16" line? Epoc 16 was a quite nice
operating system, which featured among others preemptive multitasking, and,
what's important here, dynamic ObjC-like OO system. (It used explicit C
coding though, and selectors were defined statically, so you written things
like "send(object, SELECTOR, arg1, arg2)").
Well, the thing run on, IIRC, 4.75 MHz V30 chip, with 128 or 256 MB RAM.
There was a quite nice GUI there, even!
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
2K Development: <o.cada...> http://www.2kdevelopment.cz
private <ondra...> http://www.ocs.cz/oc -
> Waiting for Erik to call me naove....
>
I don't think you are naive. I think you have made a very helpful and
constructive suggestion. However, developers should not base a small
business solely upon wrapping Carbon APIs in Cocoa. Apple can undercut such
developers at a whim even just by spreading FUD. There are also issues
about contacting/marketing to the disparate Cocoa developers. There are
also issues about how to charge for frameworks. Nevertheless, Bill has a
good suggestion. We have already seen some progress in the form of attempts
to wrap QuickTime. -
On Saturday, January 26, 2002, at 05:06 PM, Erik M. Buck wrote:> When Apple was not even training their own
> people in Cocoa, what message did that send to third parties ?
They have been training their people in Cocoa for some time, like since
Rhapsody. They just have a lot of people! :-)
-- Finlay -
On Saturday, January 26, 2002, at 10:56 AM, Finlay Dobbie wrote:>
> Virtual PC is most definitely an emulator. Classic is akin to WINE on
> Linux, and WINE stands for "Wine Is Not an Emulator".> Emulation is taken to imply emulation of a different chip architecture,
> whereas Classic is generally termed a "compatibility layer" or
> something like that.
>
WINE is a re-implementation of the win32 API on another system, classic
is not that (Carbon is). Classic emulate the hardware in which a
complete Mac OS 8 or 9 run. (did I say emulate?)
Anyway, everyone know that classis does not emulate the cpu but it sure
does emulate other part of the hardware.
Sandy. -
Sandy,>>>>>> Sandy Martel (SM) wrote at Sat, 26 Jan 2002 12:25:16 -0500:SM> Anyway, everyone know that classis does not emulate the cpu but it sure
SM> does emulate other part of the hardware.
'Course. Just like, say, Aladin those ages ago did -- it was a very nice
_EMULATOR_ of Mac, which run on ATARI ST, exploiting the advantage of having
the same CPU to make it run there almost as well as on a real machine.
Actually, first three years or so of my using Mac the actual hardware below
was from ATARI ;))))
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
2K Development: <o.cada...> http://www.2kdevelopment.cz
private <ondra...> http://www.ocs.cz/oc -
Classic is not an emulator. So sayeth the gods:
http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Instal
lIntegrate/
The_Classic_Application.html
I have not seen the source code to Classic.app, so I can't say for sure
whether it is emulating hardware or not. I assume there is some level of
protection in place to prevent Classic apps from being able to do
terrible things to the computer despite OSX running, so I would hope
they aren't providing direct access to the hardware. But as for whether
it is truly emulated or not, I couldn't tell you.
Also, I doubt anyone is intentionally going to *start* writing apps
targeted directly at classic instead of OSX, which is off-topic of the
original discussion, I believe.
-Chilton -
Isn't the elegance of Cocoa the design, not the implementation?
It makes sense from Apple's point of view - if at all possible have a
single implementation with 2 different ways to access (Carbon and Cocoa).
It's easier to write a Cocoa wrapper on top of Carbon than the other way
around.
Karl
On Friday, January 25, 2002, at 08:30 PM, Rainer Brockerhoff wrote:>> From: Ondra Cada <ocs...>--
>> Date: Sat, 26 Jan 2002 00:49:37 +0100
>>
>>>>>>>> Finlay Dobbie (FD) wrote at Fri, 25 Jan 2002 23:04:37 +0000:
>> FD> Or do you group anything with a non-Obj-C API that is part of OS X
>> FD> as "Carbon"? :-P
>>
>> In a sense, yep: the vast majority of that API is "carbon" in the
>> sense that
>> it is here just for compatibility with Classic stuff, otherwise it
>> could
>> (and should!) be implemented quite by a different way:
>
> I may be mistaken here, since I haven't done a systematic
> examination... but I had occasion to trace into the machine code of
> several Cocoa implementations (notably in file handling), and they
> appear to call Carbon File Manager routines often. Quite a few parts of
> Cocoa seem to be just a thin shell over the equivalent Carbon calls.
>
> You might argue that this is a consequence of HFS+ support, I suppose...
>
> --
> Rainer Brockerhoff <rainer...>
> Belo Horizonte, Brazil
> "I love deadlines. I love the whooshing noise they make as they go by"
> (Douglas Adams)
> http://www.brockerhoff.net/ (updated Jan. 2002)
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
>
>
Java Haiku:
cd jdk
rm -r *.*
garbage collection
Homepage:
http://homepage.mac.com/khsu/index.html -
On Saturday, January 26, 2002, at 09:33 AM, Ondra Cada wrote:> Sandy,
>
>>>>>>> Sandy Martel (SM) wrote at Sat, 26 Jan 2002 12:25:16 -0500:
> SM> Anyway, everyone know that classis does not emulate the cpu but it
> sure
> SM> does emulate other part of the hardware.
>
> 'Course. Just like, say, Aladin those ages ago did -- it was a very nice
> _EMULATOR_ of Mac, which run on ATARI ST, exploiting the advantage of
> having
> the same CPU to make it run there almost as well as on a real machine.
> Actually, first three years or so of my using Mac the actual hardware
> below
> was from ATARI ;))))
Actually, the way most of the Mac 'emulators' worked on the Amiga and
Atari ST were more akin to a "hostile port" of the Mac ROM to a new
piece of hardware (including patching out the bits that talked to the
hardware), rather than trying to emulate the Mac hardware such that the
ROM would work unmodified. The fact that the Mac ROM was forced to
work on a non-Apple piece of hardware doesn't seem to be much different
than Apple having made a new Mac ROM for a new Apple piece of hardware,
legal issues aside. ;)
Classic works in much the same way, except that instead of the ROM image
being ported to a new piece of hardware, it's sitting on top of another
OS instead. Arguably there is no real 'emulation' (software or
hardware) going on in that case. It would have been a lot different if
Classic was trying to run a Mac ROM designed for a real piece of
hardware and some other part of the system was taking CPU traps to fake
out hardware accesses to registers and such.
-Ken
Kenneth Dyke, <kcd...> (personal), <kdyke...> (work)
Sr. Mad Scientist, MacOS X OpenGL Group, Apple Computer, Inc.
Java: The blazing speed of SmallTalk with the simple elegance of C++. -
On 1/26/02 11:19 AM, Hsu at <ploiku...> wrote:> It's easier to write a Cocoa wrapper on top of Carbon than the other way
> around.
For every problem, there is a solution that is simple, easy and wrong...
;-)
Later,
--
David Rehring Psychos do not explode when light hits
Senior Software Engineer them, no matter how crazy they are...
Atimi Software, Inc.
www.atimi.com And totally insane guy! -
At 2:29 PM -0600 1/25/02, Erik M. Buck wrote:> Here is an exercise: List all of the technologies that Apple has SHIPPED to
> developers and claimed that they were the future of the Mac OS and would be
> supported "forever". Now list the ones still available from Apple.
Also list the dates they were dropped.
I believe Rhapsody for Intel was dropped in 1999 while Yellow Box for
Windows and Cocoa/Objective-C EOF were both dropped in 2000.
How many have been dropped since?
-- Chris
--
Chris Hanson | Email: <cmh...>
bDistributed.com, Inc. | Phone: +1-847-372-3955
Making Business Distributed | Fax: +1-847-589-3738
http://bdistributed.com/ | Personal Email: <cmh...> -
At 10:50 PM -0600 1/25/02, Erik M. Buck wrote:> Apple spent years saying that OpenDoc was THE future.
True.> They said GX was THE future.
True.> Apple used OpenDoc and GX internally to the
> extent possible.
Not true at all. And this is the key difference: Apple is using
Cocoa many, many, many more places than they ever used either OpenDoc
or QuickDraw GX.> There is a trust and credibility issue with Apple regardless of any
> technical merit of any technology that Apple might be half heartedly pushing
> this year.
How many technologies has Apple pushed and then dropped since the
beginning of 2001?
Apple just won't talk about future directions any more for exactly
this reason, even under NDA, except with the developers they consider
the most special (and most able to keep secrets in confidence). The
reason is to help rebuild developer and user credibility. And,
frankly, it's working pretty well with many Macintosh developers.
-- Chris
--
Chris Hanson | Email: <cmh...>
bDistributed.com, Inc. | Phone: +1-847-372-3955
Making Business Distributed | Fax: +1-847-589-3738
http://bdistributed.com/ | Personal Email: <cmh...> -
"Sing o Muse, of the anger of OpenDrawPowerGXDocTalk,
and its devastation, which put pain thousandsfold upon
the AppleDevelopers, hurled in their multitudes to the
house of Wintel, strong souls of codewarriors that gave
their blood freely to the delicate feasting of the faithless
ghouls of Redmond, and the will of Gates was accomplished..."
Cry if you will, sing Homeric laments if you must, but these dead
technologies are still dead, and even though my heart bleeds for them, I
find all the handwringing useless and not very constructive. The
original poster's questions are important to anyone venturing into the
brave new world of osx development, but substantial answers to these
questions have been lost amid the angst and rage over the historical bad
blood between Apple and its developers.
I think the original questions were very broad, and loaded with
important sub-questions, that have gotten lost in the passionate
responses to the "Apple has screwed us in the past" question. So I'd
like to pose slightly more detailed questions along the same lines.
Every developer has different needs and the issues which these questions
address are very important in making the right choice between Cocoa and
Carbon. Here are my questions:
1) If I want to take full advantage of OSX, and have fastest access to
the latest and greatest capabilities of the operating system as it
evolves, should I use Cocoa or Carbon??
1a) When Apple implements new feature FOO or new technology BAR
in OSX, do I get to use FOO and BAR first in Carbon or Cocoa?
1b) Right now (today!), can I access the most OSX features and Apple
technologies
using Cocoa? or Carbon?
1c) Is it feasible to develop primarily in Cocoa, but use APIs from
Carbon? (or vice versa)
1d) What is available in Cocoa that is not available in Carbon?
1e) What is available in Carbon that is not available in Cocoa.
1f) If I want to use the standard BSD features of OSX in my app, are
there issues which
make Cocoa a better choice than Carbon (or vice versa).
1g) If I want to integrate unix-based non-Apple technologies into my
application such as
Qt, IMSL, or third party C libraries, is Cocoa or Carbon the
right choice??
My choice of technologies must be palatable to my management. The
pointy-haired ones do not understand technology, they understand
simplistic drivel like "Microsoft uses Carbon" or "Adobe makes $40
billion using Cocoa". So the question is:
2) Who are the big name (non-Apple) vendors shipping Cocoa applications
who can make management comfortable with my picking Cocoa as a
development technology?
2a) If I choose Cocoa, are there other sources of simplistic drivel
that might be
acceptable to the pointy-haired ones?
Apple has a very bad history of screwing developers by promoting radical
new technologies and then pulling the plug on them. The "Apple Screws
its Developers & Users" poster child is not OpenDrawPowerGXDocTalk, but
HyperCard. HyperCard was well-loved by users and developers, and yet
Apple killed it anyway.
Apple's bad history with developers makes it something of a risk to
invest in Apple technologies. From the history, it appears that Apple's
tendency to pull the plug on a technology is influenced primarily by the
installed base of applications that depend on that technology. So to
properly assess the risk associated with having Cocoa or Carbon as my
primary development technology I need to ask:
3) Is it possible for Apple to ship OSX without Cocoa support? Without
Carbon support?
3a) If Apple shipped an OSX without Cocoa (Carbon?) support tomorrow,
how
many shipping products (non-Apple) would be affected.
3b) If I shipped a Cocoa or Carbon App and Apple stopped shipping
Cocoa or Carbon
support with OSX, is it *possible* for me to provide a
functional application environment
without Apple's help.
I'm sure there are lots of other considerations to be made up front when
selecting Cocoa or Carbon as the core technology for a new application,
and hopefully these questions and the vast experience available on this
list will provide a starting point for those of us still in the early
stages of such big decisions.
Sorry for the long post,
<megabight...> -
On Saturday, January 26, 2002, at 06:14 PM, <megabight...> wrote:
<snip>> 3b) If I shipped a Cocoa or Carbon App and Apple stopped shipping
> Cocoa or Carbon
> support with OSX, is it *possible* for me to provide a
> functional application environment
> without Apple's help.
It's been my understanding that the uses of Cocoa and Carbon were pretty
clear. If you have an existing (pre OS X) application and need to get
it running on OS X _quickly_, use Carbon. If you are starting from
scratch, use Cocoa.
My summary of this thread:
Cocoa *is* viable. Very viable. For now.
eric -
On Saturday, January 26, 2002, at 11:06 AM, Ondra Cada wrote:> Finlay,Classic runs in a virtual hardware space last time I checked.
>
>>>>>>> Finlay Dobbie (FD) wrote at Sat, 26 Jan 2002 15:56:30 +0000:
> FD> Emulation is taken to imply emulation of a different chip
> architecture
>
> Well, I'd argue that the overall system architecture is much more
> important
> than the CPU. It is quite imaginable to have multiple-CPU system with
> more
> _different_ chips, still running quite natively the code and even
> supporting
> SMP ;)
> ---
>
Interestingly (according to my studies), Virtual PC is technically a
"simulator", since
the "hardware" is completely software. An emulator uses native processor
hardware and
some software on non-native hardware. Classic.app pretends to be a Mac,
where
most of the hardware is not the real hardware, except for the processor.
Check out
Apple System Profiler for OS 9 in Classic, very interesting. My 400MHz
G4 is running
at "about 396MHz"! The machine model is "Classic Mac OS Compatibility".
It's a virtual
machine, except the processor. It can't see the video card or the
ethernet card at all,
nor does it know which volume is the startup volume.
bg -
So you're advocating a death spiral. Nobody rational should use
technology FOO
because Apple is likely to drop it, but Apple is most likely to drop it
specifically _because_ nobody uses it. Self-fulfilling prophecy, no? If
we want
Apple to keep Cocoa the most viable solution is to work to make it
expensive, in
some way, for them to drop it.
G
Yes, I agree here, don't make these silly predictions, make a good
application for today using the right tools. If others follow, good, if
not, you can always go back, no real harm done. Anyway Obj-c should
always have compilers, shouldn't it?
If what you're saying is that Adobe and Microsoft (and maybe Filemaker
and Macromedia) are the deciding factors of whether Cocoa gets accepted
(who else has enough sway to make the difference?), or even gets killed,
then the Mac platform is really a done deal already. So if you're still
developing for the Mac, you may as well use Cocoa as Carbon. If the Mac
OS is doomed (which it would have to be if four or five developers are
all that keeps it alive), then splitting hairs over Carbon/Cocoa is a
serious waste of energy.
If on the other had, the platform has more to it than that, then it's
still an open question. Cocoa should be able to allow you to make better
apps faster.
So is anybody making new apps that will ever be as big as the current
gorillas, or is that all there is? Who's got the next Word? The next
Photoshop? Anyone?? Just ask yourself where the Mac would have been
without them? It's all about the ideas, man. The tools are nice, but the
ideas make the difference.
bg
--
Brought to you by Mail on Mac OS X. Think Different. -
on 28/01/02 1:36, <cocoa-dev-request...> -
<cocoa-dev-request...> wrote:> Am Sonntag den, 27. Januar 2002, um 12:55, schrieb Finlay Dobbie:
>
>> On Sunday, January 27, 2002, at 11:44 AM, Stefan Jung wrote:
>>
>>> Mixing binaries...I don't no if there are traps with mixing CFM and
>>> Mach-o code.
>>
>> Omni seems to manage OK, and Carbon can be Mach-O.
> I am not up to date with CodeWarrior. Can the latest 7.2 version
> generate Mach-O?
Yes, it can generate Mach-O applications.
Not only can it generate Mach-O Carbon applications, but it can also
generate Cocoa application.
By the way, the compiler seems very good compared to GCC (both in term of
compile speed and quality of the code generated).
It can even handle Objective-C++ code.
Cocoa developers really should try to compile their applications with
CodeWarrior to see if this couldn't lead to an effort-free speed
improvement.
This should be especially true for Apple, by the way :-)
Bruno Blondeau -
Matt Judy wrote:> Actually, I have had to use IOKit quite a bit recently, and it _is_
> intelligently laid out, and not quite a 'non-OO hell'.
>
> But it is NOWHERE close to the ease of DriverKit. C++, no matter how
> well laid out, is always a pain, and never truly object oriented. With
> DriverKit, I was able to get a driver together for "X" piece of hardware
> in around an hour. IOKit will never match this.
>
> --Matt
>
> John C. Randolph wrote:
>> On Friday, January 25, 2002, at 03:49 PM, Ondra Cada wrote:
>>
>>> , DriverKit instead of the non-OO hell of IOKit,
>>
>>
>> I get the impression that you haven't actually looked at IOKit. It
>> certainly is OO code, and the IOKit team was very careful to define
>> "Kernal C++", just like the DriverKit team had once defined "Kernal
>> Obj-C". They didn't make the switch to C++ without careful
>> consideration and design. FYI, the IOKit team is led by an ex-NeXT
>> engineer.
>>
>> -jcr
>>
>>
>> John C. Randolph <jcr...> (408) 974-8819
>> ...
Looking in the archives I find that Godfrey van der Linden (and, reportedly,
Stan Shebbs) regrets the decision to replace the Objective-C based driver subsystem
with an Embedded C++ based subsystem (DriverKit to IOKit---though this is not,
necessarily, to say that the DriverKit was perfect and wouldn't have needed a
significant overhaul anyway).
See http://lists.apple.com/archives/darwin-development/2001/Oct/17.html :> Date: Wed, 17 Oct 2001 11:38:28 -0700
> To: Michael Cashwell ,
> <Darwin-Development...>
> From: Godfrey van der Linden
> Subject: Re: IOKit C++ limitations
>
>
> G'dau Micheal,
>
> The history behind '-fno-exceptions'
>
> When we decided to change IOKit from Objective-C to C++. (Which I
> now considre to be a very bad mistake). ...
>
> Godfrey
See also http://lists.apple.com/archives/cocoa-dev/2001/Aug/10.html :> Date: Fri, 10 Aug 2001 16:29:27 -0400
> From: Scott Anguish
> Subject: Re: Cocoa downgrade from openstep?
> Cc: <ocs...>, Jean-Francois Veillette , Eric Peyton
> ,<cocoa-dev...>
> To: Finlay Dobbie
>
> On Friday, August 10, 2001, at 04:06 PM, Finlay Dobbie wrote:
>
>>
>> On Friday, August 10, 2001, at 01:06 am, Ondra Cada wrote:
>>
>>> From the ObjC viewpoint (!!!) IOKit is not and can't ever be
>>> object-oriented, since there's nothing like ObjC objects in C++, and
>>> IOKit,
>>> alas, is C++-based :(((
>>
>> From any *NORMAL* programmers viewpoint, IOKit is object-oriented.
>>
>> I'm not familiar with DriverKit and how it worked, but I suspect that
>> IOKit is lowerlevel, since I can't really see running the ObjC runtime
>> environment inside the kernel as a feasible thing to do.
>
>
> Actually, Stan Shebbs mentioned something about this at the
> Stepwise BOF at MacWorld back in January..
>
> The gist of it was that they'd probably have been better off
> sticking with Obj-C rather than the EmbeddedC++ stuff they went to.
Just a couple of viewpoints from "inside".
David <Halliday...> -
On Saturday, January 26, 2002, at 04:12 AM, Bill Cheeseman wrote:> on 02-01-25 5:29 PM, John C. Randolph at <jcr...> wrote:
>
>> I'll just say that a whole lot
>> of people here have gone through Cocoa training in the last year.
>
> And Apple even recently hired a well-known NextStep/Cocoa
> programmer to add
> to the team....
Well, they added me to the *marketing* team...
But seriously, if you walk around the IL campus, you'll see a
whole lot of people who've got 10+ years of
NeXTSTEP/OpenStep/Cocoa experience, who understand why Cocoa is
a Good Thing, and who are working on making it a Better Thing.
When I look at the org chart, I'm quite encouraged.
-jcr
John C. Randolph <jcr...> (408) 974-8819
Sr. Software Engineer, Cocoa Evangelism
Apple Worldwide Developer Relations -
As far as, Cocoa moving to pure Java in five year is concerned (Thats
what a lot
of people were predicting five years ago, when the question of learning
objective-C came up).
All you have to do is look at what happened when WebObjects moved to
pure Java. It put the product in
comatose, mind you dot-con did not help. All the Objective-C guys
basically left the
platform for cocoa jobs (I wonder where those jobs are besides at Apple,
not everyone wants to move to San Jose).
The customer just wanted J2EE. No marketing was done as promised.
Cross platform
development was destroyed. Buggy release was shipped, further
alienating everyone.
WebObjects most likely will become internal to Apple soon. I wonder to
whom they are going
to market WO51, just the converted. Talk about stealth releases.
I bet you Apple could make Carbon cross platform faster than Cocoa.
Market to Higher Education, they have already been alienated. Market to
Enterprise, they have already been alienated. Only people still glutton
for punishment are
the NeXTStep developers who are hoping for return of the glory days.
Nissus, How long does it take to create Word Processor with Cocoa. Did
they hire any
NeXTStep developer. Too bad you could not buy the Word processor in
possession of Sun,
Or you could just hire Omni thats what Lighthouse use to do.
Thanks,
Rajnish
