axilmar

Amen.

Reading the comments from top to bottom, the above is exactly what I wanted to write.

What if there are hidden properties that affect each particle of a pair after they are split, in predetermined ways? that would certainly create correlations that seem to be created on the fly, but they would simply be the result of the inner workings of particles that don't communicate.

For example, if we have two balls, each containing a spin mechanism inside them which makes them spin in relation, let's say, to the magnetic north, and we throw one of them to the other...and later we discover that their spin is somehow correlated.

That is not action at a distance, that is the result of the inner mechanism of each ball.

Why not a similar thing happens with particles?

Of course the math check out, they are correct, but in my opinion, time is not a dimension, it's the 'refresh rate' of matter.

To me, there are only 3 dimensions, that of space.

That does not mean the relativity math is useless. On the contrary, what they describe is real and we can experimentally verify it.

But that does not mean we can 'move' into time, as we 'move' into space. That's why time is not a dimension.

> In general, classical correlation cannot break the Bell inequalities [assuming no peeking, ie. no action-at-a-distance in the measurement devices].

What if the particles have properties that mutate their state after they are sent to Alice and Bob?

Suppose, in the billiards example, that I put a small device into the balls that changes the spin of the ball to some predefined value.

Wouldn't that break the Bell inequalities without action at a distance?

The reason for the breaking would be that the state of the balls would be modified after they are sent to Alice and Bob. It would look like action at a distance without being 'action at a distance'.

> Victor can prepare a pair of quantum particles in a special state known as an entangled state. In this state, the outcomes of Alice's and Bob's measurements are not just random but are correlated in a way that defies any classical explanation based on local hidden variables.

What if there are no hidden properties per particle, but the combination of specific property values of particles allow for breaking Bell's Inequality?

I.e. what we call 'entanglement', it might not be 'action-at-a-distance', but the simple effect of the interaction of the properties of the two particles as they are generated.

For example, if we have two billiard balls, which are really close together, and we hit them with a third ball simultaneously, their spin will be correlated when we measure it for both balls (without taking into account other factors, i.e. friction, tilting of the table etc). Wouldn't that break Bell's inequality as well? the spins of the two balls will be correlated.

My question for Haskellers is how to do updates of values on a large scale, let's say in a simulation.

In imperative languages, the program will have a list of entities, and there will be an update() function for each entity that updates its state (position, etc) inline, i.e. new values are overwriten onto old values in memory, invoked at each simulation step.

In Haskell, how is that handled? do I have to recreate the list of entities with their changes at every simulation step? does Haskell have a special construct that allows for values to be overwritten, just like in imperative languages?

Please don't respond with 'use the IO monad' or 'better use another language because Haskell is not up for the task'. I want an actual answer. I've asked this question in the past in this and some other forums and never got a straight answer.

If you reply with 'use the IO monad' or something similar, can you please say if whatever you propose allows for in place update of values? It's important to know, for performance reasons. I wouldn't want to start simulations in a language that requires me to reconstruct every object at every simulation step.

I am asking for this because the answer to 'why Haskell' has always been for me 'why not Haskell: because I write simulations and performance is of concern to me'.

Here is a good approach between using microservices or a monolith: create your product as a series of libraries that can be used to built either a microservices-based product or a monolith product.

In this way, you can turn a monolith to microservices very easily, since the core of your code will be there already.

The Settings app is a control panel though.

This story makes me wonder if it's better to use Ada/SPARK than Rust, from a safety perspective.

It's a shame really that Namco didn't want to pay a lot of money for the rights of Ms Pac Man.

I don't understand their approach.

They clearly have a lot more money in their disposal than AtGames. Why not buy the second most significant character in the Pacman franchise?

Requirements always exist in a project, even if they are not written.

And how they cannot exist, since the only reason a program is written is because of some need...

And since requirements always do exist, they better be in written form, so as that they can be referenced, tested, discussed etc.

In previous projects, JIRA was used. In the current project, an internal tool is used, pretty much similar to JIRA.

In some older projects, a simple Word document was used and an Excel sheet for tracking progress.

Writing a requirement should be simple enough: it shall either define things, or describe processes and their side effects.

It is better to have a dedicated person to write them, because the wording and style of requirements should be consistent, and the person that writes them will gradually be more and more experienced in writing better requirements.

Having good requirements makes it a lot easier for developers to write the required programs.

Coding is hard because most APIs suck. Most APIs

a) contain many leaky abstractions.

b) are unnecessarily complex in order to adhere to a specific ideology.

c) have various gotchas, either documented or undocumented.

d) the basic concepts behind them make sense only to the authors.

e) do not contain any abstractions at all, exposing all raw technical details to the user.

f) many details about their parameters are not documented at all.

g) have undisclosed side effects.

h) not implemented in the same way in different platforms. etc.

With all these and many more, a newcomer to coding can feel lost for many years.

Why bother? the percentage of users that have JS disabled is what nowadays? 0.000000000001% maybe? even smaller?

Way too many chances for buffer overflows.

It is a nice approach to learn how things work, but not a recommended approach for building anything useful.

My idea for C++ memory safety would be compile time reference counting.

I.e. the compiler/tool to go through the code, as if it was executing, and apply reference counting to objects, revealing whether an object will be destroyed normally, prematurely or never.

This is what we actually do as humans by the way, when we are developing an algorithm in C++ with manual memory management. We do it implicitly though.