Now, I hope, people will start to understand why Sun and Intel are focussing so hard on performance-per-watt, and not just performance.
What's surprising is how long it took for power consumption of computers to be an issue. Back in 1999, no one cared about high power consumption. It wasn't until you started needing 500W power supplies in desktop PCs that people noticed, but the trend was clearly there. Even today, you still see people who want quad core processors and high-end video cards in ultra-thin notebooks that have 8 hours of battery life. No one is willing to compromise performance at all, even though those quad cores will only be running Firefox and Word.
Sure, it will take out a good chunk of the United States with it, but it will have an effect on global climate for hundreds of years afterward. The magma chamber beneath Yellowstone is *huge*; we're talking something thousands of times more powerful than Mount St. Helens.
And then of course there's the theory that the Earth's magnetic field will be almost nonexistent during the expected magnetic pole reversal coming shortly (starting within ~300 years). During the few thousand year transition, we're going to get hit hard by radiation anyway, so global warming may be irrelevant. And at least some of the CO2 will be swept away by solar wind.
True, but I know at least with the Core 2 Duo Intel not only focused on improved performance, but also lower power consumption and heat generation. I was starting to get scared of Intel chips until that point, wondering if purchasing one might be akin to laying a lump of thermite on my floor, but they made a step in the right direction. I hope that they keep moving forward with cooler, less power-hungry chips.
It's still pretty scary, though. Sure, Core 2 Duo was focused on lower power consumption, but pick any Core 2 Duo notebook and do something that involves heavy computation on both CPUs and listen to the fans crank up. Feels like CPU makers are still walking a fine line between fast and actually usable in the kind of computers people want.
Personally, I'd like to see notebook makers focus on getting the kind of battery life you see in the Nintendo DS (but using a larger battery, of course). Even if speeds are knocked in half, that's okay.
just keep computers longer and not toss them every 2 years. My HP Kayak Station ca. 1999 works just fine for word processing and 'net surfing. Which is all fully half of users probably need.
People keep TVs for 10 years, and I don't think the average person who buys a desktop or notebook is thinking of it as just a two year purchase. Now that's the "average person" of course. It's the techies who want constant upgrades and the latest and greatest. I saw saw someone in a Mac forum recently who claimed to buy the latest high-end Mac notebook as soon as it was released, then he'd sell his 9 month "old" one on ebay. Ugh.
Mac's don't enjoy a huge portion of the market share when looking at the overall picture, but when you look at some key professional markets -- music, video, and web design and programming, Mac's are actually pretty popular.
And also note that the the Mac marketshare is on the rise. For notebooks, especially, it's becoming significant. Any time I'm in a local coffeeshop or other place where there are people using notebook computers, 30-50% of them are Macs (typically iBooks and non-pro MacBooks). Five years ago this was unheard of.
And stop with the Rhode Island comparisons already. According to this page, the area of the UK is "43,000 sq. km. (93,000 sq. mi.); slightly smaller than Oregon." Oregon is the 9th largest state out of the 50.
Re:Is LISP really the most productive programming
on
Ten Geek Business Myths
·
· Score: 0, Offtopic
I like LISP (Scheme actually, don't know full LISP yet), but is it really so good? I even borrowed Paul Grahams book from the library recently, but only flipped through it. I simply have my doubts about the syntax: is it really OK for productivity? It looks kind of ugly and verbose.
Syntax is not the reason to avoid Lisp.
The biggest reason to think twice about using Lisp is library support. Do stuff in Python or Ruby (or even Perl) that uses regular expressions, ftp and email, date conversions, reading from zipped files, Unicode, MD5 checksums, MIME handling, and so on. Then do the same in Lisp using an out-of-the-box implementation that runs on all platforms. Just try it yourself.
Ruby is a perfect language to learn programming in. It has an excellent command line mode, and the syntax is easier to learn than most languages. As easy as BASIC, yet relevant for use today, and much more powerful.
I disagree. Ruby is good, don't get me wrong, but it's still not nearly as simple to pick up as BASIC and, more importantly, you can't just sit down with Ruby and start putting pixels up on the screen. Here's how I learned to do graphics on an Atari 800:
GRAPHICS 7
Now I'm looking at bitmapped screen with a few lines of text at the bottom, so I can still type commands.
COLOR 1:PLOT 10,10
Now I have a pixel on the screen. No page flipping. No waiting for vsync. No buffer flushing. No external libraries.
DRAWTO 50,50
Now I have a line.
Lots of harder problems are tons simpler in Ruby, but not stuff like this.
'If you get too excited about what is supposed to be an incredibly amazing product you simply won't buy a new Apple this year.'
What a strange comment. Are there features of Leopard that need special hardware support, features that prevent Leopard from showing it's true potential on all Macs except 2007 models? I seriously doubt it. So buy a Mac whenever you want, then upgrade the OS when the next version is available. Sure, it will cost you $129, but that's little compared to the cost of a new Mac notebook (plus AppleCare, which is a requirement these days).
Your point is well taken, however, one correction is in order: Battle Zone, an ancient Atari 3D FPS using wire-frame objects, was written in Forth.
What's your source for this? At one time or another I've heard people say that various classic video games were programming in Forth (Pac-Man, Defender, etc.)., but so far none of these rumors have been true. To the best of my knowledge, Battle Zone was programmed in assembly language.
One notable game actually written in Forth, BTW, is Starflight for the IBM PC (released by Electronic Arts in 1986).
Although when the IBM PC came out, it sure did look sad--visually--next to the displays of the Atari 800. But remember, that was the point. IBM wanted a serious business machine, not a game playing, recipe-filing computer.
Okay, I posted before reading the article. Can you tell:)
I think the fault is more with the submitter of the story than the author's presentation. The author just gives an overview of how stack computers work and their history. The submitter apparently never knew about stack computers and is all excited about them as a possible future of computing. The presentation is simple a history, mostly about stuff that's 20+ years old. So, yes, while stack processors have been commercially available and they've been used in commercial embedded systems work, they've failed to get outside that realm.
(As an aside, I'd say 99% of desktop programmers have no clue about all the stuff that's gone on in the embedded systems world, so it isn't surprising that old stuff seems new.)
Normally this kind of stuff doesn't bug me, but this is like an article in 2006 proclaiming the benefits of object-oriented programming. Doesn't anyone know their computing history?
There were stack computers in the 1960s and 1970s. There was a resurgence of interest in the 1980s--primarily because of Forth's popularity in embedded systems--resulting in a slew of stack-based "Forth engines." Forth creator Chuck Moore has been working on a series of custom Forth CPUs for 20+ years now. His latest version has 24 cores on one chip (and was entirely designed by one person and uses MILLIWATTS of power).
Stack processors and languages have one big advantage: they minimize the overall complexity of a system. The tradeoff is that they often push some of that complexity onto the programmer. That's why Forth tends to shine for small, controlled systems (like a fuel injector or telescope controller or fire alarm), but you don't see people writing 3D video games or web browsers in Forth.
Apple rushed out new systems based on an entirely new processor family (for them) and with much higher power and cooling requirements than anything they've dealt with in the past. Most of these problems would have been found with an extended testing period, but Apple wanted to get them out the door.
The two most worrisome problems are:
1. Heat. These new Macs just aren't as convenient to use as old iBooks, because you can't just slap them down anywhere. Ditto for just about any recent Windows notebook. 2. Shutdowns. This completely flies in the face of OS X being more reliable than Windows.
But the bottom line is that most video games are based around a try/die/repeat cycle. Furthermore, most video games are based around a *frustrating* try/die/repeat cycle. They're the kind of thing that a kid with endless free time can excel at, but someone for with a busier schedule they get old quick. There are exceptions, yes, but the vast majority of the big hits are like this. So most games are told like toys to an audience that wants toys.
The big win of open source is that many people can work on the same code, that work gets done faster as a result, that the code is more reliable overall. But for this to work outside of the usual suspects (Linux, Perl, Python, Apache), the architecture needs to be clean and dead simple.
All the time, working on proprietary code for a living, I see people making bad assumptions about how code works--even though all the original developers are right there in nearby offices--and there are often big whiteboard explanation sessions about little nuances of various libraries and low-level choices. A large percentage of the time these sessions end with the person thinking "Wow, I'm glad I didn't jump in and make that change without asking first."
This is exactly the same with almost any open source project of more than trivial size. The only way to combat it is to keep things as clean and blindingly simple as you can. Write as much in Python or Ruby as possible. Don't over-architect things (that is, don't make things pointlessly abstract). Ruthlessly trim features. Stay away from projects started by people with no engineering experience.
It was overpriced and underpowered. It had the IBM name, but at the time it was so completely blah compared to home computers of the time. But then again the author may be thinking of the PC in general, and not the system that started it all.
On Apache vs. Linux: Remember, Linux was just a rewrite of UNIX. Nothing amazing there.
But do we really have a need for 64 bit? Tell me what apps do you know of that are successfully using 64 bit? That is, your application runs much quicker/better in 64 bit rather than 32?
Cost of memory is the big issue. You can buy a good dual-core PC for what it would cost to put 16GB into it.
Shouldn't it be something like "Debit cards to replace money in Monopoly"? Just because the card is Visa doesn't make it anywhere near the first time brand names have been used in board games. The Barbie board game came out in the 1960s, for example. Ditto for all the games about movies, TV shows, and licensed properties.
Suppose you bought a book about Ruby and it had a 140 page introductory chapter that started with the history of FORTRAN and Algol and worked all the way up through Perl and Python and Ruby. Suppose it went off on tangents about things that Niklaus Wirth and John Backus did. Suppose it talked about various programs of historical importance (like the first compiler and PLANNER and so on). Suppose it talked about programming paradigms which don't relate to Ruby, like the development of Prolog.
Now all of this is interesting, but it's out of place in a book about Ruby.
The mac and OS X are merely a sum of the history of Apple. You know, before they had the Mac Mini and your beloved iPod, they actually did some interesting things with a few spare parts and couple of off-the-shelf chips.
Of course. But this is a book about OS X. It isn't a book about operating system history or Apple history. The author took a subject that could have easily been covered in 5 pages and expanded it to 140+.
Slashdot Mirror
You have teenagers and college students addicted to cellphones and IM.
Now, I hope, people will start to understand why Sun and Intel are focussing so hard on performance-per-watt, and not just performance.
What's surprising is how long it took for power consumption of computers to be an issue. Back in 1999, no one cared about high power consumption. It wasn't until you started needing 500W power supplies in desktop PCs that people noticed, but the trend was clearly there. Even today, you still see people who want quad core processors and high-end video cards in ultra-thin notebooks that have 8 hours of battery life. No one is willing to compromise performance at all, even though those quad cores will only be running Firefox and Word.
Sure, it will take out a good chunk of the United States with it, but it will have an effect on global climate for hundreds of years afterward. The magma chamber beneath Yellowstone is *huge*; we're talking something thousands of times more powerful than Mount St. Helens.
And then of course there's the theory that the Earth's magnetic field will be almost nonexistent during the expected magnetic pole reversal coming shortly (starting within ~300 years). During the few thousand year transition, we're going to get hit hard by radiation anyway, so global warming may be irrelevant. And at least some of the CO2 will be swept away by solar wind.
True, but I know at least with the Core 2 Duo Intel not only focused on improved performance, but also lower power consumption and heat generation. I was starting to get scared of Intel chips until that point, wondering if purchasing one might be akin to laying a lump of thermite on my floor, but they made a step in the right direction. I hope that they keep moving forward with cooler, less power-hungry chips.
It's still pretty scary, though. Sure, Core 2 Duo was focused on lower power consumption, but pick any Core 2 Duo notebook and do something that involves heavy computation on both CPUs and listen to the fans crank up. Feels like CPU makers are still walking a fine line between fast and actually usable in the kind of computers people want.
Personally, I'd like to see notebook makers focus on getting the kind of battery life you see in the Nintendo DS (but using a larger battery, of course). Even if speeds are knocked in half, that's okay.
just keep computers longer and not toss them every 2 years. My HP Kayak Station ca. 1999 works just fine for word processing and 'net surfing. Which is all fully half of users probably need.
People keep TVs for 10 years, and I don't think the average person who buys a desktop or notebook is thinking of it as just a two year purchase. Now that's the "average person" of course. It's the techies who want constant upgrades and the latest and greatest. I saw saw someone in a Mac forum recently who claimed to buy the latest high-end Mac notebook as soon as it was released, then he'd sell his 9 month "old" one on ebay. Ugh.
Mac's don't enjoy a huge portion of the market share when looking at the overall picture, but when you look at some key professional markets -- music, video, and web design and programming, Mac's are actually pretty popular.
And also note that the the Mac marketshare is on the rise. For notebooks, especially, it's becoming significant. Any time I'm in a local coffeeshop or other place where there are people using notebook computers, 30-50% of them are Macs (typically iBooks and non-pro MacBooks). Five years ago this was unheard of.
And stop with the Rhode Island comparisons already. According to this page, the area of the UK is "43,000 sq. km. (93,000 sq. mi.); slightly smaller than Oregon." Oregon is the 9th largest state out of the 50.
I like LISP (Scheme actually, don't know full LISP yet), but is it really so good? I even borrowed Paul Grahams book from the library recently, but only flipped through it. I simply have my doubts about the syntax: is it really OK for productivity? It looks kind of ugly and verbose.
Syntax is not the reason to avoid Lisp.
The biggest reason to think twice about using Lisp is library support. Do stuff in Python or Ruby (or even Perl) that uses regular expressions, ftp and email, date conversions, reading from zipped files, Unicode, MD5 checksums, MIME handling, and so on. Then do the same in Lisp using an out-of-the-box implementation that runs on all platforms. Just try it yourself.
Ruby is a perfect language to learn programming in. It has an excellent command line mode, and the syntax is easier to learn than most languages. As easy as BASIC, yet relevant for use today, and much more powerful.
I disagree. Ruby is good, don't get me wrong, but it's still not nearly as simple to pick up as BASIC and, more importantly, you can't just sit down with Ruby and start putting pixels up on the screen. Here's how I learned to do graphics on an Atari 800:
GRAPHICS 7
Now I'm looking at bitmapped screen with a few lines of text at the bottom, so I can still type commands.
COLOR 1:PLOT 10,10
Now I have a pixel on the screen. No page flipping. No waiting for vsync. No buffer flushing. No external libraries.
DRAWTO 50,50
Now I have a line.
Lots of harder problems are tons simpler in Ruby, but not stuff like this.
'If you get too excited about what is supposed to be an incredibly amazing product you simply won't buy a new Apple this year.'
What a strange comment. Are there features of Leopard that need special hardware support, features that prevent Leopard from showing it's true potential on all Macs except 2007 models? I seriously doubt it. So buy a Mac whenever you want, then upgrade the OS when the next version is available. Sure, it will cost you $129, but that's little compared to the cost of a new Mac notebook (plus AppleCare, which is a requirement these days).
Your point is well taken, however, one correction is in order: Battle Zone, an ancient Atari 3D FPS using wire-frame objects, was written in Forth.
What's your source for this? At one time or another I've heard people say that various classic video games were programming in Forth (Pac-Man, Defender, etc.)., but so far none of these rumors have been true. To the best of my knowledge, Battle Zone was programmed in assembly language.
One notable game actually written in Forth, BTW, is Starflight for the IBM PC (released by Electronic Arts in 1986).
Although when the IBM PC came out, it sure did look sad--visually--next to the displays of the Atari 800. But remember, that was the point. IBM wanted a serious business machine, not a game playing, recipe-filing computer.
Okay, I posted before reading the article. Can you tell :)
I think the fault is more with the submitter of the story than the author's presentation. The author just gives an overview of how stack computers work and their history. The submitter apparently never knew about stack computers and is all excited about them as a possible future of computing. The presentation is simple a history, mostly about stuff that's 20+ years old. So, yes, while stack processors have been commercially available and they've been used in commercial embedded systems work, they've failed to get outside that realm.
(As an aside, I'd say 99% of desktop programmers have no clue about all the stuff that's gone on in the embedded systems world, so it isn't surprising that old stuff seems new.)
Normally this kind of stuff doesn't bug me, but this is like an article in 2006 proclaiming the benefits of object-oriented programming. Doesn't anyone know their computing history?
There were stack computers in the 1960s and 1970s. There was a resurgence of interest in the 1980s--primarily because of Forth's popularity in embedded systems--resulting in a slew of stack-based "Forth engines." Forth creator Chuck Moore has been working on a series of custom Forth CPUs for 20+ years now. His latest version has 24 cores on one chip (and was entirely designed by one person and uses MILLIWATTS of power).
Stack processors and languages have one big advantage: they minimize the overall complexity of a system. The tradeoff is that they often push some of that complexity onto the programmer. That's why Forth tends to shine for small, controlled systems (like a fuel injector or telescope controller or fire alarm), but you don't see people writing 3D video games or web browsers in Forth.
Apple rushed out new systems based on an entirely new processor family (for them) and with much higher power and cooling requirements than anything they've dealt with in the past. Most of these problems would have been found with an extended testing period, but Apple wanted to get them out the door.
The two most worrisome problems are:
1. Heat. These new Macs just aren't as convenient to use as old iBooks, because you can't just slap them down anywhere. Ditto for just about any recent Windows notebook.
2. Shutdowns. This completely flies in the face of OS X being more reliable than Windows.
At work I see hundreds of batteries thrown away a month. I'll take wires over that any day.
WiFi is progress, wireless mice aren't.
Well okay, there are some, like polo :)
But the bottom line is that most video games are based around a try/die/repeat cycle. Furthermore, most video games are based around a *frustrating* try/die/repeat cycle. They're the kind of thing that a kid with endless free time can excel at, but someone for with a busier schedule they get old quick. There are exceptions, yes, but the vast majority of the big hits are like this. So most games are told like toys to an audience that wants toys.
The big win of open source is that many people can work on the same code, that work gets done faster as a result, that the code is more reliable overall. But for this to work outside of the usual suspects (Linux, Perl, Python, Apache), the architecture needs to be clean and dead simple.
All the time, working on proprietary code for a living, I see people making bad assumptions about how code works--even though all the original developers are right there in nearby offices--and there are often big whiteboard explanation sessions about little nuances of various libraries and low-level choices. A large percentage of the time these sessions end with the person thinking "Wow, I'm glad I didn't jump in and make that change without asking first."
This is exactly the same with almost any open source project of more than trivial size. The only way to combat it is to keep things as clean and blindingly simple as you can. Write as much in Python or Ruby as possible. Don't over-architect things (that is, don't make things pointlessly abstract). Ruthlessly trim features. Stay away from projects started by people with no engineering experience.
Good to hear it is covered, but that is exactly the reason you do not want a white surface if there is gonna be a lot of contact with it.
And yet this is only a problem with the new MacBooks, not the tens of millions of white iBooks sold over the last 5+ years.
It was overpriced and underpowered. It had the IBM name, but at the time it was so completely blah compared to home computers of the time. But then again the author may be thinking of the PC in general, and not the system that started it all.
On Apache vs. Linux: Remember, Linux was just a rewrite of UNIX. Nothing amazing there.
But do we really have a need for 64 bit? Tell me what apps do you know of that are successfully using 64 bit? That is, your application runs much quicker/better in 64 bit rather than 32?
Cost of memory is the big issue. You can buy a good dual-core PC for what it would cost to put 16GB into it.
Shouldn't it be something like "Debit cards to replace money in Monopoly"? Just because the card is Visa doesn't make it anywhere near the first time brand names have been used in board games. The Barbie board game came out in the 1960s, for example. Ditto for all the games about movies, TV shows, and licensed properties.
Look at it this way:
Suppose you bought a book about Ruby and it had a 140 page introductory chapter that started with the history of FORTRAN and Algol and worked all the way up through Perl and Python and Ruby. Suppose it went off on tangents about things that Niklaus Wirth and John Backus did. Suppose it talked about various programs of historical importance (like the first compiler and PLANNER and so on). Suppose it talked about programming paradigms which don't relate to Ruby, like the development of Prolog.
Now all of this is interesting, but it's out of place in a book about Ruby.
The mac and OS X are merely a sum of the history of Apple. You know, before they had the Mac Mini and your beloved iPod, they actually did some interesting things with a few spare parts and couple of off-the-shelf chips.
Of course. But this is a book about OS X. It isn't a book about operating system history or Apple history. The author took a subject that could have easily been covered in 5 pages and expanded it to 140+.
Why did the Mac use 800k floppies? Because of the GCR encoding from Woz's brilliant Apple II 5.25" floppy interface.
... for The Apple IIGS.
But Macs haven't used floppies since before OS X was available.
Why doesn't the Mac have cool onboard sound stuff? Because the Apple IIGS did, prompting the Beatles to sue Apple.
And this has nothing whatsoever to do with current Mac sound hardware or OS X.
Apple's first machine to use ADB? The Apple IIGS.
And this has nothing whatsoever to do with OS X.
Apple's first graphical GUI? System 6
And this has nothing whatsoever to do with OS X.
Remember, this is a book about OS X, not the history of Apple computers from 25 years ago.