No offense, it looks like a pretty cool text-based MUD engine, but it is not going to be competing with any of these commercial real-time 3D massive multiplayer systems any time soon. To manage a real-time 3D environment, you need raw speed.
To be honest, it looks to me like it's just trying to do too much. It leaves things so open you might as well just start from scratch.
The value of a MUD engine is that it has a certain basic functionality, and you define the variation from that functionality and specific data that fits within it. If you make a MUD engine that you can do <i>anything</i> with, you haven't really gained anything over just picking the language of your choice and the OS of your choice and going from there.
For a good case study of this effect see <a href="http://www.verge-rpg.com/">VERGE</a> (the main site's down, but there's a link that'll let you into the community). VERGE is a console-RPG construction kit. VERGE 1 had a simple scripting language that didn't give the programmer a whole lot of freedom, people complained, but they made lots of games with it (well, lots of demos; I don't believe I ever did see a VERGE game completed). To "fix" these problems, VERGE 2 was created. It allowed a whole lot more and included a "scripting" language that's really an interpreted C variant. The problem is, making a VERGE 2 game was a whole lot more complicated than making a VERGE 1 game. In fact, people would probably have been better off with just a good C library for tiled graphics with sprites and a few special effects, keyboard, and sound handling. So VERGE has more or less died off, with the occasional demo still popping up, but most of the projects having died a slow death when people who chose VERGE because they couldn't program tried to move from 1 to 2.
My first impression of the discription was that it was talking about a tightly coupled operating system/programming language like Oberon or Forth. When you step back a bit, MUQ looks a lot like some LISP or Forth variant running on EROS. Not a bad platform for a MUD, but why go to all the trouble of rewriting it in C and running it on top of another OS?
Even if/. filtered that out of the link, you could still do it on the other side of a plain HTML link.
There is no way/. could protect you from running arbitrary Javascript if you click on a link, except preventing posters from linking to arbitrary locations.
However, since/. works just fine with Javascript off, it's you can defend against it just fine by turning Javascript off while surfing/.
I don't think this is a weakness of/. but an inherent weakness of Javascript-enabled browsers.
Browsers should never have been made to have only one JavaScript option: on or off.
You ought to be able to limit your JavaScript functionality in many different ways. I browse with JavaScript off all the time, to prevent automatic pop-ups, but I have to turn it back on because so many sites just don't work with JavaScript turned off (often for no good reason: JavaScript links instead of HTML links, for example).
Desperately needed JavaScript options are: -no pop-ups (display pop-up requests in a dedicated widget) -no clickless redirection (display as links in a pseudo-frame or with a dedicated widget)
With these, I could happily browse all sites with the same settings.
I can't think of any others yet (I think they depend on the specific environment; aren't there some real security hazards?), but I'm sure there are more. What am I missing?
(aside from JavaScript, turning off all animations is another much-needed option)
Patents (like any IP) are not an inherent right, and their purpose is not to benefit the patent holder but to benefit society as a whole; they were created with the specific intent of encouraging innovation by trading full disclosure of the details of the patented mechanism in exchange for a short-term monopoly on its use.
They were created (in their modern form) to prevent excessive secrecy and completely snuff out the stifling guild model of protecting trade secrets.
Mathematics and facts of the natural sciences are specifically noted as unpatentable in patent law. This is because it was recognized that there was no need for patents in these fields; people already shared their discoveries freely in hopes of the recognition and prestige they could gain by it. Patents would only interfere with this and slow progress.
Computer science is not only a branch of mathematics (algorithms are as old as the abacus, and were formalized long before the first programmable computer), but shows all the same behavior that makes it an unsuitable field for patents. People proudly explain their clever algorithms and data structures for no direct monetary gain. Allowing software patents has only interfered with the progress of the field.
Practically every software developer breaks software patent laws. There are a great many software patents on simple, obvious, and common practices, and it is generally not feasible even to check whether you are infringing on anyone else's patents. It is also not economically feasible to legally challenge every bogus patent that one wishes to use. If one were to attempt to remain in full compliance at all times with patent law, it would be hundreds or thousands of times more expensive than the actual software development.
Not only are software patents useless and harmful, they are impossible to obey or generally enforce, thus becoming merely another weapon for competition through litigation so whoever spends the most money on lawyers wins.
Speech recognition is not at all a simple matter. It needs training and/or tweaking to work for each little sub-dialect.
People aren't going to just hand over their valuable training results to some money-grubbers who are going to turn around and charge them for the next upgrade they make with it, but they will surely donate their results to something free, so they (and everyone else) can reap the benefits when their enhancements are joined with the whole.
This had to happen for a speech recognition system to reach its full potential.
Software patents are wrong. Algorithms are math and math is not patentable. Any software patent granted is a failure of the patent office, and any upheld on challenge is a failure of the courts.
The incentive of software patents is not needed to encourage people to develop and release new algorithms, but rather it interferes horribly with software development (at least whenever it is used). It stifles innovation, hampers interoperability, and maintains monopolies on reading certain data formats.
Most of us aren't "pretty good about that sort of thing," we don't respect it because we think it's evil.
The closest most of the free software community comes to "respecting" software patents is trying to avoid getting sued over them.
Dune goes downhill? (spoilers and bad 70s guitar)
on
Sci Fi Literature 101?
·
· Score: 2
Not if you don't mind the gradual progression from science fiction built around an epic plot of imperial intrigue to being built around the plot of a porno movie.
(start cheesy 70s porno guitar)
Entrenched aristocracy gets lazy, hires bureaucrats, are eventually taken over by superbabes with ultraorgasmic powers sleeping their way to the top. Having reached the top, they sleep their way across the galaxy, holding entire planetary populations in sexual bondage until they meet our hero:
Dunclone Idaho! The sex-zombie with hyper-fuckadelic powers superior to those of the superbabes. Wait until their paths collide, and watch the arm-pit nibbling action that will decide the fate of the universe!
^_^;; (I don't care how funny you find this, don't moderate anything with "spoilers" in the subject so it's visible without clicking)
I know, big war, lots of dead people and misery, not a laughing matter, but the reference had a certain humor, something like:
God Emperor: This Hitler guy killed like 60 million people. Lackey: Wow, he must have had some really great weapons. God Emperor: No, no, not with his own hands, he just ordered his armies to do it, like I do. Lackey: Well, that's not too impressive, then, your track record totally blows his out of the water. Isn't that about par for you on a good day?
I think there's also supposed to be a good calculating explanation for the Baron's... preferences... in the upcoming House Harkonnen (I don't want to ruin any surprise, but some B.G. breeder did manage to sneak at least one offspring out of him - Jessica).
The Bene Gesserit breeders produced House Harkonnen and House Atriedes as experiments in pure evil and pure good (in appearances, at least), culminating in the Baron and Duke Leto. Paul was balanced because he was a cross between the two.
In any viable culture (that I know of, at least), true homosexuality is accepted, tolerated, ridiculed, or outlawed, but never generally praised. In the balance of things it's considered wrong, or at least wierd and deviant. Given one fresh Dunclone's reaction to Fish Speaker lesbians, I'd take it that it was considered a foul and evil obscenity in the ruling culture of the period. Harkonnens (especially the ultimate evil floating fat man himself) would be drawn by the perversity of it.
I think it would be pretty sad if they fudged the cultures of the Dune universe to make more politically correct novels.
A 13-year-old mind is mature enough to handle any reading material. In fact, the more time a person has to be exposed to wildly varied viewpoints, the better they will be able to deal with them. As for graphic sex, all it will do is teach them not to giggle at a younger age.
Expose a 13-year-old to Marx and they'll think their way out of it before they do anything stupid. Restrict their access until they reach 18 and you might have a revolutionary on your hands.
Dune -study of aristocracy, religious engineering and the creation of a messiah, rejection of computers in favor of the development of human potential resulting in continued relevance of human traits, race memory (though now discredited, it is still a fascinating idea), consequences of reliance on performance-enhancing drugs, the potential failures of perfect "prediction" of the future, the dangers of breeding humans
The Dosadi Experiment -an incredible system of adaptive law, development of societies under pressure, the dangers of psychological experiments, underlying nature of human interactions stripped of pretext and niceties, the nature of bureaucracy, the illusion of democracy, sideline on manipulation through addictions, interesting ideas about controlling runaway progress
Starship Troopers -jump engines, powered armor, a military-based limited democracy, a tribute to the infantryman of past and future, and a simple biologically motivated clash of intelligent species
The Moon is a Harsh Mistress -an anatomy of a revolution, the unexpected emergence of an AI, rational anarchism and the redeeming traits of criminals, realistic lunar colonization
Red Mars, Green Mars, Blue Mars (3 books) -despite the naive politics and silly interpersonal plots, the random details create an incredibly rich and plausible potential future that is extremely relevant to our time
My thought on the Hitchhikers Guide is that it makes fun of a lot of common themes and specific ideas in science fiction, so you will get more out of it after you've read your way around the genre.
Just picking it up as one of your first science fiction novels would be kind of like moving in from a very foreign country (no American TV... if such places still exist) and watching Simpsons: it would still be kind of funny, but not nearly as much as if you recognized all the pop-culture references.
They pay in order to be allowed to run the shows with some of their ads replacing the less expensive ads on the original broadcast. That's how the rebroadcasters make their money.
"I don't remember saying that" Sorry, you didn't, that was AndrewHowe. I wasn't keeping track of who is on this thread.
"I'll take your word for it" Don't take my word too seriously, I don't have the C spec either. I'm going on what other people have said about the standard. And like I said, it may have been about the upcoming standard, not the present one (you've gotta love it, it's finally been around long enough for people to comply and then they go and change the thing).
The fewer excess bits you use, the smaller and faster (not to mention cheaper) the chip can be.
"So that the code can run on 99.9999% of the machines someone may want to run it on, instead of, say, 85%, or 50%, or 1%, depending on how far you deviate from the standard and what assumptions you make?"
Nothing that depends on a 64-bit long (and very little that can benefit from it) is going to run on 99.9999% of machines (it will, in fact, be broken on many 64-bit machine compilers), which was my point.
"64 bit operations on an alpha are no slower than 32 bit operations, so it's not really being wasteful." Think of the memory consumption (if it's not being wasteful, why then did you claim that in this case using long was sub-optimal?).
"IIRC, C requires long to be large enough to hold a pointer. On non-NT alpha, that's 64 bits." IIRC, that's an old K&R thing and in ANSI C, pointers and ints are completely different animals and can never be inter-converted. Or maybe that's just the upcoming new ANSI standard.
"Why use a 64-bit chip if you're only ever going to use half of it?" Indeed, why use a 64-bit chip at all? (I don't like the current trend of building bigger and bigger chips; we should be learning to make more and more of them work together) But more on topic, very little portable ANSI C code will make profitable use of a 64-bit long (yes, you can write code that checks just how big it is, and do, say, bit masking operations on more bits in parallel, or write a more efficient BigInt library). If you are going to write non-portable code, why even bother sticking to the standard? I like the "long long" solution that some compilers use; for one thing, it immediately tells any other compiler that this code isn't portable ANSI C.
If you ask me, it is a design flaw. Longs are only required to have the range of a 32-bit number, so it is wasteful to include more bits. A lot of portable code will have unnecessarily bloated memory use and any reliance on the extra 32 bits throws portability out the window. Given that, a non-portable extension for 64-bit ints (since full use of 64-bits is inherently non-portable; with a lot of sizeof checking some use is possible, but not convenient) to be used only for system specific optimizations would probably be a better choice.
Given that most code run on Alphas probably isn't written with a 64-bit long in mind, it almost certainly hurts more than it helps (especially with memory access being the main bottleneck of modern systems).
The next C standard should fix this problem by providing a 64-bit int (if you ask me, they should just allow you to stack longs, doubling the bits of the minimal range each time; writing arbitrary bit size emulation into the compiler is trivial, though the trivial implementation is inefficient, and it would be a permanent fix that could have surprising benefits for certain supercomputer applications), as well as the addition of fixed bit size types (which is, I suppose, good for networking code, though I fear people will abuse it; IMHO it's better the way it is where you should chop everything up manually into whatever format the protocol takes).
As a programmer, when I moved from Windows to Linux a couple of years ago I increased my productivity 100-fold.
I doubled it by not having the system crash from under me, and I increased it by 50 times by not having any great games to distract me.
If this trend continues, I almost might as well move back to Windows; I mean what's the point of dealing with logging in every few weeks when I reboot for a measly double productivity gain?
Dammit! Extrans is eating my tags!
...only 60 times slower than C! ^_^
No offense, it looks like a pretty cool text-based MUD engine, but it is not going to be competing with any of these commercial real-time 3D massive multiplayer systems any time soon. To manage a real-time 3D environment, you need raw speed.
To be honest, it looks to me like it's just trying to do too much. It leaves things so open you might as well just start from scratch.
The value of a MUD engine is that it has a certain basic functionality, and you define the variation from that functionality and specific data that fits within it. If you make a MUD engine that you can do <i>anything</i> with, you haven't really gained anything over just picking the language of your choice and the OS of your choice and going from there.
For a good case study of this effect see <a href="http://www.verge-rpg.com/">VERGE</a> (the main site's down, but there's a link that'll let you into the community). VERGE is a console-RPG construction kit. VERGE 1 had a simple scripting language that didn't give the programmer a whole lot of freedom, people complained, but they made lots of games with it (well, lots of demos; I don't believe I ever did see a VERGE game completed). To "fix" these problems, VERGE 2 was created. It allowed a whole lot more and included a "scripting" language that's really an interpreted C variant. The problem is, making a VERGE 2 game was a whole lot more complicated than making a VERGE 1 game. In fact, people would probably have been better off with just a good C library for tiled graphics with sprites and a few special effects, keyboard, and sound handling. So VERGE has more or less died off, with the occasional demo still popping up, but most of the projects having died a slow death when people who chose VERGE because they couldn't program tried to move from 1 to 2.
My first impression of the discription was that it was talking about a tightly coupled operating system/programming language like Oberon or Forth. When you step back a bit, MUQ looks a lot like some LISP or Forth variant running on EROS. Not a bad platform for a MUD, but why go to all the trouble of rewriting it in C and running it on top of another OS?
However, there's no need for your browser to trust slashdot, since you don't need JavaScript to use it.
As for 1, you can anonymously create a web page almost as easily as you can post an anonymous message on slashdot.
Even if /. filtered that out of the link, you could still do it on the other side of a plain HTML link.
/. could protect you from running arbitrary Javascript if you click on a link, except preventing posters from linking to arbitrary locations.
/. works just fine with Javascript off, it's you can defend against it just fine by turning Javascript off while surfing /.
/. but an inherent weakness of Javascript-enabled browsers.
There is no way
However, since
I don't think this is a weakness of
Browsers should never have been made to have only one JavaScript option: on or off.
You ought to be able to limit your JavaScript functionality in many different ways. I browse with JavaScript off all the time, to prevent automatic pop-ups, but I have to turn it back on because so many sites just don't work with JavaScript turned off (often for no good reason: JavaScript links instead of HTML links, for example).
Desperately needed JavaScript options are:
-no pop-ups (display pop-up requests in a dedicated widget)
-no clickless redirection (display as links in a pseudo-frame or with a dedicated widget)
With these, I could happily browse all sites with the same settings.
I can't think of any others yet (I think they depend on the specific environment; aren't there some real security hazards?), but I'm sure there are more. What am I missing?
(aside from JavaScript, turning off all animations is another much-needed option)
Patents (like any IP) are not an inherent right, and their purpose is not to benefit the patent holder but to benefit society as a whole; they were created with the specific intent of encouraging innovation by trading full disclosure of the details of the patented mechanism in exchange for a short-term monopoly on its use.
They were created (in their modern form) to prevent excessive secrecy and completely snuff out the stifling guild model of protecting trade secrets.
Mathematics and facts of the natural sciences are specifically noted as unpatentable in patent law. This is because it was recognized that there was no need for patents in these fields; people already shared their discoveries freely in hopes of the recognition and prestige they could gain by it. Patents would only interfere with this and slow progress.
Computer science is not only a branch of mathematics (algorithms are as old as the abacus, and were formalized long before the first programmable computer), but shows all the same behavior that makes it an unsuitable field for patents. People proudly explain their clever algorithms and data structures for no direct monetary gain. Allowing software patents has only interfered with the progress of the field.
Practically every software developer breaks software patent laws. There are a great many software patents on simple, obvious, and common practices, and it is generally not feasible even to check whether you are infringing on anyone else's patents. It is also not economically feasible to legally challenge every bogus patent that one wishes to use. If one were to attempt to remain in full compliance at all times with patent law, it would be hundreds or thousands of times more expensive than the actual software development.
Not only are software patents useless and harmful, they are impossible to obey or generally enforce, thus becoming merely another weapon for competition through litigation so whoever spends the most money on lawyers wins.
Speech recognition is not at all a simple matter. It needs training and/or tweaking to work for each little sub-dialect.
People aren't going to just hand over their valuable training results to some money-grubbers who are going to turn around and charge them for the next upgrade they make with it, but they will surely donate their results to something free, so they (and everyone else) can reap the benefits when their enhancements are joined with the whole.
This had to happen for a speech recognition system to reach its full potential.
Software patents are wrong. Algorithms are math and math is not patentable. Any software patent granted is a failure of the patent office, and any upheld on challenge is a failure of the courts.
The incentive of software patents is not needed to encourage people to develop and release new algorithms, but rather it interferes horribly with software development (at least whenever it is used). It stifles innovation, hampers interoperability, and maintains monopolies on reading certain data formats.
Most of us aren't "pretty good about that sort of thing," we don't respect it because we think it's evil.
The closest most of the free software community comes to "respecting" software patents is trying to avoid getting sued over them.
It's not a link to Amazon or something. You can go read it right now.
The Eye of Argon
Go read it. You are guaranteed to regret it.
Not if you don't mind the gradual progression from science fiction built around an epic plot of imperial intrigue to being built around the plot of a porno movie.
(start cheesy 70s porno guitar)
Entrenched aristocracy gets lazy, hires bureaucrats, are eventually taken over by superbabes with ultraorgasmic powers sleeping their way to the top. Having reached the top, they sleep their way across the galaxy, holding entire planetary populations in sexual bondage until they meet our hero:
Dunclone Idaho! The sex-zombie with hyper-fuckadelic powers superior to those of the superbabes. Wait until their paths collide, and watch the arm-pit nibbling action that will decide the fate of the universe!
^_^;; (I don't care how funny you find this, don't moderate anything with "spoilers" in the subject so it's visible without clicking)
I know, big war, lots of dead people and misery, not a laughing matter, but the reference had a certain humor, something like:
God Emperor: This Hitler guy killed like 60 million people.
Lackey: Wow, he must have had some really great weapons.
God Emperor: No, no, not with his own hands, he just ordered his armies to do it, like I do.
Lackey: Well, that's not too impressive, then, your track record totally blows his out of the water. Isn't that about par for you on a good day?
I think there's also supposed to be a good calculating explanation for the Baron's... preferences... in the upcoming House Harkonnen (I don't want to ruin any surprise, but some B.G. breeder did manage to sneak at least one offspring out of him - Jessica).
The Bene Gesserit breeders produced House Harkonnen and House Atriedes as experiments in pure evil and pure good (in appearances, at least), culminating in the Baron and Duke Leto. Paul was balanced because he was a cross between the two.
In any viable culture (that I know of, at least), true homosexuality is accepted, tolerated, ridiculed, or outlawed, but never generally praised. In the balance of things it's considered wrong, or at least wierd and deviant. Given one fresh Dunclone's reaction to Fish Speaker lesbians, I'd take it that it was considered a foul and evil obscenity in the ruling culture of the period. Harkonnens (especially the ultimate evil floating fat man himself) would be drawn by the perversity of it.
I think it would be pretty sad if they fudged the cultures of the Dune universe to make more politically correct novels.
Try this: read "1984", "Brave New World", then "Make Us Happy" in that order. There is a clear progression that is absolutely hilarious.
A 13-year-old mind is mature enough to handle any reading material. In fact, the more time a person has to be exposed to wildly varied viewpoints, the better they will be able to deal with them. As for graphic sex, all it will do is teach them not to giggle at a younger age.
Expose a 13-year-old to Marx and they'll think their way out of it before they do anything stupid. Restrict their access until they reach 18 and you might have a revolutionary on your hands.
I class some of the stuff in there among the greatest moments of science fiction, like the robot designers who learned the purpose of boredom.
Realizing why the stuff is absurd is as deep a lesson as you'll get from any sci-fi.
Dune
-study of aristocracy, religious engineering and the creation of a messiah, rejection of computers in favor of the development of human potential resulting in continued relevance of human traits, race memory (though now discredited, it is still a fascinating idea), consequences of reliance on performance-enhancing drugs, the potential failures of perfect "prediction" of the future, the dangers of breeding humans
The Dosadi Experiment
-an incredible system of adaptive law, development of societies under pressure, the dangers of psychological experiments, underlying nature of human interactions stripped of pretext and niceties, the nature of bureaucracy, the illusion of democracy, sideline on manipulation through addictions, interesting ideas about controlling runaway progress
Starship Troopers
-jump engines, powered armor, a military-based limited democracy, a tribute to the infantryman of past and future, and a simple biologically motivated clash of intelligent species
The Moon is a Harsh Mistress
-an anatomy of a revolution, the unexpected emergence of an AI, rational anarchism and the redeeming traits of criminals, realistic lunar colonization
Red Mars, Green Mars, Blue Mars (3 books)
-despite the naive politics and silly interpersonal plots, the random details create an incredibly rich and plausible potential future that is extremely relevant to our time
My thought on the Hitchhikers Guide is that it makes fun of a lot of common themes and specific ideas in science fiction, so you will get more out of it after you've read your way around the genre.
Just picking it up as one of your first science fiction novels would be kind of like moving in from a very foreign country (no American TV... if such places still exist) and watching Simpsons: it would still be kind of funny, but not nearly as much as if you recognized all the pop-culture references.
They pay in order to be allowed to run the shows with some of their ads replacing the less expensive ads on the original broadcast. That's how the rebroadcasters make their money.
you can guess what went wrong...
"I don't remember saying that"
Sorry, you didn't, that was AndrewHowe. I wasn't keeping track of who is on this thread.
"I'll take your word for it"
Don't take my word too seriously, I don't have the C spec either. I'm going on what other people have said about the standard. And like I said, it may have been about the upcoming standard, not the present one (you've gotta love it, it's finally been around long enough for people to comply and then they go and change the thing).
"However, without an integer type big enough to hold a pointer, how are you going to compare a pointer to another using operators like do wish that methods of handling larger ints were specified; I mean, even the x86s have special features to handle 64-bit ints, which you just can't access using ANSI C). Actually, I'm rather fond of the idea of 24-bit chips. Chuck Moore thinks 20-bits is enough, and I really respect him, but he also thinks it's an acceptable tradeoff to use a character set where ones and lower case Ls are the same (I really recommend reading around his web site, while he might be a little over the edge, he still has a lot to teach the rest of us).
The fewer excess bits you use, the smaller and faster (not to mention cheaper) the chip can be.
"So that the code can run on 99.9999% of the machines someone may want to run it on, instead of, say, 85%, or 50%, or 1%, depending on how far you deviate from the standard and what assumptions you make?"
Nothing that depends on a 64-bit long (and very little that can benefit from it) is going to run on 99.9999% of machines (it will, in fact, be broken on many 64-bit machine compilers), which was my point.
"64 bit operations on an alpha are no slower than 32 bit operations, so it's not really being wasteful."
Think of the memory consumption (if it's not being wasteful, why then did you claim that in this case using long was sub-optimal?).
"IIRC, C requires long to be large enough to hold a pointer. On non-NT alpha, that's 64 bits."
IIRC, that's an old K&R thing and in ANSI C, pointers and ints are completely different animals and can never be inter-converted. Or maybe that's just the upcoming new ANSI standard.
"Why use a 64-bit chip if you're only ever going to use half of it?"
Indeed, why use a 64-bit chip at all? (I don't like the current trend of building bigger and bigger chips; we should be learning to make more and more of them work together) But more on topic, very little portable ANSI C code will make profitable use of a 64-bit long (yes, you can write code that checks just how big it is, and do, say, bit masking operations on more bits in parallel, or write a more efficient BigInt library). If you are going to write non-portable code, why even bother sticking to the standard? I like the "long long" solution that some compilers use; for one thing, it immediately tells any other compiler that this code isn't portable ANSI C.
Hmm... That bites.
If you ask me, it is a design flaw. Longs are only required to have the range of a 32-bit number, so it is wasteful to include more bits. A lot of portable code will have unnecessarily bloated memory use and any reliance on the extra 32 bits throws portability out the window. Given that, a non-portable extension for 64-bit ints (since full use of 64-bits is inherently non-portable; with a lot of sizeof checking some use is possible, but not convenient) to be used only for system specific optimizations would probably be a better choice.
Given that most code run on Alphas probably isn't written with a 64-bit long in mind, it almost certainly hurts more than it helps (especially with memory access being the main bottleneck of modern systems).
The next C standard should fix this problem by providing a 64-bit int (if you ask me, they should just allow you to stack longs, doubling the bits of the minimal range each time; writing arbitrary bit size emulation into the compiler is trivial, though the trivial implementation is inefficient, and it would be a permanent fix that could have surprising benefits for certain supercomputer applications), as well as the addition of fixed bit size types (which is, I suppose, good for networking code, though I fear people will abuse it; IMHO it's better the way it is where you should chop everything up manually into whatever format the protocol takes).
As a programmer, when I moved from Windows to Linux a couple of years ago I increased my productivity 100-fold.
I doubled it by not having the system crash from under me, and I increased it by 50 times by not having any great games to distract me.
If this trend continues, I almost might as well move back to Windows; I mean what's the point of dealing with logging in every few weeks when I reboot for a measly double productivity gain?