Cool, didn't know that - although to be honest they look equivalent rather than easier...:-)
But it's handy that you can get the PSN out of the dictionary as well, so you can always call over to the Process Manager while iterating if you ever need to.
Cocoa has had over a decade of use and testing in its various *Step incarnations.
It's hardly comparable - NeXT never really had the kind of wide-spread user base that Apple did. Both in terms of numbers of users, and in variety of apps. My point was more that the odd warts and barnacles that accumulate over time are normally there for a reason - there's the odd dubious hack, of course, but every API will grow over time as it matures. Of course, one of the whole points of the Carbon project was to remove stuff that really was pure cruft from the previous Toolbox APIs - and by and large they have.
Or you could use Cocoa and have real OO, not "flavored".
Leaving aside opinions on what's "real OO" or not, you can use whatever application framework you like if you use Carbon (PowerPlant, Zoop, your own cross-platform system, etc). If you're using Cocoa you're basically comitting your front end code to be Objective-C talking to AppKit.
I'd like to see your source for that figure. All of Apple's new applications are Cocoa. They've said repeatedly that Cocoa is the best path for new application development. What do you know that they don't?
I've been around long enough to know that Apple isn't a monolithic entity - there are different factions within the company, each of whom have their own agenda. The people touting the "all new applications must be written in Cocoa" line largely came from NeXT, and the drive to write the iApps in Cocoa comes directly from an ex-NeXT executive.
Apple have had numerous "xxx is the future! We mean it this time!" phases in the past, and IMHO Cocoa could quite easily find itself turning into a similar case.
Although Apple's developer programs are quite reasonable, they are quite up front about the fact that they focus most of their resources on the "top 100 developers" (Jobs' words, from their annual shareholder meeting a couple of years ago).Those developers (Microsoft, Adobe, etc) all use Carbon, and will probably continue to do so until the end of time.
I don't work for a company that size, but what can I say - we looked into Cocoa, and decided it wasn't the miracle cure it's touted to be. We write the odd in-house tool with it when we need a GUI quickly, but really that power comes from Interface Builder (which works just fine for Carbon apps as well).
Searches like this are probably sub-contracted out to the lowest bidder, which will come down to a couple of interns typing "soldier of fortune download" into Google...
Bit of a pain for WoS to have to respond to this kind of rubbish, but it's obviously sent out to intimidate (since when did the Berne Convention have anything to say about "Immediate Take Down").
Cocoa has true internationalization, complete unicode usage, real java interoperability, a modern, sophisticated set of graphics primitives, good access to a wide range of services, and a first-rate set of highly integrated widgets. Carbon DOES NOT.
Actually, it has identical access as Cocoa (from 10.2). Your anitpathy towards Carbon says more about you as a developer than it does about Carbon's usefulness.
The fact that Carbon has "a giant morass of hooks to do this or that" is simply due to its development over time - Cocoa has the benefit of being largely written all at once (and so has a fairly uniform design), however its main flaw as an API is that it just hasn't had the widespread use and testing that Carbon has.
This means it's ultimately less capable in some areas: e.g., how do I iterate through the list of GUI apps in Cocoa (in Carbon it's easy - talk to the Process Manager and walk through the list). The new Carbon APIs which are coming out of Apple these days (Carbon Events, HIViews, CF, etc) aren't making any of the "mistakes" people made in '84: these are APIs designed for the future, with opaque accessors, reference counting, and a very OOish flavour.
I'm a long time Mac developer as well ('86), as well as *nix/Win32, and frankly Carbon is one of the main reasons Mac OS X is still attractive as a platform - Cocoa is a nice framework, and it certainly was cutting edge when it first came out, but the world has moved on. It's just not that innovative any more, sorry.
And Carbon IS a legacy library
No, it's not. If you'd talked to Apple recently, or been to WWDC in the last couple of years, this would be crystal clear. Carbon is as much a part of the Mac's future as it ever was, and arguably in a more stable position than Cocoa (99% of the developers who generate money for the platform are using Carbon).
They're hardly likely to talk up the benefits of 64-bits on the desktop when their current 64-bit chip is so unsuitable. As and when they have an equivalent to AMD/Apple on the desktop, you can be sure they'll be more than happy to sing its praises.
What's interesting is the "nobody really needs 4Gb this decade" line. Just about every Mac in this room has 1Gb in it, and even the crappy test PC has 768Mb. 4Gb will be here sooner rather than later...
why one has to doubleclick the icons while just a single click is enough everywhere else. What's the reason we have those again?
The original thinking was that a single click allows you to select and unselect objects, and a double-click processes the current selection. This was quite logical, and completely consistent up until Microsoft introduced icons that looked just like "normal" icons but which react to the selection click.
Unfortunately I think people who are relatively light computer users are now more confused than ever - quite a common behaviour I've seen in relatives is double-clicking everything (including buttons in dialogs), "just to be sure".
Not quite - Carbon is an API which can be built as two different executable formats (CFM and MachO). A Carbon app built as MachO will only run on X, whereas a Carbon app built as CFM will run on both 9 and X.
Apple wants more people using X, so they build their apps as MachO. Most ISVs build their apps as Carbon CFM since the 9 market is still significant, but will probably migrate to Carbon MachO in the next year or so.
iTunes does not use the List Manager - that's been obsolete for quite some time. List Manager performance degrades drastically when you have a large number of items, and it's limited to 32Kb of data (you could only have 32Kb items if they were 1 byte each in size). Remember that API dates from 1984, when screens were 9" and a list with 32,000 items was pretty unlikely.
iTunes will either use their own internal list structure, or the Carbon Data Browser control. The Cocoa equivalent, NSOutlineView, still had some restrictions before 10.2 (e.g., at most 32Kb children per item).
iTunes is actually written in C++, and it's Carbon.
Re:You forgot to mention tabs, so I will.
on
Safari Beta Updated
·
· Score: 1
Cmd-Tilde will walk you through the entire window list (A, B, C, D, A, B, C, D, etc). Cmd-Shift-Tilde will take you backwards if you do actually want to go back to the window you just left.
Re:You forgot to mention tabs, so I will.
on
Safari Beta Updated
·
· Score: 1
You can use Command-Tilde to select your way through the application window list.
By far the scariest aspect (curiously un-mentioned by the Mayor) is that these cameras will be hooked up to facial recognition software.
In theory, just those covering a small section of London (the financial district) - but I have no doubts this will be extended to cover the whole city in time (after all, it's touted as "automatically identifying suspects or known criminals" so what government in the world would turn down the chance).
I find this far more disturbing - paying to try and alleviate congestion is fine (London is very crowded, and a similar scheme did help alleviate the traffic problems in Singapore when congestion charges were introduced there), paying for the privilege of being treated as a potential criminal is more than a little scary...
Slashdot Mirror
Cool, didn't know that - although to be honest they look equivalent rather than easier... :-)
But it's handy that you can get the PSN out of the dictionary as well, so you can always call over to the Process Manager while iterating if you ever need to.
Cocoa has had over a decade of use and testing in its various *Step incarnations.
It's hardly comparable - NeXT never really had the kind of wide-spread user base that Apple did. Both in terms of numbers of users, and in variety of apps. My point was more that the odd warts and barnacles that accumulate over time are normally there for a reason - there's the odd dubious hack, of course, but every API will grow over time as it matures. Of course, one of the whole points of the Carbon project was to remove stuff that really was pure cruft from the previous Toolbox APIs - and by and large they have.
Or you could use Cocoa and have real OO, not "flavored".
Leaving aside opinions on what's "real OO" or not, you can use whatever application framework you like if you use Carbon (PowerPlant, Zoop, your own cross-platform system, etc). If you're using Cocoa you're basically comitting your front end code to be Objective-C talking to AppKit.
I'd like to see your source for that figure. All of Apple's new applications are Cocoa. They've said repeatedly that Cocoa is the best path for new application development. What do you know that they don't?
I've been around long enough to know that Apple isn't a monolithic entity - there are different factions within the company, each of whom have their own agenda. The people touting the "all new applications must be written in Cocoa" line largely came from NeXT, and the drive to write the iApps in Cocoa comes directly from an ex-NeXT executive. Apple have had numerous "xxx is the future! We mean it this time!" phases in the past, and IMHO Cocoa could quite easily find itself turning into a similar case.
Although Apple's developer programs are quite reasonable, they are quite up front about the fact that they focus most of their resources on the "top 100 developers" (Jobs' words, from their annual shareholder meeting a couple of years ago).Those developers (Microsoft, Adobe, etc) all use Carbon, and will probably continue to do so until the end of time.
I don't work for a company that size, but what can I say - we looked into Cocoa, and decided it wasn't the miracle cure it's touted to be. We write the odd in-house tool with it when we need a GUI quickly, but really that power comes from Interface Builder (which works just fine for Carbon apps as well).
Searches like this are probably sub-contracted out to the lowest bidder, which will come down to a couple of interns typing "soldier of fortune download" into Google...
Bit of a pain for WoS to have to respond to this kind of rubbish, but it's obviously sent out to intimidate (since when did the Berne Convention have anything to say about "Immediate Take Down").
Cocoa has true internationalization, complete unicode usage, real java interoperability, a modern, sophisticated set of graphics primitives, good access to a wide range of services, and a first-rate set of highly integrated widgets. Carbon DOES NOT.
Actually, it has identical access as Cocoa (from 10.2). Your anitpathy towards Carbon says more about you as a developer than it does about Carbon's usefulness.
The fact that Carbon has "a giant morass of hooks to do this or that" is simply due to its development over time - Cocoa has the benefit of being largely written all at once (and so has a fairly uniform design), however its main flaw as an API is that it just hasn't had the widespread use and testing that Carbon has.
This means it's ultimately less capable in some areas: e.g., how do I iterate through the list of GUI apps in Cocoa (in Carbon it's easy - talk to the Process Manager and walk through the list). The new Carbon APIs which are coming out of Apple these days (Carbon Events, HIViews, CF, etc) aren't making any of the "mistakes" people made in '84: these are APIs designed for the future, with opaque accessors, reference counting, and a very OOish flavour.
I'm a long time Mac developer as well ('86), as well as *nix/Win32, and frankly Carbon is one of the main reasons Mac OS X is still attractive as a platform - Cocoa is a nice framework, and it certainly was cutting edge when it first came out, but the world has moved on. It's just not that innovative any more, sorry.
And Carbon IS a legacy library
No, it's not. If you'd talked to Apple recently, or been to WWDC in the last couple of years, this would be crystal clear. Carbon is as much a part of the Mac's future as it ever was, and arguably in a more stable position than Cocoa (99% of the developers who generate money for the platform are using Carbon).
Too much Dukes of Hazzard?
They're hardly likely to talk up the benefits of 64-bits on the desktop when their current 64-bit chip is so unsuitable. As and when they have an equivalent to AMD/Apple on the desktop, you can be sure they'll be more than happy to sing its praises.
What's interesting is the "nobody really needs 4Gb this decade" line. Just about every Mac in this room has 1Gb in it, and even the crappy test PC has 768Mb. 4Gb will be here sooner rather than later...
You are a national broadcaster trapped in the body of a regional disc jockey. There's no operation that can save you. Not on the NHS, anyway.
why one has to doubleclick the icons while just a single click is enough everywhere else. What's the reason we have those again?
The original thinking was that a single click allows you to select and unselect objects, and a double-click processes the current selection. This was quite logical, and completely consistent up until Microsoft introduced icons that looked just like "normal" icons but which react to the selection click.
Unfortunately I think people who are relatively light computer users are now more confused than ever - quite a common behaviour I've seen in relatives is double-clicking everything (including buttons in dialogs), "just to be sure".
If iTunes 3 is Carbon, it would work in OS 9
Not quite - Carbon is an API which can be built as two different executable formats (CFM and MachO). A Carbon app built as MachO will only run on X, whereas a Carbon app built as CFM will run on both 9 and X.
Apple wants more people using X, so they build their apps as MachO. Most ISVs build their apps as Carbon CFM since the 9 market is still significant, but will probably migrate to Carbon MachO in the next year or so.
iTunes does not use the List Manager - that's been obsolete for quite some time. List Manager performance degrades drastically when you have a large number of items, and it's limited to 32Kb of data (you could only have 32Kb items if they were 1 byte each in size). Remember that API dates from 1984, when screens were 9" and a list with 32,000 items was pretty unlikely.
iTunes will either use their own internal list structure, or the Carbon Data Browser control. The Cocoa equivalent, NSOutlineView, still had some restrictions before 10.2 (e.g., at most 32Kb children per item).
Perhaps he can't get Radio Norwich?
iTunes is actually written in C++, and it's Carbon.
Cmd-Tilde will walk you through the entire window list (A, B, C, D, A, B, C, D, etc). Cmd-Shift-Tilde will take you backwards if you do actually want to go back to the window you just left.
You can use Command-Tilde to select your way through the application window list.
By far the scariest aspect (curiously un-mentioned by the Mayor) is that these cameras will be hooked up to facial recognition software.
In theory, just those covering a small section of London (the financial district) - but I have no doubts this will be extended to cover the whole city in time (after all, it's touted as "automatically identifying suspects or known criminals" so what government in the world would turn down the chance).
I find this far more disturbing - paying to try and alleviate congestion is fine (London is very crowded, and a similar scheme did help alleviate the traffic problems in Singapore when congestion charges were introduced there), paying for the privilege of being treated as a potential criminal is more than a little scary...
if its a game, its a game, besides i'd like to destroy iraq
Would you feel the same way if the object of the game was to crash a plane into a US city?
Alan! There's no need for language like that.