Slashdot Mirror

Please give an example of something that the Cocoa APIs can do that the Carbon APIs cannot. According to this article, Cocoa and Carbon are functionally equivalent. Cocoa is the Objective C API. Carbon is the C/C++ API.

Is Cocoa Better than Carbon?

The short answer is no. The Cocoa and Carbon APIs both call functions in the Application Services and Core Services layers of Mac OS X. Contrary to what some people think, Carbon APIs do not call Cocoa APIs. There is no more overhead in calling Carbon APIs than there is in calling Cocoa APIs. The long answer is that if you were going to start writing a new application in a language such as C or Java, and you were only concerned with your application running on Mac OS X, you might choose to learn the Cocoa APIs because they are a higher level API than Carbon. Most Mac developers want to utilize the large base of code they have written over the years as well as their knowledge of C or C++ so they are likely to stick with Carbon rather than learn Objective-C and rewrite their code using the Cocoa APIs.

Can applications that use Cocoa do more things than applications that use Carbon?

The short answer is no. The Cocoa and Carbon APIs both call into the same parts of Mac OS X. However, there is a small set of functions that Apple has not yet made available to Carbon simply because they weren't needed for Mac applications to be made native on Mac OS X. The reverse is also true. There is a small set of functions that Carbon applications can access on Mac OS X that Cocoa-based applications can't simply because Cocoa applications didn't need them because they weren't used to having those functions anyway. Apple is working to reduce these differences to zero.

Are Cocoa-based applications "more native" than Carbon-based applications?

No. Both Cocoa and Carbon call into the same parts of Mac OS X. Cocoa applications are no more or less native than Carbon applications. The Carbon APIs are newer to Mac OS X than the Cocoa APIs and as a result there may be more problems with them in the short term than there are with Cocoa but that is a problem that Apple will solve.

On the Mac, for light-duty applications with extensive GUI widget use, the development tool REALbasic is like that. You can drag controls onto a window and build working 'mockup' applications without even writing code, even to the point that they will have tabbing between windows, drag and drop, etc... if you can program well using widgets and an object model you can knock out functional apps absurdly fast.

I'm of the mind that what needs to happen is Microsoft needs to be clubbed over the head until dead, because if not for them, LOTS of people would be making IDEs and tools like this. The way things stand, you have to have a product as great as REALbasic, AND you have to have it on an alternate platform like the Mac, in order to get anywhere with it. And since there's lots of gearheads programming Linux, they're not racing to develop this sort of thing... not their style or their culture...

My point exactly. For generic office work a mac is just as good as a pc, and generally has the same apps available. When it comes to word processing, excel, powerpoint, and the rest of the office apps, the main difference at this point is the mac versions are slightly more polished. Part of the problem probably comes from in-house visual basic apps. While there is no way to natively run these apps, virtual pc can always be employed, even tho it is a kludge. Or you could use Real Basic which is great for producing the same types of apps as visualbasic, but has the bonus of being able to compile for mac and windows.

Or just have your "VB guys" spend ten minutes learning Realbasic or AppleScript Studio and continue on your merry way.

Of course Mac OS X kicks Win2k's butt. With a fat core of pure UNIX (ask the Open Group)at its base, GNU/Mac OS X (as RMS would call it) has rock solid stability, great multitasking and all the GNU goodies Linux users have grown to love. On top of that is an interface that is so sexy members of the Mormon Faith have to get a waiver to use.

Want to talk about serving? Sure you do! Check out the $999 Server version of Mac OS X. Unlike Windows 2000, for $999 you get the whole shooting match -- no need for the those pesky client licenses that Microsoft lawyers love to sue over.

Worried that Mac OS X has no software available? Don't let your heart be troubled. Like X Windows with Enlightenment and Gnome? Mac OS X has got that. Need a good web server? How about Apache and Zeus. Want a browser that doesn't suck? We got those in spades, IE 5.1.1 (well it does suck a little), OmniWeb, Fizilla, iCab and Lynx. Need a word processor? We have Nisus Writer, BBEdit, Microsoft Office and every Macintosh users favorite, Appleworks. Need a rapid application development platform? Got those two, the free Project Builder from Apple and RealBasic. Need graphic apps? How about GIMP and Photoshop. I could go on and on, but I use Macs to make a livin' and not wastin' time on Slashdot.

Sure Mac OS X 1.0 is not the perfect OS. It has some bugs and some features are a little slow. But it is an amazing first step in the journey of putting UNIX on the consumer desktop. Linux developers can learn about an consumer OS by taking a long gander at this amazing first shot.

There are several development environments for the Mac... either free, or low-cost:

• MPW (Macintosh Programmer's Workshop) has been available from Apple for years, and is a (free for the download) full and complete C and C++ development environment.
• RealBasic is fairly cheap ($149 for standard edition, without Windows support), and is pretty well regarded, especially for hobbyist developers.
• CodeWarrior is very well regarded, supports cross-platform development (i.e., compile Windows programs from the Macintosh IDE)... it's a little more expensive ($300-$400), but I think many of the shareware developers find that the productivity increase (not only from from the IDE, but also from Metrowerk's Application framework, PowerPlant) is worth it.
• And, last but not least, every retail copy of Mac OS X comes with ProjectBuilder, the Mac OS X version of the very well regarded Next development tools. Including make, ar, gcc, and all of those command line tools Unix developers love.

In fact, I think the inclusion of ProjectBuilder with Mac OS X has enabled a lot of hobbyist/shareware developers (not to mention Next oldtimers) to get a head start at developing software for the OS. Just look at VersionTracker's Mac OS X pages for evidence.

1) has hypercard seen a new relese since..1994?
2) what can you do in hypercard that you cant do [better|faster|worse|slower] in REALbasic (hell, it's even carbon!)
3) makeing an aplication in a scripting language is lame. LAME!
3) realy, people..realy...HyperCard is dead.
4) If you just cant grow up, there are alternitives (none come to mind at the moment, but you can always make one..in hypercard =P )

HyperCard always was, and always will be, a nifty piece of software. The thing is, it's severely outdated. It was state-of-the art nifty software in its time, but now it's a relic. I'd compare HyperCard on Mac OS 6 (er...System 6) to Logo on the Apple ][. They were nifty pieces of software that enabled beginners to learn the basics of software design and programming.

In this day and age, I think we need a new tool to do the same thing. For example, REALbasic is a fully modern tool that lets you write apps for both Windows and MacOS. An OS X version has been in beta for a while now, and should be released shortly.

On the other hand, if you really have to run that old stack, SuperCard can import your old stacks. I have not personally used the product, but it should do the task quite nicely. I am unaware of plans to port SuperCard to OS X, but at least it is actively maintained.

I want to know why all this fuss about HyperCard is finally coming to the forefront, while it has virtually been abandonware for two or three years already.

Access no, but the rest of Office will run natively on OS X (4th Q release). It'll be Unix, and it will run MS Office. That can't help but sell a few boxes. Access, sadly probably won't ever be ported to the Mac. On the other hand, Real Basic can do databases, Filemaker listens to Applescript, and the free RDBMS are being ported. Access no, pretty much everything else - yes.

I think it is foolish of Adobe to pursue two operating system features being combined together as a patent. Anybody with Codewarrior or RealBasic on a Mac can make the exact same thing in under a minute.

I think its sad when large software companies fight over software techniques that are neither unique or difficult to create. I think it lowers the quality of all other software that would take advantage of those features.

Essentially it's Delphi for linux, but I have to wonder why they are keeping the linux and windows versions distint.

Sure I realise there are some very large parts of linux missing from windows, and vice versa, but surely the way forward is to abstract these details as much as possilbe from the programmer.

Sure it means that low level components have to be developed seperately for each OS, but this would make code immediately compile on both platforms.

I haven't looekd in on this project for a LONG time but you may want to check out REALbasic (just noticed they wrote IE for mac in it :)) because it lets you build Mac and Windows from the same source, despite the OS differences.

None the less, I love borland/inprise/whateverdafucktheyarecalledtoday, and their software and so long as it's not another JBuilder (cringe) i'll be happy :)

If you have access to a mac, you might also want to try Realbasic. This is supposedly a lot like vb but the programs are compiled better. It's all oop and is demoware too. It can also built to both Windows and Mac systems (compiler is mac only).

That statement was made almost 20 years ago, when BASIC had devolved into the numbered-line version that was included in most personal computer ROMs of that day. Even BASIC's creator's, Kemeny and Kurtz, denounced such versions and wrote a book called Back to BASIC in which they lambasted these "street BASICs." The BASIC that Dijkstra was talking about is quite different from today's variants, such as Visual Basic or REALBasic.

You might also find the commentary on what Dijkstra said here.

In the case of a Mac server, you have two rather esoteric options:

1. Applescript CGI. There's a good tutorial on this here. And I recommend Applescript for Dummies, which, despite its title, is a pretty good foundation in the language. (And about the only thing still in print on the subject, which is odd.)

2. RealBasic CGI. RealBasic is a version of VB for the Mac, produced by a company in Texas (IIRC). It's a solid little package, and someone out there has written module for RB to allow CGI functions...

REALbasic and FutureBASIC are _Mac_ only! I know because I _use_ REALbasic and _have_ a Mac. It's at http://www.realbasic.com/. Yes, it's as good as you say it is. But you're not telling the whole story ;)