anchor.diff:  From more 'open' perspective the core elements can be viewed as, but remember the name as a noun can be mislead:
   _This resulted as a dicussion of @pspeed and toolforger, eventually is form a skeptical question, it's really interesting by how we all see this problem confused at first!!_
   
  -```
  -  Entity -> ID. It just binds the components together, in the sense that there is one function that creates a bunch of components with the same ID, and one function to destroy all components for an ID. An entity is the set of objects that have the same ID, entities don’t exist as coherent objects inside the code.
  -
  -  Component -> Facet. A position is a facet of an entity, as its velocity, its health, its armor, its whatever. If entities were Java objects, facets would be groups of interrelated properties.
  -
  -  System -> Processor. A function that operates on a slice of components.
  -```
  +]
  +Entity -> ID. It just binds the components together, in the sense that there is one function that creates a bunch of components with the same ID, and one function to destroy all components for an ID. An entity is the set of objects that have the same ID, entities don’t exist as coherent objects inside the code.
  +
  +Component -> Facet. A position is a facet of an entity, as its velocity, its health, its armor, its whatever. If entities were Java objects, facets would be groups of interrelated properties.
  +
  +System -> Processor. A function that operates on a slice of components.
  +
   This often result in mislead skepticism about the design. So get back to read it carefully one more time and some gotchas and practical wisdom below.
   
   
  
positive.code: 
  From @pspeed:
  
  ```
    It is a bad design choice where:
    - there aren’t many entities and/or the behavior is so clearly defined that you’d just implement it one or two classes. Thing card games, a lot of puzzle games, etc..
    - the game is so simple that it’s just implemented as JME controls and a few app states. You could use an ES here but it would be wasted.
    - the game logic cuts across all objects nearly all the time. (I think of card games and puzzle games again.) This usually implies that there are few entities, though.
    - the team doing the work will have trouble understanding an ES. To me this is a huge one. Sometimes our choice of technologies is not dictated by what might be technically best… but what is technically best for the skills of the team. For example, if your artist only knows Sketchup then Blender is probably not the right tool even if it is superior in many ways.
  ```
  
  
  === Known issues:
  
negative.code: Read: link:http://blog.gemserk.com/2011/11/13/scripting-with-artemis/[http://blog.gemserk.com/2011/11/13/scripting-with-artemis/]
  
  Nearly one end up back to half ass solution, not a pure data ES if their really need scripting in.
  
  
  ==== Arbitrary Routine and Query
  