No Carbon future, what now?

[Roelf Toxopeus]

Are they moving Carbon out?
http://www.apple.com/macosx/leopard/technology/64bit.html
http://lists.apple.com/archives/carbon-dev/2007/Jun/msg00260.html

I had an inclination about this already looking at the new Quicktime,
Core 'this and that' frameworks, which are written in Obj-C and thus
Cocoa. Some have an interface, so you can access them from outside
Cocoa, others not. You'll have to use Quicktime (sic).
Also Core Audio has new functions and warnings things will be deprecated.
The current Carbon API references are loaded with deprecate warnings.

I know we can run Cocoa stuff from MacForth and PowerMops. But I'm
more thinking about possible MacIntel native versions of these Forths.
Putting all the effort in the PPC -> Intel compiler/dis-/assembler/endian
stuff while staying Carbon is great but IMHO a waste of precious energy:
you'll have to convert to Cocoa someday.

For those planning this laudable task.
My suggestion would be to write a native, don't bother with portable C,
(non OO) Forth body:
native code, I/O independent, coop multitasking (prepared), call-,
callback-mechanism, (dis)assembler, facilities for snapshot, turnkey
and saving as shared library.

You can load your preferred (non)Standard and preferred OO on top
at will. Of course many other electives are available: editor, FFP,
whatever locals etc.

It runs at the lowest level, in the Terminal or full screen when logged
in as >console. It can exist with System framework alone: Mach kernel,
BSD etc.

From here on, you can include the necessary frameworks your app
needs: OpenGL, Core Audio, Quicktime, Cocoa windows and so forth.

Note, it's not necessary to move on to higher levels in the OS, using
ANS Forth or any OOF version. You can but you don't have to.
Apart from the restrictions set by the initial root Forth, you should be
free to use whatever you want.

The initial root Forth: certainly not a portable standard obeying Forth.
What then?

Time's up, cliffhanger:
Quoting Norbert Wiener: "The price of metaphor is eternal vigilance."

Follow up in part2.

regards, cheers en veel groeten
-Roelf

http://this.is/bmbcon

[Gregory Weston]

Post by Roelf Toxopeus
Are they moving Carbon out?

If they are it's going to take years just to deprecate, let alone
eliminate. There's a lot of stuff you simply can't do in straight Cocoa
today. And a lot more that's either horribly inefficient, or horribly
convoluted to make efficient.

Post by Roelf Toxopeus
http://www.apple.com/macosx/leopard/technology/64bit.html
http://lists.apple.com/archives/carbon-dev/2007/Jun/msg00260.html

I would note that:
1) Some parts of Carbon already deal with 64-bit values.
2) The comment is about Carbon specifically. There's no indication that
there will be no 64-bit procedural code. I think the thing to question
is what parts of the Carbon API as it exists today would benefit from
"64-bitness" - what that would actually mean to them.

Post by Roelf Toxopeus
I had an inclination about this already looking at the new Quicktime,
Core 'this and that' frameworks, which are written in Obj-C and thus
Cocoa. Some have an interface, so you can access them from outside
Cocoa, others not. You'll have to use Quicktime (sic).
Also Core Audio has new functions and warnings things will be deprecated.
The current Carbon API references are loaded with deprecate warnings.

That's because the current Carbon API has a lot of legacy and
(importantly) redundant cruft.

I wouldn't read too much into this quite yet.

[Roelf Toxopeus]

Post by Gregory Weston

Post by Roelf Toxopeus
Are they moving Carbon out?

If they are it's going to take years just to deprecate, let alone
eliminate. There's a lot of stuff you simply can't do in straight Cocoa
today. And a lot more that's either horribly inefficient, or horribly
convoluted to make efficient.

Post by Roelf Toxopeus
http://www.apple.com/macosx/leopard/technology/64bit.html
http://lists.apple.com/archives/carbon-dev/2007/Jun/msg00260.html

1) Some parts of Carbon already deal with 64-bit values.
2) The comment is about Carbon specifically. There's no indication that
there will be no 64-bit procedural code. I think the thing to question
is what parts of the Carbon API as it exists today would benefit from
"64-bitness" - what that would actually mean to them.

Post by Roelf Toxopeus
I had an inclination about this already looking at the new Quicktime,
Core 'this and that' frameworks, which are written in Obj-C and thus
Cocoa. Some have an interface, so you can access them from outside
Cocoa, others not. You'll have to use Quicktime (sic).
Also Core Audio has new functions and warnings things will be deprecated.
The current Carbon API references are loaded with deprecate warnings.

That's because the current Carbon API has a lot of legacy and
(importantly) redundant cruft.
I wouldn't read too much into this quite yet.

The 'yet' is of course the crux here.

http://lists.apple.com/archives/carbon-dev/2007/Jun/thrd3.html
follow the '64-bit Carbon' and 'Is Carbon Viable?' threads

Some interesting and 'familiar feeling' issues are discussed here.
Also the 64-bitness now or later of certain Carbon parts are explained.

I can certainly sympathize with those developers who were told last WWDC
they would get 64-bit Carbon and based their strategy on that. It's all
to the dogs: time, energy, money (including attending that last WWDC).
Even if it's only delayed, it may be too late for some: customers
affected by the 64b-bit buzzword want it now.
It looks to me all unnecessary created grief.

Anyway it's very difficult to speculate, who knows what's happening?
Again I would suggest to be prepared with any new big development
wrt a Forth system: let it be GUI independent, let possible changes not
bite too hard.