Forget the Buzzword
on
Web 3.0
·
· Score: 2, Interesting
I don't understand why people have such a distaste for all things labeled 'Web 2.0.' I'm not a fan of buzzwords, and there's nothing I hate more than a middle manager with a head full of technologies he knows nothing about. But let's forget about all that and think about what it is we are trying to accomplish. I don't know about you, but I would like to make better web sites. Web sites with better usability.
Let's face it, Tim Berners-Lee never fathomed the web would be used the way we use it today. The HTML protocol was just not made to support rich e-mail clients that check our spelling as we type, or maps that allow us to drag them around transparently gathering information from the server in the background without refreshing the page. I don't see how anybody could disagree with the fact that these features enhance a user's experience on the web, and they would simply not be possible without AJAX or some other still undiscovered technology.
The sooner we stop complaining about people improperly using 'Web 2.0' buzzwords and start thinking about what this technology gives us as web developers and how we can embrace it and enhance it, the better off we will be, and the better off the users of our sites will be.
Are you implying that the Java language is not modern, and the Ruby language is?? Let's remember that Ruby was introduced in 1995 while Java was introduced in 1994.
I find it unfortunate that most of the 'newbie' tutorials jump right in to how to generate scaffold code. This code is a bit unmanageable and hard to modify, but I think it has a certain 'WOW' factor associated with it. Once the novelty wears off and you need to develop real applications, you will rarely use the generated scaffold code, and the code you write within the framework will certainly be manageable.
Where I think Rails comes out on top is the fact that it includes a full blown ORM and an MVC implementation under the same, configuration-less framework. No more XML. No more duplicate java beans...More of this on my blog if interested.
I'm trying to grasp what the implications are of this. Let's take Shor's algorithm as an example. It is my understanding that the Quantum Fourier Transform (QFT) is applied to the result of the algorithm to peak the probability amplitudes, which will help the result to collapse into the correct state when measured. So does this mean that the QFT will not need to be applied, and the result of Shor's algorithm can be read with 100% accuracy?
I think the biggest problem is that the average high school senior actually beleives that going into computer science means that he is going to learn how to make web pages.
Why is it a surprise that an Intel compiler will optimize code to an Intel chip. If they intentionally bloated the machine code for AMD processors, then that is wrong...but is it wrong for Intel to not learn the inner workings of an AMD chip and not optimize its compiler for that chip??
I think Apple is banking on Intel helping them to sell computers at a rate comparable to Dell. I think more people would switch to an intel mac instead of an IBM mac after using a wintel machine for 15 years, since there would exist some familiarity. Also, the mac faithful are going to buy a mac no matter what kind of processor is sitting inside it.
One of the main reasons for using text messaging is to communicate with someone without putting a phone up to your ear. Are they suggesting that the morse code be printed on the screen of the phone?
I think what we need to realize here is that just because the technology will be available to place in our home, doesn't mean we can reproduce the same or even a similar effect in our home. The acoustics of a standard living room are dramatically different than that of a movie theater.
The article states that MontaVista has ported its real-time version of Linux to run on the T-Engine. Additionally, Windows CE and Java have also been ported. However, running these systems on the T-Engine is known as running 'guest operating systems', which is a fancy word for 'translated operating sytems'.
In Computer Science compilation produces machine code. javac does not.
Please refer to the following paragraph taken from wikipedia:
"Most compilers translate source code written in a high level language to object code or machine language that may be directly executed by a computer or a virtual machine."
Additionally, please refer to the description of javac taken from the javac man page:
javac - Java compiler
I am not stating that the JVM builds an executable and then runs it. That is surely untrue. I was just trying to explain the difference between the inner workings of a compiler verses an interpreter. The main point I was trying to make was that a compiler will hold on to the results of parsing, type checking, etc. where as an interpreter will not.
When you compile your java code into a.class file using javac, this is producing byte code. The byte code is then run on a JVM that will further compile the byte code into machine code. Let me re-iterate, NOTHING other than machine code can ultimately run on a CPU. There is no java byte code engine built into the processor. Python and Perl are fast on startup because they simply traverse the parse tree and generate machine code as they go. They do not need to worry about storing the results of the parse tree.
Another idea would have been to have it 'COMPILE' code into native just like a c compiler.
The JVM does convert the byte code into native machine code. All programs need to be converted to native machine code in order to run.
Sun maybe should have kept java just an interpretor like PYTHON and PEARL and then people might not complain about speed.
I'm quite certain that the speed would be much worse if the JVM simply interpreted the byte code rather than compiling it. It seems that you are a bit confused about the difference between an interpreter and a compiler. An interpreter will run through all of the steps of a compiler on the fly, but will not store the results of the parse tree, type checking, etc. This means that an identical piece of code that is executed 1000 times in an interpreted language will be re-parsed and re-type checked 1000 times. Java is a bit smarter than that. It will do the compilation on the fly, AND store the results for the next time it is needed. (Which is why some java programs seem to require more an more memory as they are executed.)
What I think would make a lot of people happy is if Sun released a more tradional compiler. Such compilers do exist (like GCJ for example,) but they do not support all of the Java libraries (As far as I know, Swing is not supported in any of these compilers.) I guess this would break the write once, run anywhere view that Sun has had for the past ten years, but I think we all know that that will never be truly achieved.
You are missing the boat on this one. The point isn't whether or not we can solve a small trivial problem. The point is if it is possible to solve, in polynomial time, a problem in which the complexity of the best known algorithm increases exponentially with the size of the input.
Instead of just cities, lets use network nodes between cities. Lets say I wanted to know the fastest (in terms of bandwith or distance or whatever, assume some cost of each link,) way to route packets through every major city in the world. Think about all of the combinations of routers you could potentially use. (Do a traceroute for some short distance like 20 miles and see how many routers your packets hit.) This real world problem could take a lifetime (or much longer) to solve on today's computers.
But the most important implication is that since the travelling salesman problem is known to be NP complete, Then a polynomial time solution would mean a polynomial time solution to ALL of the problems known to be NP complete (This set of problems is large and includes many interesting problems, Google NP complete to get an idea of what could be accomplished here.)
but in quantum computing we can run all paths in parallel so we solve all possible combinaisons at once, which becomes polynomial.
This is parially true, and is exploited in Shor's factoring algorithm. But note that Shor's algorithm would not work if it relied only on doing brute force calculations in parallel. Shor's algorithm works because it reduces the problem of factorization to a series of steps that can be done in parallel, then passed through the QFT to yeild the correct result with high probability. You could not, on a quantum computer, factor a large number by trying all combinations of numbers in parallel, because you would have no way (at least no way that is known) to arrive at the answer with high probability...you would just get some random answer as you described in your book analogy.
The point here is that no one has been able to reduce an NP problem to a series of steps that can be run in parallel on a quantum computer to yield an answer with high probability. If you can do this, you will be very rich and famous
Slashdot Mirror
I don't understand why people have such a distaste for all things labeled 'Web 2.0.' I'm not a fan of buzzwords, and there's nothing I hate more than a middle manager with a head full of technologies he knows nothing about. But let's forget about all that and think about what it is we are trying to accomplish. I don't know about you, but I would like to make better web sites. Web sites with better usability.
Let's face it, Tim Berners-Lee never fathomed the web would be used the way we use it today. The HTML protocol was just not made to support rich e-mail clients that check our spelling as we type, or maps that allow us to drag them around transparently gathering information from the server in the background without refreshing the page. I don't see how anybody could disagree with the fact that these features enhance a user's experience on the web, and they would simply not be possible without AJAX or some other still undiscovered technology.
The sooner we stop complaining about people improperly using 'Web 2.0' buzzwords and start thinking about what this technology gives us as web developers and how we can embrace it and enhance it, the better off we will be, and the better off the users of our sites will be.
Are you implying that the Java language is not modern, and the Ruby language is?? Let's remember that Ruby was introduced in 1995 while Java was introduced in 1994.
I find it unfortunate that most of the 'newbie' tutorials jump right in to how to generate scaffold code. This code is a bit unmanageable and hard to modify, but I think it has a certain 'WOW' factor associated with it. Once the novelty wears off and you need to develop real applications, you will rarely use the generated scaffold code, and the code you write within the framework will certainly be manageable.
Where I think Rails comes out on top is the fact that it includes a full blown ORM and an MVC implementation under the same, configuration-less framework. No more XML. No more duplicate java beans...More of this on my blog if interested.
I'm trying to grasp what the implications are of this. Let's take Shor's algorithm as an example. It is my understanding that the Quantum Fourier Transform (QFT) is applied to the result of the algorithm to peak the probability amplitudes, which will help the result to collapse into the correct state when measured. So does this mean that the QFT will not need to be applied, and the result of Shor's algorithm can be read with 100% accuracy?
I wonder if this would help advance any photon-based quantum computer implementations. Any thoughts ?
Dvorak's 1984 view of the Mac
"The Macintosh uses an experimental pointing device called a 'mouse'. There is no evidence that people want to use these things."
enough said
I think the biggest problem is that the average high school senior actually beleives that going into computer science means that he is going to learn how to make web pages.
This is proof that your site doesn't have to be pretty to be profitable.
Talk about recursive self reference - I think this study is best suited for you number theorists out there!
What type of more-advanced technology do you suggest?
No...I'm simply stating that I wouldn't expect Intel to go out of their way to make a compiler that optimizes code for a competitor's chip.
AMD claims that they have intentionally disallowed AMD chips to use the same optimizations as Intel uses
Don't you suppose that the optimizations for AMD differ from the optimizations for Intel?
Why is it a surprise that an Intel compiler will optimize code to an Intel chip. If they intentionally bloated the machine code for AMD processors, then that is wrong...but is it wrong for Intel to not learn the inner workings of an AMD chip and not optimize its compiler for that chip??
I think Apple is banking on Intel helping them to sell computers at a rate comparable to Dell. I think more people would switch to an intel mac instead of an IBM mac after using a wintel machine for 15 years, since there would exist some familiarity. Also, the mac faithful are going to buy a mac no matter what kind of processor is sitting inside it.
One of the main reasons for using text messaging is to communicate with someone without putting a phone up to your ear. Are they suggesting that the morse code be printed on the screen of the phone?
I think what we need to realize here is that just because the technology will be available to place in our home, doesn't mean we can reproduce the same or even a similar effect in our home. The acoustics of a standard living room are dramatically different than that of a movie theater.
The article states that MontaVista has ported its real-time version of Linux to run on the T-Engine. Additionally, Windows CE and Java have also been ported. However, running these systems on the T-Engine is known as running 'guest operating systems', which is a fancy word for 'translated operating sytems'.
Please refer to the following paragraph taken from wikipedia:
Additionally, please refer to the description of javac taken from the javac man page: I am not stating that the JVM builds an executable and then runs it. That is surely untrue. I was just trying to explain the difference between the inner workings of a compiler verses an interpreter. The main point I was trying to make was that a compiler will hold on to the results of parsing, type checking, etc. where as an interpreter will not.
I think you may be mis-interpreting what I am saying. I am merely stating the obvious that only machine code can ultimately run on a processor.
When you compile your java code into a .class file using javac, this is producing byte code. The byte code is then run on a JVM that will further compile the byte code into machine code. Let me re-iterate, NOTHING other than machine code can ultimately run on a CPU. There is no java byte code engine built into the processor. Python and Perl are fast on startup because they simply traverse the parse tree and generate machine code as they go. They do not need to worry about storing the results of the parse tree.
Another idea would have been to have it 'COMPILE' code into native just like a c compiler.
The JVM does convert the byte code into native machine code. All programs need to be converted to native machine code in order to run.
Sun maybe should have kept java just an interpretor like PYTHON and PEARL and then people might not complain about speed.
I'm quite certain that the speed would be much worse if the JVM simply interpreted the byte code rather than compiling it. It seems that you are a bit confused about the difference between an interpreter and a compiler. An interpreter will run through all of the steps of a compiler on the fly, but will not store the results of the parse tree, type checking, etc. This means that an identical piece of code that is executed 1000 times in an interpreted language will be re-parsed and re-type checked 1000 times. Java is a bit smarter than that. It will do the compilation on the fly, AND store the results for the next time it is needed. (Which is why some java programs seem to require more an more memory as they are executed.)
What I think would make a lot of people happy is if Sun released a more tradional compiler. Such compilers do exist (like GCJ for example,) but they do not support all of the Java libraries (As far as I know, Swing is not supported in any of these compilers.) I guess this would break the write once, run anywhere view that Sun has had for the past ten years, but I think we all know that that will never be truly achieved.
You may have heard of NP completeness, but you obviously have no idea what it is.
You are missing the boat on this one. The point isn't whether or not we can solve a small trivial problem. The point is if it is possible to solve, in polynomial time, a problem in which the complexity of the best known algorithm increases exponentially with the size of the input.
Instead of just cities, lets use network nodes between cities. Lets say I wanted to know the fastest (in terms of bandwith or distance or whatever, assume some cost of each link,) way to route packets through every major city in the world. Think about all of the combinations of routers you could potentially use. (Do a traceroute for some short distance like 20 miles and see how many routers your packets hit.) This real world problem could take a lifetime (or much longer) to solve on today's computers.
But the most important implication is that since the travelling salesman problem is known to be NP complete, Then a polynomial time solution would mean a polynomial time solution to ALL of the problems known to be NP complete (This set of problems is large and includes many interesting problems, Google NP complete to get an idea of what could be accomplished here.)
Lets say that the certain size is on the order of 10 ^ 10000000000000000000000000000000000.
If we are merely concerning ourselves with travelling salesman problems of a small, trivial size, then we wouldn't be having this discussion.
but in quantum computing we can run all paths in parallel so we solve all possible combinaisons at once, which becomes polynomial.
This is parially true, and is exploited in Shor's factoring algorithm. But note that Shor's algorithm would not work if it relied only on doing brute force calculations in parallel. Shor's algorithm works because it reduces the problem of factorization to a series of steps that can be done in parallel, then passed through the QFT to yeild the correct result with high probability. You could not, on a quantum computer, factor a large number by trying all combinations of numbers in parallel, because you would have no way (at least no way that is known) to arrive at the answer with high probability...you would just get some random answer as you described in your book analogy.
The point here is that no one has been able to reduce an NP problem to a series of steps that can be run in parallel on a quantum computer to yield an answer with high probability. If you can do this, you will be very rich and famous