Programmer Musings

Libraries vs. DSLs

Many years ago, I was working on application software that we configured and shipped to nearly a hundred clients. Although we did the first installation on a machine that we provided, the customer had to install updates a few times a year. (This was before most people knew about the Internet.)

A few of us tried to convince the president of the company that we could make good use of a professional installation program. But, he could not see the point. He pointed out that we were already working in C, and C could do everything that the installer could do. So he concluded we could just write our own. He could not see the use of a specialized language for installation, what we would now call a Domain Specific Language (DSL).

Amusingly enough, we were already using a DSL to build all of the software. This guy was a big fan of make. We used a reasonably complex build system based around make to generate over twenty different variants of the program.

His question is actually a valid one, although at the time I didn't have the terminology to make my point. Everything I can do with a DSL, I can do in a general purpose language. In fact, I can package up the functionality for the DSL in libraries or classes and even make calling it almost as easy as using a DSL. So, why would a DSL be a advantage? I believe the answer is notation. The DSL provides no increase in functionality. But what it does do is provide a better notation for working in the domain.

Let's take make as an example. Even though almost everyone complains about the tab thing in Makefiles and the reliance on the shell, make is still in wide use. Anything you can do with make can be done with any general purpose language. It would even be possible to build libraries for common functionality needed by build tools. Yet, we still use make or other tools similar to them. Why? Despite its flaws, the make DSL is very effective for specifying dependencies and tasks needed to build one set of resources from another set of resources.

SQL is another good example of a DSL, I remember accessing databases before SQL was wide-spread. Every database API was slightly different. They all provided the same basic functionality, but there were differences. You also needed to write quite a bit of common code in every place you used a particular database's API. Then SQL came along, and things changed. No, it was not a complete language, but it did allow you to talk to the database at a higher level. In the beginning, SQL libraries were not any faster (and were often slower) than the native APIs. Nevertheless, the notation was more convenient for the kinds of operations that you need to perform on a relational database.

In many domains, a library is enough to allow you to get your work done. When the domain is understood well enough that we can really talk about it at a high level, it becomes possible to make a DSL. There seems to be a large difference in usability when a DSL is designed correctly. Even if a DSL is not perfect (like make), it may be enough better than the alternatives that still use it...even if we still reserve the right to complain.

Review of Eric Sink on the Business of Software

Eric Sink on the Business of Software
Eric Sink
Apress, 2006

Eric Sink has been writing on the Business of Software for quite some time. This book shows that not only does he know something about the business side of things, but he's also familiar with the technical side. These essays do a pretty good job of explaining issues like positioning, hiring, marketing, and pricing to those of us who are baffled by business concepts. Unlike some heavier texts I've read on this subject, Sink does a good job of introducing the topic without getting into too much detail.

Sink's writing style is clear and easy to read. He uses humor well. And his explanations sound good and plausible. (Not knowing the business side very well, I tend to take his word for it.<shrug/>) In addition to being informative, the book is a relatively quick read. He does a very good job of explaining that, in the business world, the technology issues are not the most important parts of a business (despite what we who write code might think).

If you have seen his weblog, you know that his writing is clear and his opinions are well thought-out. You may not agree with everything he has to say, but every essay will at least provoke thought. Unfortunately, if you've read his weblog, you probably don't need this book. Except for short introductions before each essay and a different organization, this material appears to be the same as his weblog.

This is not necessarily a bad thing. If you prefer reading a book to the on-line experience, the book is a really good read. The book is organized by topic, unlike the weblog, so it is easier to learn more about a particular topic.

If you have never read Sink's writings on line and are thinking about getting into the business side of software, this is a great book to ease you into the weird world of business. If you are already very familiar with his weblog, you may not get much out of the book.