I had a few thoughts today on a direction that I think that software will be taking and that I think is important to document. This idea ties into my post earlier today on generic programming and domain specific languages. Take the followig three concepts as a set:
- Generic Programming
- Domain Specific Languages (DSLs)
- Intentional and Automatic Programming
Generic programming, as mentioned earlier, is programming that invokes a metaprogramming facility from within a hosting language (this is a part of the wikipedia writeup here, and I like it a lot). It provides a means of extending a programming language to model higher level constructs, that which are much closer to the domain problem being addressed.
What generic programming provides is a means of being able to create extensions to languages that allow new syntaxes to be created that can be used by those working in the domain to be able to solve problems (instead of computer scientists) because they can utilize the computer to solve the problem, not write a program to solve the problem.
Now, if you are following the movement of the people touting DSLs, you might say that what I just described is the exact definition of domain specific languages. And I agree. And that is exactly why generic programming is important.
But whither to use generic programmingx or a DSL?
That is the question. Here is my answer. Generic programming remains in the domain of the computer programmer, ie the computer scientist worried about syntax and bit twiddling. DSLs fit in with those who are trying to solve business problems. I'm not going to go as far as to say that this is a business analyst, but it is potentially (and preferably) a person more atune to the problem domain then to the other problem domain of knowing how to program computers.
My point is, programmers will need to work to create DSLs out of existing languages (be they C++, C#, Ruby, ...), and Domain Specialists will use those DSLs to solve the higher level problems.
If you've read other posts of mine, you will find that I think that programming is too difficult. It's not that its necessarily hard to do, but that it is tedious to do. Hence my other ramblings on things like P#, a pattern based language that gets rid of a ton of boiler plate coding that I just hate to type everytime I code something.
Now, lets move up one level, or many levels. I really believe that intentional and automatic programming (IP and AP respectively) are requirements for the future, and that DSLs are an important component in facilitating both of these into realization.
I personally see DSLs fitting into a role in IP/AP where the problem domain is modeled, and then an entity can automatically integrate and deploy software. DSLs would in a way function as the implementation of well defined activities that solve business problems. The DSL code could perhaps be generated out of a software factory where the domain specialist can check a few items off of a list and get an activity that solves the problem, and that is also checked against requirements to solve that problem.
Then, a similar process could be used that can integrate thse activities into higher level processes. Note that each individual activity could be implemented via a different DSL (see my earlier posts about systems most likely being implemented in multiple DSLs), and the activities glued together via a software factory just as the individual activities generated. And checked against requirements to work. And automatically deployed and operated as the computer generated the code, and knows how to deploy and run it through the building of the DSL through generic programming.
Perhaps the eventual goal of fully automatic programming is not obtainable, after all at some point the computer must be told somethign about what to do, but surely this would be a great step forward into being able to quickly and reliably build software, and to business relying of IT to become agile.