PDA

View Full Version : Carbon vs. Cocoa: A structured debate




GothicChess.Com
Jun 21, 2007, 03:05 PM
Apparently my post regarding the status of the "keyDown" event spawed a new thread wherein the longevity of Carbon was called into question.

So let's throw this out there:

1. Is Carbon here to stay?
2. If Cocoa is the way of the future, what benefits does it have over Carbon?

Let me first preface the discussion with a few thoughts:

Carbon, to me, appears to be a natural way to code. I was around since the "Inside Macintosh: Volume I" days, originally coding in Pascal on a 128 K Mac. Ok, that makes me a dinosaur, so be it :)

But the Carbon API had its seeds in that command structure, and so much of Apple's documentation, even today, fits the "Carbon profile."

Now when I look at Cocoa, I admit, I am lost! The flowery, overly verbose modifiers and prefixes and suffixes just don't make sense to me. They look like a Windows C++ tome painted over with wide brush strokes.

For me, and I would assume for most Carbon diehards, making such a transition is non-trivial. We would, in fact, be functionally at "Programming the Macintosh: Day 1", and this is not a happy thought.

So, given that other developers would probably be in the same boat, I ask the group, what is there to gain by undergoing "programming brain surgery" to learn Cocoa? What can a Cocoa application do/offer/perform that a Carbon app cannot?

Feel free to discuss at length, but please, where you are injecting opinion, please so state.



HiRez
Jun 21, 2007, 03:13 PM
Carbon is here to stay mostly because much of Cocoa is built directly on Carbon data structures. But, Cocoa and Objective-C is a higher-level, more object-oriented programming environment that is more flexible at runtime than Carbon/C is. Personally I far prefer Cocoa and Objective C but then I have more experience with those than Carbon. You say Carbon seems more natural to you but I suspect that's just because it's what you're used to. Give Cocoa/Obj-C a chance and I think you'll like it.

GothicChess.Com
Jun 21, 2007, 03:17 PM
Carbon is here to stay mostly because much of Cocoa is built directly on Carbon data structures. But, Cocoa and Objective-C is a higher-level, more object-oriented programming environment that is more flexible at runtime than Carbon/C is. Personally I far prefer Cocoa and Objective C but then I have more experience with those than Carbon. You say Carbon seems more natural to you but I suspect that's just because it's what you're used to. Give Cocoa/Obj-C a chance and I think you'll like it.

Now that was the level-headed, well thought-out response I was hoping would start things off! Thanks! I am not saying I am turning my back on Objective-C and Cocoa, I am saying I am afraid to face it :)

I think you might be volunteering to take a few arrows in the back though, some of the posts to follow might be a little heated.

Thanks for your input though, much appreciated.

GFLPraxis
Jun 21, 2007, 03:33 PM
You should also consider that Cocoa apps mean your apps can be 64-bit once Leopard hits.
Carbon apps will not get that advantage when running on 64-bit machines.

Krevnik
Jun 21, 2007, 03:36 PM
I would say that killing Carbon at this point would be a bit of suicide. Cocoa isn't good enough for everything, and while I would hope codebases are written cleanly enough to port UI over... the reality is that they aren't.

MS will probably never be able to get rid of Win32 with .NET, and I don't see Apple getting rid of Carbon with Cocoa. The only alternative to Carbon for C-based libaries is POSIX which doesn't have any UI piece to it that works on OS X (very well, anyways). Choice is not something that should be taken away at this point in the OS' life time.

That said, I love Cocoa right now as a rapid application development environment. I have been able to prototype an app in a matter of days, and swap out the Cocoa-provided bits with my own bits to polish and improve functionality. Can't do that with Carbon... but any port to Windows would be hell.

jeremy.king
Jun 21, 2007, 03:39 PM
Taken straight from ADC:

Mac OS X supports both modern and legacy APIs. Most of the legacy APIs derive from the assorted managers that were part of the original Macintosh Toolbox and are now a part of Carbon. While many of these APIs still work in Mac OS X, they are not as efficient as APIs created specifically for Mac OS X. In fact, many APIs that provided the best performance in Mac OS 9 now provide the worst performance in Mac OS X because of fundamental differences in the two architectures.

As Mac OS X evolves, the list of APIs and technologies it encompasses may change to meet the needs of developers. As part of this evolution, less efficient interfaces may be deprecated in favor of newer ones. Apple makes these changes only when deemed absolutely necessary and uses the availability macros (defined in /usr/include/AvailabilityMacros.h) to help you find deprecated interfaces. When you compile your code, deprecated interfaces trigger the generation of compiler warnings. Use these warnings to find deprecated interfaces, and then check the corresponding reference documentation or header files to see if there are recommended replacements.

A developer who fails to adopt Cocoa can't blame Apple, they have been warned.


For me, and I would assume for most Carbon diehards, making such a transition is non-trivial. We would, in fact, be functionally at "Programming the Macintosh: Day 1", and this is not a happy thought.

<opinion>
This is a very thick headed statement. Developers need to evolve as the platform evolves, its as simple as that. You are still a programmer and those same skills apply, just different language and different APIs.
</opinion>

Krevnik
Jun 21, 2007, 03:59 PM
A developer who fails to adopt Cocoa can't blame Apple, they have been warned.

That clip doesn't talk about the deprecation of Carbon, it talks about the deprecation of the really poor toolbox APIs like the Event Manager and QuickDraw that have been long replaced with a proper event management system, Quartz and HIToolbox.


<opinion>
This is a very thick headed statement. Developers need to evolve as the platform evolves, its as simple as that. You are still a programmer and those same skills apply, just different language and different APIs.
</opinion>

That is true, but evolution of code costs money that could be spent evolving your product and making money. Business is almost always trying to find the balance, the larger the business, the slower the evolution because of the increased costs of porting/adapting codebases.

jeremy.king
Jun 21, 2007, 04:05 PM
That is true, but evolution of code costs money that could be spent evolving your product and making money.

True.

My opinion is a little distorted because I am usually making money porting applications to something a little more current. At least the speed of evolution is much slower in the desktop space than the web based space - which is reinventing itself every 2 years!

Krevnik
Jun 21, 2007, 04:12 PM
True.

My opinion is a little distorted because I am usually making money porting applications to something a little more current. At least the speed of evolution is much slower in the desktop space than the web based space - which is reinventing itself every 2 years!

The difference is that web apps have faster turn-around times since the underlying technology isn't changing. Sure your front-end to the user might change rapidly, but HTML, PHP, SQL aren't changing rapidly. That is one extreme: rapid product evolution with little to no platform evolution.

The other extreme is that you get a lot of platform evolution, but little to no product evolution (OS 9 -> OS X is a good example).

The second is really only profitable when platforms change or are added. Having to migrate to OS X from OS 9 or Windows, etc stuff like your work... since you grow the market the product can address, generating sales. Endless churn of updating your app to use the latest APIs for no benefit while addressing the same market size... not so much. :)

GothicChess.Com
Jun 21, 2007, 04:36 PM
A developer who fails to adopt Cocoa can't blame Apple, they have been warned.



I don't see any mention of Cocoa being the API to support and Carbon being the API on the way out anywhere in the statement you quote from ADC.

They were referring to very antiquated API concepts, like MoreMasters(), SetApplicZone(), MaxApplZone(), GetNextEvent(), etc.

Carbon is NOT a software-based blueprint of the original Mac 128K ROM.

<opinion>
I don't think you have furnished any definite proof Carbon is on the way out and Cocoa is preferred by Apple.
</opinion>

I do welcome seeing such evidence as it will direct my future time allocations towards learning Cocoa, if such a learning curve is warranted.

whooleytoo
Jun 21, 2007, 04:37 PM
As long as even one 'big name' application is Carbon based (Photoshop, Quark Xpress, MS Office etc..) then Carbon will be around. Apple is in no position to tell any such developer 'port to Cocoa or get off the Mac'.

The major developers will port to Cocoa - or perhaps more likely they'll start their next generation application in Cocoa - when the costs & risks involved mean it makes more sense to do so, not when Apple decides they will.

From a technical perspective, I was in the identical position to you 4 or 5 years ago, but had to take the time to learn Cocoa; as obscure and verbose as the syntax looks, and as daunting as the framework seems. It's time well spent.

The Carbon vs Cocoa debate is virtually the stereotypical API vs framework discussion: an (in this context, non-OO) API exposes functionality in its barest form, and requires you to build it into your program piece by piece.

But a framework goes a step further and groups functionality together - you don't just want to create a bare-bones application but an application that has a menubar, responds to Notifications and AppleEvents. You don't just want to create a window, but a window which can be maximised, minimised, dragged around, resized and has a view for drawing into. In Carbon you do all this yourself, in Cocoa it's done for you.

Of course, there are C++ Carbon frameworks too, but <personal prejudice here> I don't trust them. You're then dependent on a (non Apple) third party to stay in business, not be bought out, not change business direction and abandon the product. It introduces a middle-man into the development equation. Plus it introduces a degree of latency - if Apple introduces a major OS release, the 3rd party framework may well require substantial changes too, which you need to wait for before you can fix your own application</prejudice>.

If you want to develop a new application for OSX, learn Cocoa. It's easier if you have a project to keep you focused, rather than training for training's sake.

Just work with a goal in mind. Try the following, and look at the Xcode documentation and online tutorials (cocoadev.com, cocoadevcentral.com, macdevcenter.com are among the best):

- Learn the string classes, how to divide a string up, concatenate strings etc.
- Learn how to add and manipulate items in arrays.
- Now use strings to build an array of paths of all the files in a given folder on your hard drive (hint: there's a subset of NSString methods that'll help you here)
- Next, try finding out how to draw a table or outline view and populate it with the array you just built. (Personally, I'd recommend steering away from the bindings tutorials for now - they're a little obtuse - and look for tutorials that draw table views with datasources & delegates).
- Next, add a few buttons, and using the NSFileManager object, make these buttons open, delete or duplicate the selected file.
- Finally, look at the documentation for QTMovie, and QTMovieView, and see if you can put a movie view in your window. If the user clicks on a file that's a movie (hint: check the file extension), display the selected movie in the movie view.

Viola.. you have a basic media library application!

Certainly, Apple's documentation is nowhere near the quality of the Inside Macintosh volumes (very little documentation is!), but no doubt it's more difficult to maintain quality documentation due to the pace of change these days.

GothicChess.Com
Jun 21, 2007, 04:42 PM
You should also consider that Cocoa apps mean your apps can be 64-bit once Leopard hits.
Carbon apps will not get that advantage when running on 64-bit machines.

The question is, to what extent is 64-bit applicability denied to the Carbon API?

For example, my primary concerns are memory, and, to a lesser extent, being able to read and write files > 4 GB.

If I buy a 16 GB MacPro and attempt to do a malloc() of, say, 8 GB, will the malloc() call fail under Carbon?

I don't think so. While such a call is only requiring "33 bits" since 2 ^33 is about 8 GB, as long as I can cross the 32-bit limit of 4 GB, I know my app will be able to use the <overkill> I intend for it.

File size read/writes, in my case, can be broken down into 2 GB or even 1 GB chunks.

But the RAM, I need the RAM!

So, my main question is, can you malloc() more than 4 GB on a machine with that much RAM using Carbon?

GothicChess.Com
Jun 21, 2007, 05:02 PM
As long as even one 'big name' application is Carbon based (Photoshop, Quark Xpress, MS Office etc..) then Carbon will be around. Apple is in no position to tell any such developer 'port to Cocoa or get off the Mac'.

Well, if you were correct about that, I would agree with you :) You see, the original owner of Quark sold his business for like $1 billion and bailed out prior to the OS X conversion. And, the new owner came close to going bust because of the extremely long time it took Quark to get up to speed. Even dedicated publishing houses like BookMasters.com that relied heavily on Quark dropped them like a rock when they continually delayed their OS X rollout. I know this for a fact because I was publishing a book in Quark at the time and they let me know they would only be supporting Quark OS 9 for a few months longer, and they encouraged me to change over to something else.



The Carbon vs Cocoa debate is virtually the stereotypical API vs framework discussion: an (in this context, non-OO) API exposes functionality in its barest form, and requires you to build it into your program piece by piece.

But a framework goes a step further and groups functionality together - you don't just want to create a bare-bones application but an application that has a menubar, responds to Notifications and AppleEvents. You don't just want to create a window, but a window which can be maximised, minimised, dragged around, resized and has a view for drawing into. In Carbon you do all this yourself, in Cocoa it's done for you.


That is true too, but there is a down side to all of this. For example, I recently wanted to create a group of 3 radio buttons, simple enough, correct? There is a way to create a cluster of "N" radio buttons easily, and the API will switch the radio button "bullet" to the one you select, and de-select the other one for you, automatically.

However... using this predefined format means you cannot execute a command on a radio button hit, you can only "read" its state, and take some other action when some other event occurs, such as pressing a button named "Apply", or something like that.

I have a floating palette up with a few radio buttons on it. When I hit a radio button, I want to switch modes right away, and steer the program to take subsequent action based on this mode change. If I used the radio button cluster as it is bundled, I would have to create another button, then execute 2 clicks every time I wanted this change -- one click on my radio button in the group, then another click on the button I did not want there :)

This is contrary to Apple's own User Interface Guidelines -- why do in 1 click what you can do in 2?

This was a minor example, but a poignant one I believe.

In fact, I never got around to programming my radio buttons to change state after I press them, I was just in a hurry to get it done "the old fashioned way".


Of course, there are C++ Carbon frameworks too, but <personal prejudice here> I don't trust them. You're then dependent on a (non Apple) third party to stay in business, not be bought out, not change business direction and abandon the product. It introduces a middle-man into the development equation. Plus it introduces a degree of latency - if Apple introduces a major OS release, the 3rd party framework may well require substantial changes too, which you need to wait for before you can fix your own application</prejudice>.


I agree with that 100% and have seen what has happened to those who had large Borland libraries in the PC World. Of course, Micro$oft engineered their failure by releasing new operating systems that only IT knew how to code, then they released all new versions of their software that worked on the new OS, as the rest of the world struggled to buy the new Micro$oft compiler, the new Micro$oft developer training classes, the new Micro$oft certification courses....



If you want to develop a new application for OSX, learn Cocoa. It's easier if you have a project to keep you focused, rather than training for training's sake.


You know, I would, if Apple would only release a few demo applications with all of the source files, well commented. I can soak up a language/API like a sponge if I could "crib" off some existing source, I have a knack for it :) But I have yet to see a complete program, and all of the snippets I have do the same thing in widely different ways, and that contributes a great deal to my own confusion.

So, if you know of any such sites with code examples that compile under XCode, lead me there, and I will follow!

Krevnik
Jun 21, 2007, 05:03 PM
The question is, to what extent is 64-bit applicability denied to the Carbon API?

For example, my primary concerns are memory, and, to a lesser extent, being able to read and write files > 4 GB.

If I buy a 16 GB MacPro and attempt to do a malloc() of, say, 8 GB, will the malloc() call fail under Carbon?

I don't think so. While such a call is only requiring "33 bits" since 2 ^33 is about 8 GB, as long as I can cross the 32-bit limit of 4 GB, I know my app will be able to use the <overkill> I intend for it.

File size read/writes, in my case, can be broken down into 2 GB or even 1 GB chunks.

But the RAM, I need the RAM!

So, my main question is, can you malloc() more than 4 GB on using Carbon?

It depends, that isn't clear yet, since nobody really knows the full extent of support for 64-bit Carbon will or will not have, even the Apple devs on the mailing lists are unclear. malloc actually is provided by the POSIX layer, and you can write apps meant to run in 4+GB virtual address spaces for 10.4 now, but you don't get UI support.

The catch is that Carbon is where all the C-based UI code lives.

Krevnik
Jun 21, 2007, 05:10 PM
That is true too, but there is a down side to all of this. For example, I recently wanted to create a group of 3 radio buttons, simple enough, correct? There is a way to create a cluster of "N" radio buttons easily, and the API will switch the radio button "bullet" to the one you select, and de-select the other one for you, automatically.

However... using this predefined format means you cannot execute a command on a radio button hit, you can only "read" its state, and take some other action when some other event occurs, such as pressing a button named "Apply", or something like that.


Is this in Interface Builder? Carbon or Cocoa?

In Interface Builder, if you can get just the one radio button selected, then you can assign it an action when it gets selected to your controller (in Cocoa). Pretty straight-forward. To be honest, I have never tried this in XCode with Carbon. I did try it with carbonized PowerPlant once. It was still kinda messy.


You know, I would, if Apple would only release a few demo applications with all of the source files, well commented. I can soak up a language/API like a sponge if I could "crib" off some existing source, I have a knack for it :) But I have yet to see a complete program, and all of the snippets I have do the same thing in widely different ways, and that contributes a great deal to my own confusion.

So, if you know of any such sites with code examples that compile under XCode, lead me there, and I will follow!

The problem with a framework is that you enter the land of 'anything you can do to glue A and B together, works'. Samples can show you 3-4 different ways to do the same thing, and all are right.

To get a kickstart into Cocoa, I actually recommend the O'reilly books on the subject. They got me in far enough for Apple's reference docs to take over.

Nutter
Jun 21, 2007, 05:15 PM
Carbon is here to stay mostly because much of Cocoa is built directly on Carbon data structures.

This is often repeated, but I don't think it's true. You are probably referring to Core Foundation, a framework that underlies both Carbon and Cocoa. Core Foundation is in C, but that doesn't make it Carbon.

Some parts of Cocoa do use Carbon internally, such as NSMenu and NSAppleEventDescriptor ... that's about it I think. I suspect that NSMenu may have to change in Leopard as Apple seem to be abandoning 64-bit support in much of Carbon, including the Menu Manager.

The question is, to what extent is 64-bit applicability denied to the Carbon API?


This is a very controversial issue (http://www.carbondev.com/site/?page=64-bit+Carbon) at the moment. It appears that Apple have 64-bit Carbon more or less up and running, but may axe parts of it for reasons unknown. The bits that will be dropped are the UI-related bits - in other words, most things that a Cocoa developer might want will be there in 64-bit Carbon, but not much else.

Of course 32-bit Carbon is still perfectly viable, but a lot of developers are taking this as a sign that Carbon is a dead end.

And no, I don't think you can allocate more than 4 GB of memory in a 32-bit world. That is the whole point of 64-bit!

SC68Cal
Jun 21, 2007, 05:28 PM
There is no debate. Carbon is old, deprecated, and is going to get shut out in the cold like OS 9 emulation. This is what has happened with 64-bit support.

All you Carbon types spread FUD about how "Cocoa is built on top of Carbon" you're absolutely wrong. Apple has bent over backwards creating toll-free functions for you to take advantage of Cocoa technology.

Toll-free functions != "Cocoa is built on top of Carbon"

Technote TN2034 was a warning. All you greybeard OS9 fools vomited with rage when that was released. Daring Phucball jumped up and down and had enough people on his side to influence the game, at least, that is he wanted to believe. We don't have that luxury today. Vista is a mess, and people are looking for alternatives. Nobody wants to play with OS 9 again. It was dead the day it was delivered, and I REFUSE TO PURCHASE OR RECCOMEND OS X in a NETWORKED ENVIRONMENT if it will not behave itself and work like a UNIX system.

I threw out our old OS 9 boxes. I don't want any more.

Now that OS X doesn't have the ability to rot away in obscurity, Technote TN2034 will have to be taken seriously.

elppa
Jun 21, 2007, 05:55 PM
Apple has made it clear from day one (see here (http://fr.youtube.com/watch?v=Ko4V3G4NqII) — 4:45 in) that cocoa is the way to go and the way they want developers to write proper Mac OS X applications. Carbon was an intermediate step. I am not a programmer and I know this and have known it for sometime.

Surely it would have been better having a look 7 years ago at the cocoa frameworks and gradually building up your knowledge?

I don't mean to sound harsh but this post sounds awfully naïve. I mean who really expects to program in one language/framework/style all their life? Technologies move on, so should you.

Krevnik
Jun 21, 2007, 06:33 PM
There is no debate. Carbon is old, deprecated, and is going to get shut out in the cold like OS 9 emulation. This is what has happened with 64-bit support.

All you Carbon types spread FUD about how "Cocoa is built on top of Carbon" you're absolutely wrong. Apple has bent over backwards creating toll-free functions for you to take advantage of Cocoa technology.

Toll-free functions != "Cocoa is built on top of Carbon"

Technote TN2034 was a warning. All you greybeard OS9 fools vomited with rage when that was released. Daring Phucball jumped up and down and had enough people on his side to influence the game, at least, that is he wanted to believe. We don't have that luxury today. Vista is a mess, and people are looking for alternatives. Nobody wants to play with OS 9 again. It was dead the day it was delivered, and I REFUSE TO PURCHASE OR RECCOMEND OS X in a NETWORKED ENVIRONMENT if it will not behave itself and work like a UNIX system.

I threw out our old OS 9 boxes. I don't want any more.

Now that OS X doesn't have the ability to rot away in obscurity, Technote TN2034 will have to be taken seriously.

With all due disrespect... TN2034 also told you to use Carbon Events to help reduce your CPU usage down to zero while idle. ;)

The thing is... Carbon is not the old monster of horror known as the Toolbox and InterfaceLib. As long as Windows is the dominate force with tons of Win32 apps, a clean, maintained C API is a great way to get developers onto the platform. You don't burn the bridge until the victim is on /your/ side of the bridge.

And since Carbon is not InterfaceLib, and sits on the same BSD environment that Cocoa does, saying that it must be UNIX doesn't discount Carbon in any way, especially since you have pthreads, sockets, etc, all sitting right there. And you know, it would be great to be able to actually optimize a game once and awhile without running into the wonderful overhead that a dynamic runtime thrusts on you. Sure, OpenGL is C, but not all the supporting APIs I need are in OpenGL/POSIX.

And this is coming from someone who writes code predominately in C# and Obj-C.

GothicChess.Com
Jun 21, 2007, 06:35 PM
And no, I don't think you can allocate more than 4 GB of memory in a 32-bit world. That is the whole point of 64-bit!

Well, you have to be very, very clear on what you mean by "world".

For example, hard drives have been > 4 GB for eons now, even attached to a 32-bit OS you can still address what is at hard drive byte location 2^32 + 1, and beyond. This is because the OS farms out to the hard drive controller.

Conversely, the Mac was "originally" a 32-bit microprocessor, yet you could never allocate more than 1 GB of RAM because Apple used the upper 2-bits of their 32 to store the handle states for calls such as LockHandle()!

When did Apple become "truly" 32-bit clean? Was it when that "Mode32" startup extension fixed Apple's mess, or was it when Apple officially redid the Operating System?

The same can be tossed around regarding 64-bit-ness. With ANSCI C-90 (or was it 99? I forget now) we have the first instance of 64-bit vars that your compiler can use, so you can enumerate more than 4 billion with a counter. But this is clearly 64-bit emulation and not a measure of true 64-bit capabilities.

Look at Microsoft's "64-bit" operating System. They only have 36-bits addressable for RAM management, meaning a 64 GB limit for memory.

All of these "mixed" implementation of bit-ness means you really have to investigate what is meant by the associated terms.

GothicChess.Com
Jun 21, 2007, 07:02 PM
Apple has made it clear from day one (see here (http://fr.youtube.com/watch?v=Ko4V3G4NqII) — 4:45 in) that cocoa is the way to go and the way they want developers to write proper Mac OS X applications. Carbon was an intermediate step. I am not a programmer and I know this and have known it for sometime.

Surely it would have been better having a look 7 years ago at the cocoa frameworks and gradually building up your knowledge?

I don't mean to sound harsh but this post sounds awfully naïve. I mean who really expects to program in one language/framework/style all their life? Technologies move on, so should you.

Well pardon me for becoming the Chief Executive Officer of a company and graduating from being a daily coder!

I have been developing on the PC for the past 7 years, co-authoring the 2004 World Computer Chess Champion (see http://www.chessville.com/GothicChess/ComputerWorldChampionships.htm for example).

I program on the Mac as a hobby, and I am "diving back in" again.

By the way, I also wrote Blackjack Deluxe, a program that was voted one of Mac User's "50 All-Time Best Shareware Programs" in 1996.

So there!

:)

Nutter
Jun 21, 2007, 07:16 PM
Sure, you can access files larger than 4 GB with a 32-bit process, but you can't keep it all in memory at once.

That 16 GB of RAM isn't going to be any use to you unless you're able to address more than 4 GB at once, and for that you need 64-bit pointers.

(Not quite true, as the OS is perfectly capable of sharing out that memory among various processes, but you see my point I hope. Anyway, off-topic! I reckon that if you spent a little time with Objective-C and Cocoa you would most likely enjoy yourself. I would recommend doing so, even if just to satisfy your curiosity. Objective-C is a very elegant language and not at all difficult to learn.)

Krevnik
Jun 21, 2007, 07:38 PM
Sure, you can access files larger than 4 GB with a 32-bit process, but you can't keep it all in memory at once.

That 16 GB of RAM isn't going to be any use to you unless you're able to address more than 4 GB at once, and for that you need 64-bit pointers.

(Not quite true, as the OS is perfectly capable of sharing out that memory among various processes, but you see my point I hope. Anyway, off-topic! I reckon that if you spent a little time with Objective-C and Cocoa you would most likely enjoy yourself. I would recommend doing so, even if just to satisfy your curiosity. Objective-C is a very elegant language and not at all difficult to learn.)

In some cases, 4GB files really shouldn't all be in memory at once.

An analogy of 32 to 64-bit is a bit like moving from a 4000 sq ft home to a mansion when you lived alone most of the time. While the old 16 to 32-bit move was a bit more like moving from a Japanese apartment in downtown Tokyo to the 4000 sq ft home. You get a lot more benefit moving out of the apartment than you do the house.

Some things do need the extra address space, most of them are in academia like VT's cluster running expensive computations. My mother certainly doesn't need it.

Thinine
Jun 21, 2007, 08:58 PM
The thing is... Carbon is not the old monster of horror known as the Toolbox and InterfaceLib. As long as Windows is the dominate force with tons of Win32 apps, a clean, maintained C API is a great way to get developers onto the platform. You don't burn the bridge until the victim is on /your/ side of the bridge.

And since Carbon is not InterfaceLib, and sits on the same BSD environment that Cocoa does, saying that it must be UNIX doesn't discount Carbon in any way, especially since you have pthreads, sockets, etc, all sitting right there. And you know, it would be great to be able to actually optimize a game once and awhile without running into the wonderful overhead that a dynamic runtime thrusts on you. Sure, OpenGL is C, but not all the supporting APIs I need are in OpenGL/POSIX.Carbon may not entirely consist of the horrors known as Toolbox and InterfaceLib anymore, but those clean C APIs you point to aren't Carbon either. CoreFoundation, CoreServices, CoreText, etc. may be partly derived from old Carbon stuff (CoreServices especially) but part of the transition is changing the API to adopt more modern conventions, rather than the 20 year old conventions of traditional Carbon. These are also the frameworks that can be made cross platform, as we saw with CoreFoundation and Safari 3 for Windows.

Cocoa, as it was on OpenStep, before Apple bought it, was a complete framework that encompassed all of the functionality of the OpenStep OS. But when Apple decided to add Carbon to Mac OS X, the also decided that Cocoa had to access some of that functionality. As it turns out, they used a lot more old Carbon functionality for important stuff than they put into Cocoa, perhaps making Cocoa seem more limited than it could have been.

To Everyone: According to Apple engineers, the only part of Cocoa to ever be based on Carbon (directly) are parts of the UI functionality. And even that is going to be removed for Leopard (there is a new CoreUI private framework).

Krevnik
Jun 21, 2007, 09:29 PM
Carbon may not entirely consist of the horrors known as Toolbox and InterfaceLib anymore, but those clean C APIs you point to aren't Carbon either. CoreFoundation, CoreServices, CoreText, etc. may be partly derived from old Carbon stuff (CoreServices especially) but part of the transition is changing the API to adopt more modern conventions, rather than the 20 year old conventions of traditional Carbon. These are also the frameworks that can be made cross platform, as we saw with CoreFoundation and Safari 3 for Windows.

HIToolbox is part of Carbon, was written explicitly as a MacOS X API... and won't be 64-bit for Leopard.

For many programmers, Carbon is a term that encompasses much of the C API set on OS X that Cocoa doesn't use, and isn't part of the BSD/POSIX API set. So part of the annoying debate misses out on C APIs that have been introduced that will likely be 64-bit (DiscBurning, CoreImage/CoreVideo/CoreAudio, etc).

SC68Cal
Jun 21, 2007, 09:41 PM
For many programmers, Carbon is a term that encompasses much of the C API set on OS X that Cocoa doesn't use, and isn't part of the BSD/POSIX API set. So part of the annoying debate misses out on C APIs that have been introduced that will likely be 64-bit (DiscBurning, CoreImage/CoreVideo/CoreAudio, etc).

This is exactly right. Carbon was written to make a fast transition and recompile for applications that were originally written for the MacOS.

czeluff
Jun 21, 2007, 10:39 PM
let me kill this thread, right here right now :P

I went to WWDC. Carbon isn't going 64-bit, Cocoa is.

Done! ;)

cz

iSee
Jun 21, 2007, 11:57 PM
let me kill this thread, right here right now :P

I went to WWDC. Carbon isn't going 64-bit, Cocoa is.

Done! ;)

cz

Yeah. Whether it's official or not, Apple's made its priorities clear. When something had to give, they cut Carbon features. They didn't cut Cocoa. They didn't push Leopard's ship date back farther. They made the choice to cut Carbon 64. It's going to be more of the same in the future.

Now, I don't think all of Carbon will really ever be deprecated. Apple will want to continue to support all the Carbon apps out there. But as Cocoa continues to grow, Carbon will remain static--shrinking even, as Apple finds more APIs it can get away with deprecating and even dropping.

This leaves cross-platform (Mac/Win or Mac/Win/*nix) development in an interesting spot. Typically, at some level, a cross-platform framework wraps native APIs in a platform neutral interface (or you implement a subset of one platform's APIs in terms of native APIs and call that your "neutral" interface). Cocoa hasn't usually been the API wrapped because using the pure-C APIs (inevitably including lots of Carbon APIs) is a more natural fit.

You could wrap Cocoa, but you've got a difficult choice because the Cocoa frameworks are only available on Mac OS. Either you've got to hide all the dynamic OO goodness of Cocoa from the generic API (in which case, what's the point), or you've got to implement equivalent functionality on the other platforms--a very difficult task. Even Java has not done this really well. MS is porting a subset of .NET to OS X for Silverlight, but it is really a very small subset that will only be appropriate for certain kinds of apps.

I guess Apple is going to have to finally release and support Cocoa on Windows and *nix and give cross-platform development a huge boost.

MongoTheGeek
Jun 21, 2007, 11:59 PM
let me kill this thread, right here right now :P

I went to WWDC. Carbon isn't going 64-bit, Cocoa is.

Done! ;)

cz

So did I. Parts of carbon will be 64 bit. Namely all of the low level stuff. Parts of it won't be,n namely most of the GUI. How much is TBD.

That being said there is nothing that prevents C++ code from being 64 bit. There is nothing that prevents you from throwing a cocoa face on a carbon app. Done it myself.

I believe but I have no knowledge of how, that you can even mix 64 and 32 bit code together. 64 bit under the hood and 32 for the display. Honstly who really needs a an image with 32 quadrillion colors?

They have been getting people to mix and match these things for years. This is mnerly an attempt to drag people kicking and screaming into an easier to use pardigm. Don't worry. While Carbon will evnetually be going away, its not leaving anytime soon. Expect it to not be deprecated until at least 10.7

just my opinion.

Fukui
Jun 22, 2007, 01:36 AM
let me kill this thread, right here right now :P

I went to WWDC. Carbon isn't going 64-bit, Cocoa is.

Done! ;)

cz

Yea, and judging from the clapping in the audience when it was announced, a supported decision.....

garethlewis2
Jun 22, 2007, 03:24 AM
Can we get one thing perfectly clear please.

Cocoa is not built on top of Carbon. Carbon appeared after Cocoa as a bridge for developers who coded on Mac OS 7,8,9. Cocoa is NextStep built from 1986 onwards.

It seems the instant someone sees CoreFoundation, they think incorrectly of Carbon. CoreFoundation is as its name implies the CoreFoundation of OS X on top of BSD. It is written in C as it doesn't represent a layer your application will need to use in everyday tasks. Nearly every single part of Cocoa is built on this. Carbon is buiilt on top of CoreFoundation, and Cocoa is built ontop of CoreFoundation.

What does Cocoa bring over Carbon? Nothing if you want to code primarily in C. If on the other hand you want to write a program with a dynamic OO language then you have to use Objective-C.

Fukui
Jun 22, 2007, 03:29 AM
++

caveman_uk
Jun 22, 2007, 04:38 AM
You know, I would, if Apple would only release a few demo applications with all of the source files, well commented. I can soak up a language/API like a sponge if I could "crib" off some existing source, I have a knack for it :) But I have yet to see a complete program, and all of the snippets I have do the same thing in widely different ways, and that contributes a great deal to my own confusion.

So, if you know of any such sites with code examples that compile under XCode, lead me there, and I will follow!
The source for text edit is installed with the xcode tools. It's in

/Developer/Examples/AppKit/TextEdit

gnasher729
Jun 22, 2007, 06:45 AM
You should also consider that Cocoa apps mean your apps can be 64-bit once Leopard hits.
Carbon apps will not get that advantage when running on 64-bit machines.

Carbon will be available as 64 bit, once Apple evangelists get their ***es kicked by enough developers.

gnasher729
Jun 22, 2007, 06:49 AM
This is exactly right. Carbon was written to make a fast transition and recompile for applications that were originally written for the MacOS.

That was years ago. Since then all the transitional stuff has been deprecated in Carbon and has been thrown out by developers long ago. Carbon today is one of the finest APIs I have ever seen. And if you compare Carbon and Cocoa documentation - the question is: Which Cocoa documentation?

whooleytoo
Jun 22, 2007, 06:59 AM
Well, if you were correct about that, I would agree with you :)

Alright..alright.. I'm not a graphic designer so I've no idea what the cool kids are drawing with these days.:p But the point remains - it's the 'must have' application developers who'll determine when Carbon dies, Apple can only nudge them in the "right" direction by slowly strangling Carbon.


However... using this predefined format means you cannot execute a command on a radio button hit, you can only "read" its state, and take some other action when some other event occurs, such as pressing a button named "Apply", or something like that.


As pointed out below, you can - in Cocoa at least. Just create an NSAction for the radio buttons and connect it in Interface Builder.

Just because the framework classes do a lot for you, doesn't mean you can't then customise it to suit your needs.


You know, I would, if Apple would only release a few demo applications with all of the source files, well commented. I can soak up a language/API like a sponge if I could "crib" off some existing source, I have a knack for it :) But I have yet to see a complete program, and all of the snippets I have do the same thing in widely different ways, and that contributes a great deal to my own confusion.

So, if you know of any such sites with code examples that compile under XCode, lead me there, and I will follow!

TextEdit is one app mentioned, I think Sketch is another.

garethlewis2
Jun 22, 2007, 08:43 AM
Carbon may be very well written. Cocoa is also very well written. Apple, specifically Jobs wants applications written in Objective-C and now Objective-C 2.0. That rules out Carbon. Objective-C isn't difficult to program in. If you can code in C and have the smallest smidgen of access to SmallTalk or Java you could switch over coding styles in a week.

mags631
Jun 22, 2007, 09:55 AM
Regardless whether Apple deprecates all of Carbon or not, it is clear where the emphasis is being placed. This seems to be analogous to the debate: code in .NET or Win32 API directly? Maybe the API's are there (and maybe forever), but I'm guessing new capabilities and general support will be for Cocoa (akin to .NET).

GothicChess.Com
Jun 22, 2007, 10:27 AM
Carbon will be available as 64 bit, once Apple evangelists get their ***es kicked by enough developers.

Needless to say, this is about 100% opinion.

I am looking for facts.

:)

elppa
Jun 22, 2007, 10:30 AM
Well pardon me for becoming the Chief Executive Officer of a company and graduating from being a daily coder!

I have been developing on the PC for the past 7 years, co-authoring the 2004 World Computer Chess Champion (see http://www.chessville.com/GothicChess/ComputerWorldChampionships.htm for example).

I program on the Mac as a hobby, and I am "diving back in" again.

By the way, I also wrote Blackjack Deluxe, a program that was voted one of Mac User's "50 All-Time Best Shareware Programs" in 1996.

So there!

:)

I didn't know this, I wrongly assumed you were a pro programmer. So sorry. :D

That said, my advice still stands, Apple has made it clear that if you want to develop new apps for Mac OS X, then you should be looking to use the Cocoa frameworks.

SC68Cal
Jun 22, 2007, 11:13 AM
Needless to say, this is about 100% opinion.

I am looking for facts.

:)

Something the greybeards haven't been in touch with since System 8

gnasher729
Jun 22, 2007, 11:59 AM
Carbon may be very well written. Cocoa is also very well written. Apple, specifically Jobs wants applications written in Objective-C and now Objective-C 2.0. That rules out Carbon. Objective-C isn't difficult to program in. If you can code in C and have the smallest smidgen of access to SmallTalk or Java you could switch over coding styles in a week.

That is completely missing the point that rewriting our application to use Cocoa would cost us months of programmers time, require a complete test cycle which usually keeps two guys busy for four weeks, and doesn't give either my company or our customers any benefits whatsoever.

gnasher729
Jun 22, 2007, 12:00 PM
Needless to say, this is about 100% opinion.

I am looking for facts.

:)

The arse kicking is fact.
Message to Steve Jobs: Sorry, mate, no 64 bit version.

MacRohde
Jun 22, 2007, 12:13 PM
That is completely missing the point that rewriting our application to use Cocoa would cost us months of programmers time, require a complete test cycle which usually keeps two guys busy for four weeks, and doesn't give either my company or our customers any benefits whatsoever.

Right on!

It's easy enough to say "just rewrite in Cocoa 'cause it's even better" but if you've got a codebase and manpower invested in Carbon it might just not make any economical sense whatsoever.

GeeYouEye
Jun 22, 2007, 12:16 PM
Moving to 64-bit Cocoa from 32-bit Cocoa won't be exactly a walk in the park either... there's some pretty significant ABI and runtime changes as well.

If you don't actually need a 64-bit UI (and really, how many people do?), then just write your computation code in a CLI app and just call it from your Carbon app.

Incidentally, I wonder if you can fork()/exec() from a 32-bit executable to a 64-bit executable...

cblackburn
Jun 22, 2007, 12:27 PM
That is true too, but there is a down side to all of this. For example, I recently wanted to create a group of 3 radio buttons, simple enough, correct? There is a way to create a cluster of "N" radio buttons easily, and the API will switch the radio button "bullet" to the one you select, and de-select the other one for you, automatically.

However... using this predefined format means you cannot execute a command on a radio button hit, you can only "read" its state, and take some other action when some other event occurs, such as pressing a button named "Apply", or something like that.

That is just completely untrue in every way. Attached is a sample I threw together in 10 mins showing the functionality you suggested.

I'm not saying carbon is useless or anything but 99% of what you can do in carbon you can do in Cocoa and, in my opinion, much better.

Chris

SC68Cal
Jun 22, 2007, 12:57 PM
That is just completely untrue in every way. Attached is a sample I threw together in 10 mins showing the functionality you suggested.

I'm not saying carbon is useless or anything but 99% of what you can do in carbon you can do in Cocoa and, in my opinion, much better.

Chris

I think I saw a sample of this, where they did the same thing in Carbon. I might be wrong here in my recollection, but it wasn't very pretty.

EDIT: Found it
Here (http://wilshipley.com/blog/2006/10/pimp-my-code-part-12-frozen-in.html)

jeremy.king
Jun 22, 2007, 04:19 PM
That is completely missing the point that rewriting our application to use Cocoa would cost us months of programmers time, require a complete test cycle which usually keeps two guys busy for four weeks, and doesn't give either my company or our customers any benefits whatsoever.

I guess that depends on what you sell. If its a shrink wrap kind of product, then a rewrite could add new features or UI fluff :) which would allow you to market it as a new version. New customers pay full price and existing customers have the option to upgrade at a discounted rate. This revenue will help offset your investment in development with the added benefit of future proofing yourself from the eventual deprecation of Carbon. You will most likely make gains in productivity as well as Cocoa development is often faster than Carbon. I consider that a benefit. Also, as you grow you will find a bigger pool of talented Cocoa developers to choose from. Another benefit.

Its a cost of doing business as a software development company, eventually you will rewrite/refactor/reversion/repackage. The longer you wait, the greater the risk.

You are right though, your customers only care about one thing - Does it work? They don't care if its Carbon, Cocoa, Java, or GTK...You as a business owner, need to consider both the long term strategy and technical direction of your company while pleasing customers at the same time. It's a difficult balance but claiming no benefit from a newer technology seems a little pessimistic.

gnasher729
Jun 22, 2007, 05:21 PM
Moving to 64-bit Cocoa from 32-bit Cocoa won't be exactly a walk in the park either... there's some pretty significant ABI and runtime changes as well.

Oh come on. If you have code that runs on bigendian and littleendian machines, and that isn't written by complete morons, then switching from 32 to 64 bit is no problem at all. There are some people whose code runs on anything from ARM to Alpha and Itanium.

The difference is: The changes that might have been necessary to move from 32 bit Carbon to 64 bit Carbon, that was something that I could sell to management. There would have been _real_ speed differences, plus 64 bit is good for marketing. The changes to move from Carbon to Cocoa, that is nothing I would even try to sell, because it would just make me look like an idiot.

GothicChess.Com
Jun 22, 2007, 06:01 PM
Something the greybeards haven't been in touch with since System 8

Everyone who has written a Macintosh program that Steve Wozniak bought and personally wrote a check to you, raise your hand.

<raises my hand>

:)

GothicChess.Com
Jun 22, 2007, 06:19 PM
I guess that depends on what you sell. If its a shrink wrap kind of product, then a rewrite could add new features or UI fluff :) which would allow you to market it as a new version. New customers pay full price and existing customers have the option to upgrade at a discounted rate. This revenue will help offset your investment in development with the added benefit of future proofing yourself from the eventual deprecation of Carbon.

This wins the EASIER SAID THAN DONE AWARD by a landslide!

1. That is a Micro$oft Mindset in Microcosm -- "add some feature, charge more, sell upgrades", even if there is really no need for the "fluff" that was appended to the software package.

2. Where do you think the money is coming from to pay for the upfront development to make the product(s) happen? You can't create demand for a non-existant product, nor can you spend money on sales that haven't happened yet!

3. The time-to-revenue would be extremely long, and time-to-profitability much longer. If your focus group marketing showed something like:

$profitability/manpower cost = K/time to develop

...where "K" is some very attractively large constant, your most critical factor would not be manpower cost, but time to develop. In that case:

$profitability = K x manpower cost/time to develop

Since manpower cost is tied to development time, the quicker you get it out the door, the better off you will be. But, as we know:

• development time for such an undertaking would be long
• The constant "K" is most likely not large
• Operations cost are ongoing, even if there is no profit!

Krevnik
Jun 22, 2007, 11:42 PM
Moving to 64-bit Cocoa from 32-bit Cocoa won't be exactly a walk in the park either... there's some pretty significant ABI and runtime changes as well.

If you don't actually need a 64-bit UI (and really, how many people do?), then just write your computation code in a CLI app and just call it from your Carbon app.

Incidentally, I wonder if you can fork()/exec() from a 32-bit executable to a 64-bit executable...

This is the recommended way to run an app that needs 64-bit in Tiger, FYI. So yes, it is possible.

It does complicate your app somewhat though, since you are now talking about interprocess communication.

Catfish_Man
Jun 23, 2007, 01:17 AM
One nitpick; the Cocoa menu system is built on top of the Carbon MenuManager. The rest of Cocoa is, as stated in the thread earlier, unrelated to Carbon (mostly built on CoreFoundation or other lower level APIs).

I'm also wondering whether we'll get a Cocoa replacement for HITheme for custom control drawing. I know of several cocoa apps that use it (fairly major ones).

mags631
Jun 23, 2007, 07:48 AM
Any one have metrics on LOC differences between Carbon and Cocoa for same functionality? I have to believe Carbon source code > Cocoa source code given that Cocoa requires much more handling by the developer... but I don't have any metrics on that. Links?

garethlewis2
Jun 23, 2007, 07:55 AM
Here is how it really works.

You build an application in Carbon and then tell Apple to screw themselves for mandating the use of Cocoa. Your competitor decides that using Cocoa and all the features and ease of use that brings is worth the risk. One year later, your product is no longer used and theirs is. And yes, this is how things are done in the real world.

I work in Financial software development. The previous company I worked at continued using C when everybody else was moving to Java or C#. The head of IT stated the risk of moving to Java was too great. They were the biggest supplier of financial software to Wall Street and all investment banks. One year later, they had no customers. The CIO's of all the banks had read the releases from Gartner and Sun stating C's days were over as an enterprise platform due to massive problems with memory overruns and requiring a particular platform to run on. They were not willing to give in to the companies worries about cost rewrite or testing. Nobody in Finance uses C, the front office guys use C++ and Motif as they still believe this is the fastest way to run a program. They are a minority.

Eraserhead
Jun 23, 2007, 08:01 AM
I have to believe Carbon source code > Cocoa source code given that Cocoa requires much more handling by the developer...

Why, Cocoa seems to require less work than Carbon according to Wil Shipley (http://www.wilshipley.com/blog/2006/10/pimp-my-code-part-12-frozen-in.html), and his arguments, at least on that make sense.

gnasher729
Jun 23, 2007, 08:46 AM
Why, Cocoa seems to require less work than Carbon according to Wil Shipley (http://www.wilshipley.com/blog/2006/10/pimp-my-code-part-12-frozen-in.html), and his arguments, at least on that make sense.

Cocoa isn't bad at all for new development, especially for Mac-only new development, plus if you want to use some really nice new features then you are actually restricted to Leopard only development. Makes lots of sense for in house development where you can control what OS the end users are running.

Cocoa is awful for cross-platform development. All the good features are pointless, because you have to rewrite everything from scratch for Windows, for example. Using Carbon, you can take an existing Windows application and turn it into something that looks right on Windows, looks right on MacOS X and is maintainable for the future (not everybody does it right, it requires having developers who understand the Mac and MacOS user interface, but it is not really difficult). With Cocoa, you can't do that. You have to rewrite the user interface completely.

elppa
Jun 23, 2007, 09:03 AM
Cocoa isn't bad at all for new development, especially for Mac-only new development, plus if you want to use some really nice new features then you are actually restricted to Leopard only development. Makes lots of sense for in house development where you can control what OS the end users are running.

Cocoa is awful for cross-platform development. All the good features are pointless, because you have to rewrite everything from scratch for Windows, for example. Using Carbon, you can take an existing Windows application and turn it into something that looks right on Windows, looks right on MacOS X and is maintainable for the future (not everybody does it right, it requires having developers who understand the Mac and MacOS user interface, but it is not really difficult). With Cocoa, you can't do that. You have to rewrite the user interface completely.

Unless Cocoa gets ported to Windows…

jeremy.king
Jun 23, 2007, 12:16 PM
1. That is a Micro$oft Mindset in Microcosm -- "add some feature, charge more, sell upgrades", even if there is really no need for the "fluff" that was appended to the software package.

Nope...hate to break it to you, but this is just how the software world works. Even Apple does this with every major OS upgrade. :eek:

2. Where do you think the money is coming from to pay for the upfront development to make the product(s) happen? You can't create demand for a non-existant product, nor can you spend money on sales that haven't happened yet!

Well, this particular example was about an existing company, so they should have some level of ongoing sales/support revenue to help offset the initial development.


3. The time-to-revenue would be extremely long, and time-to-profitability much longer. If your focus group marketing showed something like:

$profitability/manpower cost = K/time to develop

...where "K" is some very attractively large constant, your most critical factor would not be manpower cost, but time to develop. In that case:

$profitability = K x manpower cost/time to develop

Since manpower cost is tied to development time, the quicker you get it out the door, the better off you will be. But, as we know:

• development time for such an undertaking would be long
• The constant "K" is most likely not large
• Operations cost are ongoing, even if there is no profit!

Profitability = Revenue - Cost where costs including development time, marketing, support and distribution amongst other things. Not sure what your K constant is supposed to represent - perhaps you are trying to show that some costs are the same no matter what technology is being used.

Using your own formula, since the time to develop is generally much faster using Cocoa, its in the business' best interest to adopt it for greater profitability.

GothicChess.Com
Jun 23, 2007, 03:35 PM
The previous company I worked at continued using C when everybody else was moving to Java or C#. The head of IT stated the risk of moving to Java was too great. They were the biggest supplier of financial software to Wall Street and all investment banks. One year later, they had no customers.

<opinion> This sounds extremely exaggerated. I know of some pretty bad companies, especially from the mid 1980's, that built their foundations on matchsticks that survived longer than a year amidst seas more turbulent than those "waves" that are created merely by the consequence of your development platform! Come on, who can run off 100% of their own customer base, even IF they did plaster all of the Wall Street Journal "We code in C, we code in C" ? How can the external buyer say "Damn, this was written in C, I ain't buying it!", can you tell me that?
</opinion>

GothicChess.Com
Jun 23, 2007, 03:45 PM
Nope...hate to break it to you, but this is just how the software world works. Even Apple does this with every major OS upgrade. :eek:

I ran two software startup companies. One in the late 1980's early 1990's (Circumflex Software) and one in the mid 1990's (Infinite Loop Software.) Your example is NOT how the software world works.


Well, this particular example was about an existing company, so they should have some level of ongoing sales/support revenue to help offset the initial development.

Very, very poor assumption when you talk about jumping to entirely different coding environment. You can't "offset" something unless you have 100% of it in cash reserves to start. Do you even work for a real software development company? Some of your comments reflect extremely puerile thinking.



Profitability = Revenue - Cost where costs including development time, marketing, support and distribution amongst other things. Not sure what your K constant is supposed to represent - perhaps you are trying to show that some costs are the same no matter what technology is being used.

Using your own formula, since the time to develop is generally much faster using Cocoa, its in the business' best interest to adopt it for greater profitability.

My formula was a first order extraction governing only the model of switching platforms, not an general formula applicable businesswide. And, you missed the point.

The time to develop an entire company's software suite as Cocoa applications is NOT faster if you are talking about retraining an entire staff first! Or, I suppose you would fire everyone and hire Cocoa staff and tell them to build it from scratch?

Do us all a favor, talk about stuff you know.

jsw
Jun 23, 2007, 03:52 PM
I ran two software startup companies. One in the late 1980's early 1990's (Circumflex Software) and one in the mid 1990's (Infinite Loop Software.) Your example is NOT how the software world works.I work for a large corporation and work on network appliance management software. kingjr3's model describes exactly what we've done with that product - add features to make the people on maintenance feel they're getting their money's worth because they see new things listed with each upgrade. It's cheap, easy money. And companies are very much interested in cheap, easy money. Yes, someone uses every new feature. But no one uses all of them, and many are minor.
Very, very poor assumption when you talk about jumping to entirely different coding environment. You can't "offset" something unless you have 100% of it in cash reserves to start. Do you even work for a real software development company? Some of your comments reflect extremely puerile thinking.Well, you need to be able to finance it over the development period, so you don't need 100% to start. You need income sufficient to handle the development costs as they occur.
The time to develop an entire company's software suite as Cocoa applications is NOT faster if you are talking about retraining an entire staff first!It depends on how strategic your plans are. If you're living quarter to quarter, you won't do it until you need to, and then you'll go a long time without revenue. If you can think longer-term, you'd start doing it earlier.

GothicChess.Com
Jun 23, 2007, 06:08 PM
I work for a large corporation and work on network appliance management software. kingjr3's model describes exactly what we've done with that product - add features to make the people on maintenance feel they're getting their money's worth because they see new things listed with each upgrade.

Adding features for features' sake is not a way to build repoire with your clients.

And, does your company advertise it's practice of spawning versions it has no core belief in, other than the knowledge it will lead to more money downstream?

Whenever we released a new version, we were all proud of the enhancement, and we were sure there was "nothing left to add" because the new version was "so great."

We had dedicated staff in place to actually read letters and emails sent to us by users. This staff would review the requests, correspond with the user base, and prototype recommended changes that were seemingly worthwhile. We would send specialized betas to these core users, with their names emblazoned in their special version's about box, and we developed a large, loyal base of testers this way.

With so much positive feedback, we would eventually realize "Hey that guy in Tulsa has a pretty good idea, I think we should roll this out in the next version..."

And that's how we made the next version, and we were sure there was "nothing left to add" because the new version was "so great." :)

GothicChess.Com
Jun 23, 2007, 06:17 PM
It depends on how strategic your plans are. If you're living quarter to quarter, you won't do it until you need to, and then you'll go a long time without revenue. If you can think longer-term, you'd start doing it earlier.

It depends how strategic the stockhoders will tolerate you mean :) If your profit-to-earnings ratio thins out, so will your investor base. If you want to start getting granular, so can I :) You can't just withhold small chunks of money for some forever-away-date to dump when it comes time to make major revisions without an Executive Board Meeting. It's also tough to keep such big plans "secret" for a long time, and, inevitably, there is some competitor who will get wind of it, then leverage something to counter your initiative.

That's how the real software industry operates, not with non-stop rollouts served up to deep-pocketted lemmings.

iSee
Jun 23, 2007, 08:19 PM
An analogy of 32 to 64-bit is a bit like moving from a 4000 sq ft home to a mansion when you lived alone most of the time. While the old 16 to 32-bit move was a bit more like moving from a Japanese apartment in downtown Tokyo to the 4000 sq ft home. You get a lot more benefit moving out of the apartment than you do the house.

LOL! That's the best analogy I've seen no this. Back in the 16-bit days you constantly had to deal with the the limitations and tradeoffs. While there are definitely certain circumstances where 32-bits aren't enough, it is not a central issue, day-to-day, for most apps.

jeremy.king
Jun 23, 2007, 08:53 PM
*Snip some endless blabbing about how great you were*

Do us all a favor, talk about stuff you know.

Ed, what's the point of starting this thread if you have all the answers? :rolleyes:

I don't need you to "learn" me how the software world works. In fact, the software world is much different than the 80s and 90s and its more than Blackjack or Chess, that's for sure. People want more and more and they want it now. Customers are impatient and are more than happy to pay for new versions. You wonder why things like Agile Methodologies are so popular nowadays - it's because software needs to change and adapt faster and faster.

You say you worked for two startups in the 80s and the 90s? Where exactly are those companies you mentioned today? What products were so great that they are still around today? Oh wait?! Let me guess, you got burned when OS X couldn't run them anymore? I really am curious all mighty one.

You are right, I don't work for a software company. I am a consultant and I have been in and out of various software companies so I have seen how they operate. I have seen what works and what doesn't. Speaking of which, why would you list your past companies as software consulting firms on your profile on GothicChess?

RacerX
Jun 23, 2007, 09:17 PM
Carbon, to me, appears to be a natural way to code. I was around since the "Inside Macintosh: Volume I" days, originally coding in Pascal on a 128 K Mac. Ok, that makes me a dinosaur, so be it :)What you should take into consideration is the fact that many of the people that designed the software environment for the 128K Mac left Apple with Steve Jobs and started creating NEXTSTEP.

For me, and I would assume for most Carbon diehards, making such a transition is non-trivial. We would, in fact, be functionally at "Programming the Macintosh: Day 1", and this is not a happy thought.But at what level are you really at when you are at "Programming the Macintosh: Day 1" with Cocoa compared to "Programming the Macintosh: Day 1" with Carbon?

With no programming background at all I can have a functioning app running within a short time with Cocoa... but the same couldn't be said with Carbon. I started on Macs back in 1987 and never got beyond a Hello World type of app (not counting AppleScripts). But I was able to create functional, useful apps in OPENSTEP on my first day. One of the reasons NeXT systems took off in many math departments was that with no programming experience at all people could write elaborate apps that could access Mathematica's kernel as their math engine.

So, given that other developers would probably be in the same boat, I ask the group, what is there to gain by undergoing "programming brain surgery" to learn Cocoa? What can a Cocoa application do/offer/perform that a Carbon app cannot?While it should be noted that these days it is short sighted to think of this as a one or the other type of thing (you should be trying to take advantage of both where ever you can), the primary advantage of Cocoa is the same as it has been since almost day one back in the late 1980s... services.

The primary idea (beyond object oriented programming) of this environment was to make sure that developers didn't waste time reinventing the wheel with each new app. A great example is spell checking. Word has a spellchecker, so does AppleWorks and QuarkXPress, and even Illustrator. Why should you have four spell checking engines with four custom dictionaries? That is the type of thing that developer's shouldn't have to worry about.

Or how about font handling? A friend of mine (Andrew Stone who wrote the first third party app for NeXT systems) wrote TextArt for NEXTSTEP back in 1988 building on that system's Postscript foundations. He had started out much like you writing apps in Pascal on the Mac, but was able to make incredible software almost instantly on NeXT (TextArt, which later became Create, and DataPhile).


In all reality, you are doing yourself a major disservice saying that Cocoa looks like Windows because Cocoa and you have similar origins back with the original Mac. Instead you should embrace your shared heritage with Cocoa.

jsw
Jun 23, 2007, 09:31 PM
Adding features for features' sake is not a way to build repoire with your clients.It seems to be generating revenue for us as well as for a number of other companies who do the same thing.
And, does your company advertise it's practice of spawning versions it has no core belief in, other than the knowledge it will lead to more money downstream?No, because that would be stupid.
Whenever we released a new version, we were all proud of the enhancement, and we were sure there was "nothing left to add" because the new version was "so great."I note the past tense.

What you did was great for apps you build because you love them, but not so great for apps you build so you can continue to have a job. If you wait until there's nothing left to add, you lose revenue on future releases. Software is a business, and the business of business is to make money.
We had dedicated staff in place to actually read letters and emails sent to us by users. This staff would review the requests, correspond with the user base, and prototype recommended changes that were seemingly worthwhile. We would send specialized betas to these core users, with their names emblazoned in their special version's about box, and we developed a large, loyal base of testers this way.Again, nice and also past tense, but you opened yourself up to lawsuits if someone recommended something and you implemented it, especially unscrupulous customers that would suggest patent-infringing features.
And that's how we made the next version, and we were sure there was "nothing left to add" because the new version was "so great." :)So... how's it selling now?
It depends how strategic the stockhoders will tolerate you mean :) If your profit-to-earnings ratio thins out, so will your investor base. If you want to start getting granular, so can I :) You can't just withhold small chunks of money for some forever-away-date to dump when it comes time to make major revisions without an Executive Board Meeting.No, you plan for release dates and hit them. We do.
That's how the real software industry operates, not with non-stop rollouts served up to deep-pocketted lemmings.Really. Well, we must know about different industries, then.

SC68Cal
Jun 23, 2007, 10:29 PM
Everyone who has written a Macintosh program that Steve Wozniak bought and personally wrote a check to you, raise your hand.

<raises my hand>

:)

Raise your hand if you care. This is not relevant to the debate.

In fact, didn't Wozniak back a lot of ventures and products that took a nosedive?

SEGWAY POLO ANYONE?

Greybeard.

GothicChess.Com
Jun 23, 2007, 10:57 PM
No, because that would be stupid.

My point exactly! If you TELL your customers about WHAT YOU DO, you would lose business! Yet, you have no problem doing it! Don't you have a conscience?

What you did was great for apps you build because you love them, but not so great for apps you build so you can continue to have a job.

NOT TRUE!

I built a small company that had only 4 products, one of them a shareware Blackjack program that was only $20. The shareware was released from 1991-1993, then the company was launched. We discontinued the shareware in 1993, launched the 4 programs product suite, sold the apps from 1993-1998, built up a consulting practice with the software sales revenue, sold BOTH businesses, and I retired at age 32. Then I started something else when I got bored :)

BUT WE WERE STILL GETTING SHAREWARE REGISTRATIONS IN 2003, 10 YEARS LATER!

While diminished greatly by that time, there were still about 1800 per year at $20 each = $36,000 a year. That's one product, on a dead platform, 10 years after final cutoff, and still generating revenue. It's like record sales for Elvis, going on long after he moved on. Of course, the checks went uncashed, but that is not the point.


Again, nice and also past tense, but you opened yourself up to lawsuits if someone recommended something and you implemented it, especially unscrupulous customers that would suggest patent-infringing features.

1. Our customers were loyal, not bloodsuckers.
2. We had attorneys on retainer when there was any doubt.
3. We're not stupid.
4. I have a U.S. Patent, #6,481,716 issued on November 19, 2002, so I am well versed in intellectual property matters.

So... how's it selling now?

The businesses were sold for a scalar multiple of their annual revenue streams to someone who took it to the next level. No mortgage on my 3 homes, no car payments for the rest of my life, so you tell me if I did the right thing :)

janey
Jun 24, 2007, 04:43 AM
I am looking for facts.
Well, judging from the lack of info about how much of Carbon won't be 64bit, are you expecting people to pull facts out of their asses or break NDA?
Your example is NOT how the software world works.
Do you realize that if you just read what you replied to and thought about it, it's practically what Apple and everyone else in the industry does all the time? You absolutely don't even have to be doing this for a long time or even know much to see this with plain eyes.

Or are you actually saying that Apple doesn't "'add some feature, charge more, sell upgrades', even if there is really no need for the 'fluff' that was appended to the software package."? I'm sure there's a LOT of things out there that changed in Leopard, Tiger...10.x, 9.x, ... that people considered as "fluff" or unnecessary but upgraded for various reasons.

"Fluff" is also highly subjective. I think Front Row is fluff. Automator is fluff. Time Machine is fluff. Dashboard is fluff. I think Voiceover updates in Leopard are sweet as hell, but I'm quite sure there are lots of people out there who don't know what Voiceover is, so for them it might as well be fluff.

Honestly, out of the over 300 "new features" in Leopard, how much of that will be fluff to you? I bet you won't even notice 300 "new features".
Everyone who has written a Macintosh program that Steve Wozniak bought and personally wrote a check to you, raise your hand.

<raises my hand>

I won't be very impressed until you have a Knuth check.

Eraserhead
Jun 24, 2007, 09:53 AM
How can the external buyer say "Damn, this was written in C, I ain't buying it!", can you tell me that?
</opinion>

Because this is Finance software, if it isn't secure or is unreliable it isn't worth running, the amount of money lost for a software crash isn't worth it.

Adding features for features' sake is not a way to build repoire with your clients.

That's what MS does, and they are one of the worlds largest companies.

With no programming background at all I can have a functioning app running within a short time with Cocoa... but the same couldn't be said with Carbon.

One interesting point that I have noticed recently is the amount of Mac only freeware/shareware that is excellent, and a lot of it is free too. There is more than when I was running Windows a couple of years ago, which is incredible given that Windows has 15x the market share, it shows that the Mac development tools and frameworks are far better than on Windows.

When I was using OS 8/9 back in 1998, I noticed that most Mac free/shareware was expensive and not anything like as numerous as for Windows 98. Whereas now the situation has reversed, even though Windows has continued to dominate.

GothicChess.Com
Jun 24, 2007, 11:41 AM
Because this is Finance software, if it isn't secure or is unreliable it isn't worth running, the amount of money lost for a software crash isn't worth it.

So you are saying EVERY program written in C is unreliable and not worth running? And how many C programs do you think have been written in the last 41 years??

I have written Finance Software add-on modules for ADP, which ran on the payroll server at Morgan, Lewis, & Bockius, LLP, which was the 4th largest lawfirm in the United States at the time (was like 1998.) It was a C program that linked directly to the First Union Bank in Philadelphia (now Wachovia) and it moderated the outbound feed and performed some complex transactions on the overseas payroll, which ADP does not get involved with. It effected the people in the offices in Brussels, London, Tokyo, Jakarta, and Frankfurt.



That's what MS does, and they are one of the worlds largest companies.

They are also the most corrupt. They were investigated by the Department of Justice for unlawful business practices, remember? Netscape created a fantastic product, the web browser, and Microsoft tried to absorb their innovation by making it part of the OS, cutting off the outside worlds' attempt to market their own browsers, which were vastly superior at the time.

kainjow
Jun 24, 2007, 11:42 AM
This thread has gotten way off track. We're discussing Carbon vs Cocoa, not software development business strategies.

1. Is Carbon here to stay?

No. As you have already seen, they are not investing 100% into 64-bit Carbon, but they are investing 100% into 64-bit Cocoa.

2. If Cocoa is the way of the future, what benefits does it have over Carbon?

See below.

Carbon, to me, appears to be a natural way to code. I was around since the "Inside Macintosh: Volume I" days, originally coding in Pascal on a 128 K Mac. Ok, that makes me a dinosaur, so be it :)

That's simply a matter of what you're comfortable with.

For example, Cocoa bindings is not "natural" to me since I started learning Cocoa before bindings, and bindings to me now doesn't add much benefit. Fortunately, bindings isn't "the future" but it's merely a convenience. But I have to learn it, either way (already know it fairly well).

What can a Cocoa application do/offer/perform that a Carbon app cannot?

Well, like I said, Apple is now investing everything into Cocoa. It is the future. It is easy to rapidly develop full featured applications in it. We are now in the time where most hard things have been done for us, and so we get to concentrate on what the actual app does. Like someone else said, it is given that every window you create in your app will all be closable, draggable, minimizable, etc. We don't need to implement that ourselves. It is a checkbox away. That is how Cocoa differs from Carbon.

It is 2007. Cocoa is mature. I am sorry that you are just now realizing that Cocoa is the "top dog" for OS X programming. But if you want to continue your career as a Mac developer, you must learn Cocoa (unless you want to write drivers all your life ;)).

GothicChess.Com
Jun 24, 2007, 11:52 AM
I won't be very impressed until you have a Knuth check.

My check was for a great deal more than $2.56, which is basically chicken feed considering Knuth has people "working for free" as proof-editors, a pretty good scheme.

I hold no candle to Knuth, I'm sure it's reciprocal.

:)

Well, like I said, Apple is now investing everything into Cocoa. It is the future.

That being said, is there some, definitive references, the functional equivalent of the old Inside Macintosh volumes, for Macintosh Cocoa programming?

And, is there an expected "drop dead" date when Carbon apps won't run on a Macintosh?

Eraserhead
Jun 24, 2007, 11:58 AM
So you are saying EVERY program written in C is unreliable and not worth running?

Of course not, look lets compare two different markets, I don't think I'm an expert but anyhow. In scientific computing you use one of two languages C or Fortran, you use those as they are fast and well established, in this reliability is important but at the end of the day if you lose a few hours due to a software crash you can recode the software and try again, someone else can use the supercomputer while you are dealing with your crash and its not a big deal compared to the speed advantage which allows you to model the situation better in a given time period. Of course if you crash the whole computer then its a big deal, but they use UNIX so it's unlikely to occur.

Whereas in Finance compared to the amount of money involved the computations aren't that computationally expensive, and if the system goes down you can lose millions and millions of dollars very quickly. So they don't need quite as fast a computer but it needs to keep running over and over, so Java and C# are better languages for that.


They are also the most corrupt.

Well yes, but they are a very successful software company and make a lot of money, which was my point.

EDIT @Netscape, on the Mac in 1998 we had IE and Netscape, I used IE because it was a better product, now it isn't but it was actually better then.

jsw
Jun 24, 2007, 12:29 PM
That being said, is there some, definitive references, the functional equivalent of the old Inside Macintosh volumes, for Macintosh Cocoa programming?
Yes. The online examples and Xcode help are vastly superior to the old Inside Macintosh volumes, which were so comprehensive and dense that they actually made it more difficult to learn anything. I mean, seriously, they were over a foot of shelf space, printed on incredibly thin paper (with ink whose smell I still cannot forget), and that was for an OS substantially less complex than today's.

The example programs available should be more than sufficient. The one thing I'm waiting for are Objective-C books that are updated with the improvements to that language that are in Leopard.

Fukui
Jun 24, 2007, 01:50 PM
That being said, is there some, definitive references, the functional equivalent of the old Inside Macintosh volumes, for Macintosh Cocoa programming?

And, is there an expected "drop dead" date when Carbon apps won't run on a Macintosh?

Have you logged into apple.developer.com and gone to the documentation section under "Cocoa?" There are many reference papers for cocoa. Look on Amazon.com if you can't find enough info. Aaron Hilegass has some excellent stuff.....

If your looking for a single definitive reference, your not gonna find it, cocoa is evolving so fast with each release there has been no time to make a "definitive" guide... the best you can do is read all the latest material, starting with Intro to Objective-C (2.0 if you can access it), Intro to Cocoa Programming, Intro to Core Data etc...

kainjow
Jun 24, 2007, 02:38 PM
And, is there an expected "drop dead" date when Carbon apps won't run on a Macintosh?

It looks like Apple is still adding features and improving Carbon, but not at the rate of Cocoa. No one knows when it will be unsupported - probably not for a long time. But they will probably stop adding features to it "soon". I think it will go the way of QuickDraw: it will continue to be part of the OS for several more versions, but will become deprecated in favor of Cocoa.

janey
Jun 24, 2007, 03:11 PM
My check was for a great deal more than $2.56, which is basically chicken feed considering Knuth has people "working for free" as proof-editors, a pretty good scheme.
The value of a knuth check is not in how much the check is for (btw it's $2.56 for every mistake, not every check is for $2.56) but rather in that you found a mistake in one of his books, which are not nonexistant, but still pretty difficult to find. Hell, I can hardly read some of the chapters in TAOCP, let alone be in any position to find any mistake. Something about MIX assembly doesn't appeal to me.

...regardless, you'd have to be a total idiot to cash it, or to want it for the money.

GothicChess.Com
Jun 24, 2007, 04:04 PM
Have you logged into apple.developer.com and gone to the documentation section under "Cocoa?" There are many reference papers for cocoa. Look on Amazon.com if you can't find enough info. Aaron Hilegass has some excellent stuff.....

That was partly my point, seems like there are "too many"...

If your looking for a single definitive reference, your not gonna find it, cocoa is evolving so fast

... again, that is part of the problem, trying to catch a running train...

kainjow
Jun 24, 2007, 04:06 PM
That was partly my point, seems like there are "too many"...


... again, that is part of the problem, trying to catch a running train...

Just grab this (http://www.bignerdranch.com/products/cocoa1.shtml) book and start from there. Don't worry about Tiger/Leopard-only technologies. Just learn the language and the basic concepts first.

GothicChess.Com
Jun 24, 2007, 04:09 PM
The value of a knuth check is not in how much the check is for

There is no value to me at all. Do you put on your resume: "I have a Knuth check?" I mean, who cares, seriously.

I only mentioned I have a check from Steve Wozniak because he actually bought a software program that I wrote. He even mentions this on his website, woz.org, here:

http://www.woz.org/maclinks/cool.html

janey
Jun 24, 2007, 04:14 PM
There is no value to me at all....
Why on earth would you mention it on a resume?

You have little interest in the Knuth check, and we have little interest in your Woz check.

To quote you..."who cares, seriously"? It was irrelevant when it was first mentioned.

GothicChess.Com
Jun 24, 2007, 04:23 PM
It was irrelevant when it was first mentioned.

The relevance was, some clown was implying because I am not a diehard Cocoa programmer that I had never coded anything of significance.

Getting a check from the co-founder of Apple who purchased something I had personally authored completely shot down his pithy remarks.

Knuth has no relevance compared to Wozniak with regard to this forum.

Your mention was the one that was irrelevant.

janey
Jun 24, 2007, 04:25 PM
The relevance was...
Nope, it was still pretty irrelevant. It's like saying I'm a die hard mac fan and even more so cause I met Woz. Hm, not really.

Doesn't give it much significance either.

GothicChess.Com
Jun 24, 2007, 05:17 PM
Just grab this (http://www.bignerdranch.com/products/cocoa1.shtml) book and start from there. Don't worry about Tiger/Leopard-only technologies. Just learn the language and the basic concepts first.

Thanks for that tip, and thanks for contributing something MEANINGFUL to this discussion, unlike some of the blatant pissant trolls who have nothing better to do.

I'll check it out, although I think the learning curve for this Cocoa stuff is probably fairly steep.

SC68Cal
Jun 24, 2007, 05:25 PM
Jesus, you are such a whiner Chess.

You complain about picking up a new programming language? Are you serious?

You must have slept through Computer Science 101, where they tell you "Don't worry about the specific implementation of the language, you need to learn the concepts behind the programming language."

In the space of a few months I went from some Java, to PHP & MySQL and learning some basic C as a hobby.

I don't have any problems picking up a new language. BECAUSE THEY ALL FOLLOW THE SAME FUNDAMENTAL CONCEPTS.

No wonder you're writing a chess program.

Eraserhead
Jun 24, 2007, 05:49 PM
I'll check it out, although I think the learning curve for this Cocoa stuff is probably fairly steep.

I love the book, you can do the extensions to stretch yourself or not depending on how you feel.

FWIW I didn't find it too difficult and beforehand the only programming I had done was a bit of Applescript and about 6 months of Java.

No wonder you're writing a chess program.

It does seem like a fairly good Chess program though ;).

GothicChess.Com
Jun 24, 2007, 06:08 PM
It does seem like a fairly good Chess program though ;).

In the history of computer chess, it is well known that Ken Thompson's $600,000 (1982 prices) Belle program was the first ever artificial intelligence player to make Master in United States Chess Federation play.

What is not well known, is that when I was still 20, my own Macintosh chess program, The Sniper, was the first software program to break the 2200 Master barrier, just 4 years after Thompson. (Belle was a hardware program, a dedicated machine, funded by Bell Labs.)

It did so on a Macintosh 512 KE, running on an 800K floppy disk that also had the operating system on it as well as the program! (I didn't have a computer with a hard drive yet, can you even imagine??) And, I did this in my spare time, while double majoring in Electrical and Computer Engineering :)

Later, other hardware machines broke master, like the Fidelty Mach III and the Fidelty Mach IV Master, but The Sniper was about 5 years ahead of the next software program to break Master.

Eraserhead
Jun 24, 2007, 06:13 PM
What is not well known, is that when I was still 20, my own Macintosh chess program, The Sniper, was the first software program to break the 2200 Master barrier.

If you are as good a programmer as what you've said implies you'll have no problems learning Cocoa, and I suspect you'll like it, pick up the Hillegass book (http://www.amazon.com/Cocoa-Programming-Mac-OS-2nd/dp/0321213149/ref=pd_bbs_1/103-4182780-7314252?ie=UTF8&s=books&qid=1176315336&sr=8-1) and give it a try.

garethlewis2
Jun 25, 2007, 02:22 AM
Gothic you want an example.

Take ADP. They bought the company I worked at. Wilco.

Look at Wilco on ADP's site. Then look at Calypso.

See which one has all the customers and makes the money. It isn't ADP and it isn't Wilco.

All investment banks moved over from C to Java or C# to get away from the common fact that nearly 50% of bugs in C programs are memory related issues. With C++, 50% of problems are subtle memory related issues, usually concerning when to use references, pointers and copy constructors. If you aren't using an equivalent of garbage collection in C++ your program will always contain subtle memory errors, unless you are writing the noddiest of programs.

GothicChess.Com
Jun 25, 2007, 02:49 AM
Gothic you want an example.

Take ADP. They bought the company I worked at. Wilco.

Look at Wilco on ADP's site. Then look at Calypso.

See which one has all the customers and makes the money. It isn't ADP and it isn't Wilco.

All investment banks moved over from C to Java or C# to get away from the common fact that nearly 50% of bugs in C programs are memory related issues. With C++, 50% of problems are subtle memory related issues, usually concerning when to use references, pointers and copy constructors. If you aren't using an equivalent of garbage collection in C++ your program will always contain subtle memory errors, unless you are writing the noddiest of programs.

ADP prints about 1 out of every 3 paychecks on the continent of North American, and payroll is not even their core business. I'm sure they're making some money!

You can take the cushiest development environment in the world, in the hands of a bad programmer, you will still crash with graphic animation and sound :)

I'm sorry, but if I can solve a checkmate in 268 moves in C (see http://www.gothicchess.com/javascript_endings.html ) there ain't no way some rinky-dink little financial emulation is gonna make me run out of memory.

:)

GothicChess.Com
Jun 25, 2007, 02:54 AM
If you are as good a programmer as what you've said implies you'll have no problems learning Cocoa, and I suspect you'll like it, pick up the Hillegass book (http://www.amazon.com/Cocoa-Programming-Mac-OS-2nd/dp/0321213149/ref=pd_bbs_1/103-4182780-7314252?ie=UTF8&s=books&qid=1176315336&sr=8-1) and give it a try.

I'm just lazy now in my old age of 40...

I'll definitely pick the book up after my next vacation.

Compile 'em all
Jun 25, 2007, 03:58 AM
rinky-dink little financial emulation

:)

There is no such thing as little financial applications. If you think that since you coded a chess app you can easily implement an application that supports scalability/replication/transaction_management/pooling then you are dreaming.

Every programming language is good at doing somethings and not others. C is a good choice for a coding a kernel but not a good one for a web application. A good programmer will use the right tools to get the job done.

GothicChess.Com
Jun 25, 2007, 10:09 PM
There is no such thing as little financial applications. If you think that since you coded a chess app you can easily implement an application that supports scalability/replication/transaction_management/pooling then you are dreaming.

Every programming language is good at doing somethings and not others. C is a good choice for a coding a kernel but not a good one for a web application. A good programmer will use the right tools to get the job done.

If you were correct, I would agree with you :)

I have written programs that play checkers, chess, and Gothic Chess, a much harder version of chess with more pieces [see http://www.GothicChess.com for example, and if not interested for the chess game, then maybe the 6'5" tall blonde that I hired will catch your eye :) ]

I also owned a software development company on Long Island and a computer consulting business. I could code financial management apps standing on my head underwater faster than most secretaries could type.

Trust me, financial apps are just lengthy and tedious to maintain. Chess programs require a much higher degree of precision and are much more detail-oriented.

Once you write your first chess program, let me know.

garethlewis2
Jun 26, 2007, 02:30 AM
So how did you define your pricing models?

Considering they have a varied amount of data, and you are looking to exploit the market.

The only people I know that have done this earn 9 million a year and work for Nomura, Meryl Lynch, Goldman Sachs and RBS. The 9 million is their salary and they can earn more than 30 million in bonuses. These guys could not code a financial simulation in the time it takes their secretary to type a letter. The mathematics required is so complex they don't hire anyone unless they have PHd in Theoretical Physics or Mathematics. The coding part is done by drones, but the interesting part of modelling a gigantic simulation with millions if not billions of variables is modelled by PHds. If you could write something like this and were not working for an IB, then you are without a doubt the smartest person on the planet.

GothicChess.Com
Jun 26, 2007, 12:42 PM
So how did you define your pricing models?

Considering they have a varied amount of data, and you are looking to exploit the market.

The only people I know that have done this earn 9 million a year and work for Nomura, Meryl Lynch, Goldman Sachs and RBS. The 9 million is their salary and they can earn more than 30 million in bonuses. These guys could not code a financial simulation in the time it takes their secretary to type a letter. The mathematics required is so complex they don't hire anyone unless they have PHd in Theoretical Physics or Mathematics. The coding part is done by drones, but the interesting part of modelling a gigantic simulation with millions if not billions of variables is modelled by PHds. If you could write something like this and were not working for an IB, then you are without a doubt the smartest person on the planet.

I told you a million times, don't exaggerate :)

I have published a few artificial intelligence papers, appeared in a textbooks in some CompSci Departments' libraries, two domains usually reserved for PhDs, of which I have none.

The Wright Brothers were bicycle mechanics, yet they invented the field of Avaiation.

Albert Einstein was a Swiss patent clerk, yet he published "Relativity" and demonstrated that the Newtonian Physics metaphor was lacking a great deal.

I think in today's day-and-age people are way too hung up on "credentials", but here are a few of mine:

The book I am in:
Advances In Computer Games 10 (ISBN 1-4020-7709-2)
http://www.springer.com/west/home?SGWID=4-102-22-33325233-0&changeHeader=true&referer=www.wkap.nl&SHORTCUT=www.springer.com/prod/b/1-4020-7709-2

My papers:

http://www.gothicchess.com/80.pdf
80-SquareChess. ICGA Journal, Vol.27, No.2,pp.81-95.
Notable for having solved a "Holy Grail" of chess -- how to mathematically compute the values of any chess piece, given a rectangular board of any non-zero dimension.

The Perfect 7-Piece Checkers Database.
ICGA Journal, Vol.26, No.4,pp. 229-238.
Notable for proving that it is possible to be in a winning checkers position with as few as 7 pieces on the board, and every other program in the world could not carry out the win, since the solution was far beyond a contemporary horizon of search (253 plies total). The only solution was to map every one of the 19 billion 7-piece endings all the way to mate, not "just" know if they were theoretical wins, losses, and draws. This undermined 40 years of A.I. thinking, and had a great deal of impact among researchers that have always used checkers as their software "Drosophilidae".

lazydog
Jun 26, 2007, 03:56 PM
I've been following this thread because I thought I could learn something about the future directions of Mac development, but I can't remain silent anymore… sorry!


I think in today's day-and-age people are way too hung up on "credentials", but here are a few of mine:

Oh man… this is such an uncool thing to do!!!

As for Chess programs… I'm sure that most of the regular contributors to this forum could write a half decent chess program if they wanted to.

b e n

GothicChess.Com
Jun 26, 2007, 04:07 PM
As for Chess programs… I'm sure that most of the regular contributors to this forum could write a half decent chess program if they wanted to.

b e n

Will all due respect, you have no clue what you are talking about! While there are many chess programs out there, that in no way trivializes what is required in terms of the skillsets necessary to make an outstanding one, let alone one that wins a Computer World Championship.

GothicChess.Com
Jun 26, 2007, 04:18 PM
Oh man… this is such an uncool thing to do!!!
b e n

Please be advised that my response was purely to counter the overly-sarcastic remark here:

If you could write something like this and were not working for an IB, then you are without a doubt the smartest person on the planet.

While his was latent with sarcasm, mine was presented without bias and was purely factual.

If I wanted to do something overly-outrageous, I would have cited the fact that I was the last human being to defeat a Computer World Champion in the games of chess (Deep Thought, 1989) and Checkers (Chinook, 1996) which you can see...

here:
http://www.chessgames.com/perl/chessgame?gid=1272214

... and here...
http://www.cs.ualberta.ca/~chinook/WallofHonor.php

.. though you might have to scroll down a ways on the checkers page.

Look man, I did not initiate any post that would have these people from the sidelines make marginal impugning remarks about my character.

I just wanted to know how definitive the statements were regarding Carbon being destined for the Apple Graveyard, and I asked for facts, not merely conjecture.

That having been said, I would appreciate the rest of the posts to be about this.

Thank you.

The Management

:)

garethlewis2
Jun 27, 2007, 02:37 AM
Okay, you think that coding a chess program is easier than writing a simulation with partial diffs, fine. You have your opinion, I have mine.

For Carbon. Carbon was and is viewed by Apple as a transitory platform for Adobe and Microsoft. Nobody else. Apple don't need Adobe now. Adobe screwed up when they stated their video software won't be maintained on the Mac any more. Apple released FCP. With Aperture, Apple simply showed Adobe they had 1 year to release Photoshop to the Apple users. Adobe have complied, but with a 32bit version, which has pissed off so many users, they are looking for something better. Adobe don't have the position they used to enjoy. The instant the management at Adobe fart the wrong way, Apple will release their Cocoa version of a Photoshop killer.

I really can't see the problem with moving from Carbon to Cocoa. Yes, it is a different language. And no, it isn't difficult. I will reiterate my earlier, point about Wilco who are a subsidary of ADP and Calypso which is a company in SF. Wilco used to the software house to work for when it came to back-office processing, not front-office processing. All the major IBs used Glosspack and GlossHV. In 1998 I looked at what Wilco was doing and realised the management did not want to move to C++ on Unix, or Visual C++, or Java. They had some moron in who told them that moving would cost valuable time and money. Time in development and money in lost revenue. As all the developers would need to be retrained. They chose to listen to the consultant and not us the developers who told them, unless they move, the customers will look for something newer that is easier to use and maintain. Here is the main problem with Gloss. It only runs on Unix, and it only works through a JAM or Jyac Application Manager interface, which is a tty screen software package built on ncurses. 1998 and their software only has a text interface. Windows NT 4 is out. Other companies already have a team beavering away building a NT version of their software. Wilco has two choices. Move to a knew platform or buyout another company that already has a package. They chose the latter and bought an Indian company called DEShaw. 6 months later and god knows how many green cards, the indian develeopers had disappeared and let a Java system so rubbish and buggy, the develeopers at Wilco felt betrayed by management. 2001. Calypso a small startup in SF convert a C++ trading system that runs on Unix and Windows to Java, so it could run anywhere. They get their first big clients. Wilco are still trying to build a GUI version of their software and are using PowerBuilder. 2004. Wilco doesn't appear anymore in any of the financial papers. Paribas, ING, RBS have moved all trading off Gloss and onto Calypso. Gloss handled most products but could never process interest rate derivatives or any type of derivatives product. 2007. The last I heard, Wilco was a small part of ADP offering a brokerage service running on a Unix mainframe that allowed IBs and smaller hedge fund managers to trade without a IT unit. Calypso is the world leader in financial sofware.

What was the problem that Wilco had? They could not stomach having to recode the entire application in another language. It was just too much of a jump for them.

Carbon will be replaced, Apple don't maintain backwards compatability. Classic is dead. You can't 68k programs on an intel mac for OS 8 or 9. Carbon will most likely follow the same path. Adapt or Die.

Krevnik
Jun 27, 2007, 12:39 PM
Carbon will be replaced, Apple don't maintain backwards compatability. Classic is dead. You can't 68k programs on an intel mac for OS 8 or 9. Carbon will most likely follow the same path. Adapt or Die.

Carbon as we knew it as an OS 9 + OS X Library is already dead. APIs have already replaced QuickDraw and a bunch of other transitional technologies that Carbon dragged into OS X. A lot of what is available now is a lot cleaner, newer, and OS X-only. Why would Apple spend so much time adding OS X-only functionality (some of which are C-only APIs), if they just intended to whack it all? MLTE just got nuked in favor of a new C API in Leopard, BTW.

kainjow
Jun 27, 2007, 01:56 PM
For Carbon. Carbon was and is viewed by Apple as a transitory platform for Adobe and Microsoft. Nobody else. Apple don't need Adobe now. Adobe screwed up when they stated their video software won't be maintained on the Mac any more. Apple released FCP. With Aperture, Apple simply showed Adobe they had 1 year to release Photoshop to the Apple users. Adobe have complied, but with a 32bit version, which has pissed off so many users, they are looking for something better. Adobe don't have the position they used to enjoy. The instant the management at Adobe fart the wrong way, Apple will release their Cocoa version of a Photoshop killer.

Is this speculation, or do you know this as fact? It kind of makes sense, but a Cocoa Photoshop killer would be insane.

GothicChess.Com
Jun 27, 2007, 03:02 PM
Slight diversion...

Anyone here remember the SuperPaint program? (which was far superior to the free MacPaint that came with the original Mac). Is there a free OS X Paint-style program out there now?

I have a seen a few foreign language paint programs, and I have been half tempted to write my own OS X Superpaint application. I keep an OS 9 box running just for SuperPaint, it is sooooooo easy to use for quick-n-dirty graphics.

MongoTheGeek
Jun 27, 2007, 06:13 PM
Slight diversion...

Anyone here remember the SuperPaint program? (which was far superior to the free MacPaint that came with the original Mac). Is there a free OS X Paint-style program out there now?

I have a seen a few foreign language paint programs, and I have been half tempted to write my own OS X Superpaint application. I keep an OS 9 box running just for SuperPaint, it is sooooooo easy to use for quick-n-dirty graphics.

Have you looked at the gimp? http://www.apple.com/downloads/macosx/unix_open_source/gimpapp.html

garethlewis2
Jun 28, 2007, 02:49 AM
No, it's not speculation. It is well known in the Apple development community that Adobe realise Apple could release a Cocoa Photoshop replacement. Adobe tried to shake apple with their empty bluff of not supporting their equivalent of FCP on the Mac. Apple replied by releasing FCP. And you have to ask the question. Why would a Cocoa Photoshop style application be insane. It would be 64-bit. Photoshop is 32-bit, and as I mentioned previously, professional studios are pissed at this. They have machines with 16 gigs of Ram, and they are stuck with an app that can only access 2 gigs of Ram in a single data window.

As a side-note. Carbon was already updated to 64-bit. It is on the Apple development forums if you have access. Though of course, 64-bit Carbon is a step backwards. No GC, no support for NSOperation, etc. So it was killed.

Why would they kill a well written API? It is 2007 not 1997. 1997 C API's for application writing were the norm. Windows developers scoffed at this new API, MFC containing the newest features, they knew it would be backported into Win32 APIs. Didn't happen, and never will. Now MFC is under threat from CLR.

Coding practices change.

Eraserhead
Jun 28, 2007, 08:39 AM
No, it's not speculation. It is well known in the Apple development community that Adobe realise Apple could release a Cocoa Photoshop replacement. Adobe tried to shake apple with their empty bluff of not supporting their equivalent of FCP on the Mac. Apple replied by releasing FCP.

FWIW FCP came out before Adobe pulled Premiere ;).

For a free paint program their is Seashore (http://seashore.sourceforge.net/download.php)

garethlewis2
Jun 28, 2007, 09:09 AM
And all the developers who worked on Premiere worked on FCP.

Fukui
Jun 28, 2007, 10:06 AM
Carbon as we knew it as an OS 9 + OS X Library is already dead. APIs have already replaced QuickDraw and a bunch of other transitional technologies that Carbon dragged into OS X. A lot of what is available now is a lot cleaner, newer, and OS X-only. Why would Apple spend so much time adding OS X-only functionality (some of which are C-only APIs), if they just intended to whack it all? MLTE just got nuked in favor of a new C API in Leopard, BTW.

Yes, but these new C-APIs are not carbon, they are CoreFoundation based. CoreFoundation != carbon.

aleister55
Jun 29, 2007, 12:26 AM
Apple forcing cocoa on all of you holdouts is like John Landen saying that he'll only fight if someone put's a particular kind of bottled water in his locker room.

There are no valid excuses left:mad:

GothicChess.Com
Jun 29, 2007, 04:14 PM
Apple forcing cocoa on all of you holdouts is like John Landen saying that he'll only fight if someone put's a particular kind of bottled water in his locker room.

There are no valid excuses left:mad:

Ummm, what?

Soulstorm
Jun 30, 2007, 01:33 AM
I began my OS X development by learning Carbon on OS X. Then, I decided to move to Cocoa, because everybody was telling me to do so. I think in order to see better the pros and cons of both APIs

Don't get me wrong here. I love Cocoa. I think the most complete and powerful API the world has ever seen. Class abstraction and manipulation, 'id' generic objects, and the way all this is integrated with Interface Builder continues to amaze me, even after so much time devoted to Cocoa development.

But I think that Carbon should stay. I have seen very little of Objective-C 2.0, but I don't think that it will ever be sufficient to replace another language such as C++. C++ has tons of libraries, and for that reason a developer should not be forced to throw away all those libraries, and to learn a totally new development method. I know, there is Objective C++, but that's not enough, as this is just a desperate move to support C++ with Cocoa.

Developers that develop for a specific platform need to have options. I hope Carbon continues to evolve. The way I see it, Carbon and Cocoa are here to stay. Carbon will evolve dramatically over the next versions of OS X, and will abandon many deprecated technologies and programming concepts that are now used, just as it did with Quickdraw. And, let's not forget one basic thing:

OpenGL, OpenAL, and libraries such as these in general, are not written for Objective C. I find it easier to write a program in OpenGL Carbon using classes, than developing an OpenGL application in Cocoa. Performance in OpenGL Carbon should be better, too, classes with OpenGL objects can be made cleaner and clearer.

The difference between Objective C and C++ is that Objective C is an open world programming language, and C++ is a closed world one. An open world programming language is just like designing the interior of a car. The driver seats, the wheel, etc. But C++ will be used to design the engine compartment of the car. It is more efficient, and provides better low-level management.

Concluding... I think that the world still needs Carbon. Just not in the form that exists in this time. I believe it should be upgraded, enhanced with better programming concepts, and re-designed to compete with Cocoa in areas where Cocoa lacks on functionality. I won't point out what those areas are, I believe many people in here have found some parts of Cocoa that need enhancements, or areas where C++ can perform better than Objective C.

GothicChess.Com
Jun 30, 2007, 02:09 AM
Concluding... I think that the world still needs Carbon. Just not in the form that exists in this time. I believe it should be upgraded, enhanced with better programming concepts, and re-designed to compete with Cocoa in areas where Cocoa lacks on functionality. I won't point out what those areas are, I believe many people in here have found some parts of Cocoa that need enhancements, or areas where C++ can perform better than Objective C.

I pray that you are correct! But it seems many who have posted here have whipped the Carbon-ites into submission.

I have spawned another Topic Group, http://forums.macrumors.com/showthread.php?t=322246 = Cocoa Topics for Carbon Ex-Patriots -- maybe you will find this of some interest.

lazydog
Jun 30, 2007, 04:05 AM
I know, there is Objective C++, but that's not enough, as this is just a desperate move to support C++ with Cocoa.

Hi

This is just my opinion but I can't see why Objective C++ isn't enough. What Apple has given us is a fantastic amount of flexibility in the way you can program the Mac. C++ classes, STL, OpenGL, Cocoa classes, standard Unix C, Carbon etc can all coexist happily in the same project. I would agree with you if Cocoa bound you to a 'closed box' environment… but it doesn't.

In the other thread about Cocoa, garethlewis2 mentioned that the dot method call for classes is being introduced. Along with garbage collection and integration with C++ I really think Objective-C is going to be an amazing language to program in.

b e n

alFR
Jun 30, 2007, 06:15 PM
<snip>
The Wright Brothers were bicycle mechanics, yet they invented the field of Avaiation.

Albert Einstein was a Swiss patent clerk, yet he published "Relativity" and demonstrated that the Newtonian Physics metaphor was lacking a great deal.
<snip>


Hmm, you've written some software and you're comparing yourself to Einstein and the Wright brothers. Hubris, thy name is GothicChess.Com....

Eraserhead
Jun 30, 2007, 06:26 PM
Hmm, you've written some software and you're comparing yourself to Einstein and the Wright brothers. Hubris, thy name is GothicChess.Com....

I don't think he really is, he's just using them as an example of people who weren't working in the field who became experts.

In the history of computer chess, it is well known that Ken Thompson's $600,000 (1982 prices) Belle program was the first ever artificial intelligence player to make Master in United States Chess Federation play.

What is not well known, is that when I was still 20, my own Macintosh chess program, The Sniper, was the first software program to break the 2200 Master barrier, just 4 years after Thompson. (Belle was a hardware program, a dedicated machine, funded by Bell Labs.)

So Gothic hasn't just written "some software".

Fukui
Jun 30, 2007, 08:54 PM
I have seen very little of Objective-C 2.0, but I don't think that it will ever be sufficient to replace another language such as C++. C++ has tons of libraries, and for that reason a developer should not be forced to throw away all those libraries, and to learn a totally new development method. I know, there is Objective C++, but that's not enough, as this is just a desperate move to support C++ with Cocoa..
Please don't take this the wrong way, but thats just wrong. Nobody has to throw away their C++ templates and libraries to use Cocoa. And if you haven't seen Objective-C 2.0, then well....

GothicChess.Com
Jul 1, 2007, 11:23 PM
Hmm, you've written some software and you're comparing yourself to Einstein and the Wright brothers. Hubris, thy name is GothicChess.Com....

You missed the point entirely.

Einstein was not well liked by some of his college teachers, and he was basically forced to take a job as a patent clerk to make ends meet. He couldn't get a job in his preferred field of work.

On the merit of his credentials, Albert Einstein was not highly recommended.

In 1902, the Wright Brothers were virtually unknown, unless you had a flat tire on your bicycle in the town of Kitty Hawke.

On the merit of their credentials, the Wright Brothers had no qualifications as aeronautical engineers.

That having been said, some pissant was posting on here that because I was not a slave worshipping the god of Cocoa, that I basically had no idea what I was doing as a programmer.

I merely replied, quite factually, that I had already something of merit before the age of 20. It's not relativity theory, and it won't get very far off the ground, but considering it ran on a 16 megahertz processor with no hard drive, and it fit on an 800 K floppy disk with the operating system also installed, my chess program broke the master barrier far before technological advances enabled another software program to follow suite. It took the Software Toolworks company 5 more years, on a machine that was over 6 times as fast, to finally overshadow it. I wrote it in my spare time while dual majoring. I think they had more manpower, more resources, and more time to throw at it than I did.

FabL
Jul 2, 2007, 03:07 AM
Someone claimed that Cocoa in Leopard will be founded on a new "Core UI" framework rather than HIToolbox (or whatever it uses today). If this is true, and the CoreUI framework is available to developers, wouldn't that be the solution to everyone's problems? Cross-platform developers could use pure C code and still be up-to-date with the latest UI stuff.

I've done some cross-platform development, and honestly: Wrapping C around Objective-C makes me want to wash my hands afterwards. An up-to-date C framework for UIs would be so very welcome.

GothicChess.Com
Jul 4, 2007, 06:46 AM
I've done some cross-platform development, and honestly: Wrapping C around Objective-C makes me want to wash my hands afterwards.

You and me both :)