[Severed Hand of Skywalker]

http://www.realsoftware.com/realbasi..._vs_Cocoa.html

[edddeduck]

Originally posted by Severed Hand of Skywalker:
<STRONG>http://www.realsoftware.com/realbasi..._vs_Cocoa.html</STRONG>

You don't really have to care unless you are a developer and then you choose the platform depending on 1. the language you like more
2. If you want it to be OS9 /X (you can create os x only carbon Office is one of them)

Cheers Edd

[Sharky K.]

What ever the article says... cocoa is faster and better for OS X

All the cocoa apps I have are less eating CPU and memory, can use system wide apps like spell checking etc... and are better looking.

And they say carbon is as good as cocoa is? no way.

I don't say carbon shouldn't be here.

[Macfreak7]

Originally posted by Sharky K.:
<STRONG>What ever the article says... cocoa is faster and better for OS X

All the cocoa apps I have are less eating CPU and memory, can use system wide apps like spell checking etc... and are better looking.

And they say carbon is as good as cocoa is? no way.

I don't say carbon shouldn't be here.</STRONG>

i think the reason why that article says what it says is because of this....

Does any of this matter to me as a REALbasic user?
Not really. REALbasic is mostly a Carbon-based application and it generates mostly Carbon-based applications. I say "mostly" because REALbasic provides functions such as access to the UNIX shell and Mac�OS�X serial port access that are available on Mac�OS�X but not on Mac�OS 8 or 9. This is a good example of the power of Carbon. There are a few Mac�OS�X features such as Drawers that we can't currently provide to you because they aren't accessible via the Carbon APIs. Once Apple adds them to Carbon, we can make them available to you in REALbasic.

The fact is that while Cocoa provides a richer set of functions than Carbon, REALbasic provides you with a far richer set of functions than Cocoa does. Writing an application in REALbasic takes far less time and is far easier to accomplish for the typical user than it would be in Cocoa. And applications written in REALbasic can run on Mac�OS 8, Mac�OS 9, Mac OS X, and Windows 95 through Windows XP. Don't just take our word for it, you can convince yourself. Download the Objective-C tutorial (in which you create a currency calculator) from Apple's web site. Now create the same currency calculator in REALbasic. With that exercise, you will convince yourself.

[argod]

The question should be What is difference between OOP & OOD and
functional programming.

The RealBasic guy does not have clue about it. So how is
he going to answer the carbon and cocoa difference.

If Microsoft had written it. You would call it FUD.

[Developer]

Ah, the trolls again.

First of all YOU should learn the difference between functional and procedural programming before you call someone clueless.

[Severed Hand of Skywalker]

Originally posted by Sharky K.:
<STRONG>What ever the article says... cocoa is faster and better for OS X

All the cocoa apps I have are less eating CPU and memory, can use system wide apps like spell checking etc... and are better looking.

And they say carbon is as good as cocoa is? no way.

I don't say carbon shouldn't be here.</STRONG>

I think that is because carbon developers are not taking the time to properly write the carbon app and CoCoa will not let you get away with it as much.

Adobe and Microsoft do not use sheets even though some Carbon apps do.

[CharlesS]

In a nutshell:

The difference between Carbon and Cocoa is that Cocoa is a fully object-oriented, high level framework that's easy to write applications for. If you're a programmer, you should definitely care about the difference, because new Cocoa apps will be much easier to write and will take less time to write than Carbon apps. If you're not a programmer, you shouldn't care as much - while it is true that many Carbon applications are somewhat shoddy, because it would take more work to polish them properly, if a programmer does a really good job, a Carbon app can be a great piece of software. Also, if a programmer doesn't spend much time on a project, he can make a pretty sloppy Cocoa app (my BootCD program probably qualifies for this). You do get some nice features from Cocoa apps, of course, like the spell checker and Services, but those can be implemented in a Carbon app as well - it's just more work.

In summary, you should judge apps based on the quality of the software, rather than what environment the apps were written for.

[GnOm]

Originally posted by Severed Hand of Skywalker:
<STRONG>I think that is because carbon developers are not taking the time to properly write the carbon app and CoCoa will not let you get away with it as much.</STRONG>

that is almost completely true but if you take a close look at iPhoto you�ll see that it IS possible to mess up a Cocoa App too.


bye.

[kcmac]

I am not a programmer. I am a user. This is what I found interesting in the article if true.

"Can applications that use Cocoa do more things than applications that use Carbon?
The short answer is no. The Cocoa and Carbon APIs both call into the same parts of Mac�OS�X. However, there is a small set of functions that Apple has not yet made available to Carbon simply because they weren't needed for Mac applications to be made native on Mac�OS�X. The reverse is also true. There is a small set of functions that Carbon applications can access on Mac�OS�X that Cocoa-based applications can't simply because Cocoa applications didn't need them because they weren't used to having those functions anyway. Apple is working to reduce these differences to zero."

In any case, a well designed app should kick a$# whether it is carbon or cocoa, especially as some of the differences are minimized or transparent to the user. I'm just looking forward to the day that fonts look as good in carbon as they do in cocoa and when both will use Services, if possible.

[ 02-14-2002: Message edited by: kcmac ]

[argod]

Originally posted by Developer:
<STRONG>Ah, the trolls again.

First of all YOU should learn the difference between functional and procedural programming before you call someone clueless.</STRONG>

I DO ****-ING KNOW, I just used the wrong word. Just correct
the mistake and move on.

Nevertheless, I have enough experience to school a high school punk like
you. Including 7 years of NeXTStep/OPENSTEP/WEBOBJECTS, etc experience.

[Developer]

Originally posted by argod:

I DO ****-ING KNOW, I just used the wrong word. Just correct
the mistake and move on.

Booh, relax!

I'd still call it a little bit, well, arrogant to claim that the RealBASIC developers have "no clue about OOP".

Nevertheless, I have enough experience to school a high school punk like
you. Including 7 years of NeXTStep/OPENSTEP/WEBOBJECTS, etc experience.

Yep. All doubts removed.

[michaelb]

Originally posted by Severed Hand of Skywalker:
<STRONG>I think that is because carbon developers are not taking the time to properly write the carbon app and CoCoa will not let you get away with it as much.</STRONG>

That's pretty true. Cocoa - the FRAMEWORK - is like a pre-written app, fully debugged over the past 10 years by very brainy (and they know it) NeXT software engineers.

Developers only have to come along and plug in the parts that make their app unique. That's what makes it so fast to develop in Cocoa. But that's not all.

I'm still chuckling over a post I saw here I think from an Omni developer, who didn't even know his app had suddenly got the ability to command-~ between windows. (If I found Apple adding features to
my app behind my back, I'd think that was pretty... cool!)

If you want to become a Cocoa developer, and like watching TV, here's a way to do both at the same time:
http://developer.apple.com/wwdc2001/.../free/102.html


Carbon has OOP frameworks too, the most sophisticated being Metrowerks PowerPlant. The Finder was written with it. (Don't let that put you off!)

[Person Man]

Originally posted by Sharky K.:
<STRONG>
And they say carbon is as good as cocoa is? no way.

</STRONG>

That's not true. You can write a Carbon application that is just as good as a Cocoa app, especially if you use the Carbon Event Manager, instead of the old event manager, and using ATSUI (I believe) instead of the old text handler you can get the better antialiasing that Cocoa gives you for free.

The reason most Carbon applications suck is that the programmers are LAZY and don't take advantage of the new features.

[Sharky K.]

Originally posted by Person Man:
<STRONG>

That's not true. You can write a Carbon application that is just as good as a Cocoa app, especially if you use the Carbon Event Manager, instead of the old event manager, and using ATSUI (I believe) instead of the old text handler you can get the better antialiasing that Cocoa gives you for free.

The reason most Carbon applications suck is that the programmers are LAZY and don't take advantage of the new features.</STRONG>

I also see this for a reason that carbon is not as good as cocoa.

Other example: you can't use transparent slides... no big deal but this shows that carbon can't do anything cocoa can.

[ndptal85]

One must keep in mind that Carbon is the API to use for most companies contemplating Mac ports of their Windows software since it is the API most concentrated around C++ (which is what most good Windows software is created in.).

Cocoa is great for developers who don't have other apps to code for or any legacy code bases. But its also personally limiting for the developer since Obj-C is only used on Macs. No one is going to pay $500 and buy WebObjects for Windows just so you can use Obj-C apps on Windows. So for all intents and purposes Obj-C is a Mac OS X only language. Most developers don't want to become familiar in a language that is not an industry standard.

This is why instead of Carbon slowly fading away as intended it is being enhanced to give it all the features Cocoa currently has and for the forseable future Mac OS X will be a 2 API OS which is not a bad thing since having more than one API makes it easier for a developer to choose what to use instead of potentially putting off one group or another.

As time goes on and proper Carbon coding knowledge is aquired developers will learn that there's more to making a good Carbon app than just simply getting it running on OS X. It just takes time. Apple also has a few more features to add to Carbon to bring it up to parity with Cocoa. A year from now most folks won't be able to tell the difference (or care). In the meantime we'll all get great apps coded in either one and I really couldn't care less what they use as long as it runs on OS X period.

[Eug]

That "white paper" reads more like a pro-Carbon press release than an objective comparison.

[Guy Incognito]

Originally posted by Person Man:
<STRONG>

That's not true. You can write a Carbon application that is just as good as a Cocoa app, especially if you use the Carbon Event Manager, instead of the old event manager, and using ATSUI (I believe) instead of the old text handler you can get the better antialiasing that Cocoa gives you for free.

The reason most Carbon applications suck is that the programmers are LAZY and don't take advantage of the new features.</STRONG>

Exactly!!!! And that's why carbon's always gonna suck...even though it can match or even be better than cocoa. Sing it with me boyz and gurlz: 'Programmers are LAZY, programmers are LAZY, those who think cocoa sucks are CRAZY!'

If you write a cocoa program you're automatically not going to touch any of the pre-OS X legacy events and thus taking advantage of powerful OS X features for FREE...almost no code necessary. Are you a lazy programmer too? Start making cocoa apps now, nOW, NOW!

I guess when we see other carbon apps written from scratch such as Snapz Pro X, I'll be whistling a new tune. But until then, most carbon ports are shit...why? Because 'Programmers are LAZY, programmers are LAZY, those who think cocoa sucks are CRAZY!'

[ 02-15-2002: Message edited by: Guy Incognito ]

[miro7]

Is it that the programmers are lazy that some of the carbon ports are subpar or is it that the suits are looking for a cost effective solution to a marketing problem?

I don't think that programmers, in general, are looking to put out slow, bloated code with their names on it. I do, however, think that management would love for their programmers to port the app over so that they can market it as OS X compatible with a minimum of cost overhead.

In short, I think that taking the programmers to task for subpar apps is probably the wrong way to get good apps out (in general). I think that it is more productive to complain about the managment paying the bills. However, I'd rather have a solution on OS X that is a little slower, knowing that it will get faster eventually (either by my upgrading hardware or upgrades in software) than having no interim solution than to run Classic or OS 9. At least I can switch to another app while something else grinds away.

[Smircle]

Originally posted by Sharky K.:

Other example: you can't use transparent slides... no big deal but this shows that carbon can't do anything cocoa can.

This just goes to show how little _you_ know about Carbon and coding on MacOS-X in general.

[Sharky K.]

Originally posted by Smircle:
<STRONG>Originally posted by Sharky K.:




This just goes to show how little _you_ know about Carbon and coding on MacOS-X in general.</STRONG>

Are you looking for a fight? Join the army
Don't tell me that I don't know about coding on X... tell me why or that I am wrong about this one.

[mrtaber]

As a programmer, I vote for Cocoa! Objective-C is easy to learn, and so much is done for you already in Cocoa (read CharlesS's above post about framework, etc.).

As for lazy programmers, yeah! Lazy is not a pejorative term when it comes to programmers. Good programmers are always lazy. It just depends on your definition of lazy.

Good Lazy = working smart, elegant solutions, thinking outside the box.
Bad Lazy = brute force, doing what you know, staying in the safety zone.

MarkT

[kennethmac2000]

Originally posted by Smircle:
<STRONG>Originally posted by Sharky K.:

This just goes to show how little _you_ know about Carbon and coding on MacOS-X in general.</STRONG>

So can Carbon apps do transparent sheets or not!? Yes or no?

[ 02-15-2002: Message edited by: kennethmac2000 ]

[edddeduck]

Originally posted by kennethmac2000:
<STRONG>

So can Carbon apps do transparent slides or not!? Yes or no?</STRONG>

Not at the moment...

Edd

[Developer]

Carbon application can have translucent sheets.

[kennethmac2000]

Originally posted by Developer:
<STRONG>Carbon application can have translucent sheets.</STRONG>

So are you saying that developers like Microsoft who use sheets (albeit in a rather grudging way) in their OS X applications specifically went out of their way to use opaque sheets!?

[Developer]

Originally posted by kennethmac2000:

So are you saying that developers like Microsoft who use sheets (albeit in a rather grudging way) in their OS X applications specifically went out of their way to use opaque sheets!?

No, I'm not saying that.

[kennethmac2000]

Originally posted by Developer:
<STRONG>

No, I'm not saying that.</STRONG>

So why have I never seen a Carbon app with transparent sheets then!?

If it's because I haven't looked hard enough, perhaps you'd like to give me an example of one. And while you're at it, you could also give me an example of a Cocoa app with an opaque sheet!

[Millennium]

Ideally, you shouldn't have to care what an app is written in. Carbon apps can be as good as Cocoa ones.

However, this does take real effort, particularly if you're porting an app. And some off the best things in Carbon (most notably Carbon Events) will limit your backward-compatibility; CE apps only go back as far as OS9.0, even though CarbonLib itself can theoretically go all the way back to 8.1 (though a Carbon app that only uses the stuff compatible back to 8.1 could barely be considered Carbon).

There are still some differences in features between the two API's. Carbon has superior metadata support to Cocoa. It also has a somewhat richer control set (though, to be fair, the extra controls are somewhat limited in terms of situations where you'd actually want to use them). And you can actually choose to use outline window resizing if you want. But it can't use Drawers, and its Sheets are opaque (sorry, Developer, but this is true: Carbon's Sheets are all opaque by design; a rather boneheaded oversight on Apple's part, but that's how it goes).

Carbon apps, if done carefully, can be as good as Cocoa apps. However, there are very few apps out there right now where the developers actually put in the required effort to reach this goal: the best three examples I can think of are Audion, Snapz Pro X, and Final Cut Pro. Most other developers -even those from major houses- aren't doing this, even when they don't have to worry about OS9 compatibility. Care in point: Office X: they spent all their time making tool palettes genie in and out of the toolbar and no time making their apps support long filenames. A travesty if I ever saw one, but that's Microsoft for you, I guess.

[Developer]

Originally posted by kennethmac2000:

So why have I never seen a Carbon app with transparent sheets then!?

Maybe you didn't pay much attention to it? After all it's only a minor cosmetic glitch. Maybe you even encountered a good Carbon app and thought it was Cocoa? Who knows?

Open Sherlock, don't enter any search criteria and press the search button.

And while you're at it, you could also give me an example of a Cocoa app with an opaque sheet!

Download the latest OmniWeb sneaky peek and have a look at its print sheet.

[Millennium]

Originally posted by Developer:
<STRONG>

Download the latest OmniWeb sneaky peek and have a look at its print sheet.</STRONG>

Indeed, it is opaque. Not that difficult to do, either; it involves getting a handle on the window reference for the sheet, and resetting its opacity.

You mention Sherlock's transparent Sheet, though. It definitely is transparent, but are you certain that Sherlock is even Carbon? I've been getting the distinct impression that it is not. I've been looing over the Carbon documentation, and it doesn't appear possible to make a window partially transparent in Carbon. At the absolute least, this method is undocumented.

And tell me this: if it is possible to make Sheets transparent in Carbon, then why hasn't this been done on all Carbon apps? It should be automatic; it is not. Why is this? This is the problem with Carbon: Apple hasn't done enough effort on its part to integrate it into the API. The default behaviors should be the same as Cocoa apps (Sheets are an example of this); the programmer should, where possible, have to put in extra effort to make it different from other apps, not to make it the same. Certainly for some things, that won't be possible, but one would think that for something as simple as the opacity of Sheets, it should be automatic.

[Sharky K.]

I don't say Carbon is a bad thing I just think it is not as good as Cocoa...

Lets take a real good Carbon app that most people wouldn't see as a Carbon app but think it is a Cocoa app.
By adding all those "cocoa features" to a carbon app there is more programming needed. Does that not mean the perfect carbon app is bigger than a comparable cocoa app? And more possible errors???

[Developer]

Originally posted by Millennium:

You mention Sherlock's transparent Sheet, though. It definitely is transparent, but are you certain that Sherlock is even Carbon? I've been getting the distinct impression that it is not.

See, that's the point. In a decent Carbon app (and Sherlock is a Carbon/PowerPlant app), you don't really notice much of a difference. Maybe some of the people here who claim Carbon is crap just didn't notice that they are sitting in front of a good Carbon application. And honestly I'm a little bit pissed about this Carbon is crap and Carbon programmers are lazy nonsense (and if I see that RealBASIC paper, I might not be the only one).

I don't mean you personally, but some people here repeat that over and over again with zero knowledge and zero interest to gain some.

I've been looing over the Carbon documentation, and it doesn't appear possible to make a window partially transparent in Carbon. At the absolute least, this method is undocumented.

It's a special theme brush (kThemeBrushSheetBackgroundTransparent in Appearance.h). For everything more fancy regarding transparency you have to use CoreGraphics. So have a look at the CG documentation, not the Carbon docs.

And tell me this: if it is possible to make Sheets transparent in Carbon, then why hasn't this been done on all Carbon apps? It should be automatic; it is not. Why is this?

It isn't the default, because QuickDraw can't handle the transparency. Apple doesn't know if you are going to draw into the sheet with QuickDraw or not, that's why it is off by default.

[CharlesS]

Originally posted by Millennium:
<STRONG>You mention Sherlock's transparent Sheet, though. It definitely is transparent, but are you certain that Sherlock is even Carbon? I've been getting the distinct impression that it is not. I've been looing over the Carbon documentation, and it doesn't appear possible to make a window partially transparent in Carbon. At the absolute least, this method is undocumented.</STRONG>

Sherlock is Carbon - it fails the Help Key test. Also, drag it onto XRay, and XRay tells you that it is Carbon.

[mactropolis]

Yes, Sherlock is 100% Carbon, and it does use transparent sheets. I've seen two or three other (Apple) Carbon apps around the OS that did use transparent sheets also, but i can't recall them now. Its as simple as Apple makes the OS, those applications, and the development tools...so obviously their know the API's very well and take take advantage of stuff like this which might be diffult for an external developer.

Mindor cosmetic glitches? Having transparent sheets improves the general user experience of the app on Mac OS X. Its not a minor feature. It's not a major one, however.

Also, I refute the argument that Obj-C isn't portable. Depending on the type of application, some components of the app can easily be ported to another platform. Remember, GCC supports Obj-C and GCC runs on Windows. Obviusly, some of the high-end user interface code is going to be OS X specific, and vice-versa with Windows apps.

UPDATE: Another (Apple) Carbon app that has transparent sheets: Open Help Viewer, and find a link to a page thats not local (located on the internet), and Help Viewer will display a *transparent* sheet asking you to go online and/or if it cna retieve it or if it cannot be found. Example:
And Help Viewer is definately a Carbon app, and a very bad/ugly Carbon app for that matter.

My personal opinion is that I don't mind Carbon apps, unless their are written poorly...which seems to be popular. On the other hand, Cocoa developers get more elegent apps quicker by using Cocoa, which I like. And BTW, Sherlock is *not* good example of a well written Carbon app. It has so many UI glitches all over. For example, it never remembers the spacing of display bars in the results (middle) pane. It has lots of other interface quirks all over.

[ 02-16-2002: Message edited by: mactropolis ]

[kennethmac2000]

Originally posted by Developer:
<STRONG>

Download the latest OmniWeb sneaky peek and have a look at its print sheet.</STRONG>

Errrrrrrrr... maybe its Print sheet isn't transparent because it's a Carbon sheet! TextEdit's Print sheet isn't transparent either.

Printing in Mac OS X is handled by Carbon even in Cocoa apps.

From reading the following article, however, it would appear that it has been possible since the advent of Mac OS X 10.1 to create Carbon sheets with transparency. It's just a shame that no developer seems to be doing so!

In fact, have a look at the new Mac OS X version of Toast Titanium. Not only does it use opaque sheets, but the whole application goes into modal mode when a sheet appears. Hardly very in keeping with the spirit of the Aqua HIG is it!?
http://www.interfacemafia.org/articl...8-ar0004.shtml

[Millennium]

Originally posted by Developer:
<STRONG>

It isn't the default, because QuickDraw can't handle the transparency. Apple doesn't know if you are going to draw into the sheet with QuickDraw or not, that's why it is off by default.</STRONG>

The sheet itself isn't drawn by QuickDraw, however. That's done by CoreGraphics, as other windows are. It should be possible to draw over the top of this with QuickDraw, keeping in mind that if something doesn't have a background, then no background is drawn, so the transparent window should still be visible through spaces in text and such.

It's harder to do; I won't deny that. But it's Apple's responsibility to ensure that Carbon and Cocoa apps look and function as closely to identical as is possible, and in this case, it is possible to do better.

This is why people think Carbon's not as good: developers aren't making the effort to make their apps work right. A great deal of the blame for this falls on the developers,of course, but Apple shares a part of that: some of that effort shouldn't have to be made. In the end, that may be the only argument for Carbon bot being as good that I can't see as complete crap: it's hard to make an app that works right, and it's harder than it should be.

[mactropolis]

What I see here is that some of you are overlooking the obvious reason why Cocoa is better: its easier and faster to make a propper Mac OS X.
Most peopling are not acknowleding this itself as a 'feature' of Cocoa -- and gives it another reason why it's superior to Carbon.

Yes, most people agree that its not only the Carbon developers fault. Apple could putforth more effort into Carbon. But lets see, which is the API that Apple wants for the future apps? Which is the one Apple promotes? Which is the one that Apple tells developers their should use? Perhaps a pattern here?
Indeed, Carbon is an excellent interium solutions for developers. But that's not the same as saying it's equal to Cocoa. If Apple wanted Carbon to be _the_ API of OS X, they would/could push Carbon and not make Cocoa as public as it is.

In all, saying their isn't a difference is just wrong.

That "white paper" was nothing more than an advertisement. Wander who wrote it? The CEO of REAL Software himself. Perhaps he doesn't want anyone abandoning REALBasic in favor of Cocoa by swaying the favor of the argument and leaving out important information.

Finally, as others have done in different threads, comparing this to OS 9 is flat-out invalid (MacToolbox vs. PowerPlant vs REALBasic). Those don't compare to Carbon vs. Cocoa as the differences are much less visable (if at all).

[ 02-16-2002: Message edited by: mactropolis ]

[kennethmac2000]

Originally posted by mactropolis:
<STRONG>Yes, most people agree that its not only the Carbon developers fault. Apple could putforth more effort into Carbon. But lets see, which is the API that Apple wants for the future apps? Which is the one Apple promotes? Which is the one that Apple tells developers their should use? Perhaps a pattern here?
Indeed, Carbon is an excellent interium solutions for developers. But that's not the same as saying it's equal to Cocoa. If Apple wanted Carbon to be _the_ API of OS X, they would/could push Carbon and not make Cocoa as public as it is.</STRONG>

LOL. Hangon a minute...

Are you saying that Apple tells the likes of Microsoft, Adobe and Macromedia that they should be using Cocoa!? I doubt it, because if they did, these developers would tell Apple to go stick its head where the sun don't shine.

And Apple *IS* pushing Carbon (albeit with good reason), so they have a duty to make the Aqua experience as good in Carbon apps as it is for Cocoa ones.

[ 02-16-2002: Message edited by: kennethmac2000 ]

[ 02-16-2002: Message edited by: kennethmac2000 ]

[theolein]

Originally posted by ndptal85:
<STRONG>One must keep in mind that Carbon is the API to use for most companies contemplating Mac ports of their Windows software since it is the API most concentrated around C++ (which is what most good Windows software is created in.).

Cocoa is great for developers who don't have other apps to code for or any legacy code bases. But its also personally limiting for the developer since Obj-C is only used on Macs. No one is going to pay $500 and buy WebObjects for Windows just so you can use Obj-C apps on Windows. So for all intents and purposes Obj-C is a Mac OS X only language. Most developers don't want to become familiar in a language that is not an industry standard.

This is why instead of Carbon slowly fading away as intended it is being enhanced to give it all the features Cocoa currently has and for the forseable future Mac OS X will be a 2 API OS which is not a bad thing since having more than one API makes it easier for a developer to choose what to use instead of potentially putting off one group or another.

As time goes on and proper Carbon coding knowledge is aquired developers will learn that there's more to making a good Carbon app than just simply getting it running on OS X. It just takes time. Apple also has a few more features to add to Carbon to bring it up to parity with Cocoa. A year from now most folks won't be able to tell the difference (or care). In the meantime we'll all get great apps coded in either one and I really couldn't care less what they use as long as it runs on OS X period.</STRONG>

What quite a few people seem to forget is that you can write your Cocoa application almost completely in Java. Under the hood all the java classes are simply wrappers around the same ObjC classes. This makes Cocoa very very interresting for Java programmers and Java is a lot simpler in syntax and memory handling than ObjC. One can, although I'm still busy trying to figure out how to mix plain vanilla C headers and ObjC headers, mix C and ObjC with no problem. All you really need ObjC for is the GUI and even there you can use Java although you'll be interfaceing with the system in a different way.

I love Cocoa for this amazing flexiblity. You can even do distributed processing across different machines. OSX/Darwin networks could in theory walk all over Microsoft's .Net with cocoa's distributed services. This is something that makes me wonder sometimes. Apple could have an amazing set of applications if they really worked on it.

[Mr Scruff]

Originally posted by mactropolis:
<STRONG>Yes, most people agree that its not only the Carbon developers fault. Apple could putforth more effort into Carbon. But lets see, which is the API that Apple wants for the future apps? Which is the one Apple promotes? Which is the one that Apple tells developers their should use? Perhaps a pattern here?
Indeed, Carbon is an excellent interium solutions for developers. But that's not the same as saying it's equal to Cocoa. If Apple wanted Carbon to be _the_ API of OS X, they would/could push Carbon and not make Cocoa as public as it is.

In all, saying their isn't a difference is just wrong.

That "white paper" was nothing more than an advertisement. Wander who wrote it? The CEO of REAL Software himself. Perhaps he doesn't want anyone abandoning REALBasic in favor of Cocoa by swaying the favor of the argument and leaving out important information.</STRONG>

Let's get this straight - if Macromedia or Adobe or Microsoft or any other big developer started developing a completely new app tommorow, they would be targeting two api's. Win32 on Windows and Carbon on Mac OS X. Also, they are very unlikely to port any of their existing apps to Cocoa from the existing Carbon.

The reason for this is that for developers, Carbon resembles Win32 a lot more than Cocoa. So if they are trying to support both platforms, it will create a large amount of extra effort for them doing the Mac version in Cocoa. Infact if they had to do that, it's likely many apps would not have OS X versions at all.

When people found out Maya was being done in Carbon for X, many people were surprised. But why should you be? They're porting existing code from one api to another. They are always going to use the api that makes this easiest (Carbon).

If you are doing a Mac OS X only app (like for example Internet Explorer for Mac) then it's possible to consider doing it in Cocoa. If it's cross platform, or based on an already large codebase then it doesn't make any sense whatsoever to do this.

Your arguement seems to be that because many developers have done 'quick and dirty' ports to Carbon, it makes it a poor api. However, without the presence of Carbon, I can guarantee you that you wouldn't have seen many of these apps at all. Infact, you may never have seen them again (except in classic).

[ndptal85]

mactropolis,
Don't worry about the RealBASIC CEO trying to get people to stick with RealBASIC instead of moving over to Cocoa. First that not what he's trying to do. Second, its not as if one is as easy to use as the other.

Despite that Cocoa is a RAD platform (Rapid Application Development) you still need to know how to friggin program with it. You need to know how to code in C so that you can step up to Obj-C. RealBASIC on the otherhand is just a particular version of the BASIC programming languge. No one who actually knows how to code in C, Obj-C or C++ is going to settle for the performance drawbacks that using BASIC causes. 99% of the folks who use BASIC (on any OS, be it VB on Windows or RealBASIC on Windows or Mac) do so because they can't program in anything else.

So yeah Cocoa is easy to use, but only to those who already know how to really code. This would make worrying about a bunch of RealBASIC developers jumping to Cocoa silly. They aren't because most of them can't.