Speed of light: 3 x 10^8 m/s Reasonable chip size: 1cm Ask uncle Google about "(300 000 000 (m / s)) / (1 cm)"
Response: 30 gigahertz
We will never see another 10x speed up on the basis of clockrate. Forget the heat thing (although that's also a killer), clockrate is dead, dead, dead.
Gee, thanks for assuming that I'm incompetent. No, I use an actual text editor (which even shows you the different between spaces and tabs and everything), not Notepad. Step one was the hardest because I assumed that I needed to replace the tabs with 4 spaces, like God intended, but when I ran it, I saw that it didn't work, and quickly realized that it was meant to be replaced with 8 spaces. All of the other steps worked the first time, which made step one the hardest relatively speaking, but none of the steps (including one) was especially hard. Maybe if I used a crappy text editor that doesn't distinguish tabs and spaces number one would have been actually hard, but if you program in Python without being aware of the difference between tabs and spaces the fault is your own.
Here's code you can put in your Python 2.x code today to future proof it against the change to xrange:
try:
range = xrange except NameError:
pass
After that, just write range in your code and it will automatically use the equivalent of Python 2's xrange. If you're running Python 2.6, you can use a print function (instead of a print keyword) by adding from __future__ import print_function to your header as well, and you're good to go for a large number of Python 3 switching problems.
I got it to run in Python 3, and here are the changes I need to make:
1) The file was screwed up and used a tab instead of 8 spaces (a problem unrelated to Python 3). 2) I had to change all the print statements into print functions by wrapping the argument in parentheses. 3) I had to change xrange to range. 4) I had to add from functools import reduce to the top of the file.
Done. 4 changes made in 5 minutes, the hardest of which (#1) would have screwed up Python 2.x as well.
You're joking about McCain's age, but the fact is he was born August 29, 1936 in Coco Solo Naval Air Station, Panama Canal Zone, Panama, AKA not in the US of A.
Racist Obama haters are too busy checking the font on his birth certificate to own up to this fact.
That's just another example of the problem, really. Articles have to battle vandalism so much of the time that self-appointed editors just revert first and ask questions later, with the unfortunate consequence of ensuring that the article will never be better than mediocre.
I've noticed that too. Here's the thing, there are three kinds of articles in Wikipedia today: stubs, mediocre articles, and decent articles. No one is watching the stubs, so you can add stuff to those, though there is a serious problem getting past the deletionists to make a stub in the first place. Mediocre articles on the other hand had some good information in the past, but now paragraph three cuts off halfway through and the references section is screwed up. When you look at the history of the page, you see that basically the only changes made to it in the last year were vandalism and reverts, but the reverts weren't done properly and information was lost. Finally, the decent articles are decent because there are specific people who patrol the page to keep out vandalism. The trouble is, they're assholes and they also keep out new information and revert any improvements to the page. Good luck pointing out that the sections of the page need to be reorganized: you'll just be reverted away.
Devil's advocate: If other people can't understand your error messages, doesn't that make them... bad error messages?
Remember: "Programs should be written for people to read, and only incidentally for machines to execute"
OTOH, if you do a good job of commenting on your easter egg in the source, whoever comes along after you should still be able to understand what's going on, and you get to amuse yourself with jokes. Win-win?
I remember a time not too long ago when 16 registers on a CPU were a big deal, and DOS apps couldn't read Mac files (even the 'simple' ASCII txt files) and there were different file-system structures 7bit vs 8bit vs *. We think that.txt is the safest solution for portability and longevity but IBM used to think the same thing about punch-cards!
Things have changed. When IBM was making punchcards, how many computers were there in the world? Let's be generous and say a couple hundred thousand. To compare, there are over 13 million iPhones in the world alone, to say nothing of Macs, PCs, or any of the other gazillion devices that can all read Unicode text. Certain digital formats are too big to ever really die, and Unicode is one of them. Similarly, JPEGs will never die. Why? Because people will always want to open pictures, and as long as we have software that can open pictures, it's trivial to make it so that it can open grandma's old family JPEGs in addition to whatever the standard format of 2050 is.
Now, hardware specs *can* die. For example, Apple is phasing out Firewire 400 right now. We can imagine in 10 years, maybe USB will be replaced by something wireless. But digital file formats are always going to be forward compatible, since it's trivial to make sure you can convert them to the new format. I can't use my mouse from 1995, but I can open a Word file in Office 95 format with TextEdit.
So, the key to keeping your data forever is pretty simple: Make multiple copies of it and store them in physically different locations (to prevent lost by disaster), and every couple years take a couple hours out to copy it onto a new physical device (to prevent loss by bit rot or physical format changes).
It looks like another input manager though. You can't really trust "plugins" (they're not really plugins but elaborate memory hacks) like those to work when a new version of Safari comes out. The simple solution is just to use a custom CSS file that blocks ads, like the one on http://www.floppymoose.com/.
There's nothing special about the NES era, as the article insinuates.
Not so. The NES was the first game console with a significant library of non-sucky titles. I tried playing my old Atari 2600 a few years ago and gave up, because it's all crap except for maybe a couple of games (Adventure, Outlaw,... I can't think of a third title, and I had dozens and dozens of games). On the other hand, there are a ton of great NES game. Tetris had an NES version, and it's still gold. (OK, so the NES version was crap compared to the Game Boy version. But still...) Super Mario Bros. 3 is the best game of all time. MegaMan is still popular as are a number of different platformers from back then. BattleToads and Ninja Turtles were popular beat 'em ups. Bomberman introduced a formula that's still around. The RPGs from the NES were generally crappy, but they laid the groundwork for future games and are decent as the basis for a remake. Most of the game ideas that we like now were previewed in a basically decent form on the NES.
That said, the SNES is still a better console overall because it had the good play mechanics of the NES and combined it with non-ugly graphics. Zelda 3, for example, is great and will never go out of style. The RPGs of the SNES don't need to be remade to be playable.
I've used the WiiWare and Virtual Console stores, but I think Nintendo really needs to work out the DRM issue. If I want to change to a different colored Wii in a couple years, will there be any way to bring my current games with me? What if my current machine just dies for some reason? What about when the Wii 2 comes out? Will there be any way of bringing my current collection of WiiWare with me to future consoles? Yeah, you can link your Wii with a My Nintendo account, but so far as I can tell, so far that has no effect whatsoever on your ability to retrieve your games in the future...
Buddhism is great. When a samurai cuts a dude into two pieces, it's really helpful to remember that he's nothing but petals in a stream. It really helps you sleep at night.
Here's the thing: that only happens in Python if you go outside the BMP, but even in the best character encoding scheme, unless you normalize, you can't tell if é is U+00E9 (Latin small letter e with acute) or e plus U+0301 (Combining acute accent). So, you can never really trust the length of a Unicode string.
Would it be better if Python reported the length of non-BMP characters correctly? Yes. But, given how funky Unicode can be, it's an understandable trade off to make.
The proper solution is to do what they did: hide from the programmer what internal format is used for strings. The only time programmers should know about the encoding is when they themselves explicitly select an encoding so that they can turn a bunch of bytes into a string or when they're sending the string out into the world as a bunch of bytes. Encode and decode explicitly at the edges. Internally, hide the implementation details. It's just basic OO.
UCS-2 does not provide any representation for characters outside the BMP
That's not quite correct. You can use characters outside the BMP, they just have messed up len and slices, since they're actually made of two pseudo-characters.
You have to BUY the privilige of getting a cone, chocolate, or nuts top with real money. The ice cream only costs $5, but I've heard that getting cones will cost you $4, and chocolate will cost you $3.
No, just Hell no. I will not pay for something that I could do for free with a Drumstick
Slashdot Mirror
Speed of light: 3 x 10^8 m/s
Reasonable chip size: 1cm
Ask uncle Google about "(300 000 000 (m / s)) / (1 cm)"
Response: 30 gigahertz
We will never see another 10x speed up on the basis of clockrate. Forget the heat thing (although that's also a killer), clockrate is dead, dead, dead.
Gee, thanks for assuming that I'm incompetent. No, I use an actual text editor (which even shows you the different between spaces and tabs and everything), not Notepad. Step one was the hardest because I assumed that I needed to replace the tabs with 4 spaces, like God intended, but when I ran it, I saw that it didn't work, and quickly realized that it was meant to be replaced with 8 spaces. All of the other steps worked the first time, which made step one the hardest relatively speaking, but none of the steps (including one) was especially hard. Maybe if I used a crappy text editor that doesn't distinguish tabs and spaces number one would have been actually hard, but if you program in Python without being aware of the difference between tabs and spaces the fault is your own.
You misspelled puts? ;-D
Here's code you can put in your Python 2.x code today to future proof it against the change to xrange:
try:
range = xrange
except NameError:
pass
After that, just write range in your code and it will automatically use the equivalent of Python 2's xrange. If you're running Python 2.6, you can use a print function (instead of a print keyword) by adding from __future__ import print_function to your header as well, and you're good to go for a large number of Python 3 switching problems.
I got it to run in Python 3, and here are the changes I need to make:
1) The file was screwed up and used a tab instead of 8 spaces (a problem unrelated to Python 3).
2) I had to change all the print statements into print functions by wrapping the argument in parentheses.
3) I had to change xrange to range.
4) I had to add from functools import reduce to the top of the file.
Done. 4 changes made in 5 minutes, the hardest of which (#1) would have screwed up Python 2.x as well.
You're joking about McCain's age, but the fact is he was born August 29, 1936 in Coco Solo Naval Air Station, Panama Canal Zone, Panama, AKA not in the US of A.
Racist Obama haters are too busy checking the font on his birth certificate to own up to this fact.
That's just another example of the problem, really. Articles have to battle vandalism so much of the time that self-appointed editors just revert first and ask questions later, with the unfortunate consequence of ensuring that the article will never be better than mediocre.
Well, you clearly didn't look at what I added, because the bit on Bulgakov was cited. The other bits were janitorial.
Give me one reason why this was reverted and you'll be giving me one more reason than the reverter did.
I've noticed that too. Here's the thing, there are three kinds of articles in Wikipedia today: stubs, mediocre articles, and decent articles. No one is watching the stubs, so you can add stuff to those, though there is a serious problem getting past the deletionists to make a stub in the first place. Mediocre articles on the other hand had some good information in the past, but now paragraph three cuts off halfway through and the references section is screwed up. When you look at the history of the page, you see that basically the only changes made to it in the last year were vandalism and reverts, but the reverts weren't done properly and information was lost. Finally, the decent articles are decent because there are specific people who patrol the page to keep out vandalism. The trouble is, they're assholes and they also keep out new information and revert any improvements to the page. Good luck pointing out that the sections of the page need to be reorganized: you'll just be reverted away.
Devil's advocate: If other people can't understand your error messages, doesn't that make them... bad error messages?
Remember: "Programs should be written for people to read, and only incidentally for machines to execute"
OTOH, if you do a good job of commenting on your easter egg in the source, whoever comes along after you should still be able to understand what's going on, and you get to amuse yourself with jokes. Win-win?
More importantly, who the hell says "soccer pitch"? Americans say "soccer field." Brits say "football pitch." No one says "soccer pitch."
Sounds like the writer was a Brit who tried to put it in Americanese but failed.
Things have changed. When IBM was making punchcards, how many computers were there in the world? Let's be generous and say a couple hundred thousand. To compare, there are over 13 million iPhones in the world alone, to say nothing of Macs, PCs, or any of the other gazillion devices that can all read Unicode text. Certain digital formats are too big to ever really die, and Unicode is one of them. Similarly, JPEGs will never die. Why? Because people will always want to open pictures, and as long as we have software that can open pictures, it's trivial to make it so that it can open grandma's old family JPEGs in addition to whatever the standard format of 2050 is.
Now, hardware specs *can* die. For example, Apple is phasing out Firewire 400 right now. We can imagine in 10 years, maybe USB will be replaced by something wireless. But digital file formats are always going to be forward compatible, since it's trivial to make sure you can convert them to the new format. I can't use my mouse from 1995, but I can open a Word file in Office 95 format with TextEdit.
So, the key to keeping your data forever is pretty simple: Make multiple copies of it and store them in physically different locations (to prevent lost by disaster), and every couple years take a couple hours out to copy it onto a new physical device (to prevent loss by bit rot or physical format changes).
It looks like another input manager though. You can't really trust "plugins" (they're not really plugins but elaborate memory hacks) like those to work when a new version of Safari comes out. The simple solution is just to use a custom CSS file that blocks ads, like the one on http://www.floppymoose.com/.
Most of those are 2600-era arcade games, not 2600 games. Or if they were also 2600 games, the home version sucked balls.
I will give you Pitfall though, that was cool.
There's nothing special about the NES era, as the article insinuates.
Not so. The NES was the first game console with a significant library of non-sucky titles. I tried playing my old Atari 2600 a few years ago and gave up, because it's all crap except for maybe a couple of games (Adventure, Outlaw, ... I can't think of a third title, and I had dozens and dozens of games). On the other hand, there are a ton of great NES game. Tetris had an NES version, and it's still gold. (OK, so the NES version was crap compared to the Game Boy version. But still...) Super Mario Bros. 3 is the best game of all time. MegaMan is still popular as are a number of different platformers from back then. BattleToads and Ninja Turtles were popular beat 'em ups. Bomberman introduced a formula that's still around. The RPGs from the NES were generally crappy, but they laid the groundwork for future games and are decent as the basis for a remake. Most of the game ideas that we like now were previewed in a basically decent form on the NES.
That said, the SNES is still a better console overall because it had the good play mechanics of the NES and combined it with non-ugly graphics. Zelda 3, for example, is great and will never go out of style. The RPGs of the SNES don't need to be remade to be playable.
I've used the WiiWare and Virtual Console stores, but I think Nintendo really needs to work out the DRM issue. If I want to change to a different colored Wii in a couple years, will there be any way to bring my current games with me? What if my current machine just dies for some reason? What about when the Wii 2 comes out? Will there be any way of bringing my current collection of WiiWare with me to future consoles? Yeah, you can link your Wii with a My Nintendo account, but so far as I can tell, so far that has no effect whatsoever on your ability to retrieve your games in the future...
Buddhism is great. When a samurai cuts a dude into two pieces, it's really helpful to remember that he's nothing but petals in a stream. It really helps you sleep at night.
See also:
http://en.wikipedia.org/wiki/Sohei
http://en.wikipedia.org/wiki/Yamabushi
Are you OS X or Linux or Windows? I'm on OS X. My understanding is that this varies from OS to OS.
Well, in that case, Python must be using UTF-16 in version 2.6 for OS X and not UCS-2.
Here's the thing: that only happens in Python if you go outside the BMP, but even in the best character encoding scheme, unless you normalize, you can't tell if é is U+00E9 (Latin small letter e with acute) or e plus U+0301 (Combining acute accent). So, you can never really trust the length of a Unicode string.
Would it be better if Python reported the length of non-BMP characters correctly? Yes. But, given how funky Unicode can be, it's an understandable trade off to make.
The proper solution is to do what they did: hide from the programmer what internal format is used for strings. The only time programmers should know about the encoding is when they themselves explicitly select an encoding so that they can turn a bunch of bytes into a string or when they're sending the string out into the world as a bunch of bytes. Encode and decode explicitly at the edges. Internally, hide the implementation details. It's just basic OO.
That's not quite correct. You can use characters outside the BMP, they just have messed up len and slices, since they're actually made of two pseudo-characters.
I would show that I was able to print it, but Slashdot hates Unicode.
You have to BUY the privilige of getting a cone, chocolate, or nuts top with real money. The ice cream only costs $5, but I've heard that getting cones will cost you $4, and chocolate will cost you $3.
No, just Hell no. I will not pay for something that I could do for free with a Drumstick
Someone makes a unique, innovative title and the first thing people think is: Ooh, let's get a sequel to that.