And XML will allow you to write these web forms! Use XML/XSL for IE, and XML XSLT'd into pure standard HTML for Netscape... you can do it using CGI scripts, ASP, Perl and lots of other ways, and you only have to make ONE XML document. The scripts check which browser is being used, and automatically outputs it as required. It's easy as pie.
Good grief... you've been working with XML for six months? And you think "XML is basically a big ol' delimited text file. The only things separating it from a 30-year old text file is the fact that it's hierarchical and the fact that there are parsers that let you navigate the tree structure easily"? I don't believe you HAVE been working with XML for six months and think that. XML allows the context to be marked up along with data. Yes, XML is text. That's good. But the power of XML is in the contextual information that goes with the data. SGML and it's baby XML allow data exchange that we've never been able to do before, or if there were ways, it was proprietary, or too complex to use effectively. Yes, XML is overhyped for what it can do TODAY. But in a couple of years, that will not be HYPE. There are standard XML dialects available. People will use them, so they don't have to make their own. Schemas will become standardized. Right now, they are not, but that means that the stupid people who are wasting time and money going against other people's DTDs will not be able to exchange XML effectively without writing XSLTs to convert data between companies and people. XML is extensible, which means in the future when a schema is out-dated, you will be able to extend it, without breaking the old XML. XSLT will be able, in the future, to automatically convert XML between schemas - all you'll have to do is map the elements and attributes to the new/other schema. It will be EASY to convert between to different schemas. Even between languages. Say you have in XML, Bob Smith which tags the DTD defines, and you want to talk to some French XML-using program that stores contacts: Bob Smith All you need is to run an XSLT (XSL-Transformation) from the English to French tags, using a simple visual editor that links the tags. You could also combine tags, like and into one like Bob Smith for other schemas and programs that use XML for different uses. Once you establish the transformation, you don't have to do it again for that data source. That means time is saved massively. So even if there isn't full agreement on the way to mark up data, it will still be a huge leap for data transfer. Not only that, but XPath and related specs describe ways to transfer data, access it from any point and element type, and other things that are FAR beyond what we are able to do today without massive coding time, and even then, the program that does the parsing is only good for the data source you mapped it to, because there is no semantic tags and context to determine what that data MEANS. Even if a human has to look at the tag names to know what the data is supposed to mean, we have still saved time. But because of XML related technologies, most of this can be automatic. You can get a list of all elements, attributes, CDATA, processing instructions, displayed any way you like, to determine what to do, and if the schemas are the same, you don't even have to do that. Microsoft plans on making standard schemas. That's what they are going to do, and yay for that, because we need 'em. But most of the standard schemas and DTDs will be made in B2B. The big companies will define schemas that smaller companies will use to be able to be suppliers, partners, distributers, etc.... As long as the schemas are good, and encompass the transactions that take place, it doesn't matter who makes them. The smaller companies will be able to extend schemas or map to their own specific schemas easily, in co-operation with their business partners, or alone. It doesn't matter. It's just whether it will be easy for them. I believe it will be, once the tools become available. It will be as easy as writing an email message, which also uses standard message formats, and which people argued wouldn't happen once upon a time.
The reason why VB is not used for those critical applications (and you are wrong about it being desktop only, there are TONS of VB and SQL Server developers who write client server and n-tier apps, that do the job that needs to be done, in less development time than C++ and Java), is that it's not object oriented and doesn't allow free threading like C++ and Java. Visual Basic 7 will have OOP power. You'll see people writing critical applications after VB7 comes out. You may say no, because VB is still not as low-level as C++ or Java, but that's just fine, because VB developers can switch over and make C++ COM+ objects, and use EJBs for the critical parts, and VB for the less-than-critical parts. The languages will mix and match abilities. Since Visual Studio 7 will be an IDE for languages and web development, the components and Web Services will be accessed as if they are native, allowing all kinds of flexibility in your applications. C# sounds like it will allow us to write Java-like programs, but that's just because ANY language you write today SHOULD be based on the good things that other languages provide, like garbage collection, and security built in like Java allows. Just because it is a language designed for the internet doesn't mean they are stealing Java's ideas in the sense that people here make it out. It only makes sense to take Java's benefits. Java took C++'s benefits and culled the good things that other languages of the past brought to mind. C# is obviously being designed for the "programmable" internet, something Java wasn't designed for. It is also designed for Web Services, a concept that Sun is pushing as well as Oracle and many of the big companies that pretend they are all for the OpenSource community, but if you watched Scott McNealy at JavaOne you would realize all Sun gives a damn about is MONEY! They say so, if you just listen to the web casts. Everyone here is acting like Sun is our friend. Bull. That's so untrue, they would LOVE to be in MS's shoes (pre-trial that is). At least we know what MS does with it's power. They built the best browser in the world, FOR Windows. You all think they should build a browser that works as well for Solaris??? That's retarded! That's called stupidity. The reason is, and EVERYbody here should realize by now, that the browser is a platform and will become a tool that accesses components to make customized operating systems in the future, no matter what kind of hardware you are using. You'll be able to pick and choose your components, and design your own OS. If you see that MS's component that controls your video sucks for some reason, then you can use a EJB to do the same, or build your own. All MS wants is to have control over the platform that utilizes these components. Sun does too. So do all the companies in the world. So they will all make their own, and they will run on application servers, with clients on the devices that access the servers. That's what I think will happen. C#VM is made supposedly to allow this to happen more easily, and be language agnostic. That means you should be able to run your old code using this VM. I don't see the problem. We could all write MS, and ask them to please make this available in a license form like Java is, or better. Instead of just making fun and saying it won't work, and VB people are lame beginners - which has nothing really to do with C# anyways. BAH! Java is overrated, and everyone knows it. You just can't admit it. VB is overrated too. They are all shitty. I am just glad to hear about a NEW language that is made to deal with these things. You all should be too, and forget about you biased attitudes.
Beg to differ on this, QC allows something called superimposition, that has no parallel in ordinary computation. This allows for bits (actually called qubits in QC) to hold more than one state/value at any time. Through interference, and the like, we get a result (or in the case of this new algorithm, we get a sampling). This is by no means the only difference.
If you checked out the manufacturer's site, you might note that the c3d's are not read the same way as DVDs and CDs. Instead of reflecting light off the media, the flourescent markers are read simultaneously (10 layers - right away a tenfold increase in speed), but the method for reading must also be very different, which I suppose must result in an additional tenfold increase in speed. Really, I don't doubt this at all; it's well within the realm of possibility. As for the speed of the bus, well, I don't know what they are using to test this device, but it must be new, but also within the realm of possibility; however, I don't think that they made any claims to doing anything but accessing the data at 1G/sec. Their test systems were probably designed specifically for the C3D, which is why they are looking for companies to help them develop this stuff. They did say after all, that they want to ship the product in about 12 months... obviously the hardware controllers, and prob. buses (and manufacturing of the media) is just not ready yet. But what do I know?
Slashdot Mirror
And XML will allow you to write these web forms! Use XML/XSL for IE, and XML XSLT'd into pure standard HTML for Netscape ... you can do it using CGI scripts, ASP, Perl and lots of other ways, and you only have to make ONE XML document. The scripts check which browser is being used, and automatically outputs it as required. It's easy as pie.
Good grief ... you've been working with XML for six months? And you think "XML is basically a big ol' delimited text file. The only things separating it from a 30-year old text file is the fact that it's hierarchical and the fact that there are parsers that let you navigate the tree structure easily"? I don't believe you HAVE been working with XML for six months and think that. XML allows the context to be marked up along with data. Yes, XML is text. That's good. But the power of XML is in the contextual information that goes with the data. SGML and it's baby XML allow data exchange that we've never been able to do before, or if there were ways, it was proprietary, or too complex to use effectively. Yes, XML is overhyped for what it can do TODAY. But in a couple of years, that will not be HYPE. There are standard XML dialects available. People will use them, so they don't have to make their own. Schemas will become standardized. Right now, they are not, but that means that the stupid people who are wasting time and money going against other people's DTDs will not be able to exchange XML effectively without writing XSLTs to convert data between companies and people. XML is extensible, which means in the future when a schema is out-dated, you will be able to extend it, without breaking the old XML. XSLT will be able, in the future, to automatically convert XML between schemas - all you'll have to do is map the elements and attributes to the new/other schema. It will be EASY to convert between to different schemas. Even between languages. Say you have in XML, Bob Smith which tags the DTD defines, and you want to talk to some French XML-using program that stores contacts: Bob Smith All you need is to run an XSLT (XSL-Transformation) from the English to French tags, using a simple visual editor that links the tags. You could also combine tags, like and into one like Bob Smith for other schemas and programs that use XML for different uses. Once you establish the transformation, you don't have to do it again for that data source. That means time is saved massively. So even if there isn't full agreement on the way to mark up data, it will still be a huge leap for data transfer. Not only that, but XPath and related specs describe ways to transfer data, access it from any point and element type, and other things that are FAR beyond what we are able to do today without massive coding time, and even then, the program that does the parsing is only good for the data source you mapped it to, because there is no semantic tags and context to determine what that data MEANS. Even if a human has to look at the tag names to know what the data is supposed to mean, we have still saved time. But because of XML related technologies, most of this can be automatic. You can get a list of all elements, attributes, CDATA, processing instructions, displayed any way you like, to determine what to do, and if the schemas are the same, you don't even have to do that. Microsoft plans on making standard schemas. That's what they are going to do, and yay for that, because we need 'em. But most of the standard schemas and DTDs will be made in B2B. The big companies will define schemas that smaller companies will use to be able to be suppliers, partners, distributers, etc.... As long as the schemas are good, and encompass the transactions that take place, it doesn't matter who makes them. The smaller companies will be able to extend schemas or map to their own specific schemas easily, in co-operation with their business partners, or alone. It doesn't matter. It's just whether it will be easy for them. I believe it will be, once the tools become available. It will be as easy as writing an email message, which also uses standard message formats, and which people argued wouldn't happen once upon a time.
The reason why VB is not used for those critical applications (and you are wrong about it being desktop only, there are TONS of VB and SQL Server developers who write client server and n-tier apps, that do the job that needs to be done, in less development time than C++ and Java), is that it's not object oriented and doesn't allow free threading like C++ and Java. Visual Basic 7 will have OOP power. You'll see people writing critical applications after VB7 comes out. You may say no, because VB is still not as low-level as C++ or Java, but that's just fine, because VB developers can switch over and make C++ COM+ objects, and use EJBs for the critical parts, and VB for the less-than-critical parts. The languages will mix and match abilities. Since Visual Studio 7 will be an IDE for languages and web development, the components and Web Services will be accessed as if they are native, allowing all kinds of flexibility in your applications. C# sounds like it will allow us to write Java-like programs, but that's just because ANY language you write today SHOULD be based on the good things that other languages provide, like garbage collection, and security built in like Java allows. Just because it is a language designed for the internet doesn't mean they are stealing Java's ideas in the sense that people here make it out. It only makes sense to take Java's benefits. Java took C++'s benefits and culled the good things that other languages of the past brought to mind. C# is obviously being designed for the "programmable" internet, something Java wasn't designed for. It is also designed for Web Services, a concept that Sun is pushing as well as Oracle and many of the big companies that pretend they are all for the OpenSource community, but if you watched Scott McNealy at JavaOne you would realize all Sun gives a damn about is MONEY! They say so, if you just listen to the web casts. Everyone here is acting like Sun is our friend. Bull. That's so untrue, they would LOVE to be in MS's shoes (pre-trial that is). At least we know what MS does with it's power. They built the best browser in the world, FOR Windows. You all think they should build a browser that works as well for Solaris??? That's retarded! That's called stupidity. The reason is, and EVERYbody here should realize by now, that the browser is a platform and will become a tool that accesses components to make customized operating systems in the future, no matter what kind of hardware you are using. You'll be able to pick and choose your components, and design your own OS. If you see that MS's component that controls your video sucks for some reason, then you can use a EJB to do the same, or build your own. All MS wants is to have control over the platform that utilizes these components. Sun does too. So do all the companies in the world. So they will all make their own, and they will run on application servers, with clients on the devices that access the servers. That's what I think will happen. C#VM is made supposedly to allow this to happen more easily, and be language agnostic. That means you should be able to run your old code using this VM. I don't see the problem. We could all write MS, and ask them to please make this available in a license form like Java is, or better. Instead of just making fun and saying it won't work, and VB people are lame beginners - which has nothing really to do with C# anyways. BAH! Java is overrated, and everyone knows it. You just can't admit it. VB is overrated too. They are all shitty. I am just glad to hear about a NEW language that is made to deal with these things. You all should be too, and forget about you biased attitudes.
They may be taken, but they don't belong to MS.
Beg to differ on this, QC allows something called superimposition, that has no parallel in ordinary computation. This allows for bits (actually called qubits in QC) to hold more than one state/value at any time. Through interference, and the like, we get a result (or in the case of this new algorithm, we get a sampling). This is by no means the only difference.
MSNBC's article points out that 7 qubits have been linked together, but we need 25 for such a search as Grover's to be possible.
Check out the site and you'll see they are making the drives backwards comp.
If you checked out the manufacturer's site, you might note that the c3d's are not read the same way as DVDs and CDs. Instead of reflecting light off the media, the flourescent markers are read simultaneously (10 layers - right away a tenfold increase in speed), but the method for reading must also be very different, which I suppose must result in an additional tenfold increase in speed. Really, I don't doubt this at all; it's well within the realm of possibility. As for the speed of the bus, well, I don't know what they are using to test this device, but it must be new, but also within the realm of possibility; however, I don't think that they made any claims to doing anything but accessing the data at 1G/sec. Their test systems were probably designed specifically for the C3D, which is why they are looking for companies to help them develop this stuff. They did say after all, that they want to ship the product in about 12 months ... obviously the hardware controllers, and prob. buses (and manufacturing of the media) is just not ready yet. But what do I know?