Hacker News Reader

Comment by username90 | Hacker News Reader

> How is #4 even a problem to begin with?

Lets say you are making an RPG where you can equip items. You write a lot of pure functions and behavior for stat adjustments etc. Then the designer comes to you and say that items are no longer constants, every item needs a durability which goes down on use. In Java this would be a few line change, just add a new field in items and add a line to subtract it in relevant places. In Haskell you would need to bubble up the new item change to the global state and properly set it in each part of the code where you use items. If you aren't careful you can easily miss to properly bubble it up somewhere and the item doesn't get updated, or you might have the same item referenced in several places and now you'd have to refactor it to have a global item pool to since tracking down all places that should be updated is not feasible.

View on HN

> In Java this would be a few line change, just add a new field in items and add a line to subtract it in relevant places.

And then find out that since items used to be constants all instances of a given type of item are actually the same item object, so modifying one unexpectedly affects them all. Or worse, sometimes items are copied and sometimes they're shared by reference, so whether they're affected depends on each item's individual history.

One of the benefits of Haskell is that it forces you to think through these aspects of the API in advance. A mutable object with its own distinct identity and state is a very different concept from an immutable constant and the design should reflect this. Changing one into the other is not an action to be taken lightly.

Not a Haskell expert, but I think I know what you mean -you are passing items by value to many functions and complain it's not modified in others, when you call them, or you need to compose flow so updates are properly "bubbled".

But with assumption that code was working before and you had for example function: use :: Item -> Item, and you change duration in this function, what else do you need to change to "bubble" new state? I don't get this.

BTW What's the problem with global store and passing only IDs ? I feel like this is probably valid approach and anyway ECS are implemented in similar manner AFAIK - https://en.m.wikipedia.org/wiki/Entity_component_system

As I understand it, a function use :: Item -> Item in Haskell guarantees that it can't change any property of any item;even more so if the function were use :: Item -> Effect, as could be done on the initial assumption that Items can't change.

In general you can't mutate records. Nothing prevents you from making a new one that's slightly different though. It just won't change the already existing one.

In practice this is not actually a problem. It just takes a little getting used to to get yourself out of the 'memory-address as identity' mindset that procedural languages have.

Can you provide an example (even in pseudocode, syntax doesn't matter here)?

I don't think that's how you'd handle a state change in idiomatic Haskell. What you propose sounds very error-prone.

Reply on news.ycombinator.com