Like 123, I hate repeating myself to horses wearing blinds, so I'll just say this.
[quote]Originally posted by AirSluf:
<strong>
Many, including you have said threads, well if a thread is stopped by a funnel lock that does exist--read the documentation--then no other threads can pass that point and the delay hits.</strong><hr></blockquote>
So why can other apps hit the BSD layer while the Finder remains locked? Answer me this and then explain how adding more funnels would solve the problem, when all access to the file system is obviously not locked...
You're staring so closely at the technical solution with the kernel, and how that must be right, and how YOU must be right that you're obviously totally blind to the effects of the problem and thereby shouldn't be able to draw informed conclusions on the cause of it.
I suggest it's time to just drop this discussion, cause you know you're right and me and 123 are convinced you're wrong, and it's too much a matter of prestige for you to ever consider the fact that you might be mistaken.
So you can lay off you condescending tone now and get on with your life. I know I will.
[ 04-05-2002: Message edited by: Whyatt Thrash ]</p>
[quote]But I'll laugh my ass off if I ever see anything about OS X adding any more of those un-needed funnels.<hr></blockquote>
You can laugh as hard as you want, just keep in mind that you don't have a reason. Funnels are not "un-needed" and adding more of them may even make sense as they are the "root cause" of all sorts of issues, BUT: the blocking Finder is just not one of them.
Okay, I've been following this thread since it started. Interesting stuff.
However, can anyone explain why a lack of "funnels" would cause the Finder to lock up with something like sorting a folder? Open a folder with several hundred items in it. Set it to list view. Sort by name. Done. Sort by date created. Done. Sort by version. Done. Sort by kind... wait... spinning disc... wait... wait... wait... done. Sort by name. Done. Sort by kind... wait... spinning disc... wait... wait... wait... done. Sort by date modified. Done.
See? I think you can only blame bad programming and lack of threading for that. The Finder *should* display the chasing arrows in the status bar if a window is waiting to do something like this. You *should* be allowed to do other tasks... not that something like this should freeze everything up for a minute or two.
<strong>However, can anyone explain why a lack of "funnels" would cause the Finder to lock up with something like sorting a folder? Open a folder with several hundred items in it. Set it to list view. Sort by name. Done. Sort by date created. Done. Sort by version. Done. Sort by kind... wait... spinning disc... wait... wait... wait... done.</strong><hr></blockquote>
Damn, I hadn't even realized that was the cause of it. You were right, as soon as I set it to sort by name it read like a charm. Wonderful, man. I can browse my mp3-directory again. In a less practical way, but at least it's snappy.
Can't we all agree that Finder has issues, one way or another? It doesn't matter why anymore because in a month or two it'll be fixed:
Railhead Design:
Another 10.2 Seed Released
Another seed of Apple?s next major OS upgrade has been made available to select premiere developers. This latest seed sports drastic Finder revisions and major ?tune-ups? in performance, sorting, auto-scrolling, spring-loaded folder action, contextual menu handling ? and the new print foundation (CUPS) is also being thoroughly pushed, jammed, and slammed into place by developers.
A few ?Apple people? are also hinting that Apple will be showcasing the new additions coming to OS X 10.2 on their website within the next six weeks ? but I?m still trying to get more solid information, though this makes (obvious) sense if we are to expect 10.2 to be released in July. But again, we?ll have to see?
<strong>Can't we all agree that Finder has issues, one way or another? It doesn't matter why anymore because in a month or two it'll be fixed:
Railhead Design:
Another 10.2 Seed Released
Another seed of Apple?s next major OS upgrade has been made available to select premiere developers. This latest seed sports drastic Finder revisions and major ?tune-ups? in performance, sorting, auto-scrolling, spring-loaded folder action, contextual menu handling ? and the new print foundation (CUPS) is also being thoroughly pushed, jammed, and slammed into place by developers.
A few ?Apple people? are also hinting that Apple will be showcasing the new additions coming to OS X 10.2 on their website within the next six weeks ? but I?m still trying to get more solid information, though this makes (obvious) sense if we are to expect 10.2 to be released in July. But again, we?ll have to see?
</strong><hr></blockquote>
Well, Railhead didn't know much about Photoshop (his b85 was way off), so I don't know how good his sources are.
But the bit about Apple posting news about 10.2 on Apple.com in a few weeks sounds correct.
Apple has more or less confirmed that 10.2 will be showcased on WWDC May 6, and I guess that they will publish some info on 10.2 on Apple.com the same day or so.
I wish the finder was faster also. But Apple is doing a good job for working with a new kernel and code set they have never worked with.
Cocoa is the better API, but coding for it won't really explode until we get a true 64 bit archetecture. Carbon was originally created so developers could easily port OS 9 apps to OS X. Don't forget that.
But this flame war of a thread is is emberassing.
Finally, if you hate the finder that much, use Snax or another finder alternative.
I wish the finder was faster also. But Apple is doing a good job for working with a new kernel and code set they have never worked with.
</strong><hr></blockquote>
Actually, the engineers that are working on it were the ones who designed it. So they know it inside and out.
[quote]<strong>
Cocoa is the better API, but coding for it won't really explode until we get a true 64 bit architecture. Carbon was originally created so developers could easily port OS 9 apps to OS X. Don't forget that.
</strong><hr></blockquote>
Has has already been established, Carbon and Cocoa are designed to be *EQUAL* API's. There is no way in h ell that Adobe and the like are going to rewrite their apps in Cocoa, just because some *believe* that Cocoa is better than Carbon.
And would you please cite some examples as to why you believe that Cocoa is better?
[quote]<strong>
But this flame war of a thread is is emberassing.
</strong><hr></blockquote>
And fun
[quote]<strong>
Finally, if you hate the finder that much, use Snax or another finder alternative.</strong><hr></blockquote>
There are a few I could find real quick. I have more at home.
Carbon was created for a buffer for Developers to quickly port Classic apps to OS X. So basically, it is a "port" of the classic mac os API to run in a unix enviroment. Cocoa is pretty much Openstep, which is the upgrade to NextStep which is an off shoot of BSD Unix. The biggest problem Carbon is going to produce is when apple decides to take OS X to a true 64 bit platform. Since cocoa and most of the other enviroments and elements of OS X are Object Oriented, like 99% of other Posix systems, it can be easily upgraded to 64 bit, or scaled. This is the problem with standard c programming. All the code is compiled together, and dependent on itself. With Object orientated programming, you make different parts, and they work together to make the app. A good example, strictly for concstruction, and not durability etc, is making lincoln logs, (cocoa) and a tree (carbon.) With Lincoln logs, you can constantly rebuild your little house, and the base, which is say, 32 bit, you can swap out easily for a new base, 64 bit. With a tree, it constantly grows, and you can never rebuild a tree. And once it's root is established, 32-bit, to make it 64 bit you would have to completely cut down the tree. Also, with a tree, you can cut off limbs and have new ones grow. But it starts to weaken because of this, and if you ever have to take a big chunk out of the base, even if you patch it with wood cement, you eventually will have to brace the tree, and that tree is never really "whole" anymore.
With the lincoln logs, if one piece gets broken, you can simply replace it.
This is the problem Windows right now. They have built it in a "Tree" fashion. So it's going to be hard to make NT 64 bit without growing a new tree.
Posix systems and their apps can usually be made 64 bit, or even 128 bit easily, with simply taking out the base and swapping them. Look how fast red hat had a 64 bit version of their flavor of linux to run on itaniums.
Also taking full advantage of Open GL, Java, and many other elements of Mac OS X's posix system is the other great thing about Cocoa.
Plus, It's adobe's fault for them having these problems converting to a cocoa system. If they kept supporting irix they would have been able to quickly port it from their sgi verion to mac os x. The reason they quit supporting it is.... MICROSOFT.
Thats another great thing about object-c. You can make a program for linux and easily make it for darwin or cocoa. And thats whats so great. It's very open. Can you imagine games coming over to amc os x super fast if all the companies had to do is change certain parts of the code with object c?
Thats why companies that don't adapt are going to kill themselves or get left behind. Also it's why if apple doesn't get cocoa to be more fully supported by more than posix gurus and programmers, mac os x is good as dead. Why even waste our time on a UNIX system if your not going to take full advantage of it.
Why put a 500 horse power engine in a vehicle with a rear end gear ratio to pull. Sure you can pull houses off of their foundation, but when you can't go over 35 miles per hour whats the point? You're wasting gas, and you wasted a big investment.
Not really. A lot of things are programmed in C/C++ in other POSIX sys's, but they are made mostly of components in the same way as Object C works. Not one big blob of code. Unfortunately, carbon enviroment wants one big blob of code. \
I read the links. And they all pretty much summed it up like this:
At this point, Carbon has some disadvantages. But so does Cocoa (Printing manager, anyone? It's CARBON!) As far as things like ScrollWheel support and moving the Preferences menu item, these are the programmer's job, not Carbon's. There is even Carbon Service support (buggy, but it's there). And finally, Mac OS X 10.2 should address most of the outstanding issues, so the two API's will be equal.
As far as the Lincolin Log/Tree analogy, couldn't Apple just rewrite the Carbon API for 64/128 bit and ask developers to recompile their apps? If not, why?
Because it's a lot harder than just asking nicely. re-writing code is a serious deal. And you can just strip out the code you want and replace it. Like the tree, all the code is dependent on each other, In the testing phase, when adding new pieces, you test it to make all the existing lines of code to work. Even all the code you couldn't strip. Carbon really isn't scalable either. Which means it wasn't designed to be upgraded. Which in turn means that the code was written to be 32 bit. In Object oriented programming, a compnonent determines bittage, and all the pieces look at that component to determine what they are themselves. In other wordsm you got to regrow the tree.
So which is faster, more reliable, and moreeconomical? Replacing a piece of houses in aneighbor hood, like the water meter, going through a forest and cutting chunks out of trees and patching them up and hoping they don't die, or regrowing a forest?
So if they are going to have to rewrite code, why not go ahead and rewrite it in Object C?
You aren't seeing the picture here. This isn't to be rude here. This is the problem with MS, and many other developers, and why us personal computer users are still 32 bit when people like SGI are 64 bit + for the past 10 years., and going 128 bit and even higher in the past few years. And it's not cost. Carbon was developed to be an inbetween Mac OS 9.x and Cocoa. It was to get apps to OS X quickly. The reason they constantly make Carbon more like cocoa is so they can easily make the apps jump to cocoa and then completely remove the carbon api. Cocoa is a true unix enviroment. So why keep using carbon when we talk about a UNIX system. Carbon is a simply a quick hyrbid. The owner of Realbasic defended carbon saying they are the same. But he didn't once mention the fact when OS X changes to true 64 bit, carbon is going to be scaled out because it can't keep up. It isn't a true Unix Enviroment.
Thats why apple is pushing for Cocoa. The reason so many pieces of apples code are in Carbon? Time, money, and laziness. Apple had to rush many elements of OS X to get it out, so they took their own short cut they developed for developers. The dock is cocoa, because it had to be to work smoothly. The reason why the finder is slow is because it's a hybrid/different language system windows manager on a POSIX system. To speed it up, and make it more smooth like the classic finder, they will need to make it cocoa. Plain and simple.
Trust me, we need to start getting people to go to cocoa, or when Windows goes 64 bit, us mac fanatics will be left in the dust.
"As far as the Lincolin Log/Tree analogy, couldn't Apple just rewrite the Carbon API for 64/128 bit and ask developers to recompile their apps? If not, why?"
So they can rewrite it AGAIN when it goes 256/512? and AGAIN when it goes 1024/2056, and AGAIN....
That starts to break compatibility, and creates problems., and slowsit down even faster.
GPTurismo, I'm having some trouble following your argument.
First, you can get past most word-size problems simply by using ANSI C: The C standard defines the sizes of its types relative to each other, and it defines constants for max and min values whose values are set by the compiler. If you follow the standard, all that's required to switch word sizes is a recompile. You run into trouble if you use compiler-specific types like "int16," but that's true in any language. OO does not necessarily buy you abstraction from underlying word sizes.
As has been discussed at length on these boards, machines have remained 32 bit for as long as they have (significantly more than 10 years!) because a range of plus or minus 2 billion is adequate for all but the most demanding tasks required of a computer. The cases a 32-bit architecture can't handle efficiently have been (and generally remain) rare enough not to be worth imposing the tradeoffs associated with a 64-bit architecture, or worked around with specialized additions. The venerable 68040 processor had an 80-bit floating point unit.
The programming concept you're looking for is "modularity," and it is not an advantage unique to OO. Modular programming was firmly entrenched when Dennis Ritchie designed C in 1973 (n.b.: OO had been around for about 8 years by then). Some OO languages take it to another level. But if you want to split your C app into a lot of manageable chunks, that's quite possible.
As for Carbon, it is not purely OO (although it, like the Mac Toolbox, borrows from OO), but it's quite possible to write an OO application using Carbon, complete with code divided up into chunks and linked either statically or dynamically. You could write a Carbon app in Objective-C if you wanted to (as it was possible with the Toolbox, via MacApp or PowerPlant or TCL, or hand-rolled code). In fact, nearly all Cocoa apps have some Carbon code in them, because Carbon is currently the only way to access OS X's HFS+ and XML parsing libraries.
If the Carbon API is contributing to the current Finder's shortcomings, it's because of growing pains, not because of any deficiencies specific to Carbon, or to procedural code.
Steve once said that he wished he'd used Smalltalk rather than Pascal as the original Macintosh's language. Imagine where we'd be if he had!
Comments
[quote]Originally posted by AirSluf:
<strong>
Many, including you have said threads, well if a thread is stopped by a funnel lock that does exist--read the documentation--then no other threads can pass that point and the delay hits.</strong><hr></blockquote>
So why can other apps hit the BSD layer while the Finder remains locked? Answer me this and then explain how adding more funnels would solve the problem, when all access to the file system is obviously not locked...
You're staring so closely at the technical solution with the kernel, and how that must be right, and how YOU must be right that you're obviously totally blind to the effects of the problem and thereby shouldn't be able to draw informed conclusions on the cause of it.
I suggest it's time to just drop this discussion, cause you know you're right and me and 123 are convinced you're wrong, and it's too much a matter of prestige for you to ever consider the fact that you might be mistaken.
So you can lay off you condescending tone now and get on with your life. I know I will.
[ 04-05-2002: Message edited by: Whyatt Thrash ]</p>
You can laugh as hard as you want, just keep in mind that you don't have a reason. Funnels are not "un-needed" and adding more of them may even make sense as they are the "root cause" of all sorts of issues, BUT: the blocking Finder is just not one of them.
However, can anyone explain why a lack of "funnels" would cause the Finder to lock up with something like sorting a folder? Open a folder with several hundred items in it. Set it to list view. Sort by name. Done. Sort by date created. Done. Sort by version. Done. Sort by kind... wait... spinning disc... wait... wait... wait... done. Sort by name. Done. Sort by kind... wait... spinning disc... wait... wait... wait... done. Sort by date modified. Done.
See? I think you can only blame bad programming and lack of threading for that. The Finder *should* display the chasing arrows in the status bar if a window is waiting to do something like this. You *should* be allowed to do other tasks... not that something like this should freeze everything up for a minute or two.
<strong>However, can anyone explain why a lack of "funnels" would cause the Finder to lock up with something like sorting a folder? Open a folder with several hundred items in it. Set it to list view. Sort by name. Done. Sort by date created. Done. Sort by version. Done. Sort by kind... wait... spinning disc... wait... wait... wait... done.</strong><hr></blockquote>
Damn, I hadn't even realized that was the cause of it. You were right, as soon as I set it to sort by name it read like a charm. Wonderful, man. I can browse my mp3-directory again. In a less practical way, but at least it's snappy.
Railhead Design:
Another 10.2 Seed Released
Another seed of Apple?s next major OS upgrade has been made available to select premiere developers. This latest seed sports drastic Finder revisions and major ?tune-ups? in performance, sorting, auto-scrolling, spring-loaded folder action, contextual menu handling ? and the new print foundation (CUPS) is also being thoroughly pushed, jammed, and slammed into place by developers.
A few ?Apple people? are also hinting that Apple will be showcasing the new additions coming to OS X 10.2 on their website within the next six weeks ? but I?m still trying to get more solid information, though this makes (obvious) sense if we are to expect 10.2 to be released in July. But again, we?ll have to see?
<strong>Can't we all agree that Finder has issues, one way or another? It doesn't matter why anymore because in a month or two it'll be fixed:
Railhead Design:
Another 10.2 Seed Released
Another seed of Apple?s next major OS upgrade has been made available to select premiere developers. This latest seed sports drastic Finder revisions and major ?tune-ups? in performance, sorting, auto-scrolling, spring-loaded folder action, contextual menu handling ? and the new print foundation (CUPS) is also being thoroughly pushed, jammed, and slammed into place by developers.
A few ?Apple people? are also hinting that Apple will be showcasing the new additions coming to OS X 10.2 on their website within the next six weeks ? but I?m still trying to get more solid information, though this makes (obvious) sense if we are to expect 10.2 to be released in July. But again, we?ll have to see?
Well, Railhead didn't know much about Photoshop (his b85 was way off), so I don't know how good his sources are.
But the bit about Apple posting news about 10.2 on Apple.com in a few weeks sounds correct.
Apple has more or less confirmed that 10.2 will be showcased on WWDC May 6, and I guess that they will publish some info on 10.2 on Apple.com the same day or so.
I wish the finder was faster also. But Apple is doing a good job for working with a new kernel and code set they have never worked with.
Cocoa is the better API, but coding for it won't really explode until we get a true 64 bit archetecture. Carbon was originally created so developers could easily port OS 9 apps to OS X. Don't forget that.
But this flame war of a thread is is emberassing.
Finally, if you hate the finder that much, use Snax or another finder alternative.
<strong>This is childish.
I wish the finder was faster also. But Apple is doing a good job for working with a new kernel and code set they have never worked with.
</strong><hr></blockquote>
Actually, the engineers that are working on it were the ones who designed it. So they know it inside and out.
[quote]<strong>
Cocoa is the better API, but coding for it won't really explode until we get a true 64 bit architecture. Carbon was originally created so developers could easily port OS 9 apps to OS X. Don't forget that.
</strong><hr></blockquote>
Has has already been established, Carbon and Cocoa are designed to be *EQUAL* API's. There is no way in h ell that Adobe and the like are going to rewrite their apps in Cocoa, just because some *believe* that Cocoa is better than Carbon.
And would you please cite some examples as to why you believe that Cocoa is better?
[quote]<strong>
But this flame war of a thread is is emberassing.
</strong><hr></blockquote>
And fun
[quote]<strong>
Finally, if you hate the finder that much, use Snax or another finder alternative.</strong><hr></blockquote>
And I'm sure some are.
<a href="http://www.oreillynet.com/pub/a/mac/2001/05/23/cocoa_vs_carbon.html"; target="_blank">http://www.oreillynet.com/pub/a/mac/2001/05/23/cocoa_vs_carbon.html</a>;
<a href="http://www.savannahmug.org/mmo/archived/cocoacarbon/cocoacarbon.html"; target="_blank">http://www.savannahmug.org/mmo/archived/cocoacarbon/cocoacarbon.html</a>;
<a href="http://maccentral.macworld.com/news/0101/04.macosx.shtml"; target="_blank">http://maccentral.macworld.com/news/0101/04.macosx.shtml</a>;
There are a few I could find real quick. I have more at home.
Carbon was created for a buffer for Developers to quickly port Classic apps to OS X. So basically, it is a "port" of the classic mac os API to run in a unix enviroment. Cocoa is pretty much Openstep, which is the upgrade to NextStep which is an off shoot of BSD Unix. The biggest problem Carbon is going to produce is when apple decides to take OS X to a true 64 bit platform. Since cocoa and most of the other enviroments and elements of OS X are Object Oriented, like 99% of other Posix systems, it can be easily upgraded to 64 bit, or scaled. This is the problem with standard c programming. All the code is compiled together, and dependent on itself. With Object orientated programming, you make different parts, and they work together to make the app. A good example, strictly for concstruction, and not durability etc, is making lincoln logs, (cocoa) and a tree (carbon.) With Lincoln logs, you can constantly rebuild your little house, and the base, which is say, 32 bit, you can swap out easily for a new base, 64 bit. With a tree, it constantly grows, and you can never rebuild a tree. And once it's root is established, 32-bit, to make it 64 bit you would have to completely cut down the tree. Also, with a tree, you can cut off limbs and have new ones grow. But it starts to weaken because of this, and if you ever have to take a big chunk out of the base, even if you patch it with wood cement, you eventually will have to brace the tree, and that tree is never really "whole" anymore.
With the lincoln logs, if one piece gets broken, you can simply replace it.
This is the problem Windows right now. They have built it in a "Tree" fashion. So it's going to be hard to make NT 64 bit without growing a new tree.
Posix systems and their apps can usually be made 64 bit, or even 128 bit easily, with simply taking out the base and swapping them. Look how fast red hat had a 64 bit version of their flavor of linux to run on itaniums.
Also taking full advantage of Open GL, Java, and many other elements of Mac OS X's posix system is the other great thing about Cocoa.
Plus, It's adobe's fault for them having these problems converting to a cocoa system. If they kept supporting irix they would have been able to quickly port it from their sgi verion to mac os x. The reason they quit supporting it is.... MICROSOFT.
Thats another great thing about object-c. You can make a program for linux and easily make it for darwin or cocoa. And thats whats so great. It's very open. Can you imagine games coming over to amc os x super fast if all the companies had to do is change certain parts of the code with object c?
Thats why companies that don't adapt are going to kill themselves or get left behind. Also it's why if apple doesn't get cocoa to be more fully supported by more than posix gurus and programmers, mac os x is good as dead. Why even waste our time on a UNIX system if your not going to take full advantage of it.
Why put a 500 horse power engine in a vehicle with a rear end gear ratio to pull. Sure you can pull houses off of their foundation, but when you can't go over 35 miles per hour whats the point? You're wasting gas, and you wasted a big investment.
GPT
[ 04-12-2002: Message edited by: GPTurismo ]</p>
At this point, Carbon has some disadvantages. But so does Cocoa (Printing manager, anyone? It's CARBON!) As far as things like ScrollWheel support and moving the Preferences menu item, these are the programmer's job, not Carbon's. There is even Carbon Service support (buggy, but it's there). And finally, Mac OS X 10.2 should address most of the outstanding issues, so the two API's will be equal.
As far as the Lincolin Log/Tree analogy, couldn't Apple just rewrite the Carbon API for 64/128 bit and ask developers to recompile their apps? If not, why?
So which is faster, more reliable, and moreeconomical? Replacing a piece of houses in aneighbor hood, like the water meter, going through a forest and cutting chunks out of trees and patching them up and hoping they don't die, or regrowing a forest?
So if they are going to have to rewrite code, why not go ahead and rewrite it in Object C?
You aren't seeing the picture here. This isn't to be rude here. This is the problem with MS, and many other developers, and why us personal computer users are still 32 bit when people like SGI are 64 bit + for the past 10 years., and going 128 bit and even higher in the past few years. And it's not cost. Carbon was developed to be an inbetween Mac OS 9.x and Cocoa. It was to get apps to OS X quickly. The reason they constantly make Carbon more like cocoa is so they can easily make the apps jump to cocoa and then completely remove the carbon api. Cocoa is a true unix enviroment. So why keep using carbon when we talk about a UNIX system. Carbon is a simply a quick hyrbid. The owner of Realbasic defended carbon saying they are the same. But he didn't once mention the fact when OS X changes to true 64 bit, carbon is going to be scaled out because it can't keep up. It isn't a true Unix Enviroment.
Thats why apple is pushing for Cocoa. The reason so many pieces of apples code are in Carbon? Time, money, and laziness. Apple had to rush many elements of OS X to get it out, so they took their own short cut they developed for developers. The dock is cocoa, because it had to be to work smoothly. The reason why the finder is slow is because it's a hybrid/different language system windows manager on a POSIX system. To speed it up, and make it more smooth like the classic finder, they will need to make it cocoa. Plain and simple.
Trust me, we need to start getting people to go to cocoa, or when Windows goes 64 bit, us mac fanatics will be left in the dust.
So they can rewrite it AGAIN when it goes 256/512? and AGAIN when it goes 1024/2056, and AGAIN....
That starts to break compatibility, and creates problems., and slowsit down even faster.
First, you can get past most word-size problems simply by using ANSI C: The C standard defines the sizes of its types relative to each other, and it defines constants for max and min values whose values are set by the compiler. If you follow the standard, all that's required to switch word sizes is a recompile. You run into trouble if you use compiler-specific types like "int16," but that's true in any language. OO does not necessarily buy you abstraction from underlying word sizes.
As has been discussed at length on these boards, machines have remained 32 bit for as long as they have (significantly more than 10 years!) because a range of plus or minus 2 billion is adequate for all but the most demanding tasks required of a computer. The cases a 32-bit architecture can't handle efficiently have been (and generally remain) rare enough not to be worth imposing the tradeoffs associated with a 64-bit architecture, or worked around with specialized additions. The venerable 68040 processor had an 80-bit floating point unit.
The programming concept you're looking for is "modularity," and it is not an advantage unique to OO. Modular programming was firmly entrenched when Dennis Ritchie designed C in 1973 (n.b.: OO had been around for about 8 years by then). Some OO languages take it to another level. But if you want to split your C app into a lot of manageable chunks, that's quite possible.
As for Carbon, it is not purely OO (although it, like the Mac Toolbox, borrows from OO), but it's quite possible to write an OO application using Carbon, complete with code divided up into chunks and linked either statically or dynamically. You could write a Carbon app in Objective-C if you wanted to (as it was possible with the Toolbox, via MacApp or PowerPlant or TCL, or hand-rolled code). In fact, nearly all Cocoa apps have some Carbon code in them, because Carbon is currently the only way to access OS X's HFS+ and XML parsing libraries.
If the Carbon API is contributing to the current Finder's shortcomings, it's because of growing pains, not because of any deficiencies specific to Carbon, or to procedural code.
Steve once said that he wished he'd used Smalltalk rather than Pascal as the original Macintosh's language. Imagine where we'd be if he had!
[ 04-13-2002: Message edited by: Amorph ]
[ 04-13-2002: Message edited by: Amorph ]</p>