4 ms·

Hello HN, I'm the original author of Duckling (with @blandinw). As usual, always happy to get feedback and suggestions.

by ar7hur 7y ago

nudpiedo 7y ago
I must say it looks very eat from the point of view of usability. Are the training data sets open? Do you see feasible for small app coders (who don’t have thousands of examples to train) to use Duckling as more or less NLP parser without getting too much deep into the NLP and AI theory? Are the trained sets mean to be used by different client code or languages?
- ar7hur 7y ago
  Yes all the training data is in the repo. Duckling is relevant to parse very structured language, typically temporal expressions (dates and times...). It relies on a mix of rules and machine learning. Rules and datasets for many (human) languages are available in the repo. You don't need a lot of data to add support for what you need, owing to this hybrid rules+ML approach (as opposed to just ML).
- patapizza 7y ago
  Hey, author of the Haskell re-write (https://github.com/facebook/duckling https://github.com/facebook/duckling). We've implemented custom dimensions for extensibility (example: https://github.com/facebook/duckling/blob/master/exe/CustomDimensionExample.hs https://github.com/facebook/duckling/blob/master/exe/CustomD...).
jcadam 7y ago
Out of curiosity, why the move from Clojure to Haskell?
- l5t 7y ago
  Scalability. More context on the move from the 2017 post https://medium.com/wit-ai/open-sourcing-our-new-duckling-47f44b776809 https://medium.com/wit-ai/open-sourcing-our-new-duckling-47f...
- blandinw 7y ago
  I touched on that on Reddit: https://www.reddit.com/r/Clojure/comments/68r4lz/one_of_facebook_projects_migrating_from_clojure/ https://www.reddit.com/r/Clojure/comments/68r4lz/one_of_face... 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).
  - dominotw 7y ago
    > Everything is hashmap-typed and you need to do runtime checks to make sure the data you receive is what you expect. You cannot trust any input I don't mean this in a type system flamewar but in java if you receive Person object and want to get firstName. Your options are still the same. 1. runtime check to see person.firstName is not null. 2. or blindly assume that it can never be null and do person.firstName.trim() So those are the exact options in clojure too. What am I missing here.
    - LandR 7y ago
      Also check that person isn't null, probably. person?.firstName?.trim(); What (s)he means though is in Java if firstName is there then it will be a string. In Clojure firstName might be anything, a string, a number or even an entire other hashmap or type, literally anything. This might or might not cause a runtime crash if you are doing something that assumes it's a string. So you check.
      - dominotw 7y ago
        ok so it saves an extra (typeof x) check. To be honest I rerely see the typeof check in clojure code.
        Jach 7y ago
        And "saves" is a bit of a misnomer, since it implies the "cost" (of all the static type machinery) is less. Well, dynamic fans (or those with dynamic preferences if "fan" is too strong) will disagree. ;) In practice many systems get streams of bits from somewhere (like the network) that commonly get interpreted into strings and from there other types. The validation and conversion is necessary in any language, after that though it's just FUD to bring up that a function expecting a person with a :name key and string value potentially could be given something else. In the cases where through changes we make it something else, static types are a nice extra assurance on consistency, but that isn't the only way or the most impactful way to gain assurances.
2sk21 7y ago
Interesting! When I worked at IBM, we evaluated Duckling (the Haskell version) for use in the Watson Assistant product but decided to write our own numerical quantity parser/interpreter. We used ANTLR and created context-free grammars as we found that we could improve both precision and recall substantially. Sadly not open source though.
notenoughbeans 7y ago
It knows about "Labor day" but not "Labour day".
- binarymax 7y ago
  Which language ruleset are you using? I imagine the latter is not in EN_US, but would be in EN_GB
jmiskovic 7y ago
Hi, thanks for dropping in. What's the status of Clojure implementation? Would you recommend new projects to use it? Is anyone looking at new/old issues? Are there potential new maintainers for Clojure version?
- ar7hur 7y ago
  The current Clojure version is quite stable, we used it at wit.ai/Facebook for several years before moving to Haskell. I'd love to see somebody taking over and resuscitate it! One interesting direction could be to remove Java dependencies (mostly to Date) so that it's usable in ClojureScript. It would make a great JS library.
- deleted 7y ago
  [deleted]

Hello HN, I'm the original author of Duckling (with @blandinw). As usual, always happy to get feedback and suggestions.

by ar7hur 7y ago

Hello HN, I'm the original author of Duckling (with @blandinw). As usual, always happy to get feedback and suggestions.

I must say it looks very eat from the point of view of usability. Are the training data sets open? Do you see feasible for small app coders (who don’t have thousands of examples to train) to use Duckling as more or less NLP parser without getting too much deep into the NLP and AI theory? Are the trained sets mean to be used by different client code or languages?

ar7hur 7y ago
Yes all the training data is in the repo. Duckling is relevant to parse very structured language, typically temporal expressions (dates and times...). It relies on a mix of rules and machine learning. Rules and datasets for many (human) languages are available in the repo. You don't need a lot of data to add support for what you need, owing to this hybrid rules+ML approach (as opposed to just ML).
patapizza 7y ago
Hey, author of the Haskell re-write (https://github.com/facebook/duckling https://github.com/facebook/duckling). We've implemented custom dimensions for extensibility (example: https://github.com/facebook/duckling/blob/master/exe/CustomDimensionExample.hs https://github.com/facebook/duckling/blob/master/exe/CustomD...).

jcadam 7y ago

Out of curiosity, why the move from Clojure to Haskell?

l5t 7y ago
Scalability. More context on the move from the 2017 post https://medium.com/wit-ai/open-sourcing-our-new-duckling-47f44b776809 https://medium.com/wit-ai/open-sourcing-our-new-duckling-47f...
blandinw 7y ago
I touched on that on Reddit: https://www.reddit.com/r/Clojure/comments/68r4lz/one_of_facebook_projects_migrating_from_clojure/ https://www.reddit.com/r/Clojure/comments/68r4lz/one_of_face... 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).
- dominotw 7y ago
  > Everything is hashmap-typed and you need to do runtime checks to make sure the data you receive is what you expect. You cannot trust any input I don't mean this in a type system flamewar but in java if you receive Person object and want to get firstName. Your options are still the same. 1. runtime check to see person.firstName is not null. 2. or blindly assume that it can never be null and do person.firstName.trim() So those are the exact options in clojure too. What am I missing here.
  - LandR 7y ago
    Also check that person isn't null, probably. person?.firstName?.trim(); What (s)he means though is in Java if firstName is there then it will be a string. In Clojure firstName might be anything, a string, a number or even an entire other hashmap or type, literally anything. This might or might not cause a runtime crash if you are doing something that assumes it's a string. So you check.
    - dominotw 7y ago
      ok so it saves an extra (typeof x) check. To be honest I rerely see the typeof check in clojure code.
      - Jach 7y ago
        And "saves" is a bit of a misnomer, since it implies the "cost" (of all the static type machinery) is less. Well, dynamic fans (or those with dynamic preferences if "fan" is too strong) will disagree. ;) In practice many systems get streams of bits from somewhere (like the network) that commonly get interpreted into strings and from there other types. The validation and conversion is necessary in any language, after that though it's just FUD to bring up that a function expecting a person with a :name key and string value potentially could be given something else. In the cases where through changes we make it something else, static types are a nice extra assurance on consistency, but that isn't the only way or the most impactful way to gain assurances.

2sk21 7y ago

Interesting! When I worked at IBM, we evaluated Duckling (the Haskell version) for use in the Watson Assistant product but decided to write our own numerical quantity parser/interpreter. We used ANTLR and created context-free grammars as we found that we could improve both precision and recall substantially. Sadly not open source though.

notenoughbeans 7y ago

It knows about "Labor day" but not "Labour day".

binarymax 7y ago
Which language ruleset are you using? I imagine the latter is not in EN_US, but would be in EN_GB

jmiskovic 7y ago

Hi, thanks for dropping in. What's the status of Clojure implementation? Would you recommend new projects to use it? Is anyone looking at new/old issues? Are there potential new maintainers for Clojure version?

ar7hur 7y ago
The current Clojure version is quite stable, we used it at wit.ai/Facebook for several years before moving to Haskell. I'd love to see somebody taking over and resuscitate it! One interesting direction could be to remove Java dependencies (mostly to Date) so that it's usable in ClojureScript. It would make a great JS library.
deleted 7y ago
[deleted]