Can you please explain "how we instantly know?" I see this bandied about. If by "instantly know" there is an observable change in the particles pair, that seems to me a form of FTL transmission. We each send a series of entangled particles to/from a distant location. We carefully time observing the particles or not observing the particles so as to send bits of information. I would think that is not possible.

Otherwise, if you mean "instantly know" by simply knowing that the other particle must be the opposite of what you have observed with a high statically likelihood, it sounds like not spooky action at a distance but what Frango Assado saids is Bohm's interpretation. I guess I am having a hard time understanding how something can be spooky action at a distance without transmitting information.

I have never been able to find a place to answer this idea: Is it possible that quantum entanglement is actually just fixing two particles to a stable spin?

(If I understand it correctly) If a person takes two entangled particles and take each one to a place farther than it takes the speed of light to travels, each can be measured faster than it would take for light to travel to "inform the other" of its state, yet each particle will always have the opposite of the other's state. The kicker for me is: one cannot know what state each will be, only that they will be opposites. This is why there is no information transfer. There is a correlation of behavior, not an inducement of behavior.

It seems to me this can be explained with the mind-experiment of replacing the two particles with a pair of coins. The two would naturally align and "stick," although in opposite directions, such as heads to heads or tails to tails. Quantum entanglement means the reduction of "noise" from space itself. If no longer being disturbed by interactions with the universe, physics would suggest they would continue to keep the the same momentum. If they are separated without being disturbed, distance is not relevant. Whenever, wherever, and as long as they are "viewed the same way" they will have opposite ends showing because they have kept the same rate of momentum. The catch is this is happening in more dimensions than our normal three, so the spin doesn't make sense in classical term.

P.S. I am an armchair physicist. I apologize for any misuse of a term.

The very point of a patent is to publicly give out your understanding of an implementation for protection for a period of time from anyone else being able to use that implementation.

Specifically, if a person writes code that uses a patent, Microsoft cannot claim ownership of the code (because it is copyrighted), but Microsoft can sue you to prevent you from using the code because they own the idea.

It is a misunderstanding to say that the laws are coming into conflict. As an example, if it was against the law to drive less than 50 mph and above 40 mph on a road, you are guilty of one or both for driving on the road. Law is about one question: which, if any laws, have you violated. For those with which you are guilty, what should be your punishment. This is why the law is about people finding people guilty or not guilty. Innocence is not a part of law. Unfortunately, laws that are astutely obvious get struck down because there is enough outrage.

The DMCA was written specifically to kill fair use without actually striking down fair use. In an admiring-an-evil-genus way, I'm impressed withe DMCA.

The reason why you are confused is because you're used to a compiled environment, where every call is an immediate action. A C/C++ program must be coded to (i.e. explicitly) deletes memory references. If you explicitly delete, you can also tie in other explicit behavior; therefore, it's common "duh this is how you do it" practice to tie "finalize" behavior to the object's deletion. But remember, it is your program's logic that has decided when to get rid of it. In a GC environment, deletion is no longer an explicit event--it is autonomous, automatic; therefore, it is illogical to tie anything to the deletion of the memory reference to anything other than deletion of the memory reference. There is no connection between when the object was dereferenced and when the GC chooses to clean up the reference. Generally, the only events that are tied to the finalize method are sanity checks to make sure non-Java code knows the reference is going away. Put differently: in Java, memory deallocation is not a part of the running logic of your program and so the program must create an explicit method of releasing resources in your program's logic. In other words, do what you were doing before, just don't call it finalize. That's a gripe of mine about Java: It confuses C++ users who are used to using the function finalize because Java gives finalize a specific purpose that cannot act the same way.

Having worked with Rails for a year, I have found listening to people who talk on any web forum about any language draws out nothing but hyperbole. So, I would take most of what is said here with a grain of salt since it is obvious that most of the people commenting here are stating "truths" from religious wars.

The framework operates a multiple levels. At the highest, a complete page can be generated from scaffold that automatically hook model to controller to view. I have found the scaffolds to be lack luster. From a completely database-centric view, there are some neat things that are automatically generated. For instance, verification methods in models are use to display errors on the page and mark input fields in red. My personal experience has found scaffolds to be lackluster.

Most well-designed applications revolve around the application's use, not its internal data representation. Using scaffold strongly ties the interface to data representation which creates the situation that "the user can be wrong." You see this in Microsoft Access databases where you can enter something in or choose options that are mutually exclusive. Because the application lets you see that data, the program generates an error if you are wrong. From what I have seen, the gripe is that the full scaffold is too specific and rigid. Well, duh?! That's the point of each layer of scaffold--to provide a guide for usage.

Personally, I have shunned most of the page scaffolding and tend to rely on creating my own use flow. I use the controllers to present that choices are possible and to manipulate the models as opposed to the common practice of having the controller just load a set of records and pass it to the view (which formats the output). The advantage is that the user is never wrong. Options that are logically inconsistent are never presented. Add to this the ability to monkey-patch (the extension of predefined classes) and lambdas, the code is clean and concise. Both can be used to refactor procedural code into functional code and move it out of the controllers and models. Most importantly, the design allows you to think about what you want to manipulate and then after the fact extend the functionality. A common example of the is the statement:
1.day.from_now
The numeric class is extended in Rails so that you do not have find and use a static date class, but can state simply the desired result.

So, where does it fail miserably? So far, I have not found any great place that it does. It performs as well I need it to serve about a dozen users on a lowly Pentium 4 machine with 256 megs of RAM. So far, the application has been 99% maintenance free. A date verification package I am using had a Feb 29th bug in it. The cool thing is that since I can see the source, I could fixed it. Perhaps there are issues with scaling, but from what I understand, the system was designed around a non-centric design. In theory, a correctly designed application should be able scale horizontally.

Given that there are other high-profile, high-use web sites written in Rails that do not suffer from Twitter's issues, I am left thinking that its failure in general looking for a specific reason. Rails has been very stable and easy to extend, but then I write for maintenance and ignore hype.