Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Re: CodeWarrior

Originally posted by leo
Why take away an alternative? You have never used CodeWarrior, have you? The build process is an order of magnitude faster in CW than in PB. Also the code completion and code reference features are way superior in CW. And the GUI of the IDE feels a lot snappier.
Until Apple can provide the same speed and completeness, no professional programmer I can think of would ever be glad to see CodeWarrior go away.

[edit: foreigner's typos...]

Oh, I forgot to add: In every one of my personal tests, CW produced faster code, typically 5-25% faster.

[edit: addition]

Personally, I dumped CW in the 6-7-8 transition when they kept promising OS X support but couldn't deliver. gcc from Jaguar on is quite fast compiling relative to previous gcc, but, you are correct, nowhere near as fast as CW or of course MSVC++. Runtime-wise, I don't see a difference in my code between CW-compiled and gcc-compiled, but YMMV.

Unfortunately, Metrowerks severely screwed the pooch with their OS X 10.0/1 support early on, making promises left and right that were never delivered, only to finally say, "Oh, well, you should upgrade to CW 8; we have that fixed now!". They won't be getting my money for a few more years.
 
Eclipse

I'm not a GUI developer so I can't speak to Interface Builder too much, it seems cool every time I play with it though.

Give me an Objective C Eclipse plugin and I'd be in heaven though! (Or make Project Builder as intuitive as Eclipse is for Java)
 
Re: CodeWarrior

Originally posted by leo
Why take away an alternative? You have never used CodeWarrior, have you? The build process is an order of magnitude faster in CW than in PB. Also the code completion and code reference features are way superior in CW. And the GUI of the IDE feels a lot snappier.
Until Apple can provide the same speed and completeness, no professional programmer I can think of would ever be glad to see CodeWarrior go away.

[edit: foreigner's typos...]

Oh, I forgot to add: In every one of my personal tests, CW produced faster code, typically 5-25% faster.

[edit: addition]

So 5-25% is an order of magntude faster?

99.9% of coding is in the planning, implementation, debugging. If you waste that much time compiling just get a faster machine.

I'm very impressed with Project Builder and Interface Builder. I come from the Visual Studio world where it's $800 just for the Professional Edition. Don't take a great free tool for granted. Actually this is what sold my company on doing cross platform development.

We use MFC for the front end in Windows, Qt for the front end in Linux (Work in progress) and ObjC for the front end in OS X. All our back end classes are standard C++. It requires more time and planning but implementation errors are fixed significantly easier. Not to mention testing is easier.

I'm straight and god I hate bush ;)
 
Re: Re: Answers

Originally posted by praetorian_x
Diff!?! I have to run a friggen DIFF every time I change the NIB? What the hell is this crap?

Sounds like you're doing it backwards. If you want to use IB to generate your initial header files, that's fine. But once you're into the iterative process, the Right Thing To Do is to add your outlets or actions to your header in PB, then reload it in IB. IB code generation works when you're starting a project, not when you're revising one.
 
I must say that I prefer CW of PB. Mainly because I have used CW since version 3 and I am conformatable with it and chnage in work productivity is bad for me. But I can see myself using PB more and more.
I like the act that CW can do multiple platforms with minimal conversions for simple apps.
I like that PB is included with OS X and is 'free' once you buy the OS.
I think its great that as soon as one month from today we will have some development framwork to allow for 64 bit computing. It seems a solid bet that sooner than later the 970 will appear in a Mac model.
 
Re: Re: More than the compiler

Originally posted by holmesf
4. As for assembly or compiling for PC, why on earth would Apple spend its time and money on this? True, gcc supports compiling for PC already, but why would Apple want to even enable it?

I can see at least two reasons. (1) To avoid the power curve failures. I was there when the 68040 fell behind the x86. It was a painful experience, forcing a radical CPU changes. And now it is happening with the G4 line; they are being forced to dump their primary high-end chip supplier. Going with the x86 Mac could be a safety bet.

(2) It will make an easier "switch" platform. It is a big risk for a Windows user to try to switch to Mac. Between new hardware and many new applications you will have to buy, it will cost about $2000 or more, and they may not like it. An x86 Mac lets Microsoft users try a Mac, and if they don't like it, they can install Windows and all their old applications on it. Very low risk.
 
To echo what others have said, Project Builder needs some serious work to be considered an upto par IDE. Anyone doubting this should play with Eclipse a little bit. To put it simply it is awesome. Autocomplete, refactoring, flagging syntax errors on the fly, the works.

Besides, I think it's pretty much a given that it will receive an update. It is after all the Worldwide DEVELOPERS Conference. I would think it would need updating for whatever cocoa frameworks features apple add in panther.

Granted I still use it for Cocoa, and still prefer programming in Cocoa to anything else, including programming java in eclipse, but it would be nice for it to see some major upgrades.
 
Re: Re: Re: More than the compiler

Originally posted by JoeRadar
I can see at least two reasons. (1) To avoid the power curve failures. I was there when the 68040 fell behind the x86. It was a painful experience, forcing a radical CPU changes. And now it is happening with the G4 line; they are being forced to dump their primary high-end chip supplier. Going with the x86 Mac could be a safety bet.

(2) It will make an easier "switch" platform. It is a big risk for a Windows user to try to switch to Mac. Between new hardware and many new applications you will have to buy, it will cost about $2000 or more, and they may not like it. An x86 Mac lets Microsoft users try a Mac, and if they don't like it, they can install Windows and all their old applications on it. Very low risk.
Oh boy, here we go again.
 
I can see at least two reasons. (1) To avoid the power curve failures. I was there when the 68040 fell behind the x86. It was a painful experience, forcing a radical CPU changes. And now it is happening with the G4 line; they are being forced to dump their primary high-end chip supplier. Going with the x86 Mac could be a safety bet.

(2) It will make an easier "switch" platform. It is a big risk for a Windows user to try to switch to Mac. Between new hardware and many new applications you will have to buy, it will cost about $2000 or more, and they may not like it. An x86 Mac lets Microsoft users try a Mac, and if they don't like it, they can install Windows and all their old applications on it. Very low risk.

Ok. Please. Enough of this. Lets just hammer this into the ground and not have it appear again for a long time.

We are talking about Project Builder here. We are talking about the NeXTStep team. They could if they wanted move the Cocoa frameworks to x86 in a month, we know this. There is no reason for them to keep a running port right now to maintain this.

Now x86. This has been talked over so many times. Lets start from the top shall we? Carbon. Classic. Do not run on x86 and never will. As a developer, if I was forced to make a cpu switch just after moving to OS X i would walk away. Is 3% enough to justify anymore? Yes...it is...because I have carbon. If Apple makes commodity hardware, there will be no Apple as we know it. Drop the idea. Apple will NEVER do it. Especially as Palladium is being built into the CPU of some major venders.

Mat
 
Re: Re: More than the compiler

Originally posted by holmesf
snip
4. As for assembly or compiling for PC, why on earth would Apple spend its time and money on this? True, gcc supports compiling for PC already, but why would Apple want to even enable it?

One very good reason is to support developers that want to do cross-platform. I for one ! If I want to create an app that runs on OS X and Windows, my choices are very limited. Windows has the big market share. Help developers move over to OS X :)
 
Re: Re: Re: More than the compiler

Originally posted by Flynnstone
One very good reason is to support developers that want to do cross-platform. I for one ! If I want to create an app that runs on OS X and Windows, my choices are very limited.

Look, if you want to create a cross-platform application, you're not going to be using Carbon or Cocoa for it. PB/IB are Cocoa development tools first, and Cocoa/Java a distant second, and Carbon third, and everything else last. Unless you're hoping Apple will port all of Carbon over to Windows (we've been down that road before), a cross-platform PB/IB would be a huge waste of time.
 
Originally posted by jamilecrire
So 5-25% is an order of magntude faster?

Who said so? I didn't. Please read my post carefully. I said the build process is an order of magnitude faster, the code execution (in my personal tests) is 5-25% faster.


99.9% of coding is in the planning, implementation, debugging. If you waste that much time compiling just get a faster machine.

Hm, when I am debugging and implementing, I don't want to wait a minute for the next run, I want to wait a few seconds. Why pay thousands of €s for a machine that's 100% faster when I can buy software for less that's 10 times faster?
Sorry, I am sure you have never been involved in a large-scale development process. Build times of software can easily take hours, even days.

http://gcc.gnu.org/ml/gcc/2002-08/msg00768.html
http://gcc.gnu.org/ml/gcc/2002-08/msg00767.html

(Addition: Try to read the whole thread, it's interesting. BTW Stan Shebs is apple's guy for gcc.)
 
Re: Answers

Originally posted by mj_1903
1. Project Builder as of the December release (the latest) is quite unstable in general use. There were rumors that it was a beta, but it feels like a poorly done release. Really, there is little Apple can improve on. This tool has been around for over a decade and has been refined to perfection. As for support of other languages, thats a different question all together.

I totally agree on the stability rating ;( Sometimes I spend more time restarting PB, than actually working with it.

Aw, recently very many bugs appear on apple software, especially on foreign localized machines.

Anyway - the PB could use some class exploring tools, and pre looking method call checking, as the JBuilder can do. With so many new classes around all the time, it is really making integration of new apis easier -although real programmers don't of course need those toys. ;)

However I'm more in the Java programming buissnes anyway, and there are better tools for Java programming than PB.

I like theway how PB can integrate all kinds of languages in one Project.
I've just recently created my first 'apple script application' with it. oh well... ;)
 
Project Builder does indeed need quite a bit of work to be a "world class" or even mediocre development tool.

-- Compilation speed. Compared to CodeWarrior, PB's gcc frontend is ridiculously slow. Hit build, and go grab some coffee

-- User Interface. Programmers are users too, and I can't imagine a more convoluted user interface. With all of the panes, tabs, and hidden settings, it feels like it was designed by Q of Jame Bond fame (or perhaps Dr. Evil?)

-- Code generation. Not strictly a PB problem because it is just relying on gcc, but the code generated is notoriously poor

-- Overall speed. PB is simply painfully slow to do just about anything, even basic things like editing code, the UI lags behind noticably

-- Debugging. The built-in debugger is a fairly quirky frontend to gdb, which is functional, but circa early-1990's in terms of features

-- Integration with Interface Builder. This hasn't improved much since the NeXT days... you still have to do manual diffs, and the Carbon .nib support is poor at best compared to Cocoa

Compared to tools like VC++, Eclipse, or CodeWarrior (which hasn't exacly seen innovative development over the last few years), well, it simply doesn't measure up.

I use PB on a daily basis out of necessity, but I'm not exactly sanguine about it.
 
Windows apps

The only windows compatibility I see coming to Project Builder any time soon would be to re-introduce the "Yellow Box" for windows. Then you could develop your Cocoa app and run it on OS X and Windows.

Adding Win32 (or Win64) compatibility will decimate OS X native software development - why write to the Cocoa API's when Win32 code will run on OS X?

I used OpenStep for Windows back in the 90's and loved it; unfortunately, Project Builder's code editor hasn't evolved much since then in the usability department. See Eclipse (or .NET Studio from what people tell me) for what an IDE should act like today!
 
Originally posted by mj_1903
Carbon. Classic. Do not run on x86 and never will...

There are good reasons for Apple not to come out with a x86, but I disagree with this one. Apple moved all of its pre-carbon code and developers from the 680x0 processor to the PowerPC processor. To move to an x86 is very possible. And of course there is always emulation.

From my experience, switching between CPUs is much easier than switching between APIs. As long as the code does not have hand-rolled assembly or make assumptions of byte orders for integers, most code just requires a recompile.

To reduce the chance of cannibalization (e.g., buy a Dell and install MacOS X), Apple could add a "dongle" to its x86 hardware that MacOS would require but would not prevent Windows or Linux from running on it.

I don't think x86 will happen soon because Apple needs to close the speed gap with the current hardware line (which the 970 should do) and move more of its installed base to Mac OS 10. But once they do, as Steve Jobs said recently, "Apple will have options".

A ProjectBuilder that includes multiple CPU targets (PowerPC 32, PowerPC 64, x86, ...) makes sense for developers.
 
Re: Re: CodeWarrior

Originally posted by jamilecrire
So 5-25% is an order of magntude faster?

He was talking about compile times, which, pre-Jaguar, were one or two orders of magnitude faster in CW (Jaguar is at least 10x faster than 10.1 dev tools on compiling, but not quite as fast as CW in most cases). The dev tools team had some interesting graphs comparing gcc 2.95, gcc 3.1, and CW compile times for a few projects, and gcc3.1/CW were both absolute speed demons relative to gcc2.95, but gcc3.1 was still a bit slower than CW. In my experience, CW was significantly faster than gcc 3.1 even, but I jumped that ship for other reasons.


99.9% of coding is in the planning, implementation, debugging. If you waste that much time compiling just get a faster machine.

Actually, what irks me is that PB by default doesn't separate a "Development" build from a "Deployment" build; to switch from one to the other you are supposed to do a build clean and then rebuild in the other. Personally, I have three different build types (a just-below-release type for testing which performs asserts and such but otherwise acts like the production code) and switch between them constantly. A clean build takes 30-45 minutes on a 733MHz processor, so this is a major pain. Of course, I now (after much undocumented pain and torture) have stuff set up in PB to put different build types in different folders, but it's a kludgy system that occasionally breaks (I end up debugging the release executable for instance, or none of my break points register in gdb unless I re-set them after gdb is running ...).


I'm very impressed with Project Builder and Interface Builder. I come from the Visual Studio world where it's $800 just for the Professional Edition. Don't take a great free tool for granted. Actually this is what sold my company on doing cross platform development.

Absolutely. PB is in many ways superior to VC++ 6 on Windows (I have no reason to fork over another grand for ".net" ...), and even if it is only 90% of par with CodeWarrior, it is worth the money.


We use MFC for the front end in Windows, Qt for the front end in Linux (Work in progress) and ObjC for the front end in OS X. All our back end classes are standard C++. It requires more time and planning but implementation errors are fixed significantly easier. Not to mention testing is easier.

I'm straight and god I hate bush ;)

All of that could have come out of my own mouth and been just as true :) Except we just gave up on a GUI front end for Linux for now and use the console only ... Which of course shows how necessary the GUI is for our app ... :)
 
Re: Re: Re: CodeWarrior

Originally posted by jettredmont
He was talking about compile times, which, pre-Jaguar, were one or two orders of magnitude faster in CW (Jaguar is at least 10x faster than 10.1 dev tools on compiling, but not quite as fast as CW in most cases). The dev tools team had some interesting graphs comparing gcc 2.95, gcc 3.1, and CW compile times for a few projects, and gcc3.1/CW were both absolute speed demons relative to gcc2.95, but gcc3.1 was still a bit slower than CW. In my experience, CW was significantly faster than gcc 3.1 even, but I jumped that ship for other reasons.



Actually, what irks me is that PB by default doesn't separate a "Development" build from a "Deployment" build; to switch from one to the other you are supposed to do a build clean and then rebuild in the other. Personally, I have three different build types (a just-below-release type for testing which performs asserts and such but otherwise acts like the production code) and switch between them constantly. A clean build takes 30-45 minutes on a 733MHz processor, so this is a major pain. Of course, I now (after much undocumented pain and torture) have stuff set up in PB to put different build types in different folders, but it's a kludgy system that occasionally breaks (I end up debugging the release executable for instance, or none of my break points register in gdb unless I re-set them after gdb is running ...).



Absolutely. PB is in many ways superior to VC++ 6 on Windows (I have no reason to fork over another grand for ".net" ...), and even if it is only 90% of par with CodeWarrior, it is worth the money.



All of that could have come out of my own mouth and been just as true :) Except we just gave up on a GUI front end for Linux for now and use the console only ... Which of course shows how necessary the GUI is for our app ... :)

My bad on the compile times. He is right my projects aren't as large as those implemented by others I'm sure. However, I like PB. I guess it's because I'm used to working on it and I don't have Code Warrior. Now I'm tempted to try it out!!!! I guess since I have 4 computers on my desk (QS 733, Ultra 5 360, Dual 933 WinXP, AthlonXP 2000+ Linux) I don't notice when one computer is running something becuse I switch to the next.

I'll have to up a picture of my setup, it's crazy! My Ultra is under my 19" Monitor, and I have my 22" Cinema next to it. All the computers are behind the monitors or on the sides. Ahhhh.... the toys of being a software developer.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.