DJdj-wonk·Sep 19, 2015
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 shows using a heredoc. That's simple and easy t
Read the rest
o 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?