Xcode 4

[Michael_google gmail_Gersten]

I am also in the "PPC is dead, long live the PPC!" crowd.

Frankly, I don't need to upgrade past my G4. 1 point 21, err, 42
jigahurts of power.

No, seriously, people, stop, take a deep breath, and stop chasing the
clock-core count.

What do you have on a typical system choice?

i386 -- which includes 386 or better
x86_64 -- which is the latest chipset in 64 bit mode

And PPC: generally compiles to smaller code than the 386 compatible
code does. Better register usage / allocation than the 386 compatible
code. (Remember, you only need more than 3 registers if you are doing
common sub expression elimination, and no compiler other than
expensive optimizing compilers do this. Or so claimed Intel back when
the 286 was still around and the 386 was in development.)

And don't forget what optimizers learned: The intel instruction set
stinks for optimization. SuperOptimizer was the first expose of that
that I remember.

So what do you have?

Assume _64: Suddenly you're doubling your memory footprint by default.
Assume late model cpu with a better register set: Good, but as far as
I know, not default. Does the system even support "I need at least a
level N x86 family"? (I think the current family is level 6, but
please don't quote me.)

===

What is the power of a G4 system like? Really: It's pretty darn GOOD.

Why do some programs run so slowly? Bad programming?

Maybe it's because I grew up programming on 1.77 Megahertz machines.
Yea, 1000 times slower. Not 1 GB, not even 1 MB, but fractions of that
-- 48 KB. Many thousands of times less memory.

(Don't even ask about the disk space :-).

Think I'm going back too far? OK. Look at 68010 systems. That's at
least in the same ballpark, right? Ok, how about a 68040 based,
pizza-box sized machine with 8-32 MB depending on configuration?
Compare that to a 8 to 32 GB machine running 1,000 times faster: Do
your programs actually run 1,000 times faster?

G4 systems, not to mention G5 (multiple CPU, don't know about multiple
core) desktops have plenty of power. They are not old, worn, ready to
discard.

These systems probably qualify for the "4 out of 5 computers sold are
still on the desktop today" (apologies to Toyota).

Is it current? No.
Do they still exist out there, and still get used? Yes.

People still port various linux flavors to 386 boxes. No one is saying
throw the old away.

Did it make sense when OS upgrades were easy to do to say "MacPorts
will only support the recent OS's"? Yes.

When upgrading an OS means throwing away a perfectly functional
hardware box? No.

What can we expect from Apple in the future? Well, lets look at the past:
1. EOF is for your business! No, actually, it's now dead.
2. Web Objects is the future of web developement! Look at Direct to
Web and Direct to Java Client! -- now, both dead.
3. The OS is flexible enough to work with different hardware. -- Oh,
we're tossing support for older hardware.

I grew up learning -- in school, in early work force, etc., -- that
business's tended to look at 30 year planning. I can understand
"Upgrade the software" faster than that. But "Throw out the whole
thing and start over" every 5? When computers have effective lifespans
of 10-15 years? (Seriously, only the disk drive fails faster, and
that's normally a replaceable.)

Will I toss my Apple stuff? Nope.
Will I ever recommend apple to others? ... Well, ...

The OS is nicer. Compared to Microsoft Windows, much nicer.

The user interface/Finder? meeh, a lot of it seems to be "Look, we're
different". Just because.

For a business? Used to be yes, now, not so sure.

Bottom line: Do you want to replace your hardware every 5 years, even
though it works just fine, because the company wants to sell you a new
box?

** PLEASE **, keep support as long as practical for both 10.5.8 PPC
and the current intel-family.

Right now, that means not using xcode 4. Maybe if lion requires xcode
4, then ... ?

Frankly, I'm upset at Apple. They are consistently sending the
message, "Do not depend on us or our products for long term
solutions".

Alright, /soapbox.