FWIW, I was trying to figure out if this was the Church successor (no, that's "Venture"), and found http://probcomp.csail.mit.edu/, which gives an overview.
Wow this looks great, I've been thinking about something that does exactly this for a while.
Apps that start to order everything by your preferences built up over time start to become possible and automatically repeating past uses. E.g. A new report completed and its 70% percent certain you move reports to a certain folder, it just happens.
Needs a lot of UI thought to be easy to override...
Anyway, I'd be interested to see how performant this is.
Have a look at DeepDive too: http://deepdive.stanford.edu/, this looks very similar at first glance. The approach of treating data integration&extraction as a statistical inference problem is IMHO a big idea on the rise.
A lot of talk about this being aimed at "non-technical" people, but these types of interfaces are still widely needed for developers, too. It can make trivial jobs much, much faster to complete both programmatically and through a GUI. Technical folks like abstractions too!
I like this quite a bit, although the similarity to SQL might pose more problems than it's worth in the long run.
That and AmazonML's striking similarity to Excel/CSV (not to mention the crop of ML-on-demand providers) show these types of interfaces and user experiences are a pretty glaring need right now in data science / ML / classification.
I saw them present a while back and someone in the audience asked "why SQL" stating that all innovative projects like this end up coming up with their own query language. The response was that everyone knows SQL so it's easy to get started and that they want to enable access from environments like Python and R for more advanced querying.
In addition, SQL design is simply really good. It's of the few successful declarative language: you get what you describe. It's also a total, in that all programs terminate. These are really good characteristics to have.
SQL is really good. My issue is you run into inconsistencies in the way you expect a function to work (when they're shared semantically across SQL and BQL in this case) and that eventually leads to confusion. Like working in the Arduino language versus C.
