4 ms·

I don't understand how the writer didn't realise somewhere during writing this that they're conflating immutable state concerns and higher-level state validatio

by weego 5y ago

I don't understand how the writer didn't realise somewhere during writing this that they're conflating immutable state concerns and higher-level state validation in logic loops. Collision detection validation and the game loop, to use the example, has absolutely nothing to do with what kind of data structure you're using, and is absolutely not what functional programming was 'supposed to help us avoid'.

dkarl 5y ago
I don't know if the author meant to, but he describes a problem that people run into with concurrent systems, and which creates a lot of real-life bugs if people don't anticipate it and design for it. In the author's case, the solution is trivial because it can be solved by specifying the order of updates, but in concurrent systems that isn't always an option. Let's say instead of Manuel the Carpenter's position on the screen, we're updating the status of Monte the Money Launderer's application for a line of credit. The CreditCheck system receives an external credit report and updates Monte's application state to indicate he has passed the credit check. The Approval system sees the credit check result, sees that all other conditions have been met, and updates the application state to Approved. At the same time, a loan officer who has received a call from the FBI about Monte uses the Control system to put a manual Hold on the loan. If the concurrent updates from the Approval and Control systems are combined naively, the application can end up in the state of Approved and Hold simultaneously. The loan officer, seeing that the Hold has been successfully placed on the application, believes that Monte has been blocked, but in fact Monte is able to access the Approved line of credit. Like the problem described by the author, this is a pretty basic problem that most HN readers would design for from the start, but the title "Immutability is not enough" should (theoretically) select for readers who are a little bit surprised by it.
- deleted 5y ago
  [deleted]

by weego 5y ago

dkarl 5y ago

I don't know if the author meant to, but he describes a problem that people run into with concurrent systems, and which creates a lot of real-life bugs if people don't anticipate it and design for it. In the author's case, the solution is trivial because it can be solved by specifying the order of updates, but in concurrent systems that isn't always an option. Let's say instead of Manuel the Carpenter's position on the screen, we're updating the status of Monte the Money Launderer's application for a line of credit. The CreditCheck system receives an external credit report and updates Monte's application state to indicate he has passed the credit check. The Approval system sees the credit check result, sees that all other conditions have been met, and updates the application state to Approved. At the same time, a loan officer who has received a call from the FBI about Monte uses the Control system to put a manual Hold on the loan. If the concurrent updates from the Approval and Control systems are combined naively, the application can end up in the state of Approved and Hold simultaneously. The loan officer, seeing that the Hold has been successfully placed on the application, believes that Monte has been blocked, but in fact Monte is able to access the Approved line of credit. Like the problem described by the author, this is a pretty basic problem that most HN readers would design for from the start, but the title "Immutability is not enough" should (theoretically) select for readers who are a little bit surprised by it.

deleted 5y ago
[deleted]