4 ms·

One of my first questions was "What are the motivations for a language over a library?" After reading more, I see that Stan has both. There are integrations wit

by dj-wonk 11y ago

One of my first questions was "What are the motivations for a language over a library?" After reading more, I see that Stan has both. There are integrations with R, Python, Julia, C++, Stata, the command line, and more. To ask an intentionally over-simplified question: if the key value add of Stan in the functionality and approach -- why bother with the overhead of an external DSL? Why not use an internal DSL -- e.g. borrow data structures and/or syntax of another language? Arguments for an external DSL are, hopefully: cross-language portability and domain-clarity for people. But how does this play out if you want to support multiple languages and interop? Let's say I'm using Python, for example, and want to build up a model programmatically. The example at https://github.com/stan-dev/pystan https://github.com/stan-dev/pystan shows using a heredoc. That's simple and easy to start. However, a big downside of a plain-text DSL is that it can be hard to manipulate programatically. To do that, each language implementation has to be 'business' of converting to and from text. This reminds me of the 'SQL' problem ... many language SQL wrappers spend considerable time munging text. Ug. Given my bias towards data-oriented programming, I see another approach: why not use a rich data structure language (other than plain text) as the foundation? Why not edn, for example? If the LISPy nature of that is not preferred, then why not something else? (Does the C-community have some kind of generic data description language? I wouldn't recommend JSON necessarily but that would be better than a hand-rolled DSL, in my opinion.) Here's why I recommend starting with 'rich' data as opposed to parsing text... I'm not saying human DSLs are bad. I'm just saying they don't have to be the foundation. If you want a human external DSL, great -- but why not convert the human DSL to a canonical data structure? Then build everything around the data, rather than build everything around the text format?

chmullig 11y ago
In my mind, there's two points to Stan. The first is the actual math -- it can fit lots of models, much faster and more flexibly than other alternatives. The second is to go out and meet the practitioners where they are. That means making Stan models look like the equations in your paper. It means connecting to existing research software ecosystems. It means making it easy to adapt. In this case, if you end up tightly coupled to, say, specific R data structure then it becomes much, much harder to make it also work well for Python, and for Stata, etc. Additionally, it means that if I start on a model in Python then I cannot easily switch to using R (or vice-versa). Using a DSL also has the nice property of cleanly separating Stan world vs R world. That makes it easier for users to build an accurate mental model for what happens when/where, which hopefully then leads to better performance. Most importantly though, Stan code is incredibly concise and clear for specifying models.
bengHN 11y ago
As you mentioned, there are pros and cons to inventing the Stan DSL. Originally, we wanted a language that was not too different from the BUGS language because the BUGS family was what most applied Bayesians were using (if they weren't using some specialized MCMC algorithm for their problem). And programmatic manipulation (while not impossible) of a Stan program was not high on our priority list. Since the underlying language is C++, you can bypass the Stan language and write (or generate) the C++ directly with a lot of effort. It uses standard (including Eigen) data structures.
- dj-wonk 11y ago
  > you can bypass the Stan language and write (or generate) the C++ directly with a lot of effort Did you mean "without" a lot of effort? :)
  - bengHN 11y ago
    Unfortunately no, but a few brave souls have done so. It is slowly getting easier.
- eggy 11y ago
  Clasp [1] could be used to write a Common Lisp version, and as most know, CL makes it easy to write DSLs, interface with C++ (with Clasp), and manipulate code as data, even more so than Julia. I may look into this soon. Very exciting. Great work by the Stan team by making it available across so many popular languages! [1] https://drmeister.wordpress.com/2014/09/18/announcing-clasp/ https://drmeister.wordpress.com/2014/09/18/announcing-clasp/

by dj-wonk 11y ago

chmullig 11y ago

In my mind, there's two points to Stan. The first is the actual math -- it can fit lots of models, much faster and more flexibly than other alternatives. The second is to go out and meet the practitioners where they are. That means making Stan models look like the equations in your paper. It means connecting to existing research software ecosystems. It means making it easy to adapt. In this case, if you end up tightly coupled to, say, specific R data structure then it becomes much, much harder to make it also work well for Python, and for Stata, etc. Additionally, it means that if I start on a model in Python then I cannot easily switch to using R (or vice-versa). Using a DSL also has the nice property of cleanly separating Stan world vs R world. That makes it easier for users to build an accurate mental model for what happens when/where, which hopefully then leads to better performance. Most importantly though, Stan code is incredibly concise and clear for specifying models.

bengHN 11y ago

As you mentioned, there are pros and cons to inventing the Stan DSL. Originally, we wanted a language that was not too different from the BUGS language because the BUGS family was what most applied Bayesians were using (if they weren't using some specialized MCMC algorithm for their problem). And programmatic manipulation (while not impossible) of a Stan program was not high on our priority list. Since the underlying language is C++, you can bypass the Stan language and write (or generate) the C++ directly with a lot of effort. It uses standard (including Eigen) data structures.

dj-wonk 11y ago
> you can bypass the Stan language and write (or generate) the C++ directly with a lot of effort Did you mean "without" a lot of effort? :)
- bengHN 11y ago
  Unfortunately no, but a few brave souls have done so. It is slowly getting easier.
eggy 11y ago
Clasp [1] could be used to write a Common Lisp version, and as most know, CL makes it easy to write DSLs, interface with C++ (with Clasp), and manipulate code as data, even more so than Julia. I may look into this soon. Very exciting. Great work by the Stan team by making it available across so many popular languages! [1] https://drmeister.wordpress.com/2014/09/18/announcing-clasp/ https://drmeister.wordpress.com/2014/09/18/announcing-clasp/