4 ms·

Usually a map can be fine, but isnt it a maintenance nightmare. At least if you change an object, the compiler will complain if an attribute is not found, but

Usually a map can be fine, but isnt it a maintenance nightmare. At least if you change an object, the compiler will complain if an attribute is not found, but this leads to runtime error/ or bad behaviour

acarabott 6y ago
Adding a version field can be useful to avoid this. Particularly if your entire state is stored in one object.
- andi999 6y ago
  Agree. But then every function using the map has to query the versiom field?
  - hakre 6y ago
    Who says there is only one version field?
- hakre 6y ago
  Yes, personally I'm (generally) against version fields, however in the OPs meaning as I read it, if you add the version field it breaks the value (the version field invalidates value comparison for equality) and therefore will end up adding complexity. This may go contrary towards the topic, as OP clearly states major goal is to reduce complexity. So adding a value and make it (inherently) incompatible in the value system breaks the benefits of a couple of the six points outlined in the OP (given the version field suggestion). Just saying. Your mileage may vary. But again, introducing version attributes is most of the time (and that is a warning) _increasing_ complexity. One of the articles referred to by the op is [out-of-the-tar-pit] which is fundamentally about complexity and WTF it is paradigms, on syntax level and language support. A version field is a counter on higher level on top of anything of it (and therefore in the off-topic domain already to a larger extend) and also ruining any of the value comparison ability (adding the version field exploits the value inequality in DO as per OP making it part of the versioning system) introducing meta-date and IMHO ruining DO. If you need to encapsulate state to take a short-cut, introduce state. Don't ruin value(s). Just my 2 cents. (/edit: better than version attributes are just any attributes as they work towards both directions of change. not that straight forward to deal with at first, but offering more flexibility. it would be that some older value handling functions are incomplete [but compatible] and new ones just fitting. similar, namespacing for attributes are orthogonal as well [as in closure, depends language at task supports them] while version fields are imposing one general forward direction only, IMHO only for last resort if any other kind of consistency is already considered lost beyond recognition [most often this is _not_ true in computer systems, it's just that everyone involved is too f-c-k'ing lazy to take care and then blames others for anything but getting the job done my/your-self. when in doubt ask operations, they may tell you if they have time]) [out-of-the-tar-pit]: https://raw.githubusercontent.com/papers-we-love/papers-we-love/master/design/out-of-the-tar-pit.pdf https://raw.githubusercontent.com/papers-we-love/papers-we-l... Moseley/Marks 2006
hakre 6y ago
Yes, for sure it is. But what is the alternative? A compiler can only complain on a monolith, it can't scratch boundaries out of the system it compiles (and still within that monolith, encapsulated system the data might be inconsistent). For distributed systems this has been solved in the last two decades (if not even longer), but still systems are pressing against formality, how come? Continue to write the code to deal with the (always changing) data, maybe that's it when diving data apart from code (:OP/DO#1 ; Perlis 9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.).
- andi999 6y ago
  How has this been solved for distributed systems?
  - dcuthbertson 6y ago
    One way is to have an Interface Definition Language and rely on an IDL compiler to write the interfaces in the language of your choice. Senders and receivers will expect the same types to be marshalled/unmarshalled. If a sender attempts to send data that is different from the interface, either the compiler will catch it, or hopefully a runtime error will happen - either the sender will fail to marshal the data, or the receiver will fail to unmarshal it. Still, there are "garbage-in, garbage-out" situations that someone will have to debug, but starting with well-defined interfaces and tooling to generate code helps a lot.

acarabott 6y ago

Adding a version field can be useful to avoid this. Particularly if your entire state is stored in one object.

andi999 6y ago
Agree. But then every function using the map has to query the versiom field?
- hakre 6y ago
  Who says there is only one version field?
hakre 6y ago
Yes, personally I'm (generally) against version fields, however in the OPs meaning as I read it, if you add the version field it breaks the value (the version field invalidates value comparison for equality) and therefore will end up adding complexity. This may go contrary towards the topic, as OP clearly states major goal is to reduce complexity. So adding a value and make it (inherently) incompatible in the value system breaks the benefits of a couple of the six points outlined in the OP (given the version field suggestion). Just saying. Your mileage may vary. But again, introducing version attributes is most of the time (and that is a warning) _increasing_ complexity. One of the articles referred to by the op is [out-of-the-tar-pit] which is fundamentally about complexity and WTF it is paradigms, on syntax level and language support. A version field is a counter on higher level on top of anything of it (and therefore in the off-topic domain already to a larger extend) and also ruining any of the value comparison ability (adding the version field exploits the value inequality in DO as per OP making it part of the versioning system) introducing meta-date and IMHO ruining DO. If you need to encapsulate state to take a short-cut, introduce state. Don't ruin value(s). Just my 2 cents. (/edit: better than version attributes are just any attributes as they work towards both directions of change. not that straight forward to deal with at first, but offering more flexibility. it would be that some older value handling functions are incomplete [but compatible] and new ones just fitting. similar, namespacing for attributes are orthogonal as well [as in closure, depends language at task supports them] while version fields are imposing one general forward direction only, IMHO only for last resort if any other kind of consistency is already considered lost beyond recognition [most often this is _not_ true in computer systems, it's just that everyone involved is too f-c-k'ing lazy to take care and then blames others for anything but getting the job done my/your-self. when in doubt ask operations, they may tell you if they have time]) [out-of-the-tar-pit]: https://raw.githubusercontent.com/papers-we-love/papers-we-love/master/design/out-of-the-tar-pit.pdf https://raw.githubusercontent.com/papers-we-love/papers-we-l... Moseley/Marks 2006

hakre 6y ago

Yes, for sure it is. But what is the alternative? A compiler can only complain on a monolith, it can't scratch boundaries out of the system it compiles (and still within that monolith, encapsulated system the data might be inconsistent). For distributed systems this has been solved in the last two decades (if not even longer), but still systems are pressing against formality, how come? Continue to write the code to deal with the (always changing) data, maybe that's it when diving data apart from code (:OP/DO#1 ; Perlis 9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.).

andi999 6y ago
How has this been solved for distributed systems?
- dcuthbertson 6y ago
  One way is to have an Interface Definition Language and rely on an IDL compiler to write the interfaces in the language of your choice. Senders and receivers will expect the same types to be marshalled/unmarshalled. If a sender attempts to send data that is different from the interface, either the compiler will catch it, or hopefully a runtime error will happen - either the sender will fail to marshal the data, or the receiver will fail to unmarshal it. Still, there are "garbage-in, garbage-out" situations that someone will have to debug, but starting with well-defined interfaces and tooling to generate code helps a lot.