Blogger: JP Morgenthal
There's many approaches that analysts take to formulate their opinions on a particular topic. I usually formulate a theory based on my own experiences and then look for information that supports or refutes my theory. Unfortunately, when it comes to issues rooted in software development and programming, there's often more opinion than there is fact. This results in a requirement to get "hands on" to help decipher the data. So, I've been playing with building a DSL in Ruby, which resulted in a lot more questions, but no so many answers.
When it comes to Domain-Specific Languages (DSL), it seems there's a strong growing interest on the part of developers, but where, if anywhere, do DSLs have a place? Perhaps it's my enterprise application background, but it seems to me that the number of DSLs can increase exponentially, without having established best practices for development and selection. I also believe DSLs are subject to Darwinian thinning and without acceptance or use they will wither away. Still, DSLs introduce the need for very good documentation, knowledgeable users or both; things many IT organizations have shown general disregard toward due to time and money.
A proliferation of DSLs in an organization dramatically increases the organization's risk surrounding its IT assets; perhaps more so than traditional business logic. For example, one of the biggest issues surrounding legacy COBOL assets in organizations is lack of knowledge about what those programs do and, in some cases, the location of the source code. It makes it very difficult to modernize and sunset these applications; and this was just one language. Now, imagine this same problem 5-8 years out and 10-20 DSLs. While it seems that we should be better suited to think about code as an asset based on our legacy experiences, the truth is many organizations still do not treat code as a first-class asset and the basis for the creation of a DSL is more likely to walk out the door in the brain of the developer than to be captured and properly managed.
On the other hand, DSLs can also be viewed as a means to preserve IT assets. Since DSLs can be encoded in other programming languages, they can be used to protect the organization from the continual, unmanageable change in general-purpose programming languages and available supporting skills. However, I remember my compiler construction course back in college, I was one of 4 out of 27 that was able to successfully complete the coursework. Developing a language is a complex skill that requires deep understanding of the domain and architectural experience; a known limitation in the industry as illustrated by the lack of architects for SOA projects.
One interesting use that I have garnered from my exploration of DSLs is Microsoft's use of them surrounding data management. My research shows many DSL examples can be categorized as advanced application initialization and configuration, but the work being output from Redmond seems to be focused on moving to a 1:1 relationship between the internal memory representation of data and its persistent form.
One can only imagine what they are working on in their well-funded labratories, but if their work on DSLs as represented by LINQ, M and .NET 4.0 are any indication, it would seem that Microsoft is attempting to remove the separation that emerged due to the expensive storage models of the past, which are still prevalent today, and replace them with the a single logical representation that flows from design through execution. A move in this direction would clearly make data more available and usable to the organization without requiring expensive human and machine resources to participate in the process.
Comments