DSL renaissance
During my last post, I had a few thoughts on domain-specific languages, too. Languages like Ruby and Groovy have really led the way in the last few years in a renaissance for embedded domain-specific languages.
I think for certain problems, DSLs are a beautiful solution. I find it hard to get excited about the more model-y forms of this like Microsoft’s software factory stuff or really the whole term language oriented programming. Maybe that’s because I see DSLs as a tool to use, not a new way to program. I believe that the bulk of an application will be written with a general purpose language for a long time to come. DSLs are a great way to allow users to control parts of an application in terms they understand, without forcing them to also learn and use a general purpose language. They can also be useful within an application if you need a more succinct way to represent well-defined domains of knowledge, rules, etc, particularly if the details change frequently.
Some people have advocated radically different paradigms based on models or graphical programming techniques. Personally, I’m not buying it. I don’t think it’s an accident that we program in textual programming languages. Textual languages are the pinnacle of what humans have developed for symbol representation and manipulation. For programming, nothing beats text for its combination of information density, precision, input speed, human understanding, and machine understanding. I think programmers are going to be typing characters into text editors for a long, long time to come.
Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for 
to consider:
1. typing for decades can cause arthritis.
2. humans think in symbols (icons) not necessarly text (which is a subset of symbols).
3. Would you consider VoiceXML a DSL?
On #2, I don’t see the limited symbol domain of text as a problem, rather I see that as a strength as it allows precision and automated processing. I think text is a pretty flexible system – I’m willing to stick with it.
On #3, I consider XML-based languages to be DSLs, but then I’m willing to take a pretty wide interpretation of the term. However, I think most XML-based DSLs are fairly bad as DSLs due to their verbosity. I think either external DSLs built with tool support from language tools or embedded DSLs in general-purpose languages that have good support for them are much better options.
Consider the Java Swing LayoutManager classes. Is laying out a graphical form easier if you have a VisualBasic style form editor, or if you have a text editor and GridBagLayout objects?
Consider software architecture. Is it easier to get a high level overview of a component using a UML diagram or looking at source code?
Text is a new phenomenon. Vision is an old one. We have fairly well developed vision because we were at one time hunters. Humans can easily discern between two colors. Or look at three objects and tell which one is bigger. Humans are very bad at looking at two instances of “.x = 486″ and one of “.x = 490″ and realizing that the width of two boxes is different.
To harness the power of our biology I would recommend using colors, shapes, and size to communicate information. I really like those widgets that do a frequency count of keywords and then render the common words in a bigger font. (UserScripts.org used to do this… don’t know the name of the technique). That was a communication medium that harnessed our biology! Very cool.
I too think we’ll use text editors for a long time… but I think the cause is developer’s lacking imagination rather than a test editor’s fitness of purpose.
On layouts, I think clearly VB is easier in that choice, but I think this is a false dichotomy. Clearly there are lots of possibilities in between these two extremes. I don’t know much about layout stuff, but I’m sure there are DSLs out there that lie in between writing GridBag code and pushing pixels on a grid. The VB editor isn’t doing the same thing either – it’s giving you a pixel-perfect rendering, not a resizable layout. I’d be willing to bet that using a DSL could be even faster and more efficient presuming you knew what you wanted to create. But, my point in the post was really that while domains may have DSLs and we will use those DSLs, we will still spend the majority of our time writing code in a general purpose language in a text editor.
I think there is still a load of room for improvement in the way text editors convey information. IDEs have improved rapidly at leveraging syntax highlighting, marking error occurrences, code folding to hide unimportant stuff, indicating whether a method is overriding another method, displaying diffs against an SCM, etc. But those are visual editor improvements, not changes in the code itself. I distrust any part of my program that doesn’t exist somewhere as text in a file.
The benefit of text is that it is precise. Writing code is necessarily an exercise in precision given the target (computer) is kind of a stickler for it. Our visual systems are phenomenal but they are not designed for the kind of precision a language demands.