Don't build a DSL (except for when you have to)

The advice from everyone who's ever built a Domain Specific Language (DSL) is: don't. Language design is hard. Language implementation is harder. Making your users program in a language you invented is a fool's errand. So, why did we build one?

The existing solution

Have you built an actuarial model in Excel? It's amazing, in a somewhat horrifying kind of way. It's a massive undertaking. You are expressing model logic in individual cell formulas, scattered throughout many sheets within a workbook. Often times, workbooks grow to the limits of what Excel will manage to open and run on a single computer. But, actuaries know their tool. You know the Excel formulas instinctively, and you can follow the logic of a convoluted model that I wouldn't even attempt to parse. So, what's the problem? And why is a DSL the solution?

The problem

The problem is twofold: clarity and modifiability. Yes, an Excel pro can follow the chain of formulas through the cells of an audit spreadsheet to eventually understand what the model is doing. Is it easy? Is it clear? No. If only there were some way to clearly define the logic of a model, and let that automatically be transformed into the mess of Excel formulas. That would be nice. Especially when we consider the modifiability problem. When an actuary needs to update a model in excel, they are touching formulas inside of many cells, and potentially breaking parts of the sheet they can't even see, while also likely needing to make the same update in multiple Excel workbooks where the model is replicated. This is not fun, to say the least. If only there were some way to have our logical model updates automatically be propagated throughout all the data we cared about. That would be nice.

The current answer

Of course there already is an answer to this: just let users use a GUI to specify what kind of model they have, and what data to run it on, and have the computer automatically generate spreadsheets. The catch is that "specify what kind of model" part. Actuarial models are complicated. Specifying complex mathematical logic through a system of dropdowns, dialog boxes, and draggable flow chart arrows is insanity. Humans actually already spent thousands of years developing a system of formal mathematics to be able to precisely communicate ideas beyond simple pictures. Computer programming languages are formalisms in this mathematical tradition. Precisely specifying an actuarial model is hard, but it shouldn't be made harder because of a cumbersome user interface. So if the traditional graphical approach is a bad way for users to get this job done, how should they specify their models?

The solution

We still need Excel, since it's an industry standard. We can use Excel to communicate with all stakeholders because everyone knows it. But, for clarity of understanding and easy of modification, Xval provides Xact, our Domain Specific Language.

The main benefit of a domain specific language (as opposed to a general purpose language like Python), is its clarity within the domain it is designed for. In a general purpose language you typically need to re-purpose general data structures and write custom operational logic. This dance tends to obscure the "point" of what you're doing. General purpose languages are powerful because they work for any problem. But they are cumbersome because they have to work for any problem. However, a DSL can make assumptions about the computation in order to dramatically increase clarity. If you're always going to be applying the logic in a column to every row, you don't need to write code to do that, the DSL bakes in that assumption in order to keep the important logic front and center. Actuarial modeling logic is complex enough that the thought of building some sort of drag-n-drop flow box GUI makes me nauseous, so this is one of the rare cases where a domain specific language hits the sweet spot between flexibility and power.