I think the big-picture difference is something like, “What is the language being optimized for.” When designing a language, there are a ton of different trade-offs. PPLs are typically heavily optimized for data analysis on large datasets and fancy MCMC algorithms. Squiggle is more for intuitive personal estimation.
Some specific differences:
Squiggle is optimized much more for learnability and readability (for the models that it works with). This is good for cases where we want to get people up to speed quickly, or for having others audit models.
Squiggle is in Javascript, so can run directly in the browser and other Javascript apps. (Note: WebPPL is also in JS, but is very different).
The boot-up time for Squiggle, for small models, is trivial (<100ms). For many PPLs it can be much longer (10s+).
If you’re happy with using a PPL for a project, it’s probably a good bet! If it really doesn’t seem like a fit, consider Squiggle.
Do you have any plans for interoperability with other PPLs or languages for statistical computing? It would be pretty useful to be able to, e.g. write a model in Squiggle and port it easily to R or to PyMC3, particularly if Bayesian updating is not currently supported in Squiggle. I can easily imagine a workflow where we use Squiggle to develop a prior, which we’d then want to update using microdata in, say, Stan (via R).
I think that for the particular case where Squiggle produces a distribution (as opposed to a function that produces a distribution), this is/should be possible.
No current plans. I think it would be tricky, because Squiggle both supports some features that other PPL’s don’t, and because some of them require stating information about variables upfront, which Squiggle doesn’t. Maybe it’s possible for subsets of Squiggle code.
Would be happy to see experimentation here.
I think one good workflow would be to go the other way; use a PPL to generate certain outcomes, then cache/encode these in Squiggle for interactive use. I described this a bit in this sequence. https://www.lesswrong.com/s/rDe8QE5NvXcZYzgZ3
Thanks for the question!
I think the big-picture difference is something like, “What is the language being optimized for.” When designing a language, there are a ton of different trade-offs. PPLs are typically heavily optimized for data analysis on large datasets and fancy MCMC algorithms. Squiggle is more for intuitive personal estimation.
Some specific differences:
Squiggle is optimized much more for learnability and readability (for the models that it works with). This is good for cases where we want to get people up to speed quickly, or for having others audit models.
Squiggle is in Javascript, so can run directly in the browser and other Javascript apps. (Note: WebPPL is also in JS, but is very different).
The boot-up time for Squiggle, for small models, is trivial (<100ms). For many PPLs it can be much longer (10s+).
If you’re happy with using a PPL for a project, it’s probably a good bet! If it really doesn’t seem like a fit, consider Squiggle.
Do you have any plans for interoperability with other PPLs or languages for statistical computing? It would be pretty useful to be able to, e.g. write a model in Squiggle and port it easily to R or to PyMC3, particularly if Bayesian updating is not currently supported in Squiggle. I can easily imagine a workflow where we use Squiggle to develop a prior, which we’d then want to update using microdata in, say, Stan (via R).
I think that for the particular case where Squiggle produces a distribution (as opposed to a function that produces a distribution), this is/should be possible.
No current plans. I think it would be tricky, because Squiggle both supports some features that other PPL’s don’t, and because some of them require stating information about variables upfront, which Squiggle doesn’t. Maybe it’s possible for subsets of Squiggle code.
Would be happy to see experimentation here.
I think one good workflow would be to go the other way; use a PPL to generate certain outcomes, then cache/encode these in Squiggle for interactive use. I described this a bit in this sequence. https://www.lesswrong.com/s/rDe8QE5NvXcZYzgZ3