"It'll be faster" doesn't count because that's wrong.
"It'll be less buggy" doesn't count because that's wrong.
"It'll be more featureful" only counts if being able to use emacs text shortcuts and spell checking while renaming files is a major feature for you.
"It'll fix synchronization issues with FTP and other network media" is wrong.
First off, let me say that I've worked with both Carbon and Cocoa, and their respective ancestors. I believe that rewriting Finder in Cocoa will *vastly* improve its performance, reliability, and overall user experience.
Why? Not because Cocoa is some kind of magical framework for creating bullet-proof applications, but because of more pragmatic reasons. You say it won't be faster. I think this is untrue. While Cocoa and the Objective C runtime do, in fact incur some very real overhead, remember that this mechanism served perfectly well on 25Mhz 68030s.
Cocoa encourages code reuse, and it also provides a robust, mature toolset for building complex applications. I believe a Cocoa Finder will be more modular and extensible. I believe it will ultimately prove to be faster and more stable, again, not by some magic API, but through the time-proven benefits of high code reuse, modularity, and an overall better integration with the platform's emerging technologies.
First off, let me say that I've worked with both Carbon and Cocoa, and their respective ancestors. I believe that rewriting Finder in Cocoa will *vastly* improve its performance, reliability, and overall user experience.
Don't you think your nickname makes you sound a little biased?
Quote:
Why? Not because Cocoa is some kind of magical framework for creating bullet-proof applications, but because of more pragmatic reasons. You say it won't be faster. I think this is untrue. While Cocoa and the Objective C runtime do, in fact incur some very real overhead, remember that this mechanism served perfectly well on 25Mhz 68030s.
Yes, and it did much less than it does today.
A cleanly written application in Carbon is, due to much lower overhead, likely to be faster than a cleanly written application in Cocoa.
If you're suggesting a rewrite of the Finder, regardless of whether in Carbon or in Cocoa, that's a wholly different matter. But Cocoa in and by itself is not going to fix any problems.
Quote:
Cocoa encourages code reuse, and it also provides a robust, mature toolset for building complex applications.
No doubt about that.
Quote:
I believe a Cocoa Finder will be more modular and extensible.
We already have a lot of extensibility. File system plug-ins are on a level lower than the Finder. Network services (e.g. WebDAV, FTP) are on a level lower. Contextual menu items have been possible (and an UI crime) since OS 8. The Finder uses HIToolbar, which is pretty much the same as NSToolbar. The Finder could, based on some minor and long-needed Carbon improvements, gain features such as spell checking.
Where do you see a further need for modularity?
Quote:
I believe it will ultimately prove to be faster and more stable, again, not by some magic API, but through the time-proven benefits of high code reuse, modularity, and an overall better integration with the platform's emerging technologies.
"Emerging technologies" are, or should be, just as available on Carbon. Again, Cocoa may encourage cleaner code, but that doesn't mean such clean code is impossible in Carbon.
There is no inherent reason why a Carbon Finder couldn't be just as good as a Cocoa Finder.
There is no inherent reason why a Carbon Finder couldn't be just as good as a Cocoa Finder.
How about:
There is no inherent reason why an improved, re-factored or rewritten-from-scratch* Carbon Finder couldn't be just as good as a Cocoa Finder, except for the fact that a Cocoa Finder would have to be rewritten, API-agnostic parts of the code (which should be minor) aside. Of course, that reason alone could be good enough (it certainly was to Apple for certain apps that were migrated, such as the Carbon DVD Studio Pro 1.x to the Cocoa DVD Studio Pro 2.0 and newer), but, again, that doesn't mean that Carbon, per se, is inherently bad.
meh. steve jobs is still there. Was Rubinstein & Tevanian with Jobs anywhere from 1976-1984? No. Yes they were instrumental to the company's progress from the 90's to now. But Jobs knows what he is doing. It will be good to get some fresh blood in there.
Maybe Cocoa is better, becuase the framework is better. I find having programmed in both Objective-C and C++ that Objective-C is a much more productive language. If it comes down to coming up with a super sporty C++ based framework with all the coolness of Cocoa, or re-writing some Carbon apps in Objective-C, I'll take Cocoa/Objective-C.
I prefer Cocoa by far as well. I just don't like some of the ignorance and urban myths that have been going around here.
I prefer Cocoa as well, but Chucker's exactly right. There are a lot of great apps written in Carbon, and the Finder is not much better or worse for it. I'd like Cocoa infinitely more, of course, if it wasn't written in a dead-end Mac-only language only supported by one of the worst IDE's in common usage today and only compilable by the slowest, worst-generating compiler in widespreadU.
Avie is responsible for all the crust in OS X we'll nveer get rid of (until we sandbox that crap in Classic II). Mach, the Mach-BSD schizo trap solution, Mach-O ABI, Mach-O exec format, NeXT cruft like using NSStrings to refer to files (reversing improvements made with System 7), UNIX cruft like blind file i/o operations, and boatloads of other crap.
Not-invented-here syndrome reached a ludicrous peak with Mr. not-invented-by-me-personally.
In the future Apple would do well to leave the academics in acadamia! There's a reason we have teaching institutions, so those who 'do' don't have to deal with them.
OS X will continue to gain in performance the less and less legacy crap is retained in the OS. And that legacy is the transition layer, Carbon. [/B]
What a bunch of crap!
First of all, all the legacy stuff which actually slows the OS down is Avie's doing. Carbon cannot be blamed for the horrible performance of threading, paging, accessing globals, etc. Those problems are due to the schizophrenic and bloated Mach-BSD kernel.
Secondly, well written Carbon apps are FASTER and use FEWER resources than Cocoa apps. Carbon events and Carbon controls use fewer resources than Cocoa's equivalents. Cocoa also lacks a lightweight object (or opaque data type) to reference files, instead only offering NSDocuments, which use an FSRef internally (since 10.1).
Cocoa wouldn't help anything. It's not re-entrant so it doesn't help with threading. It wouldn't use fewer resources. What would be the point of making it Cocoa?!
Meanwhile there are many reasons to use Carbon WRT the Finder. It has to handle Aliases, icons, and various file attributes which have no equivalent APIs in Cocoa. If I were to write the Finder from scratch today, I would probably use Carbon. Cocoa only helps when dealing with lots of views or controls, which the Finder doesn't really have that many. Plus, most of the complex stuff the Finder does is performed by other APIs which fit with Carbon just fine.
Go find another scapegoat, or better yet don't talk about crap you don't understand \
I've heard on a few occasions that the Mach microkernel is a bottleneck. In layman's terms, what exactly is wrong with the Mach microkernel? And replacing it is a non-trivial task, right? Are there any existing kernels that would be good substitutes?
I've heard on a few occasions that the Mach microkernel is a bottleneck. In layman's terms, what exactly is wrong with the Mach microkernel? And replacing it is a non-trivial task, right? Are there any existing kernels that would be good substitutes?
The fundamental problem is the ABI, because once you set that you can't replace it without emulating the Mach-BSD schizoid monster. You have to support SYSV and Mach to run current OS X apps and drivers. There can be no substitutes, only a new OS written from scratch with some kind of emulation (Classic Part Deux).
So I guess we'll have to "limp along" until a successor is developed? Is there anything that can be done to optimize Mach significantly? I realize this is pure speculation, but do you think Apple is already planning a successor to appear in the next 5-10 years?
maybe something drastic happened or maybe it didn't. why does everything have to be dramatic? for all we know avie had other plans when NeXT was bought by apple and steve asked him to come with him for a few years to transition the operating system. with leopard, i think we will truly have the os that steve and avie envisions when NeXT was founded. os x is a pretty mature product now. perhaps it's not that big of a challenge anymore for avie. now it's mostly going to be maintenance and a few cool features each revision.
guys like steve and avie seem to be moving forward constantly towards the next big challenge. when steve was ousted from apple, he was already a very rich man. he could have just retired at 28 or whatever and loafed around with his riches. instead he bought pixar and started another computer company. maybe avie has tackled all the big issues in os x and is ready to move on to the next challenge.
So I guess we'll have to "limp along" until a successor is developed? Is there anything that can be done to optimize Mach significantly? I realize this is pure speculation, but do you think Apple is already planning a successor to appear in the next 5-10 years?
Blocking may be further improved as well as paging, but I don't expect much.
Apple doesn't really plan long term; they never have. These problems are due to poor planning (and Avie's pig-headedness). For example, given all the time spent trying to get the old Mach-O toolchain working with ecgs, Apple could have stuck with PEF/xcoff or used ELF. The supposed reason was to save time (which only makes sense from Avie's perspective), but IMO it ended up doing the opposite and we're still suffering from the consequences.
What really ought to be done is to consider the post-UNIX age. I suspect the next consumer OS will be developed for some embedded purpose wholly removed from the history of teletypes, punch cards, and dot matrix printers. Hopefully it will be developed long enough without a big company buying them out as not to suck.
Comments
Originally posted by CosmoNut
There's no reason to keep it carbon anymore.
Exactly what I mean!
tf
Originally posted by Chucker
Please name a reason to make it Cocoa.
Easy! It stinks because it's carbon!
Originally posted by Chucker
Please name a reason to make it Cocoa.
"It'll be faster" doesn't count because that's wrong.
"It'll be less buggy" doesn't count because that's wrong.
"It'll be more featureful" only counts if being able to use emacs text shortcuts and spell checking while renaming files is a major feature for you.
"It'll fix synchronization issues with FTP and other network media" is wrong.
First off, let me say that I've worked with both Carbon and Cocoa, and their respective ancestors. I believe that rewriting Finder in Cocoa will *vastly* improve its performance, reliability, and overall user experience.
Why? Not because Cocoa is some kind of magical framework for creating bullet-proof applications, but because of more pragmatic reasons. You say it won't be faster. I think this is untrue. While Cocoa and the Objective C runtime do, in fact incur some very real overhead, remember that this mechanism served perfectly well on 25Mhz 68030s.
Cocoa encourages code reuse, and it also provides a robust, mature toolset for building complex applications. I believe a Cocoa Finder will be more modular and extensible. I believe it will ultimately prove to be faster and more stable, again, not by some magic API, but through the time-proven benefits of high code reuse, modularity, and an overall better integration with the platform's emerging technologies.
Originally posted by Anders
Easier development and portability in the future?
Tell that the iTunes team.
Originally posted by [alloc init]
First off, let me say that I've worked with both Carbon and Cocoa, and their respective ancestors. I believe that rewriting Finder in Cocoa will *vastly* improve its performance, reliability, and overall user experience.
Don't you think your nickname makes you sound a little biased?
Why? Not because Cocoa is some kind of magical framework for creating bullet-proof applications, but because of more pragmatic reasons. You say it won't be faster. I think this is untrue. While Cocoa and the Objective C runtime do, in fact incur some very real overhead, remember that this mechanism served perfectly well on 25Mhz 68030s.
Yes, and it did much less than it does today.
A cleanly written application in Carbon is, due to much lower overhead, likely to be faster than a cleanly written application in Cocoa.
If you're suggesting a rewrite of the Finder, regardless of whether in Carbon or in Cocoa, that's a wholly different matter. But Cocoa in and by itself is not going to fix any problems.
Cocoa encourages code reuse, and it also provides a robust, mature toolset for building complex applications.
No doubt about that.
I believe a Cocoa Finder will be more modular and extensible.
We already have a lot of extensibility. File system plug-ins are on a level lower than the Finder. Network services (e.g. WebDAV, FTP) are on a level lower. Contextual menu items have been possible (and an UI crime) since OS 8. The Finder uses HIToolbar, which is pretty much the same as NSToolbar. The Finder could, based on some minor and long-needed Carbon improvements, gain features such as spell checking.
Where do you see a further need for modularity?
I believe it will ultimately prove to be faster and more stable, again, not by some magic API, but through the time-proven benefits of high code reuse, modularity, and an overall better integration with the platform's emerging technologies.
"Emerging technologies" are, or should be, just as available on Carbon. Again, Cocoa may encourage cleaner code, but that doesn't mean such clean code is impossible in Carbon.
There is no inherent reason why a Carbon Finder couldn't be just as good as a Cocoa Finder.
There is no inherent reason why a Carbon Finder couldn't be just as good as a Cocoa Finder.
How about:
There is no inherent reason why an improved, re-factored or rewritten-from-scratch* Carbon Finder couldn't be just as good as a Cocoa Finder, except for the fact that a Cocoa Finder would have to be rewritten, API-agnostic parts of the code (which should be minor) aside. Of course, that reason alone could be good enough (it certainly was to Apple for certain apps that were migrated, such as the Carbon DVD Studio Pro 1.x to the Cocoa DVD Studio Pro 2.0 and newer), but, again, that doesn't mean that Carbon, per se, is inherently bad.
*) Not gonna happen.
Carbun sux d00d!
Originally posted by Kickaha
Oh I knew that,
I figured; I just wanted to clarify for the others.
Don't be as conceited to think that I wrote all that just for you!
I just like yanking your chain.
I sure noticed.
Carbun sux d00d!
I prefer Cocoa by far as well. I just don't like some of the ignorance and urban myths that have been going around here.
Originally posted by Chucker
I prefer Cocoa by far as well. I just don't like some of the ignorance and urban myths that have been going around here.
I prefer Cocoa as well, but Chucker's exactly right. There are a lot of great apps written in Carbon, and the Finder is not much better or worse for it. I'd like Cocoa infinitely more, of course, if it wasn't written in a dead-end Mac-only language only supported by one of the worst IDE's in common usage today and only compilable by the slowest, worst-generating compiler in widespreadU.
Avie is responsible for all the crust in OS X we'll nveer get rid of (until we sandbox that crap in Classic II). Mach, the Mach-BSD schizo trap solution, Mach-O ABI, Mach-O exec format, NeXT cruft like using NSStrings to refer to files (reversing improvements made with System 7), UNIX cruft like blind file i/o operations, and boatloads of other crap.
Not-invented-here syndrome reached a ludicrous peak with Mr. not-invented-by-me-personally.
In the future Apple would do well to leave the academics in acadamia! There's a reason we have teaching institutions, so those who 'do' don't have to deal with them.
Originally posted by mdriftmeyer
OS X will continue to gain in performance the less and less legacy crap is retained in the OS. And that legacy is the transition layer, Carbon. [/B]
What a bunch of crap!
First of all, all the legacy stuff which actually slows the OS down is Avie's doing. Carbon cannot be blamed for the horrible performance of threading, paging, accessing globals, etc. Those problems are due to the schizophrenic and bloated Mach-BSD kernel.
Secondly, well written Carbon apps are FASTER and use FEWER resources than Cocoa apps. Carbon events and Carbon controls use fewer resources than Cocoa's equivalents. Cocoa also lacks a lightweight object (or opaque data type) to reference files, instead only offering NSDocuments, which use an FSRef internally (since 10.1).
But sure, blame Canada, I mean Carbon.
Originally posted by CosmoNut
There's no reason to keep it carbon anymore.
There's no reason not to.
Cocoa wouldn't help anything. It's not re-entrant so it doesn't help with threading. It wouldn't use fewer resources. What would be the point of making it Cocoa?!
Meanwhile there are many reasons to use Carbon WRT the Finder. It has to handle Aliases, icons, and various file attributes which have no equivalent APIs in Cocoa. If I were to write the Finder from scratch today, I would probably use Carbon. Cocoa only helps when dealing with lots of views or controls, which the Finder doesn't really have that many. Plus, most of the complex stuff the Finder does is performed by other APIs which fit with Carbon just fine.
Go find another scapegoat, or better yet don't talk about crap you don't understand
Originally posted by DoughBoy
I've heard on a few occasions that the Mach microkernel is a bottleneck. In layman's terms, what exactly is wrong with the Mach microkernel? And replacing it is a non-trivial task, right? Are there any existing kernels that would be good substitutes?
The fundamental problem is the ABI, because once you set that you can't replace it without emulating the Mach-BSD schizoid monster. You have to support SYSV and Mach to run current OS X apps and drivers. There can be no substitutes, only a new OS written from scratch with some kind of emulation (Classic Part Deux).
So I guess we'll have to "limp along" until a successor is developed? Is there anything that can be done to optimize Mach significantly? I realize this is pure speculation, but do you think Apple is already planning a successor to appear in the next 5-10 years?
guys like steve and avie seem to be moving forward constantly towards the next big challenge. when steve was ousted from apple, he was already a very rich man. he could have just retired at 28 or whatever and loafed around with his riches. instead he bought pixar and started another computer company. maybe avie has tackled all the big issues in os x and is ready to move on to the next challenge.
Originally posted by DoughBoy
strobe,
So I guess we'll have to "limp along" until a successor is developed? Is there anything that can be done to optimize Mach significantly? I realize this is pure speculation, but do you think Apple is already planning a successor to appear in the next 5-10 years?
Blocking may be further improved as well as paging, but I don't expect much.
Apple doesn't really plan long term; they never have. These problems are due to poor planning (and Avie's pig-headedness). For example, given all the time spent trying to get the old Mach-O toolchain working with ecgs, Apple could have stuck with PEF/xcoff or used ELF. The supposed reason was to save time (which only makes sense from Avie's perspective), but IMO it ended up doing the opposite and we're still suffering from the consequences.
What really ought to be done is to consider the post-UNIX age. I suspect the next consumer OS will be developed for some embedded purpose wholly removed from the history of teletypes, punch cards, and dot matrix printers. Hopefully it will be developed long enough without a big company buying them out as not to suck.