Hi, Joel here, I'm founder of a conversational platform here in Brazil (Ubots). In fact launching a bot should not be a technically complex task. On the other hand there are several disciplines where the complexity resides, such as dialog management, dialog state tracking, analytics (decision support), and mainly designing conversations which actually solve people problems in a simple manner, given that the big picture can become increasingly complex over time (if you want some control over it). There are also less supervised approaches where you normally need less / none intervention, but the more unsupervised it is, the less control you have.
I don't see how this is related to statically typed vs dynamically typed. This is more a case of Primitive Obsession http://c2.com/cgi/wiki?PrimitiveObsession and a lack of a adapter/serialization layer.
I meant, typed vs not-typed. Someone mentioned Clojure, and for me thats the whole point: on one hand, and for a whole category of problems the best abstraction is not to have a strong schema, given the variable parts. On the other hand however there are scenarios where you already know the structure sufficiently well. A matter of abstraction IMO
The verbosity itself shouldn't be a problem, if it someway helps to understand the class / method meaning. But, on the other hand redundancy can be a problem in my opinion, specially considering there is always a context where your code lives.
I think that one of the best ways to learn things in depth is to share and discuss it with other skilled professionals who can share their thoughts based on other points of view.
There is always something new to learn from the others, and even if you know more than them, remember that it doesn't matter if you know 100% of something if you don't know how to communicate in a clear and concise way.
The main peculiarity about this solution is that on this case we had a complex input type, where a transition on an inner element may influence the state on the outer element.
For example, given the following structure:
- A1 (state=1)
-- B1 (state=2)
--- C1 (state=5)
-- B2 (state=3)
If the state of C1 changes, then this change should be considered by the B predicates, and so should the A predicates.
After all, for the example in specific we are returning all the updated statuses in a list, as in our case we needed to show what was the difference on the overall state after the execution.
Nice article!
After deeper thoughts i finally realized what bothers me about it: It doesn´t address the inner dependencies between those transitions.
By your comment above, it´s not a big deal because of this kind of hierarchical structure you described, but it was not clear when i first read it.
