At the risk of being modded down, I think the moderation system is broken-- clearly moderators are fighting over the position, rather than the quality of the post.
Yes. And this new 64 bit chip will issue 8 instructions per a clock cycle, while intels chips (I'm not conversant on AMD's details) generally take multiple clock cycles per single instruction. While many of them have been optimized to execute in a single clock cycle, and multiple instruction paths can occur under the intel design, on average, the amount of WORK DONE (not instructions executed) on an intel design is much less than that on a PowerPC design.
Which means that all those people who think that a 2.8GHz pentium is necessarily faster than a 1GHz powerPC are ignorant or idiots.
Unfortunately, there are no benchmarks that have not been cooked by one faction or another.
Re:is this really a question?
on
The End Of Minix?
·
· Score: 5, Funny
There are 25 million mac users, at least.
I'm not aware of any hippie communes that got larger than 25 people total-- at some point the fighting over women destroys the idea.
On the other hand, there were some religious sects that were able to grow their communes much more, and were much bigger than 25 people.
But they were only able to do this because they used religion to eliminate sex, and its attending issues.
Since Mac users get far more sex than the average computer user, (according to Gartner and IDC) this is not the case for Apple's market.
The BSDs are free, both as in Beer and as in Speech.
What other definition of "Free" are you using?
Since the GPL is designed to destroy the software industry (it wants to be the wedge that makes it impossible for anyone to ever charge for software) I don't consider the GPL and the GNU project to be about freedom, in any shape or form.
The BSD license is far more free-- you're FREE to do anything you want with the code.
Anyone who thinks megaherts tells you how fast a processor is, deserves the assfucking they will get when they follow that belief in their computer purchasing.
If you really did take price/performance, you'd be running PowerPCs NOW.
ITs this fantasy that clockrate is performance (and the "benchmarks" that only measure clockrate) that allow you to say something so idiotic and not be laughed off the planet-- so many other people want to believe in the superiority of a processor hobbled by backwards compatibility going all the way to the 4004 that you are in good company.
All you need to do is make a chip oscillate fast, and Joe Customer will think it's the greatest thing since sliced bread.
Not to mention most of the geek wannabes who post on slashdot.
I think its time Apple start calling anything based on the power PC architecture twice its clock speed, and anyhting thats both powerPC and 64 bits at 4 times its clock speed. After all, the processor does twice as much as a 32 bit processor in a given clock.
So calling this new PowerPC that runs at "1.8GHz" a "7.4GHz PowerPC" is just as legitimate as Intel calling their pentiums 2.8GHz, etc. (Cause they don't really actually run at 2.8GHz. That's just one clock rate that exists at some point on the processor. Processor clocking is far more complicated than that.)
These published clock rates are a marketing fiction to begin with, so tis time for apple to release their 3GHz processors in January and that 7GHz 64 bit one the following january.
grade upwards of 100 assignments if you don't have to try and find 7 types of computers/compilers to grade.
What are they grading-- source code or an executable?
In either case the IDE is irrelevant-- you just supply source code as a text file and an executable that runs on the given platform.
I think grading executables is absurd, though. You should be able to show that it works on your platform of choice if required, but the grading should be grading the source code.
In my classes we were never graded on code, just given tests. If you could pass the tests without ever writing any software you could still pass the class. But given the piss poor coding opinions I've seen, I shudder to think of TAs marking students code down for having too many comments, or not fitting the politically correct placement of spaces in a parameter list, etc.
You misunderstood. My point is that there is nothing in teaching C++ that requires a specific IDE to be used-- it can be taught on any platform and letting the student use whatever tools they prefer.
GCC or some other IDE may not be superior-- I'm not saying they are. I'm saying that requiring students to use a given IDE is something that someone who is not actually teaching the language would likely do.
I repeat myself because people don't read very closely.
Please feel free to explain what Visual C++ has that is necessary for teaching graphics programming, that any other compiler or IDE for the platform can't.
Especially for a 400 level class
The only reason colleges provide such piss poor services is that students put up with it... and as a result they turn out students who can't think for themselves very well, and can't even take a position.
If you're teaching graphics programming, then the exercises can be done on any platform-- Linux, Mac Windows. The OS isn't even necessary to require- let alone the IDE.
Carbon only exists to support people who have existing Mac OS applications that they want to move to OS X.
If you're beginning, learn Objective C and use cocoa.
There is no reason to use carbon for new applications. You can access every API that exists in carbon from within cocoa apps and objective-c, but the reverse isn't true.
With Cocoa you get everything Carbon has, but with Carbon you don't get everyhting Cocoa has-- especially the superiority of Objective-C and the Appkit and Foundation frameworks.
Anything you really need to do, you can do in carbon, its just a lot harder.
There's no reason not to use Cocoa for Mac applications.
Yes, when you say something strongly (eg: not couched with lots of "I think" and "if its ok with you for me to think this way, my opinion would be.. but if its not ok, I retract what I said") and the moderator disagrees with you, and is your tpyical slashdot incompetant pseudo-geek idiot, they will mark you as flamebait simply because they disagree with what you said.
Moderation seems to often be more about whether the moderator agrees with you than in weeding out the actual flamers.
What the hell? I thought Ambrosia was a quality place but this is pretty silly:
but like an OO framework, you must design your object hierarchy well ahead of time.
You should check out XP-- Extreme Programming. Its an excellent methodology that works fine with OO development. Its quite trivial to refractor your code when your project changes direction.
I'd say spending time designing your object hierarchies before you start programming is an example of *bad* development process, not good, even though I used to do exactly that same thing.
There is also a rather serious learning curve for Cocoa,
True, though it is significantly less of a learning curve than you have to deal with for Carbon. Cocoa re-uses objects a lot, whereas every Carbon API has a whole new set of data structures it takes as parameters, etc.
The learning curve is much lower for Cocoa than for Carbon. (And consequently, development is much faster in cocoa as well.)
and if you decide to go with Cocoa over Carbon, you've essentially written off any xplat possibilities.
That's just silly, unless your idea of "xplat" is crossing between OS X and Mac OS. But OS 9 is dead and I don't think people are really writing apps to support it. As for going from OS X to windows or linux, you have FAR MORE xplat possibility with cocoa-- first off there's cocoa-java, but even if you use objective-c There is work on an open source cocoa called gnustep. I'm aware of no xplat carbon frameworks, let alone superior ones.
Most of the major applications for Mac OS X are written in Carbon, and will continue to be.
That's just crap. Most of the major applications written for OS X are written in Cocoa. The only carbon apps are ones that started on OS 9 and were ported.
IF you're porting an app from OS 9, sure, use carbon. But if you're starting from scratch, it would be stupid to not use cocoa.
What the hell? I thought Ambrosia was a quality place but this is pretty silly:
but like an OO framework, you must design your object hierarchy well ahead of time.
You should check out XP-- Extreme Programming. Its an excellent methodology that works fine with OO development. Its quite trivial to refractor your code when your project changes direction.
I'd say spending time designing your object hierarchies before you start programming is an example of *bad* development process, not good, even though I used to do exactly that same thing.
There is also a rather serious learning curve for Cocoa,
True, though it is significantly less of a learning curve than you have to deal with for Carbon. Cocoa re-uses objects a lot, whereas every Carbon API has a whole new set of data structures it takes as parameters, etc.
The learning curve is much lower for Cocoa than for Carbon. (And consequently, development is much faster in cocoa as well.)
and if you decide to go with Cocoa over Carbon, you've essentially written off any xplat possibilities.
That's just silly, unless your idea of "xplat" is crossing between OS X and Mac OS. But OS 9 is dead and I don't think people are really writing apps to support it. As for going from OS X to windows or linux, you have FAR MORE xplat possibility with cocoa-- first off there's cocoa-java, but even if you use objective-c There is work on an open source cocoa called gnustep. I'm aware of no xplat carbon frameworks, let alone superior ones.
Most of the major applications for Mac OS X are written in Carbon, and will continue to be.
That's just crap. Most of the major applications written for OS X are written in Cocoa. The only carbon apps are ones that started on OS 9 and were ported.
IF you're porting an app from OS 9, sure, use carbon. But if you're starting from scratch, it would be stupid to not use cocoa.
I'd rather be rich and not have the the respect of a poser such as yourself.
However, if you're working on a product to compete with mine, I can't help but agree that you should be using assembly for everything-- and to recommend that you create your own ui widgets while you're at it.
Cocoa puts you in the MVC pattern, meaning that you have rather good portability if you decide to go to a different view-- just subclass your controler and tie it to the new UI.
It seems to me that Interface Builder has supplanted the need for languages like RealBasic and Hypercard et al.
Interface builder and the appkit give you the quick and easy and powerful gui devleopment-- with more depth than realbasic, in the languages correct for professional development (Applescript, Obj-C, C, C++, Java).
Realbasic seems great for learning (and thus may be appropriate for the person who started this topic) but not for professional development.
If you need a quick app that can run on multiple platforms and are new to programming, then use RealBasic.
IF you need multi-platforms and are an experienced programmer, use Java.
IF you don't need multi-platform, use Objective-C.
If you're writing for the Mac, write in Objective-C, C++, or even REALbasic, but not Java. There's simply no good reason
This is just a bit of bigotry.
Java is an excellent language and it is very well supported under cocoa and on the Mac.
There is a good reason: cross platform applications.
While I like Objective-C over Java, those are the only two languages I'd recommend anyone write in-- get rid of RealBasic, C and C++ before you get rid of Java.
Its common for people to take a macho attitude and pooh-pooh java, but this is just as silly as those who think real programmers write for the command line and pooh-pooh the gui.
Java's future is assured, while objective-c's not. I prefer objective-C but telling someone there is no reason to use java is just bad advice.
C# is already dead. It would be stupid to write applications in it.
Nobody is going to support it because everyone knows that doing so puts them at the mercy of Microsoft, and microsoft has shown themselves to be both desirus of the entirety of the application market and also willing to undermine the ability of competitors to work on the platform. C# makes it really easy for them to do this.
Slashdot Mirror
This post has been moderated thusly:
Flamebait=2, Insightful=3, Interesting=2, Overrated=3, Total=10.
At the risk of being modded down, I think the moderation system is broken-- clearly moderators are fighting over the position, rather than the quality of the post.
Yes. And this new 64 bit chip will issue 8 instructions per a clock cycle, while intels chips (I'm not conversant on AMD's details) generally take multiple clock cycles per single instruction. While many of them have been optimized to execute in a single clock cycle, and multiple instruction paths can occur under the intel design, on average, the amount of WORK DONE (not instructions executed) on an intel design is much less than that on a PowerPC design.
Which means that all those people who think that a 2.8GHz pentium is necessarily faster than a 1GHz powerPC are ignorant or idiots.
Unfortunately, there are no benchmarks that have not been cooked by one faction or another.
There are 25 million mac users, at least.
I'm not aware of any hippie communes that got larger than 25 people total-- at some point the fighting over women destroys the idea.
On the other hand, there were some religious sects that were able to grow their communes much more, and were much bigger than 25 people.
But they were only able to do this because they used religion to eliminate sex, and its attending issues.
Since Mac users get far more sex than the average computer user, (according to Gartner and IDC) this is not the case for Apple's market.
The BSDs are free, both as in Beer and as in Speech.
What other definition of "Free" are you using?
Since the GPL is designed to destroy the software industry (it wants to be the wedge that makes it impossible for anyone to ever charge for software) I don't consider the GPL and the GNU project to be about freedom, in any shape or form.
The BSD license is far more free-- you're FREE to do anything you want with the code.
Anyone who thinks megaherts tells you how fast a processor is, deserves the assfucking they will get when they follow that belief in their computer purchasing.
If you really did take price/performance, you'd be running PowerPCs NOW.
ITs this fantasy that clockrate is performance (and the "benchmarks" that only measure clockrate) that allow you to say something so idiotic and not be laughed off the planet-- so many other people want to believe in the superiority of a processor hobbled by backwards compatibility going all the way to the 4004 that you are in good company.
All you need to do is make a chip oscillate fast, and Joe Customer will think it's the greatest thing since sliced bread.
Not to mention most of the geek wannabes who post on slashdot.
I think its time Apple start calling anything based on the power PC architecture twice its clock speed, and anyhting thats both powerPC and 64 bits at 4 times its clock speed. After all, the processor does twice as much as a 32 bit processor in a given clock.
So calling this new PowerPC that runs at "1.8GHz" a "7.4GHz PowerPC" is just as legitimate as Intel calling their pentiums 2.8GHz, etc. (Cause they don't really actually run at 2.8GHz. That's just one clock rate that exists at some point on the processor. Processor clocking is far more complicated than that.)
These published clock rates are a marketing fiction to begin with, so tis time for apple to release their 3GHz processors in January and that 7GHz 64 bit one the following january.
grade upwards of 100 assignments if you don't have to try and find 7 types of computers/compilers to grade.
What are they grading-- source code or an executable?
In either case the IDE is irrelevant-- you just supply source code as a text file and an executable that runs on the given platform.
I think grading executables is absurd, though. You should be able to show that it works on your platform of choice if required, but the grading should be grading the source code.
In my classes we were never graded on code, just given tests. If you could pass the tests without ever writing any software you could still pass the class. But given the piss poor coding opinions I've seen, I shudder to think of TAs marking students code down for having too many comments, or not fitting the politically correct placement of spaces in a parameter list, etc.
You misunderstood. My point is that there is nothing in teaching C++ that requires a specific IDE to be used-- it can be taught on any platform and letting the student use whatever tools they prefer.
GCC or some other IDE may not be superior-- I'm not saying they are. I'm saying that requiring students to use a given IDE is something that someone who is not actually teaching the language would likely do.
I repeat myself because people don't read very closely.
Gee, I pointed out an objective fact. No judgment is required-- it is well known that this is RMS's position.
Thus merely repeating RMS's position in public is "flamebait".
Interesting.
Please feel free to explain what Visual C++ has that is necessary for teaching graphics programming, that any other compiler or IDE for the platform can't.
Especially for a 400 level class
The only reason colleges provide such piss poor services is that students put up with it... and as a result they turn out students who can't think for themselves very well, and can't even take a position.
If you're teaching graphics programming, then the exercises can be done on any platform-- Linux, Mac Windows. The OS isn't even necessary to require- let alone the IDE.
Which makes him a model student for what colleges these days are trying to turn out.
I'm forced to conclude that you're just whining because you have to actually work for a living.
Carbon only exists to support people who have existing Mac OS applications that they want to move to OS X.
If you're beginning, learn Objective C and use cocoa.
There is no reason to use carbon for new applications. You can access every API that exists in carbon from within cocoa apps and objective-c, but the reverse isn't true.
With Cocoa you get everything Carbon has, but with Carbon you don't get everyhting Cocoa has-- especially the superiority of Objective-C and the Appkit and Foundation frameworks.
Anything you really need to do, you can do in carbon, its just a lot harder.
There's no reason not to use Cocoa for Mac applications.
I think you represent the average linux user.
Yes, when you say something strongly (eg: not couched with lots of "I think" and "if its ok with you for me to think this way, my opinion would be.. but if its not ok, I retract what I said") and the moderator disagrees with you, and is your tpyical slashdot incompetant pseudo-geek idiot, they will mark you as flamebait simply because they disagree with what you said.
Moderation seems to often be more about whether the moderator agrees with you than in weeding out the actual flamers.
What the hell? I thought Ambrosia was a quality place but this is pretty silly:
but like an OO framework, you must design your object hierarchy well ahead of time.
You should check out XP-- Extreme Programming. Its an excellent methodology that works fine with OO development. Its quite trivial to refractor your code when your project changes direction.
I'd say spending time designing your object hierarchies before you start programming is an example of *bad* development process, not good, even though I used to do exactly that same thing.
There is also a rather serious learning curve for Cocoa,
True, though it is significantly less of a learning curve than you have to deal with for Carbon. Cocoa re-uses objects a lot, whereas every Carbon API has a whole new set of data structures it takes as parameters, etc.
The learning curve is much lower for Cocoa than for Carbon. (And consequently, development is much faster in cocoa as well.)
and if you decide to go with Cocoa over Carbon, you've essentially written off any xplat possibilities.
That's just silly, unless your idea of "xplat" is crossing between OS X and Mac OS. But OS 9 is dead and I don't think people are really writing apps to support it. As for going from OS X to windows or linux, you have FAR MORE xplat possibility with cocoa-- first off there's cocoa-java, but even if you use objective-c There is work on an open source cocoa called gnustep. I'm aware of no xplat carbon frameworks, let alone superior ones.
Most of the major applications for Mac OS X are written in Carbon, and will continue to be.
That's just crap. Most of the major applications written for OS X are written in Cocoa. The only carbon apps are ones that started on OS 9 and were ported.
IF you're porting an app from OS 9, sure, use carbon. But if you're starting from scratch, it would be stupid to not use cocoa.
What the hell? I thought Ambrosia was a quality place but this is pretty silly:
but like an OO framework, you must design your object hierarchy well ahead of time.
You should check out XP-- Extreme Programming. Its an excellent methodology that works fine with OO development. Its quite trivial to refractor your code when your project changes direction.
I'd say spending time designing your object hierarchies before you start programming is an example of *bad* development process, not good, even though I used to do exactly that same thing.
There is also a rather serious learning curve for Cocoa,
True, though it is significantly less of a learning curve than you have to deal with for Carbon. Cocoa re-uses objects a lot, whereas every Carbon API has a whole new set of data structures it takes as parameters, etc.
The learning curve is much lower for Cocoa than for Carbon. (And consequently, development is much faster in cocoa as well.)
and if you decide to go with Cocoa over Carbon, you've essentially written off any xplat possibilities.
That's just silly, unless your idea of "xplat" is crossing between OS X and Mac OS. But OS 9 is dead and I don't think people are really writing apps to support it. As for going from OS X to windows or linux, you have FAR MORE xplat possibility with cocoa-- first off there's cocoa-java, but even if you use objective-c There is work on an open source cocoa called gnustep. I'm aware of no xplat carbon frameworks, let alone superior ones.
Most of the major applications for Mac OS X are written in Carbon, and will continue to be.
That's just crap. Most of the major applications written for OS X are written in Cocoa. The only carbon apps are ones that started on OS 9 and were ported.
IF you're porting an app from OS 9, sure, use carbon. But if you're starting from scratch, it would be stupid to not use cocoa.
Microsoft only has %40 market share. Linux has %10, and the various Mac OS versions have the remaining %50.
Get your facts straight!
PS- for the impaired, my point is to point out that the %95 number is just as fabricated as the numbers I gave.
Premature optimization is the root of all evil.
Real artists ship.
People prefer software that actually works.
I'd rather be rich and not have the the respect of a poser such as yourself.
However, if you're working on a product to compete with mine, I can't help but agree that you should be using assembly for everything-- and to recommend that you create your own ui widgets while you're at it.
Cocoa puts you in the MVC pattern, meaning that you have rather good portability if you decide to go to a different view-- just subclass your controler and tie it to the new UI.
Objective-C is portable because GCC is portable.
It seems to me that Interface Builder has supplanted the need for languages like RealBasic and Hypercard et al.
Interface builder and the appkit give you the quick and easy and powerful gui devleopment-- with more depth than realbasic, in the languages correct for professional development (Applescript, Obj-C, C, C++, Java).
Realbasic seems great for learning (and thus may be appropriate for the person who started this topic) but not for professional development.
If you need a quick app that can run on multiple platforms and are new to programming, then use RealBasic.
IF you need multi-platforms and are an experienced programmer, use Java.
IF you don't need multi-platform, use Objective-C.
If you're writing for the Mac, write in Objective-C, C++, or even REALbasic, but not Java. There's simply no good reason
This is just a bit of bigotry.
Java is an excellent language and it is very well supported under cocoa and on the Mac.
There is a good reason: cross platform applications.
While I like Objective-C over Java, those are the only two languages I'd recommend anyone write in-- get rid of RealBasic, C and C++ before you get rid of Java.
Its common for people to take a macho attitude and pooh-pooh java, but this is just as silly as those who think real programmers write for the command line and pooh-pooh the gui.
Java's future is assured, while objective-c's not. I prefer objective-C but telling someone there is no reason to use java is just bad advice.
C# is already dead. It would be stupid to write applications in it.
Nobody is going to support it because everyone knows that doing so puts them at the mercy of Microsoft, and microsoft has shown themselves to be both desirus of the entirety of the application market and also willing to undermine the ability of competitors to work on the platform. C# makes it really easy for them to do this.
COBOL has more of a future.
You can build tools in Objective-C, and GCC supports objective-C so objective-c itself should be pretty portable.
Its just the cocoa frameworks that aren't. (Though there are people creating an open source version of it.)