What's the disadvantage of building a DSL as a "library" on top of another language like C++ as opposed to going the more independent/standalone route?
What's the disadvantage of building a DSL as a "library" on top of another language like C++ as opposed to going the more independent/standalone route?
A library building on top of C++ don't need to write a compiler (to translate DSL programming code into machine instructions).
Yet they could still utilize compiler technologies. For example, TF and Pytorch develops compilers to optimize the graph (analogous to a serialized and executable binary) provided by ML engineers.
Same question as @jiaju: as someone that uses tensorflow and pytorch a lot. Both of them look like normal computation-focused Python libraries like NumPy. If I remember correctly, all of them have a low-level implementation in C. I'm curious about what differentiates a library from a DSL? Is it how they use resources for computations?
The line between DSLs and libraries has become increasingly more hazy in the last decade or so. Classically, DSLs had their own syntax and had to have their own parsers, and the user had to learn the syntax of that language. In some cases this worked out really well, like SQL, where a user did not need to learn a language like C to interface with databases.
Nowadays, there are so many languages to learn that creating a DSL increases the learning curve for users. Creating a library and interfacing it with a language like Python, and creating idiomatic uses of your library is like making a DSL, except the user has less to learn to start using it assuming they already know a programming language to start with.
@jchao01 The disadvantages of library-type DSLs, if I recall, were the following: - verbose (because it's not baked into the language, it requires more syntax and must be shoehorned into the host language's syntax instead) - hard to limit features (can't remember precisely what Kayvon said about this, but my hypothesis is that this is the result of the DSL's abstractions/concepts not coinciding with those of the host language) - hard to debug (the DSL's features may not coincide with those of the host language, so debuggers will naturally not be fluent in those concepts unless extensive work is done) - to some extent bounded by the performance of the host language (unless the DSL is an interface to a lower-level library in a more performant language)
So overall, I think you can see that the primary disadvantage is that the concepts and abstractions expressed in the DSL don't coincide with those of the host language, making it more unwieldy to use.
Please log in to leave a comment.
On what level do these DSLs differ from normal libraries (e.g. NumPy, STL)? Or can they be thought of as libraries that have routines/notation paradigms that are optimized for some specific use? I guess I'm not sure DSLs are a subclass of libraries or if they're different in implementation. Without knowing beforehand, I could read that each of these DSLs are packages installable in some high-level language and believe it.