blandinw
Joined 16 years ago
Joined 16 years ago
Also, the author is being very direct about what he thinks of Acton's behavior, he's not being passive-aggressive.
I don't know of any benchmarks. HeidelTime and SUTime are two solid projects... although the rule files [0][1] are a bit scary if you ask me :-).
Quick thoughts:
- SUTime relies on TokensRegex [2] which is similar to how Duckling parses sentences at a high-level
- SUTime seems to only provide English rules
- I don't know of any production use cases of either
[0] https://github.com/stanfordnlp/CoreNLP/tree/master/src/edu/s...
[1] https://github.com/HeidelTime/heideltime/blob/master/resourc...
We had planned to release the Bot Engine at F8 long before MSFT's announcement. If you ask me, F8 might have affected their timing more than the other way around ;-)
Today, Wit offers many advantages out-of-the-box so you don't have to setup your own solution.
As NLP gets more commoditized (e.g. through open-source, open datasets), Wit will have to provide even more value than today to stay relevant. Value can be ease of use, accuracy, etc. That's how the field makes progress.
Regarding best interest, if you mean FB's best interest, FB wants more intelligent bots in Messenger, VR, etc. It makes sense to provide the tools to do so. Opening these tools also helps make them better (why is FB open-sourcing React for example?)
If you mean the Wit team's best interest, we're always happy to provide better tools to developers and innovate in AI / UX. That's why we started Wit after all :-)
X as a service allows you to get X with a lot less efforts. It allows you to understand the problem and your needs by getting started quickly. Over time, if X as a service saved you enough time and you become successful, you can choose to develop an expertise in X and cut the dependency.
Wit is also about building a community of developers and advancing the state of the art of NLP in apps. Once the bot engine matures a bit, we'll be focusing again on the community aspect of Wit and hopefully advance the field enough so that efforts like the standardization you mentioned are started.
TL;DR Haskell made more sense for us to scale with the number of requests (existing FB infra) as well as the number of engineers working on the project (type checking, etc).