Monday, October 08, 2007

ALT.NET Conference Sessions: DSL

I rummaged Technorati and looks like a lot of people already put up their summaries / impressions of the sessions at the ALT.NET Conference in Austin, TX. Here's some more about some of the sessions that I'm not seeing much discussion about: Domain-Specific Languages for Business Users / Developers The DSL talk started off a little rough (the organizer wasn't there), but Arafat Mohamed stepped up and started the conversation. Just about everyone in the room was there to learn about DSLs and were not really using them in their projects. We talked about what we thought a DSL really was. It seems that just about anything can be a DSL (depending on how specific you are to what domain). According to Martin Fowler, "a domain-specific language is a veneer over an API" (I think that's the verbage he used). He differentiates between an internal DSL (one that is consumed by developers) versus an external DSL (one that is consumed by the users). Martin Fowler has some more information on his website. There is also some information on Wikipedia. One of the primary applications for DSLs that I can think of is a business rules engine. For example, you have a cell phone provider who has complex billing semantics and wants to be able to add new rules easily. There are a lot of concerns with this, however. Developers may not want the analysts modifying the behavior of the system as they may not be as disciplined. On the flip side, managers want the analysts to do the work to keep the developer freed up. It is a delicate balance that can only really be helped by properly training the analysts so that they know the proper practices. You can also avoid problems by creating the proper tooling. Going to the more practical side... Scott Guthrie pointed out that IL had some pragmas that could be used to give the debugger hints on what the original source file was and what line of that source file corresponds to the generated code. He said that they used this mechanism for debugging the generated code from XAML, XOML and the other declarative constructs. You could also use Boo as a meta-language to construct your DSL. In theory, Visual Studio should be able to debug Boo since Boo compiled to IL and _should_ have the line numbers and source file information embedded in the PDB files. (in theory). Boo is also the source of Boobs (the build system with an oral fixation) and Binsor. Oren (Ayende) has a lot of posts regarding Boo. Also, if you want good IDE support for Boo, look at SharpDevelop. If you need to develop your own language from scratch, Antlr seems to be the way to go. The people in the room who had used it said it was better than the old-school lexx / yacc approach. There are a lot of concerns though in creating a DSL in that you would have to maintain it and train everyone how to use it. This reminds me of two things: 1) Wasabi, the language created by Joel Spolsky for FogBugz (linky) 2) The MUMPS System (linky) In both cases, developers will basically have a bunch of work that they can't really put on their resume because their expertise is in an in-house language. A DSL may create the same sort of situation. Also, whoever develops the DSL will be the authority on it and if he/she decides to leave the company without properly documenting it, the DSL will be useless. At the end of the session, I think everyone got a good feel for the positives and negatives of creating and using domain-specific languages. I learned that I would need to think long and hard before considering implementing a DSL and that there are a lot of solutions (Boo, Ruby, scripting) that would require a lot less work up front and would provide fellow developers with some take-aways. Another summary on the DSL session: David Woods

No comments: