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

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?

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.

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'.

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.

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'.

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

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?

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.

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.

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

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.

It had some good capabilities not found elsewhere.

https://en.wikipedia.org/wiki/NeWS

In order to solve deadlocks, I created a mutex that first does a try lock, then if that fails it unlocks all mutexes of the thread and then relocks them in memory order.

Not very efficient some times, especially if there are many mutexes involved (i.e maybe it does not scale up), but it allows me to have algorithms not deadlock.

Perhaps it could be made more efficient with various tricks, I may have to do research on that idea...

You can always allocate a very large buffer and do your string operations there, using memncpy and the assorted functions which can be inlined in many architectures and be really fast.

Then you can dispose of the buffer really quickly with one call or reuse it for later operations by simply setting a few pointers to initial status...

In the example given, all polymorphism can be removed, and the shapes can be stored in std::tuple structure.

And then the operations would be faster than C, since no switch statement would be needed.