5 ms·

For me, even though it's PHP, ProcessWire consistently models data in a human way. I've put the out-the-box backend CMS in front of people that interact with co

For me, even though it's PHP, ProcessWire consistently models data in a human way. I've put the out-the-box backend CMS in front of people that interact with computers very little and they instantly "get it". All data is simply a node in a hierarchy, and is easily movable and editable. I don't understand why more frameworks don't copy this basic structure. If you watch "The mother of all demos"[1] the structure is almost visually 95% the same. I look at Angular and it's looks complicated - the article is about how complicated it is. Surely we should be striving for tools the everyday man can pick up and play with? [1] - https://www.youtube.com/watch?v=yJDv-zdhzMY https://www.youtube.com/watch?v=yJDv-zdhzMY

jacques_chester 13y ago
> I don't understand why more frameworks don't copy this basic structure. Lots of problem domains are difficult to model as trees because often, a node can be logically assigned to multiple parents, but the tree model requires it be physically assigned to only one. Recently I bought a prepaid SIM card for a trip I am making to the USA. In my bookkeeping system, I could enter it either as a transaction against the "Telephone & Internet" expense account, or I could enter it against "International Travel". What I can't do, because trees require mutual exclusion, is enter it under both. That breaks the model. If instead Renaissance accountants had understood sets and relations, I might be able to log it against both and then derive whichever view of the data was necessary. And that's the problem with hierarchical data. It privileges one and only one view of the problem domain. As soon as you need some other view, you are in trouble. If your project management system organises by project, then getting per-staff reports is now much harder. If your class hierarchy views A->B as the natural order of creation, what happens when you come up with cases where C->A but not C->B? You can't: you have to introduce complicated workarounds. Hierarchies are simple to understand on their face. But they quickly come apart when faced with the real world and ad hoc queries about the state of the real world.
- LBarret 13y ago
  Sets and relations are indeed the most richest metamodel but most of the time a dag (directly acyclic graph) is enough : object can be connected to many parents but it keeps most the hierarchical organisation, which is easier to model.
  - jacques_chester 13y ago
    What can be modelled as a graph can be modelled as sets and relations and vice versa; they're both equally powerful. But just as any two Turing-complete languages are equally powerful, the discussion doesn't end there. It's still the same problem: you have mixed the logical model and physical structure of your data together. You are privileging one view of the data over all other views. I consider switching to a full graph model a complicated workaround for the limitations of trees. You now introduce new and exciting paradoxes and you will need to litter your code with special cases (B means C, but only when A is not an ancestor, otherwise it means D). Ask C++ programmers about the joys of multiple inheritance. In some cases the logical model is a graph and in those cases you should absolutely model it as a graph. But modelling all problems as a graph is inadvisable.

jacques_chester 13y ago

> I don't understand why more frameworks don't copy this basic structure. Lots of problem domains are difficult to model as trees because often, a node can be logically assigned to multiple parents, but the tree model requires it be physically assigned to only one. Recently I bought a prepaid SIM card for a trip I am making to the USA. In my bookkeeping system, I could enter it either as a transaction against the "Telephone & Internet" expense account, or I could enter it against "International Travel". What I can't do, because trees require mutual exclusion, is enter it under both. That breaks the model. If instead Renaissance accountants had understood sets and relations, I might be able to log it against both and then derive whichever view of the data was necessary. And that's the problem with hierarchical data. It privileges one and only one view of the problem domain. As soon as you need some other view, you are in trouble. If your project management system organises by project, then getting per-staff reports is now much harder. If your class hierarchy views A->B as the natural order of creation, what happens when you come up with cases where C->A but not C->B? You can't: you have to introduce complicated workarounds. Hierarchies are simple to understand on their face. But they quickly come apart when faced with the real world and ad hoc queries about the state of the real world.

LBarret 13y ago
Sets and relations are indeed the most richest metamodel but most of the time a dag (directly acyclic graph) is enough : object can be connected to many parents but it keeps most the hierarchical organisation, which is easier to model.
- jacques_chester 13y ago
  What can be modelled as a graph can be modelled as sets and relations and vice versa; they're both equally powerful. But just as any two Turing-complete languages are equally powerful, the discussion doesn't end there. It's still the same problem: you have mixed the logical model and physical structure of your data together. You are privileging one view of the data over all other views. I consider switching to a full graph model a complicated workaround for the limitations of trees. You now introduce new and exciting paradoxes and you will need to litter your code with special cases (B means C, but only when A is not an ancestor, otherwise it means D). Ask C++ programmers about the joys of multiple inheritance. In some cases the logical model is a graph and in those cases you should absolutely model it as a graph. But modelling all problems as a graph is inadvisable.