Hacker News Reader

Comment by ar7hur | Hacker News Reader

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

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.

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?

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).

Hey, author of the Haskell re-write (https://github.com/facebook/duckling). We've implemented custom dimensions for extensibility (example: https://github.com/facebook/duckling/blob/master/exe/CustomD...).

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?

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.

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

Scalability. More context on the move from the 2017 post https://medium.com/wit-ai/open-sourcing-our-new-duckling-47f...

I touched on that on Reddit: 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).

> 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.

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.

ok so it saves an extra (typeof x) check.

To be honest I rerely see the typeof check in clojure code.

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.

Also this quote was about the cited reason for FB preferring Haskell to Clojure generally, not about this project specifically. IME it's common in big organisations to prefer stuff that has controls at the cost of productivity. It's probably harder to ship buggy Haskell code even if it's harder to write.

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

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

Reply on news.ycombinator.com