[timmerk]

I heard that Barebones said BBEdit 9 will be rewritten in Cocoa - anyone know if this is true and anyone have an idea of release?

--
Free stuff without referrals? http://referralaccelerated.com

[Kevin]

That would really be cool...

All the Cocoa features available for BBedit..

[Krypton]

The Yojimbo app would suggest that that is the way they are heading.

[Horsepoo!!!]

But what does a Cocoa rewrite do to the end-user?



I kid, I kid. I'm not one of those "Cocoa rewrites bring nothing to the end-user" zealots. *eyes CharlesS and others*

[timmerk]

It lets you use Cocoa services, themes will work nice (the interface is a weird hack in BBEdit right now), and the interface is snappier - Interarchy 8 is rewritten in Cocoa and is much faster.

[Horsepoo!!!]

Originally Posted by timmerk

It lets you use Cocoa services, themes will work nice (the interface is a weird hack in BBEdit right now), and the interface is snappier - Interarchy 8 is rewritten in Cocoa and is much faster.

Ohhh I know what lets you use. I'm just playin' around with the people that try to make me believe these things aren't important.

And before someone interrupts me by saying the lines are blurred and Cocoa and Carbon can be intertwined. I realize that. But the project needs to be Cocoa at heart with bits and pieces of Carbon...not the other way around.

Of course this whole Cocoa argument only applies to apps that should make use of these services, IMO. I couldn't care less about the framework when it comes to games.

[OreoCookie]

I personally don't care. I use TextMate which does an excellent job for what I do (long LaTeX documents, managing several of them at a time, etc.).

[Millennium]

Unlikely. All the so-called "Cocoa benefits" already exist in BBEdit. They gain no benefit, except possibly mindshare among Cocoa-for-Cocoa's-sake zealots, by throwing away their existing Carbon code.

[OreoCookie]

Well, I have never liked BBEdit's interface too much. That is (indirectly) tied to its Carbon roots. TextMate on the other hand has a lot of nifty features (intelligent closing of environments, tabbed interface where you can reorder tabs as you like, ordering of files in the drawer which allows you to sort things independently of their physical location).

Although I haven't tried out the latest version of BBEdit, I find it a bit pricey.

[ltr3]

Originally Posted by timmerk

I heard that Barebones said BBEdit 9 will be rewritten in Cocoa - anyone know if this is true and anyone have an idea of release?

As Rich Siegel himself said:
Whether an application was written using Carbon or Cocoa is as irrelevant as whether the programmer was wearing pajamas or a ball gown.

Of Pajamas and Ball Gowns

The only thing that matters to me is whether or not the app does what I need it to. As far as expensive, as compared to what? I can pay for BBEdit with a few hours of work...

[Chuckit]

That's Rich Siegel, president of Bare Bones, for anyone who didn't recognize the name.

Incidentally, as far as I know, CharlesS is primarily a Cocoa programmer, so I don't know why people think he has some kind of personal stake in promoting Carbon.

[CharlesS]

Originally Posted by Chuckit

That's Rich Siegel, president of Bare Bones, for anyone who didn't recognize the name.

Incidentally, as far as I know, CharlesS is primarily a Cocoa programmer, so I don't know why people think he has some kind of personal stake in promoting Carbon.

Yeah, I've pretty much only used Carbon within the framework of a Cocoa app, when I want to access some feature that Cocoa doesn't have (like FSRefs). I'm not quite sure why my name came up there. I usually argue against the zealots on both sides of the argument. Of course, this usually ends up causing everyone to hate me...

1. I don't agree with the people that say that the Finder, iTunes, or whatever else needs to be rewritten in Cocoa, because rewriting an app from scratch and getting it to the same level of usability that the old version had would be a major undertaking, and in general, the rapid-development aspect of Cocoa would be completely lost when doing such a thing. Most likely, you'd end up with a program inferior to what you started with, and the situation wouldn't improve until several versions later, and in a lot of cases it wouldn't be worth it.

2. But at the same time, I can't agree with the zealots on the other side (hi, Millenium) who often claim that Cocoa apps offer *no* benefits over Carbon apps. Cocoa apps have quite a few nice features that Carbon apps generally don't, including the system-wide spell checker, the cmd-ctrl-D dictionary, automatic Services support without needing extra code, the emacs shortcuts such as ctrl-A, ctrl-E, etc., being able to use the Command key to manipulate the entire UI when the app's in the background without having to move it to the front, etc. Of course, in BBEdit/TextWrangler's specific case, it doesn't make sense to rewrite in Cocoa to get these features, because BBEdit and TextWrangler have most of them (except for the being usable in the background with the Command key thing). Many people use this fact to argue that these features aren't Cocoa features. However, I would like to point out something obvious:

$ otool -L /Applications/Third\ Party/TextWrangler.app/Contents/MacOS/TextWrangler
/Applications/Third Party/TextWrangler.app/Contents/MacOS/TextWrangler:
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 128.0.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 35.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 24989.0.0)
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 11.0.0)
/System/Library/Frameworks/WebKit.framework/Versions/A/WebKit (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 18.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.2)

Also, you have annoying little UI quirks that Apple could have fixed long ago, but probably never will since they don't seem to care about UI consistency anymore, such as the fact that the line endings don't go in the same place in Carbon and Cocoa text widgets. They never fix this, despite the fact that people have been complaining about it ever since OS X was still in the public beta.

[Thinine]

Originally Posted by CharlesS

I don't agree with the people that say that the Finder, iTunes, or whatever else needs to be rewritten in Cocoa, because rewriting an app from scratch and getting it to the same level of usability that the old version had would be a major undertaking, and in general, the rapid-development aspect of Cocoa would be completely lost when doing such a thing. Most likely, you'd end up with a program inferior to what you started with, and the situation wouldn't improve until several versions later, and in a lot of cases it wouldn't be worth it.

A Cocoa based iTunes would be vastly superior to the current version in every way. More features and speed with a smaller, more maintainable code base. Just take a look at Cog's import and data display performance (it's a very alpha program) compared to iTunes. A rewrite would also provide a good time to replace iTunes' current ID3 tag editor with a more modern and flexible one. A Cocoa rewrite would be a worthwhile and very doable in the year until Apple's likely to release iTunes 7.

But none of this will happen since it's likely Apple wants to keep as much of the code base the same across platforms, which really sucks for us Mac users, since we have to kept in the dark ages of QT's cross platform code.

[Horsepoo!!!]

I haven't used BBEdit in a long time so I can't confirm if what Millenium says is true (that BBEdit has *all* of the 'Cocoa benefits')...

...but, what the hey, I'll download it to see what they've added.

...

Indeed, they've included almost every thing Cocoa apps get free.

This is indeed one of the very few Carbon apps that has gone beyond my expectations making use of nibs for its interface...drawers, all the Cocoa services (services, spell check, auto-complete, dictionary, etc.)

I guess I should have checked it out before making my sweeping remark. BBEdit would be one of the few Carbon apps that it wouldn't make sense to rewrite. Especially since the general consensus is that it works...and works well.

I'm not sure the same could be said for very many Carbon apps.

[CharlesS]

Originally Posted by Thinine

A Cocoa based iTunes would be vastly superior to the current version in every way. More features and speed with a smaller, more maintainable code base.

More features: Not really, all the development time would have to go into re-implementing all the existing features. There's a pretty good chance that the initial version would have fewer features than the current version until after another revision or two.

Speed: I'm not sure why people try to use speed as an argument, since Carbon is much faster than Cocoa.

[Thinine]

You've never used Core Data, have you? It kicks the crap out of whatever iTunes is using right now. Threading is also much easier in Cocoa, which would be a great benefit to iTunes, since it currently doesn't thread that well (I think it still uses the old cooperative threading in Carbon). And if you think Apple's engineers couldn't implement every feature iTunes has right now in a year, you must think they're pretty stupid.

[Chuckit]

Originally Posted by Thinine

A Cocoa based iTunes would be vastly superior to the current version in every way. More features and speed with a smaller, more maintainable code base. Just take a look at Cog's import and data display performance (it's a very alpha program) compared to iTunes.

1. Since when does Cocoa = speed? If anything, Cocoa is slower because Objective-C's method-call overhead. Unless Apple is just crippling Carbon, I don't see why Cocoa would necessarily be faster.

2. What additional features would iTunes reap from Cocoa? Neither framework really has a digital-jukebox library.

3. I don't see anything special about Cog, nor do I see what it gets from Cocoa that it couldn't with Carbon.

[Thinine]

See my response to CharlesS. And there isn't anything special about Cog aside from the fact it's a Cocoa app using Core Data and it's song importing performance is greater than iTunes'.

[Millennium]

Originally Posted by CharlesS

2. But at the same time, I can't agree with the zealots on the other side (hi, Millenium) who often claim that Cocoa apps offer *no* benefits over Carbon apps.

It's not my intent to come across as a Carbon-zealot, and I apologize if I sound like one. What I am trying to do is counter the people who want an app to be re-written in Cocoa but can't offer any concrete reasons for it. Note that re- in there; I am in no way opposed to developing applications in Cocoa. Quite the opposite. I am, however, tired of people who advertise "written in Cocoa" as a feature of their apps, as though it offered any intrinsic benefits to users.

Cocoa apps have quite a few nice features that Carbon apps generally don't, including the system-wide spell checker, the cmd-ctrl-D dictionary, automatic Services support without needing extra code, the emacs shortcuts such as ctrl-A, ctrl-E, etc., being able to use the Command key to manipulate the entire UI when the app's in the background without having to move it to the front, etc.

And, as BBEdit and TextWrangler show, none of these are impossible in Carbon. I'm not opposed to rewrites, as long as someone can give a concrete reason for throwing away their existing code that doesn't reduce to 'zomg COCOA RULZ!!!!!1!!'. For an example of a project which is in the middle of doing something like this right now and has a well-thought-out reason behind it, consider Josh Aas' take on why Firefox is being transitioned to use Camino's Cocoa-widget code.

[Thinine]

I don't care about BBEdit (though TextMate is an impressive example of what a Cocoa text editor can do) but I do think iTunes would greatly benefit from a Cocoa rewrite. iTunes bothers me on my quad, since it's one of the few apps that I can get to hiccup when just updating tags or switching views.

[Chuckit]

Originally Posted by Thinine

See my response to CharlesS. And there isn't anything special about Cog aside from the fact it's a Cocoa app using Core Data and it's song importing performance is greater than iTunes'.

So rather than simply write a better import algorithm (in fact, Apple has the entire source to CoreData and could simply reuse that), you believe the entire application should be rewritten?

[Thinine]

Wait, wait. You're suggesting that Apple port Core Data to Carbon and use that? You must be joking or incredibly stupid. It would seem that would just negate your entire point about staying in Carbon producing a more stable application, since the new Core Data Carbon would have to be debugged like Core Data has been for the last year and a half.

[Chuckit]

I was saying they could copy whatever uber-fast SQLite code they've stuck in Core Data. Most of the functionality in Core Data would not be necessary to address your complaint about import speed.

[Thinine]

Core Data is much more than merely SQLite integration. Managed object contexts, etc.

[Chuckit]

Yes, but we're merely talking about what the end user sees, right? Specifically, your complaint was iTunes' import speed.

[Thinine]

Yeah, and I'm talking about viable solutions. If you think rewriting iTunes in Cocoa isn't viable, how can you think rewriting Core Data in Carbon is? It doesn't make any sense.

[Chuckit]

Who said anything about "rewriting Core Data in Carbon"? I merely said that if the problem is iTunes import routine, that needs to be rewritten, not that and every other part of the application, and that Apple already has the source code to an import routine you approve of that could probably be fairly easily adapted to work within iTunes.

[Thinine]

Yeah, you imply in that statement (has the source code for) that Core Data be used to replace whatever they use now for iTunes data management. That would require porting or otherwise replacing the functionality of it to work in Carbon. Unless you really think Core Data could be well integrated into a Carbon application as it exists now.

In any event, iTunes must be rewritten eventually, unless Apple wants it to become the crustiest OS X application. The whole dual development of Carbon and Cocoa is ridiculous as well, so a Carbon iTunes likely means a stagnant iTunes.

[CharlesS]

Originally Posted by Thinine

You've never used Core Data, have you? It kicks the crap out of whatever iTunes is using right now.

Please elaborate on exactly what benefit basing iTunes on CoreData would have to the end user.

The one thing iTunes would get from Cocoa, as I see it, would be emacs shortcuts in the ID4 text fields (this drives me nuts). However, a far better use of development time would be to fix the Carbon text widget so that iTunes and all other Carbon apps would inherit this functionality automatically. That would make me quite happy.

Threading is also much easier in Cocoa, which would be a great benefit to iTunes, since it currently doesn't thread that well (I think it still uses the old cooperative threading in Carbon).

Er, what?

Originally Posted by Millennium

It's not my intent to come across as a Carbon-zealot, and I apologize if I sound like one. What I am trying to do is counter the people who want an app to be re-written in Cocoa but can't offer any concrete reasons for it. Note that re- in there; I am in no way opposed to developing applications in Cocoa. Quite the opposite. I am, however, tired of people who advertise "written in Cocoa" as a feature of their apps, as though it offered any intrinsic benefits to users.

And, as BBEdit and TextWrangler show, none of these are impossible in Carbon.

It does offer some intrinsic benefits - the ones I outlined above, and a few more minor things as well. Sure, those benefits can be duplicated manually in a Carbon app, but that doesn't take away from the fact that all Cocoa apps have these features. It's particularly ironic, because the way BBEdit and TextWrangler get a lot of these features is by linking against the Cocoa framework and writing some of the app in Objective-C (run class-dump on TextWrangler sometime, and you'll see it). Plus, Cocoa apps have a higher likelihood to conform to certain design aesthetics, due to Interface Builder being required for Cocoa but not necessarily for Carbon (a lot of Carbon apps still use the old ResEdit-style resources, just in a data fork .rsrc file). All in all, there are a number of reasons that it's nice to know that a given app is written in Cocoa.

Of course, this doesn't mean that every Carbon app must be rewritten in Cocoa. You see, there is a middle ground here in between all the various zealotries.

Originally Posted by Thinine

The whole dual development of Carbon and Cocoa is ridiculous as well

No, it's not. Apple's plans are (or at least were, granted I read about this a couple of years ago) to eventually get Cocoa rewritten to the point that it is built on top of Carbon. When this happens, Carbon and Cocoa will provide a low-level and high-level API for developers to choose from (and yes, there are some times when a low-level API is nice to have). Hopefully, whenever this is done, it will get rid of some of the annoying noticeable little differences between the two. I would expect it would also make it even easier than it is now to access each API's features from the other.

[madmacgames]

Originally Posted by OreoCookie

TextMate on the other hand has a lot of nifty features.

As a programmer, I personally cannot stand TextMate. Yeah it has some nice flash and gizmo's going for it, but IMO it really does not have alot of useful features and is certainly lacking power features. I really don't see how it can increase anyone's productivity. To be honest I really hate it. I guess lazy programmers might like it for coding, but I mean I really really hate it.

BBedit's interface is not "pretty" and it is not nifty and it doesn't have cool gizmos, but it is not about that. It is about being a powerful text editor. I think that you'll find alot of us "BBEdit guys" already know this, and really don't care that it isn't pretty or nifty or flashy or gimmicky, because that's not why we use it.

We use it because 1. it gets the job done, 2. it is really powerful, and 3. it stays the heck out of your way.

*if comparing to TextMate a 4th might be, 4. It doesn't think it knows better than you*

[Chuckit]

Madmacgames, could you provide some examples of good editing features BBEdit has that TextMate doesn't and misfeatures TextMate has that BBEdit doesn't? I'm curious.

[CharlesS]

Well, BBEdit costs $200, so I should hope it has some abilities that the $50 TextMate doesn't...

[OreoCookie]

Originally Posted by madmacgames

As a programmer, I personally cannot stand TextMate. Yeah it has some nice flash and gizmo's going for it, but IMO it really does not have alot of useful features and is certainly lacking power features. I really don't see how it can increase anyone's productivity. To be honest I really hate it. I guess lazy programmers might like it for coding, but I mean I really really hate it.

BBedit's interface is not "pretty" and it is not nifty and it doesn't have cool gizmos, but it is not about that. It is about being a powerful text editor. I think that you'll find alot of us "BBEdit guys" already know this, and really don't care that it isn't pretty or nifty or flashy or gimmicky, because that's not why we use it.

We use it because 1. it gets the job done, 2. it is really powerful, and 3. it stays the heck out of your way.

*if comparing to TextMate a 4th might be, 4. It doesn't think it knows better than you*

I still think BBEdit is overpriced and overrated. There are lots of other editors out there (e. g. Pepper, the much-acclaimed SubEthaEdit) that can do plain-vanilla editing. So aren't there other, cheaper (as in less than $200) editors that can do the same? What are those power features you're talking about?

Maybe LaTeXing in TextMate is different from programming in TextMate, but the most important feature for me (which is not a gizmo of sort, that's for sure, nor is it flashy) is to sort files in a unique way in the sidebar, having access to all necessary files without those superfluous other TeX files. I can start by sorting them by what they are for: supplements > header.tex, title.tex, etc. and main > chapter_01.tex, etc. Later, it's more useful to sort by author Author A > files, Author B > files, etc., and then merge some files.

You might consider editing with macros a gizmo, but it helps me to avoid mistakes, especially with misspelled environments. I rarely do any mistakes which prevent the .tex file from compiling.

[madmacgames]

Originally Posted by OreoCookie

What are those power features you're talking about?

Here are just a few:
- Opening files by name, for example system files, TextMate won't do. You have to go into terminal and use the "mate" command line helper, which is a pain unless you are already in a terminal.
- Opening remote files over FTP or SFTP, again TextMate doesn't do.
- Search & Replace is too basic in TextMate. It is ok for day to day stuff, but if you code year round, it will eventually fall short. Compare it to BBEdit's Search & Replace dialog. Now there is a power search.
- Subversion support is superior in BBEdit, IMO (and I even think BBEdit's support does not go far enough). TextMate doesn't even have a delete from repository option for SVN in the default Bundle. And I didn't see an option to commit a whole working copy. Instead you have to select the right folder when you want to do that, and each time you want to do that. These are just a couple, but I'll take better functional Subversion integration with plain text printouts over HTML printouts any day.
- Comparing files and diffs. I'm not really sure what the purpose of the diff Bundle in TextMate is. Yeah you can look at a cool colored diff output in HTML format, but can't really do much with it. BBEdit diff and file comparing features are much more powerful.

One thing TextMate does have going for it are the tab triggered snippets. BBEdit has kind of similar thing (the Glossaries), but it is tedious to use in BBEdit, IMO. I hope they address this in BBEdit 9. But I could care less about some of the TextMate gizmos like smart typing and code folding. I've just never been big on hiding my code from myself. One other thing I really dislike about TextMate is that there is no preference to turn off auto indenting. That one really irks me because what ends up happening is you either have to be on the backspace key all the time or end up with a file full of blank lines that have a bunch of tabs in them for no reason. BBEdit at least gives you the option, and you can use the other with the keystroke command + return.

Which brings me to the final point of things lacking in TextMate, because it is getting late. TextMate does not offer you enough preferences. You might think BBEdit has too many, and trust me they do take some time to go through, but tweaking the program to your liking is fantastic, especially if it is a program you use every day, all day. There are alot of things I wanted to change about the way TextMate worked, but there was no option for it.

Like I say TextMate seems to be ok for day to day normal coding, but if you code every day then you're going to run into situations where you need to do things that either TextMate does not do, doesn't do very well, or doesn't have the power you need.

[madmacgames]

Originally Posted by OreoCookie

You might consider editing with macros a gizmo.

Automation isn't a gizmo. It's a useful feature, but BBEdit has equivalent automation features, so it's not really worth discussing in a comparison since both offer the ability, as far as I can tell, equally well for arguement's sake. But I really don't know since I'm not really big on automation when it comes to coding, and haven't even really used BBEdit's automation features other than to quickly see what they were about.

[eevyl]

Originally Posted by CharlesS

Yeah, I've pretty much only used Carbon within the framework of a Cocoa app, when I want to access some feature that Cocoa doesn't have (like FSRefs).

So you are saying Carbon has some developer features that Cocoa does NOT have? You so so MUST be kidding! Cocoa is vastly superior to the begining and the end user in anything and 200% faster and it's so easy to rewrite a thousands lines of Carbon code application to Cocoa that one handed monkey could do it! </irony>

I cannot fathom too that Horsepoo! talked about BBEdit gaining stuff if it was ported to Cocoa without checking if it already had all those "gains" in its current Carbon incarnation. Must have been one in a lifetime, he for sure has checked all Carbon applications and knows first hand that they are crap compared to being rewritten in Cocoa

[OreoCookie]

Originally Posted by madmacgames

Here are just a few:
- Opening files by name, for example system files, TextMate won't do. You have to go into terminal and use the "mate" command line helper, which is a pain unless you are already in a terminal.

I'm not sure what you mean here … are you talking about hidden files?

Originally Posted by madmacgames

- Opening remote files over FTP or SFTP, again TextMate doesn't do.

Point taken.

Originally Posted by madmacgames

- Search & Replace is too basic in TextMate. It is ok for day to day stuff, but if you code year round, it will eventually fall short. Compare it to BBEdit's Search & Replace dialog. Now there is a power search.

TextMate supports search with reg exes like BBEdit does. So the search dialogs are equally powerful. Note the nifty feature that you can search and replace within a selection with the touch of a button -- a feature I came to love.

Originally Posted by madmacgames

- Comparing files and diffs. I'm not really sure what the purpose of the diff Bundle in TextMate is. Yeah you can look at a cool colored diff output in HTML format, but can't really do much with it. BBEdit diff and file comparing features are much more powerful.

I haven't used that feature a lot, since I work differently (several authors combining texts).

Originally Posted by madmacgames

One thing TextMate does have going for it are the tab triggered snippets. BBEdit has kind of similar thing (the Glossaries), but it is tedious to use in BBEdit, IMO. I hope they address this in BBEdit 9. But I could care less about some of the TextMate gizmos like smart typing and code folding. I've just never been big on hiding my code from myself. One other thing I really dislike about TextMate is that there is no preference to turn off auto indenting. That one really irks me because what ends up happening is you either have to be on the backspace key all the time or end up with a file full of blank lines that have a bunch of tabs in them for no reason. BBEdit at least gives you the option, and you can use the other with the keystroke command + return.

Code folding can be a nice feature. I use it for my .bib files so I can just read the beginning of the entry -- including the id tag of said entry. I don't need to see the rest.

If you don't want to fold code, I found them very helpful as visual cues where environments stop.

Originally Posted by madmacgames

Like I say TextMate seems to be ok for day to day normal coding, but if you code every day then you're going to run into situations where you need to do things that either TextMate does not do, doesn't do very well, or doesn't have the power you need.

I think you misunderstood my comment a bit. I wasn't making a case for TextMate, rather one against BBEdit: there are other capable editors out there that I think are equally powerful or even more powerful. Paying $200 for a text editor is insane. Just to make it clear, I don't wanna argue for a specific alternative (nor is this -- for me at least -- about Carbon or Cocoa; in fact, I wouldn't be excited even if it were fully rewritten from scratch in Cocoa), I just feel that paying that much for an editor is a rip-off. There are plenty of alternatives out there which are either for free (emacs, vim or even TextWrangler for instance) or cost far less (from the top of my head: SubEthaEdit, Pepper, TextMate) than $200.

On another note: I don't do programming, but I do rely on a text editor pretty much 5-6 days a week, so I do `code' every day and find TextMate more than capable. So to say that a specific editor is or is not fit for a specific task is entirely personal.

Edit: fixed some spelling, apparently I shouldn't post before having my coffee in the morning.

[CharlesS]

Originally Posted by eevyl

So you are saying Carbon has some developer features that Cocoa does NOT have? You so so MUST be kidding! Cocoa is vastly superior to the begining and the end user in anything and 200% faster and it's so easy to rewrite a thousands lines of Carbon code application to Cocoa that one handed monkey could do it! </irony>

Uh, and when exactly did I say any such thing?

hint:

Originally Posted by CharlesS

1. I don't agree with the people that say that the Finder, iTunes, or whatever else needs to be rewritten in Cocoa, because rewriting an app from scratch and getting it to the same level of usability that the old version had would be a major undertaking, and in general, the rapid-development aspect of Cocoa would be completely lost when doing such a thing. Most likely, you'd end up with a program inferior to what you started with, and the situation wouldn't improve until several versions later, and in a lot of cases it wouldn't be worth it.

Originally Posted by CharlesS

Speed: I'm not sure why people try to use speed as an argument, since Carbon is much faster than Cocoa.

[monkeybrain]

Umm, CharlesS, he said "</irony>".

[Amorya]

The reason I usually promote cocoa as a benefit for the end user is because, on average, a cocoa app is more likely to obey the interface guidelines more consistently than a carbon app. This is on average - because cocoa makes it much easier to obey the guidelines (for the programmer I mean), more cocoa apps do. In other words, cocoa is more forgiving of a programmer who doesn't want to put the effort in.

I don't think cocoa has some magic capabilities that carbon does not - it's all about ease of programming. Hence I wouldn't advise rewriting Photoshop in cocoa - the gain would be outweighed by the bloody ages it would take to essentially start again, even taking into account the rapid programming model of cocoa.

BBEdit is one of the better carbon apps in my mind. There are things about it that suck (like the preferences dialog), and there are things that are done well (like using Services).

BTW, in my app development (nothing much publicly released I'm afraid) I've used both carbon and cocoa. I always use cocoa for the main project, but I really appreciate that you can drop down to carbon with no trouble. Particularly for graphics, that can be a godsend.


Amorya

[madmacgames]

Originally Posted by OreoCookie

TextMate supports search with reg exes like BBEdit does. So the search dialogs are equally powerful.

No, I'm afraid they are not "equally powerful". Have you even seen or used the search dialog in BBEdit 8? regex is just the tip of the iceberg, and since they both have it, it was nullified.

Wait you have said you have not even tried BBEdit 8, so there is no possible way you can make that claim or any of other strikes against BBEdit you are making. That is what is insane, talking about an application's features that you haven't even used.

[Thinine]

Originally Posted by Amorya

I don't think cocoa has some magic capabilities that carbon does not - it's all about ease of programming. Hence I wouldn't advise rewriting Photoshop in cocoa - the gain would be outweighed by the bloody ages it would take to essentially start again, even taking into account the rapid programming model of cocoa.

Bindings and Core Data come pretty damn close to magic.

[Gavin]

Does cocoa .vs carbon give you an advantage when getting your code working as a universal binary?

Could it be that some of the legacy stuff is harder to port?

[Amorya]

Originally Posted by Gavin

Does cocoa .vs carbon give you an advantage when getting your code working as a universal binary?

Could it be that some of the legacy stuff is harder to port?

Cocoa is typically easier to port, yes... it's the same with getting resolution independence and things like that. Cocoa gives it for free (mostly), and carbon has more work to do to get the same level.

Of course, carbon is a godsend if you're doing something unusual that the designers of cocoa did not expect.


Amorya

[Dair Grant]

Originally Posted by Amorya

Cocoa is typically easier to port, yes...

Sorry, that just not true. You have exactly the same issue no matter which framework you're using - if you have data that goes between architectures then you need to swap it appropriately. If you build your file formats on an API that takes care of this for you (e.g., CFPropertyList or NSKeyedArchiver) then it's handled for you, if you read/write raw data directly then you need to handle it.

Originally Posted by Amorya

it's the same with getting resolution independence and things like that. Cocoa gives it for free (mostly), and carbon has more work to do to get the same level.

That's also not true... Any modern Carbon application uses HIViews and CoreGraphics, at which point resolution independence (when it's released) should be automatic.

Originally Posted by Thinine

Bindings and Core Data come pretty damn close to magic.

Bindings are just synchronised key-value pairs, and CoreData is just a database interface. They both have their uses, but neither are magic.

[Thinine]

Core Data is far more than "just a database interface."

[Chuckit]

Originally Posted by Thinine

Bindings and Core Data come pretty damn close to magic.

Bindings comes pretty close to magic if magic is almost useless for any nontrivial application.

[Thinine]

Just because you don't know how to use it doesn't make it useless.

[CharlesS]

Originally Posted by Thinine

Just because you don't know how to use it doesn't make it useless.

Well, I wouldn't call it useless since it might work well for some purposes other than mine. However, the fact that bindings break NSOutlineView's itemAtRow:, making it impossible to access the actual object without using undocumented APIs, was a dealbreaker for me...

[bewebste]

One point re: porting iTunes to Cocoa to take advantage of CoreData - remember that CoreData is 10.4 and above only, whereas the current iTunes runs all the way back to 10.2.8. I highly doubt that Apple's going to be dumping both Jaguar and Panther support for iTunes anytime soon.