Sega are still committed to a platform-agnostic stance. In fact their recent TGS presentation stated that at the moment PS2 was their primary target, simply because of the larger userbase. Even that doesn't look likely to swing them much, though.
It's worth pointing out that Sega are still working with other arcade manufacturers on the System 246 board.
Even if you subscribe to the worst MS conspiracy theories, you can't give MS sole credit for killing desktop Java.
Desktop Java is dead? That's news to me, since I'm currently working with plenty of big companies who are still developing desktop Java solutions.
What died was the idea that Java would be the development language of choice for all desktop apps in the future, from diarying systems to desktop publishing. And that's a good thing, IMO.
$10 Canadian? Bah. I'll offer a bottle of Dr Pepper and a packet of crisps to the first person who can hack into my box located at IP address 127.0.0.1 and delete all the files on it...
You may be the last person on this planet to learn that WORA (in java at least) is a complete myth for non-trivial software.
Complete myth? Hardly. Many programs (the majority of real-world code IME) will work straight off. Of course if you're going to have to support it, particularly under heavy use, then you'll expect people to be using it with a specified and tested JVM and platform. They call it WOTE for a reason, you know.;) And unless you're utterly insane the same is true for cross-platform libraries of any level of complexity. If I tested my program with FooLib 1.2 on Red Hat then I'm not supporting you using FooLib 1.3b on OS X.
Java does allow you "to just write the code once and ship it to all your customers", provided you make it clear that the only supported versions are the ones you've tested against and they run it on other versions/VMs/platforms at their own risk. And anyone who needs to run it on a different platform will be able to, and 99% of the time it will work just fine provided the code was well written in the first place. The same can never be true of binary distributions using shared libraries.
Of course WORA doesn't work perfectly - it's one of the first things I point out when teaching Java. But you seem to be painting a picture of a world where Java code needs to be carefully targetted at particular platforms and will fall over if you try to run it elsewhere, and that's even further from the truth.
You could distribute your app as "shrouded source" which is just machine obfuscated source code.
Which does nothing for those users who aren't happy recompiling from scratch, and doesn't do much to appease the boss/lawyers/project manager who is hung up on the idea that it's a bad plan to let customers see our source code in any form.
Not just old news, but positively antique. Here's a link to a C&VG article complete with screenshots of the PS2/XBox versions, which were announced long before the GC one. Also an IGN preview of the PS2 version.
Cool. I'm convinced, but some would view this as a slightly circular argument.
2) Java is slow because some libraries have already been written in other languages.
You make a good case here. But again, some might frown and accuse that argument of being a bit of a non sequitur.
2) Java is slow because some people who don't use it don't know how to use it.
Again, 100% solid. But I fear some might be slightly wary of the utter irrelevance of what you're saying and still other might suggest that the fact you can't count to three makes you a less than optimal judge of speed of numerical computation...
If you'd like to execute your code with native speed on any platform from a single sourcebase, why not use a cross-platform application framework?
Because then you either have to recompile for all platforms and provide binaries for all of them (along with suitable installation instructions/programs) or you have to make your source available. The former is a pain, since the whole aim of writing truly cross-platform software is that it can run on any platform, not just those you happen to have development tools for. The latter may not be desirable (not all software is open source, you know) and causes hassle for people who don't feel they have the skill to compile code from source and install it.
I'm afraid your code is pretty much useless for testing Java vs C++ performance. If you'd checked out the Sun FAQ on benchmarking Hotspot you'd have seen something like this:
I write a simple loop to time a simple operation and HotSpot looks even slower than Java 2 SDK. What am I doing wrong? Here's my program:
(Program almost identical to yours snipped, since it's setting off the lameness filters;)
You are writing a microbenchmark.
Remember how HotSpot works. It starts by running your program with an interpreter. When it discovers that some method is "hot" -- that is, executed a lot, either because it is called a lot or because it contains loops that loop a lot -- it sends that method off to be compiled. After that one of two things will happen, either the next time the method is called the compiled version will be invoked (instead of the interpreted version) or the currently long running loop will be replaced, while still running, with the compiled method. The latter is known as "on stack replacement" and exists in the 1.3/1.4 HotSpot based systems.
But it still shows that the host is receiving the mails and *someone* is reading them. The solution for link-following is to remove anything from the link which might provide information about who's responding (anything that looks like a unique identifier, in particular a reference to your e-mail address). For responding, perhaps the best approach is to forge your own headers (fighting fire with fire) to give the impression of responding from an account that genuinely *is* invalid.
So rely on personal recommendations and pick up the comics in collected graphic novel format rather than on a monthly basis.
Some series that I'd recommend:
Lenore (Roman Dirge) - Very sick and twisted, some genuinely thought-provoking stuff in here. Outstanding stuff, now available in two collections.
Transmetropolitan (Warren Ellis) - Some real bite in this one from time to time, though I miss the one-offs from the earlier parts of the series. Still running, but a fair few collections available.
Preacher (Garth Ennis) - Don't read it if you're offended by the odd bit of blasphemy, but for anyone else it's great stuff.
That's a fair point to a certain extent, but the tie isn't particularly direct in this case. If my company can't compete because of restrictive IP law, then I don't have any resources to buy expensive business lunches, but I wouldn't have called this article "The end of expensive business lunches?" either...
Perhaps that's a slight oversimplification, I suppose, because stifling the ability to compete tends to lead to monopolies or near-monopolies, which in turn *does* stifle the need for innovation somewhat. But the more direct problem is the destruction of the right to compete, and the abuse of draconian IP law we're beginning to see.
What does this have to do with innovation?
on
The End of Innovation?
·
· Score: 4, Insightful
This isn't a question of 'the end of innovation' at all, except possibly in a Microsoftesque "Help! Stop the bad man! He's depriving me of my ability to innovate!" sort of a way. The issue is an entirely separate one, that of fair use and the purpose and extent of IP rights.
There's nothing to stop people coming up with new and better ways of carrying out these same tasks, or entirely different tasks - the constraints that we're looking at here are primarily on reverse engineering, which has never really struck me as being an integral part of innovation...
The first such anti-virus virus, Den_Zuko, was discovered in 1988. Check out this article on VNUnet, which has more info on the history of such software and why it's a bad idea.
More recently, the Linux.Cheese.Worm has done similar things for Linux users infected by the Linux.Lion.Worm.
Sometimes they boil down to brute force, but not always. Incomplete information makes brute-forcing things difficult (that's the main problem with Bridge, rather than any randomising element). In fact dealing with random elements in some situations can actually be almost as simple as non-random games - maybe even simpler, since the computer is going to have the edge in calculating the probabilities of particular events taking place.
There are plenty of evolutionary approaches to generating AI similar to the one you describe for Quake. I'd be interested in seeing if a good Quake bot could be generated using GP...
But that's exactly why chess is so uninteresting. It generally boils down to a question of making a better brute force algorithm. Other games are far more interesting from an AI perspective - Bridge is a very good one to look at.
One of the most interesting AI players I've seen in recent years is the Angband borg, which plays the roguelike game Angband with a relatively high level of skill (although it's far too much of a coward for my liking...)
But very rarely in the ways you expect. Look at the predictions people were making for life in the year 2000 back in 1800, or 1900, or 1950, or even 1990. You'll see that a lot of it didn't happen. Some did, and some things that people hadn't even considered happened as well. But a lot of it just didn't take place.
Regardless of whether advancement takes place, the link that Vinge assumes between computer hardware performance and computer intelligent does not exist. If true machine intelligence comes about within the next thirty years it will not be as a direct result of improved hardware performance. There aren't any systems out there that aren't intelligent, but could be if we could overclock their processors to 150GHz.
Very interesting, but it still doesn't address the question of whether artificial intelligence that approaches human intelligence, let alone surpasses it is possible. A lot of the ideas of what the future would contain in 100 years a century ago were wrong. In fact the same is true for much shorter periods of time.
Yes, technology will advance in the next X years, but to assume that a necessary part of that advancement is the creation of a machine that is more intelligence than a human is just plain ridiculous. Some would argue that a machine intelligence of that nature is absolutely impossible in the first place (not that I agree with them, but there are rational arguments that suggest this).
I'm basing my view on the state of AI and what we can expect in the future on the results of research I've seen and carried out at some of the top AI departments in the world, so I think I've got a fairly good grasp of the subject matter, and I am 100% happy to say that faster computers will not give us any form of machine intelligence.
Progress in computer hardware has followed an amazingly steady curve in the last few decades [17]. Based largely on this trend, I believe that the creation of greater than human intelligence will occur during the next thirty years.
Progress in computer hardware has followed this curve and continues to do so. Progress in computer intelligence however, hasn't. Computers are still stupid. They can now be stupid more quickly. This isn't going to produce super-human intelligence any time soon.
Dr Vinge reminds me somewhat of that most mocked of AI doomsayers, KevinWarwick.
How can you be so foolish? This isn't anything to do with monopolies. This is just another sign of Microsoft innovating in response to the times, under-promising and over-delivering, as they put it. Never before has anyone come up with this sort of rule, so once more MS are taking a brave step forward. And it's just this sort of brave, plucky, all-American innovation that the evil commie DOJ want to stifle...
...I'm going to recommend a book from (gasp!) Microsoft Press. If ever they institute some sort of formal test before people are let loose on poor innocent computers, Code Complete should be the programmer's equivalent of the Highway Code.
It's full of good advice, and there's nothing in there that's particularly language-dependent. My one complaint would be the lack of solid OO coverage - a book that addresses the same sort of issue for OO languages would be great as well.
For more specific information on MS systems, I think the one text book that covers everything you need to know in sufficient detail is Mr Bunny's Guide to ActiveX - if you haven't read this book and are currently developing for MS platforms, stop now. You can read the book too, but that's entirely optional.
And before I'm inundated by anti-Microsoft zealots accusing me of only putting forward pro-MS books, might I also recommend the remarkable Mr Bunny's Big Cup o' Java, which will teach you everything, something, or even less about Java, and possibly a little about rabbits.
Slashdot Mirror
Sega are still committed to a platform-agnostic stance. In fact their recent TGS presentation stated that at the moment PS2 was their primary target, simply because of the larger userbase. Even that doesn't look likely to swing them much, though.
It's worth pointing out that Sega are still working with other arcade manufacturers on the System 246 board.
Desktop Java is dead? That's news to me, since I'm currently working with plenty of big companies who are still developing desktop Java solutions.
What died was the idea that Java would be the development language of choice for all desktop apps in the future, from diarying systems to desktop publishing. And that's a good thing, IMO.
Not only doesn't it hurt, it doesn't work under Win2K. Or doesn't as of the nightly I'm using, anyway...
Ctrl+F4 to close a tab works fine, though...
$10 Canadian? Bah. I'll offer a bottle of Dr Pepper and a packet of crisps to the first person who can hack into my box located at IP address 127.0.0.1 and delete all the files on it...
Indeed. The article you link says:
"There won't be any coding for Jedi," a representative of the ONS said. "So it won't be called a religion even if 10,000 people do it."
But there *is* a coding for Jedi, so I'd say they were somewhat wrong, yes?
1 hour 45 minutes. Or, as the creator of the system puts it, long enough to cast two spells in Final Fantasy VII. :)
Footnote for the anal: Yes, I am aware that FFVII's spells had relatively short animations. I'm sure he meant GFs.
Where better to start than Sun's own tutorial?
Complete myth? Hardly. Many programs (the majority of real-world code IME) will work straight off. Of course if you're going to have to support it, particularly under heavy use, then you'll expect people to be using it with a specified and tested JVM and platform. They call it WOTE for a reason, you know. ;) And unless you're utterly insane the same is true for cross-platform libraries of any level of complexity. If I tested my program with FooLib 1.2 on Red Hat then I'm not supporting you using FooLib 1.3b on OS X.
Java does allow you "to just write the code once and ship it to all your customers", provided you make it clear that the only supported versions are the ones you've tested against and they run it on other versions/VMs/platforms at their own risk. And anyone who needs to run it on a different platform will be able to, and 99% of the time it will work just fine provided the code was well written in the first place. The same can never be true of binary distributions using shared libraries.
Of course WORA doesn't work perfectly - it's one of the first things I point out when teaching Java. But you seem to be painting a picture of a world where Java code needs to be carefully targetted at particular platforms and will fall over if you try to run it elsewhere, and that's even further from the truth.
Which does nothing for those users who aren't happy recompiling from scratch, and doesn't do much to appease the boss/lawyers/project manager who is hung up on the idea that it's a bad plan to let customers see our source code in any form.
Not just old news, but positively antique. Here's a link to a C&VG article complete with screenshots of the PS2/XBox versions, which were announced long before the GC one. Also an IGN preview of the PS2 version.
Okay, let's look at those arguments again.
1) Java is slow because Java is slow.
Cool. I'm convinced, but some would view this as a slightly circular argument.
2) Java is slow because some libraries have already been written in other languages.
You make a good case here. But again, some might frown and accuse that argument of being a bit of a non sequitur.
2) Java is slow because some people who don't use it don't know how to use it.
Again, 100% solid. But I fear some might be slightly wary of the utter irrelevance of what you're saying and still other might suggest that the fact you can't count to three makes you a less than optimal judge of speed of numerical computation...
Because then you either have to recompile for all platforms and provide binaries for all of them (along with suitable installation instructions/programs) or you have to make your source available. The former is a pain, since the whole aim of writing truly cross-platform software is that it can run on any platform, not just those you happen to have development tools for. The latter may not be desirable (not all software is open source, you know) and causes hassle for people who don't feel they have the skill to compile code from source and install it.
Well, you asked...
I'm afraid your code is pretty much useless for testing Java vs C++ performance. If you'd checked out the Sun FAQ on benchmarking Hotspot you'd have seen something like this:
But it still shows that the host is receiving the mails and *someone* is reading them. The solution for link-following is to remove anything from the link which might provide information about who's responding (anything that looks like a unique identifier, in particular a reference to your e-mail address). For responding, perhaps the best approach is to forge your own headers (fighting fire with fire) to give the impression of responding from an account that genuinely *is* invalid.
So rely on personal recommendations and pick up the comics in collected graphic novel format rather than on a monthly basis.
Some series that I'd recommend:
That's a fair point to a certain extent, but the tie isn't particularly direct in this case. If my company can't compete because of restrictive IP law, then I don't have any resources to buy expensive business lunches, but I wouldn't have called this article "The end of expensive business lunches?" either...
Perhaps that's a slight oversimplification, I suppose, because stifling the ability to compete tends to lead to monopolies or near-monopolies, which in turn *does* stifle the need for innovation somewhat. But the more direct problem is the destruction of the right to compete, and the abuse of draconian IP law we're beginning to see.
This isn't a question of 'the end of innovation' at all, except possibly in a Microsoftesque "Help! Stop the bad man! He's depriving me of my ability to innovate!" sort of a way. The issue is an entirely separate one, that of fair use and the purpose and extent of IP rights.
There's nothing to stop people coming up with new and better ways of carrying out these same tasks, or entirely different tasks - the constraints that we're looking at here are primarily on reverse engineering, which has never really struck me as being an integral part of innovation...
The first such anti-virus virus, Den_Zuko, was discovered in 1988. Check out this article on VNUnet, which has more info on the history of such software and why it's a bad idea.
More recently, the Linux.Cheese.Worm has done similar things for Linux users infected by the Linux.Lion.Worm.
Sometimes they boil down to brute force, but not always. Incomplete information makes brute-forcing things difficult (that's the main problem with Bridge, rather than any randomising element). In fact dealing with random elements in some situations can actually be almost as simple as non-random games - maybe even simpler, since the computer is going to have the edge in calculating the probabilities of particular events taking place.
There are plenty of evolutionary approaches to generating AI similar to the one you describe for Quake. I'd be interested in seeing if a good Quake bot could be generated using GP...
But that's exactly why chess is so uninteresting. It generally boils down to a question of making a better brute force algorithm. Other games are far more interesting from an AI perspective - Bridge is a very good one to look at.
One of the most interesting AI players I've seen in recent years is the Angband borg, which plays the roguelike game Angband with a relatively high level of skill (although it's far too much of a coward for my liking...)
But very rarely in the ways you expect. Look at the predictions people were making for life in the year 2000 back in 1800, or 1900, or 1950, or even 1990. You'll see that a lot of it didn't happen. Some did, and some things that people hadn't even considered happened as well. But a lot of it just didn't take place.
Regardless of whether advancement takes place, the link that Vinge assumes between computer hardware performance and computer intelligent does not exist. If true machine intelligence comes about within the next thirty years it will not be as a direct result of improved hardware performance. There aren't any systems out there that aren't intelligent, but could be if we could overclock their processors to 150GHz.
Very interesting, but it still doesn't address the question of whether artificial intelligence that approaches human intelligence, let alone surpasses it is possible. A lot of the ideas of what the future would contain in 100 years a century ago were wrong. In fact the same is true for much shorter periods of time.
Yes, technology will advance in the next X years, but to assume that a necessary part of that advancement is the creation of a machine that is more intelligence than a human is just plain ridiculous. Some would argue that a machine intelligence of that nature is absolutely impossible in the first place (not that I agree with them, but there are rational arguments that suggest this).
I'm basing my view on the state of AI and what we can expect in the future on the results of research I've seen and carried out at some of the top AI departments in the world, so I think I've got a fairly good grasp of the subject matter, and I am 100% happy to say that faster computers will not give us any form of machine intelligence.
Progress in computer hardware has followed this curve and continues to do so. Progress in computer intelligence however, hasn't. Computers are still stupid. They can now be stupid more quickly. This isn't going to produce super-human intelligence any time soon.
Dr Vinge reminds me somewhat of that most mocked of AI doomsayers, Kevin Warwick.
How can you be so foolish? This isn't anything to do with monopolies. This is just another sign of Microsoft innovating in response to the times, under-promising and over-delivering, as they put it. Never before has anyone come up with this sort of rule, so once more MS are taking a brave step forward. And it's just this sort of brave, plucky, all-American innovation that the evil commie DOJ want to stifle...
...I'm going to recommend a book from (gasp!) Microsoft Press. If ever they institute some sort of formal test before people are let loose on poor innocent computers, Code Complete should be the programmer's equivalent of the Highway Code.
It's full of good advice, and there's nothing in there that's particularly language-dependent. My one complaint would be the lack of solid OO coverage - a book that addresses the same sort of issue for OO languages would be great as well.
Code Complete at Amazon
For more specific information on MS systems, I think the one text book that covers everything you need to know in sufficient detail is Mr Bunny's Guide to ActiveX - if you haven't read this book and are currently developing for MS platforms, stop now. You can read the book too, but that's entirely optional.
And before I'm inundated by anti-Microsoft zealots accusing me of only putting forward pro-MS books, might I also recommend the remarkable Mr Bunny's Big Cup o' Java, which will teach you everything, something, or even less about Java, and possibly a little about rabbits.
Why go for third party add-ons? You do know there's support for regular expressions in Java these days?