jhellerstein
commented
12 years ago It's nice to hear a vote for Datalog syntax. Our previous work on Overlog used Datalog syntax. The most recent implementation was JOL, a Java-based implementation. We used it to write an entire Hadoop Filesystem clone and rewrite parts of Hadoop MapReduce. See write-up here and code here.
In our experience, the variable-matching style of Datalog syntax became burdensome when writing programs like the filesystem which ran into hundreds of rules. We are also trying to make the comprehension style of Bloom be familiar to the many programmers who have used languages like Python and Ruby with similar collection constructs.
You're right that it would not be hard to provide a Datalog "skin" for Bloom. We don't have plans to do so now, but would be happy to see it come from community contribution.
Thanks for your ongoing support and feedback.
From what I've read, it appears that Bloom and Dedalus are both languages designed to accomplish the same goal: allow programmers to write more intuitive and natural distributed programs. But according to the slide below (from a presentation by @neilconway), Bloom is supposed to have a "friendly syntax" and "mainstream appeal".
I was surprised to see that it was believed that the relational algebra style of Bloom was more friendly than the sugared Datalog style of Dedalus. My question: why does Bud accept the relational algebra style syntax that it does instead of the beautiful datalog syntax from Dedalus? It's very easy to pre-process the datalog input and keep all the internal representations the way they are currently. Is there another project planned that will accept that kind of input?