WWDC: 64-Bit ProjectBuilder?

[MacRumors]

Mac Edition's Naked Mole Rat Report (http://macedition.com/nmr/nmr_20030528.php) indicates that WWDC may bring a dramatically improved 64-bit Project Builder -- allowing developers to migrate to the PowerPC 970 based machines.

This rumor provides further hints at overt PowerPC 970 discussion at WWDC. The timing of hardware introductions, however, remains up for debate.

[ibookin']

If this is true it's yet another piece of the 970 puzzle.

Sounds good to me. :D

[syco]

Excellent. I'd love for some really cool 970 apps to be available as soon as the 970s are released.

[DrGruv1]

Anything new that helps the 970 along is great!

[Zeke]

This is looking promising. Hopefully all these stories aren't coming from MacRumors and thus have separate sources...

[neilt]

I think everyone will agree that some sort of 64bit architecture will be discussed at WWDC. I don't think that this means we will really be seeing one at that time. Although, I am putting off a major purchase in the hopes that it may be true.

[MacManiac1224]

I think this just means that there is even more of a chance that the 970 will make it's debut with Panther at WWDC

[Nermal]

To be honest, I thought we expected this anyway! I certainly did :)

Edit: OK, I guess we're talking about the When, not the What.

[Remus]

I am still looking at the 970 hardware being announced in mid August with a September ship date.

Of course I have no inside info and hope that they come sooner....

[BlueJekyll]

Just wanted to point out that it is the compiler we have to worry about. It doesn't matter at all if Project Builder is 64bit enabled, although maybe it will need to have some settings for building different binary types, i.e. Both 32 and 64, or one or the other.

So just worry about gcc, Project Builder.

[leo]

Originally posted by BlueJekyll
Just wanted to point out that it is the compiler we have to worry about. It doesn't matter at all if Project Builder is 64bit enabled, although maybe it will need to have some settings for building different binary types, i.e. Both 32 and 64, or one or the other.


Yes. It is not a great achievement to make the IDE 970-ready.
And gcc 3.3 is already enabled to produce PowerPC 970-optimized code. (This was mentioned before on MacRumors.)

http://gcc.gnu.org/cgi-bin/cvsweb.cgi/~checkout~/gcc/gcc/config/rs6000/power4.md?rev=1.4.4.4&content-type=text/plain

[Remus]

Originally posted by BlueJekyll
Just wanted to point out that it is the compiler we have to worry about. It doesn't matter at all if Project Builder is 64bit enabled, although maybe it will need to have some settings for building different binary types, i.e. Both 32 and 64, or one or the other.

So just worry about gcc, Project Builder.

I thought I heard that GCC was being worked on running on a 970 chip.

Of course if I herd I would be a bunch of cows... :p

[maxvamp]

I have to wonder what more there is to this story, if indeed it turns out to true.

I know that Metrowerks is a Motorola company, and Project Builder is on it's way on replacing CodeWarrior, a very expensive piece of software ( Much like the way IE killed Netscape ).

So I guess the real questions are...at the risk of turning this into a pure development thread....

1) What is Project builder lacking, or what is CodeWarrior doing poorly that can be improved upon in a new 970 version of Project Builder.

2) What features would actually take several sessions at the conference?

3) Will this new version allow writing in C++? Maybe Assembly? Howabout HTML ?

4) Will we be able to write Win32/X86 code on it too, making OSX more of a Developer's platform? ( Highly doubted )

I suspect that GCC will already have compiler enhancements for this chip, so I guess this is a somewhat moot point.

Feel free to speculate / flame / etc.


Max

[holmesf]

Originally posted by maxvamp
I have to wonder what more there is to this story, if indeed it turns out to true.

I know that Metrowerks is a Motorola company, and Project Builder is on it's way on replacing CodeWarrior, a very expensive piece of software ( Much like the way IE killed Netscape ).

So I guess the real questions are...at the risk of turning this into a pure development thread....

1) What is Project builder lacking, or what is CodeWarrior doing poorly that can be improved upon in a new 970 version of Project Builder.

2) What features would actually take several sessions at the conference?

3) Will this new version allow writing in C++? Maybe Assembly? Howabout HTML ?

4) Will we be able to write Win32/X86 code on it too, making OSX more of a Developer's platform? ( Highly doubted )

I suspect that GCC will already have compiler enhancements for this chip, so I guess this is a somewhat moot point.

Feel free to speculate / flame / etc.


Max

I'll be glad to see code-warrior go away. I personally don't think Project builder lacks anything. At least anything I need.

Perhaps they could make a project builder starting point for iTunes plugins, since right now they have to be programmed with a poorly done SDK.

3. You can already code in C++, or objective-C++ for that matter. Do Cocoa classes exist in C++? Well no, but there's a good reason. Objective-C is just a better language for encapsulation purposes than C++. Cocoa has some of its classes written in Java, but they're quite bad. I can imagine the same thing happening for C++...yuck.

Project builder supports some web programming things to do with PERL, MySQL, ect, but I'm not well versed on them as I'm not a web programmer. HTML is already supported in the way that any text editor can pump out HTML since its not a compiled language.

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?

[maxvamp]

Item number four was the only thing I could think of that CodeWarrior does, that PB does not. I actually have no interest in seeing this feature either.

Visual Studio.net works rather well, and serves the windows folk for their needs.

Maybe we need better process and thread tracking tools?

Max

[mj_1903]

I have to wonder what more there is to this story, if indeed it turns out to true.

I know that Metrowerks is a Motorola company, and Project Builder is on it's way on replacing CodeWarrior, a very expensive piece of software ( Much like the way IE killed Netscape ).

So I guess the real questions are...at the risk of turning this into a pure development thread....

1) What is Project builder lacking, or what is CodeWarrior doing poorly that can be improved upon in a new 970 version of Project Builder.

2) What features would actually take several sessions at the conference?

3) Will this new version allow writing in C++? Maybe Assembly? Howabout HTML ?

4) Will we be able to write Win32/X86 code on it too, making OSX more of a Developer's platform? ( Highly doubted )

I suspect that GCC will already have compiler enhancements for this chip, so I guess this is a somewhat moot point.

Feel free to speculate / flame / etc.


Max

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.

2. Features like how to write optimized 64bit assembly would take quite a while. There are even minor things that could chance in the way Objective-C works that Apple could go over, and heaven forbid Apple may make Interface Builder easier to use to add things like Preference Panels (aka NSToolbar) and other minor things. There is many things they could discuss, but nothing sticks out like a sore thumb to change, replace or add.

3. As stated before, PB supports C++. Here is a short list of languages that it supports right now.

- C
- C++
- Objective-C
- Objective-C++
- Assembly (PPC only I assume)
- Java (many variants including swing)
- JSP
- HTML

Now, thats a small list. Many people could add to it, but thats all I have delved into or witnessed. As to the previous poster, writing Objective-C++ is great when hooking into existing C++ code and I assume that somewhere in Mac OS X there is C++ code handling the Cocoa classes. I shall have to ask some people about that though so don't hold me to it.

4. There is no reason to write Win32/X86 to start with, but what type of code are you going to deal with? We have Microsoft's gunk (VC++, VB, add .Net to them, C#, J#, et al) or any of the other IDE's? I can write C++ code on Mac OS X in Project Builder, place it on a pc, compile it with minor changes and it will run fine. Apple gives us the dev tools for free for a reason...so we write Mac OS X applications.

As for SDK hooks in Project Builder...well...we may see it but I highly doubt it.

Mat

[reyesmac]

Once again it looks like Apple will come out with a machine whos true potential wont be seen until much later when they update the OS and companies update thier apps. News like this pretty much means that applications wont run as fast as they can until they are updated, like what happened with altivec. I am sure the REV 2 Powermacs will be worth every penny since they should have 10.3 on them but the people who buy the Powermacs now will have to buy 10.3 just months after they bought a new system. I hope it gives unoptomized apps plenty of a speed boost to satisfy the early adopters and justify the price. Remember how the early G4's were faster than G3's when they were running altivec code but around the same speed when they werent? The 970 should be much faster than current G4's without updating any code...right?

[leo]

Originally posted by holmesf
I'll be glad to see code-warrior go away.

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]

[mactastic]

Originally posted by reyesmac
Once again it looks like Apple will come out with a machine whos true potential wont be seen until much later when they update the OS and companies update thier apps. News like this pretty much means that applications wont run as fast as they can until they are updated, like what happened with altivec. I am sure the REV 2 Powermacs will be worth every penny since they should have 10.3 on them but the people who buy the Powermacs now will have to buy 10.3 just months after they bought a new system.

Apple usually gives people who bought right before an update like that a major deal if not a free upgrade right? Its all of us who paid for jag'wire' who will have to pay the full $129 again.

[freundt]

kinda off topic, and I'm sure redundant, but look at the blurb from the apple site regarding WWDC:

Get an in-depth look at the future of the Mac platform and a preview release of the next major version of Mac OS X, codenamed “Panther,” at the Worldwide Developers Conference 2003, Jun 23-27 in San Francisco. Register by Friday, May 23, to save. [May 20]

bold text is the part I'm talking about...

Future of the Mac Platform?

umm.. would they be talking about 64bit 970 processors?

Anyways,
feeding my measly fuel to the fire....

_f

[zigi]

I'd like to see a kind of IntiliSense® included for the pure Cocoa classes. Coupled with a nice project indexer, which would allow auto-completion of your own code. VC++ is very good for this and makes writing/modifying complex code a lot easier. See any of the Quake II/III source for how much of an aid it can be.

[whooleytoo]

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.


Yup, I'd certainly have to agree.

PB is unquestionably very powerful, and free; but IMO CW is immeasurably faster at compilation; plus better for prototyping. I can't understand why anyone would want CW to disappear!?!

Mike.

[praetorian_x]

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.


Have you have ever used emacs, eclipse or visual studio? There are all *sorts* of things that PB could improve upon. Smart code indenting. Keyboard macros. Easy extensions. Code completion. Autogeneration/maintenence of header files. Better CVS integration (see eclipse). A non-hack integration with Interface Builder (Diff!?! I have to run a friggen DIFF every time I change the NIB? What the hell is this crap?)

Originally posted by mj_1903

3. As stated before, PB supports C++. Here is a short list of languages that it supports right now.

- C
- C++
- Objective-C
- Objective-C++
- Assembly (PPC only I assume)
- Java (many variants including swing)
- JSP
- HTML



Personally, I'd rather develop in notepad for anything other than Obj-C. At least its fast. PB's text editing abilities are a joke.

Personally, as you can probably guess, I hope they make some massive improvements. My dream? PB with tight IB integration (no diffing crap), and embedded emacs with code completion hacked on top of it for ObjC code.

Mmmmmmm. emacs. _drools_

Cheers,
prat

[jerk]

Originally posted by reyesmac
Once again it looks like Apple will come out with a machine whos true potential wont be seen until much later when they update the OS and companies update thier apps. News like this pretty much means that applications wont run as fast as they can until they are updated, like what happened with altivec. I am sure the REV 2 Powermacs will be worth every penny since they should have 10.3 on them but the people who buy the Powermacs now will have to buy 10.3 just months after they bought a new system. I hope it gives unoptomized apps plenty of a speed boost to satisfy the early adopters and justify the price. Remember how the early G4's were faster than G3's when they were running altivec code but around the same speed when they werent? The 970 should be much faster than current G4's without updating any code...right?

Yes, it should!

It has been said a thousand times before, and obviously has to be said again:
Please understand that the processor going 64 bit is in most cases completely unrelated to speed improvements. For some apps, using 64 bit variables were only 32 bits are needed will be a performance loss, and they will hopefully not do that. For some very special apps, the possibility of having an address space larger than 32 bits (4GBytes) may result in a performance improvement.

The 970 is supposed be faster in itself than a 745x, also in 32 bit mode.

People confuse this shift with the Intel 16->32 bit shift which also made several other changes.

Please also understand that there is no change in the powerpc spec for going 64 bit - the powerpc (and power) architecture has been prepared for this all the time, only that the few extra things that needs to be done for having is 64 bit ppc is optional and wasn't implemented in the older ppcs.

[mohaukachi]

Originally posted by maxvamp
So I guess the real questions are...at the risk of turning this into a pure development thread....

AHHH you jinxed it! now look at this mess. back to the core issue . . . this dosent say "the 970s will be at WWDC" it dosent say they wont either tho. i remain meditative.

k

[jettredmont]

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.

[eric_n_dfw]

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)

[jamilecrire]

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 ;)

[Jeff Harrell]

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.

[seamuskrat]

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.

[JoeRadar]

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.

[benjaminpg]

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.

[eric_n_dfw]

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.

[mj_1903]

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

[Flynnstone]

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 :)

[Jeff Harrell]

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.

[leo]

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.)

[visor]

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... ;)

[moki]

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.

[dhaveconfig]

Originally posted by leo
http://gcc.gnu.org/ml/gcc/2002-08/msg00768.html
http://gcc.gnu.org/ml/gcc/2002-08/msg00767.html



nice. thanks for that link.

I have to say that I'm not so impressed with PB stability lately either. I would have been shocked if I didn't get an updated version at WWDC....

[eric_n_dfw]

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!

[DeusOmnis]

I hope PB has better text-editing abilities, right now there are a few key things missing for me.

[JoeRadar]

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.

[jettredmont]

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 ... :)

[jamilecrire]

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.