We did a programming language for a project. It was a clinical rules language. The distinguishing features of it were the data model (it had first class access

We did a programming language for a project. It was a clinical rules language. The distinguishing features of it were the data model (it had first class access to the temporal data model we had on the back end), and that we kept the tri-state model of SQL with values and NULL. Other than that it didn't have any real structured types, and just few high level actions. It was a straightforward project, ALGOL-esque, basic control structures. It compiled to Java source code, and the resulting classes loaded in to the app server. We used a "compiler compiler" tool, rather than doing it ourselves. It gave us an AST that we then walked. First time doing anything like that, especially with a tool like that. Especially in an ALGOL like language, getting the expressions to work is the "hard" part. That's where your "napkin to white board to syntax file" falls apart with reduce errors and what not. But when you get it to work, it's magic. When you get "a = a + 1" to work, and know that where 1 line of code works, 10000 lines of code will work, it's an amazing feeling. You just build the things a piece at a time, testing all the way. In the end, we had an unresolved precedence issue (as I recall), but we never bothered to fix. The funniest unexpected outcome was the classic SQL model of using NULL. Simply, 1 + NULL = NULL, and we expanded that to all expressions. It kind of fell apart in something like: IF A = 1 AND B = 2 OR C > 3 THEN... If any of those variable (A, B, C) was NULL, the entire expression evaluated to NULL, which was false. It took me by surprise when it happened, but, "duh", of course. I simply changed the NULL rule to no apply to boolean operators. Instead of evaluating to NULL, I had them all evaluate to FALSE, and that fixed that. Looking at Wirths work (Pascal, Oberon, etc.), you'll see that compilers can be simple. They're work, but they're simple work. We obviously make them more and more sophisticated all the time, but your compilers don't need to be that way to be effective, productive, and useful. We created thousands of lines of code using that language, it solved the problem very nicely that it was supposed to do. Runtimes can be hard, but that's a separate problem.