or Connect
AppleInsider › Forums › Software › Mac OS X › MacOS X finder needs to be re-written in cocoa
New Posts  All Forums:Forum Nav:

MacOS X finder needs to be re-written in cocoa - Page 3

post #81 of 90
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!

[ 04-13-2002: Message edited by: Amorph ]

[ 04-13-2002: Message edited by: Amorph ]</p>
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
"...within intervention's distance of the embassy." - CvB

Original music:
The Mayflies - Black earth Americana. Now on iTMS!
Becca Sutlive - Iowa Fried Rock 'n Roll - now on iTMS!
Reply
post #82 of 90
First of all I admit to not having read all 80 comments so if I repeat something that has already been said, I apologize.

During the days of 10 before 10.1 when everyone was complaining about how slow the finder was, I went to an Apple dealer and ask him why that was. He told me that the finder was not really compatible with OSX and needed to be updated.

I was completely floored by that and I still am. Can you imagine MS writing a version of Explorer that wasn't compatible with the OS? Cocoa, as i understand it, is the native language of OSX and is the language that native apps have to be written in. Carbon is merely a shortcut that allows programs to be run in 9 and 10.

If Apple wants the rest of the industry to completely retool and produce programs that run natively in 10, they should be leading the way by writing all of their own OSX programs in its native language. What on earth are they thinking?
Apple has no competition. Every commercial product which competes directly with an Apple product gives the distinct impression that, Where it is original, it is not good, and where it is good, it...
Reply
Apple has no competition. Every commercial product which competes directly with an Apple product gives the distinct impression that, Where it is original, it is not good, and where it is good, it...
Reply
post #83 of 90
Mac Voyer:
The Mac dealer you spoke to was either an idiot, a liar, or extremely misinformed. The current Finder was completely written, IIRC, from scratch for Mac OS X. It may be written in Carbon, but that is irrelevant because Carbon and Cocoa are [ideally] peers. Carbon may be a shortcut also, but brand-new programs can be written with Carbon and work beautifully with OSX. I cite Ambrosia's great software goodies as examples.
post #84 of 90
[quote]Originally posted by starfleetX:
<strong>Mac Voyer:
The Mac dealer you spoke to was either an idiot, a liar, or extremely misinformed. The current Finder was completely written, IIRC, from scratch for Mac OS X. It may be written in Carbon, but that is irrelevant because Carbon and Cocoa are [ideally] peers. Carbon may be a shortcut also, but brand-new programs can be written with Carbon and work beautifully with OSX. I cite Ambrosia's great software goodies as examples.</strong><hr></blockquote>

Maybe, but please respond to the last part of my post. Why should anyone do a total cocoa rewrite when Apple, itself, is taking shortcuts. The best programs written for Apple should be written by Apple, not some third party such as Microsoft.
Apple has no competition. Every commercial product which competes directly with an Apple product gives the distinct impression that, Where it is original, it is not good, and where it is good, it...
Reply
Apple has no competition. Every commercial product which competes directly with an Apple product gives the distinct impression that, Where it is original, it is not good, and where it is good, it...
Reply
post #85 of 90
[quote]Originally posted by Mac Voyer:
<strong>Why should anyone do a total cocoa rewrite when Apple, itself, is taking shortcuts. The best programs written for Apple should be written by Apple, not some third party such as Microsoft.</strong><hr></blockquote>Repeat after me: Carbon is not a shortcut. Carbon is completely viable for writing Mac OS X applications.

It would be utterly rediculous to expect the third parties to completely re-write millions upon millions of lines of code in a completely different style. If Apple didn't provide a strong Carbon bridge to Mac OS X, you would see zero support from the important companies like Adobe and Microsoft and even most of the smaller software developers. Apple said that by writing the Finder in Carbon that they were "eating their own dogfood" and proving to third-parties that Carbon was good enough be used in mission-critical applications that the user would have to interact with on a regular basis. Of course, Apple seems to have done a terrible job with the Finder, no? Well, that's what this whole thread is about. Some people say Apple should have let AppleWorks be the shining Carbon example (although it too looks to be an ugly hack-job) rather than the Finder. However, others say that a Cocoa Finder would be no better than our current Carbon Finder, that this one is just sufferring growing pains since it hasn't had the 15 years of optimizations and improvements that the old "classic" Finder had.

Yes, Apple's apps *should* be the best apps out there, but they aren't. Why? We don't know. Final Cut Pro 3 sure looks like a great app; it runs superbly for me on OSX. Guess what? It's carbon! But why is the Finder so bad? Perhaps Steve got mad at the Finder team and fired them all. Perhaps a complete re-write is in the works for 10.2. Perhaps there are simply problems on a deeper level than we normally think about in the Finder, as AirSluf has started pointing out.

[ 04-14-2002: Message edited by: starfleetX ]</p>
post #86 of 90
post #87 of 90
Ok, I clearly need to be educated on this.

I thought that there were certain features that could be implemented in Cocoa but not Carbon. That if you wanted to make full use of OSX, then you had to program in Cocoa. Carbon was just a way to easily port older programs to a new OS but at some point they would have to be rewritten to take full advantage of the new features of the OS.

If this is not true, then what is the purpose of Cocoa in the first place?

[ 04-14-2002: Message edited by: Mac Voyer ]</p>
Apple has no competition. Every commercial product which competes directly with an Apple product gives the distinct impression that, Where it is original, it is not good, and where it is good, it...
Reply
Apple has no competition. Every commercial product which competes directly with an Apple product gives the distinct impression that, Where it is original, it is not good, and where it is good, it...
Reply
post #88 of 90
post #89 of 90
[quote]Originally posted by Mac Voyer:
<strong>Ok, I clearly need to be educated on this.

I thought that there were certain features that could be implemented in Cocoa but not Carbon. That if you wanted to make full use of OSX, then you had to program in Cocoa. Carbon was just a way to easily port older programs to a new OS but at some point they would have to be rewritten to take full advantage of the new features of the OS.

If this is not true, then what is the purpose of Cocoa in the first place?

[ 04-14-2002: Message edited by: Mac Voyer ]</strong><hr></blockquote>

At the moment, there are certain features that Cocoa can access that Carbon cannot. But most of those will be resolved in Mac OS X 10.2. The part you don't hear about is the fact that there are also Carbon-only things that Cocoa cannot get at (easily), like access to Resource Forks.

Cocoa has been around for a long time, in the form of NeXTSTEP at NeXT Computer. When Apple bought NeXT and made NeXTSTEP into Mac OS X, it kept Cocoa and introduced Carbon as a way to easily make old Mac OS programs Mac OS X native. And in the future, it will make no difference whether you use Carbon or Cocoa to make your app (as long as you do a good job making it).

There are other factors that make an app nore native than another, like whether it is compiled as Mach-0 instead of PEF or CFM. That is what really makes the difference, not the language or framework an app is built on.

Now, could someone please explain the differences between CFM and Mach-0? AirSluf?
"Because the people who are crazy enough to think they can change the world, are the ones who do." - Think Different
Reply
"Because the people who are crazy enough to think they can change the world, are the ones who do." - Think Different
Reply
post #90 of 90
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Mac OS X
AppleInsider › Forums › Software › Mac OS X › MacOS X finder needs to be re-written in cocoa