Fowler's current focus is domain-specific languages, and almost all DSLs aim to simplify a programming problem. But can business-oriented DSLs evolve to a point where business managers and analysts can assemble their own systems using a DSL?
In Fowler's analysis, the prognosis for that occurring are not very good:
One of the original aims of COBOL was to allow people to write software without programmers, and we know how that worked out. So when any scheme is hatched to write code without programmers, I have to ask what's special this time that would make it succeed where COBOL (and so many other things) have failed...
Programming involves a particular mind-set, an ability to both give precise instructions to a machine and the ability to structure a large amount of such instructions to make a comprehensible program. That talent, and the time involved to understand and build a program, is why programming has resisted being disintermediated for so long.
Instead of DSLs that business managers use to write programs, DSLs readable by business people are of possibly more value:
The sweet spot ... is in making DSLs business-readable rather than business-writeable. If business people are able to look at the DSL code and understand it, then we can build a deep and rich communication channel between software development and the underlying domain...
With a business-readable DSL, programmers write the code but they show that code frequently to business people who can understand what it means. These customers can then make changes, maybe draft some code, but it's the programmers who make it solid and do the debugging and testing.
Fowler also points out that business analysts routinely write large amount of spreadsheet macros and code that analyzes data via spreadsheets. That rather important business functions often depend on such spreadsheet-based code illustrates business managers' desire and interest to specify behavior and rules on their own.
What do you think of the concept of business-readable DSLs? Have you encountered such DSLs in your experience?
IMHO DSLs have only a chance to succeeed if they allow the user to express >what< he wants to be done. As soon as they have to be extended to allow the user to define >how< something is to be accomplished it starts to get into programming and it is only a question of time till a programming depth has been reached at which the user cannot follow any more. If the program is very simple that depth might not be reached. But this also means that the program cannot do much more as, say, Hypercard. IMHO DSLs are useful as long as they represent an abstraction at a level the user can understand. The added value delivered by the DSL is that level of abstraction accessible to the user.
If you sit down and define a graphical interface for some system with very rich functionality you realize after a while that it gets more and more difficult to make all the functionality accessible through a graphical interface. Somewhen you might reach a point where you don't see a way any more to express some functionality graphically. This is IMHO where DSLs set in: you define a "language" simpler as the root language with which the system was programmed in that also the user can understand. And then you give the user a way through this DSL to express >what< he wants to be done. All this has nothing to do with being able to replace the developer with the end-user: the developer has simply another task to get done which is implementing the DSL.
> What do you think of the concept of business-readable > DSLs?
Not sure what to make of the whole idea of "end user languages"? It's like saying we attempt to simplify maths by making it's syntax more verbose and provide some cute visual hints. No one expects it will turn layman into readers of the proof of the Poincaré conjecture.
Excel "programming" succeeded because it doesn't require much more skill than using a calculator and everyone already learned to use one in school.
Another issue is the provision of domain specific extensions ( macros and friends ) for general purpose languages. Here the problem is mostly a matter of tool support and I like the idea if for nothing else than because writing a tool that is capable to deal with a language L and domain specific extensions of L will turn out to be a better tool for L in the end - more abstract, better modularization etc.
> Not sure what to make of the whole idea of "end user > languages"? It's like saying we attempt to simplify maths > by making it's syntax more verbose and provide some cute > visual hints.
All right. Let's say you have a shop floor manufacturing control system where you can define different lots. Each lot defines carriers with raw material. For each lot you can say which type of machine the carriers need to visit in what order, what production "recipe" to use for the lot for each machine type, and so on. All this can be defined by the user with some DSL.
Now what happens in the background when the user has started the production of the lot is much more complex:
* The planning system needs to be triggered. It created a new plan taking into account which machines of which type are available. If not available how long does it take to change production recipe? Would that be a better solution? Etc.
* Some robot needs to grab the material and move it from one machine to the user.
* When some machine goes down, the planning system needs to create a new plan re-assigning carriers to different machines.
* And many other things.
The point is what happens in the background is dawn complicated. The end-user has no change to program all that. But he has an interface, which is the DSL, with which he can say what wants to get done.
> Not sure what to make of the whole idea of "end user > languages"? It's like saying we attempt to simplify maths > by making it's syntax more verbose and provide some cute > visual hints. No one expects it will turn layman into > readers of the proof of the Poincaré conjecture.
In your example, the layman is by definition a novice in math - potentially a curious one but a novice nonetheless. Making the language of math simpler isn't going to help because thinking mathematically requires years of training. In their own domain, users are already thinking on an expert level. A language customized to their needs is simply giving them a means of expressing knowledge they already have.
Recently I helped an administrative department at my university implement a vendor package. A core task to be done was defining what constitutes a curriculum for each major. At our university, it can be done at the department or college level. The vendor provided a simple DSL and IDE customized for creating these rules and then trained the users, none of whom had a technical background. I was skeptical in the beginning. Surprisingly, the users did well without IT help.
First, using COBOL as the base analogy/metaphor for "user level programming" fails because COBOL, to quote a former colleague, is "just assembler with big words". It is not a high-level language; much of what is done in C can be done in COBOL (and is, sadly).
Second, the notion that users are capable of building anything more data sophisticated than a spreadsheet (think, 0 normal form) is folly. They don't; the spreadsheet metaphor mitigates against that. And with naive' data structures, one ends up with folly like xml :) .
The issue devolves, as it always does, to whether it is more important to have robust (ACID based) data structures which support intelligent multi-user access; or individual autonomous super-calculators (what IBM had in mind in 1981).
Something I'm always trying to get into the heads of people who are enamored by shiny new tools is that the language and the tools don't fundamentally change the task. Just like a nail-gun doesn't make me a carpenter, a DSL isn't going to turn a business expert into a programmer.
The fundamental challenge of business related programming is taking fuzzy requirements and translating them into a rigidly literal program is not solved by newer tools or better languages. It may make the the programmer more efficient and/or effective but they still do the same basic thing.
Having said that, I see DSLs as having the potential to be like an abstraction layer in a way that OO is used (when used effectively.) Basically, it doesn't get rid of the underlying complications, it just allows the developer to focus on one part of the problem at a time. The developer will use this language but also understand what it translates to in a more general language. There's a benefit of making the language readable to the business person but it can be dangerous because natural language is very dependent on interpretation. A simple example: what does 'by September' mean? Some people take it to mean 'by the first of September'. Other people will take it to mean 'by the end of September'. This is a huge difference but there's no one right answer. Great care must be taken to ensure the 'readable' language is not at all vague and I don't know that this is feasible or that it guarantees there will be no confusion.
> Something I'm always trying to get into the heads of > people who are enamored by shiny new tools is that the > language and the tools don't fundamentally change the > task. Just like a nail-gun doesn't make me a carpenter, a > DSL isn't going to turn a business expert into a > programmer.
Very true. However, the carpenter's value isn't in knowing how to use the tools, it's in knowledge of how to build cabinets, a porch, a house, etc. The users are the experts and we're trying to pull information from their heads. Trying to marry the two domains has been tricky. In the example I gave earlier, about the vendor I worked with recently, the DSL fit perfectly for the task. It was a tiny language using the users' jargon, a simple if-else for branching, and a simple looping mechanism. The users did great with it.
> > Something I'm always trying to get into the heads of > > people who are enamored by shiny new tools is that the > > language and the tools don't fundamentally change the > > task. Just like a nail-gun doesn't make me a carpenter, > a > > DSL isn't going to turn a business expert into a > > programmer. > > Very true. However, the carpenter's value isn't in knowing > how to use the tools, it's in knowledge of how to build > cabinets, a porch, a house, etc. The users are the experts > and we're trying to pull information from their heads. > Trying to marry the two domains has been tricky.
The skill of a business programmer is taking the ideas of the expert and converting them into reality in the form of a program. Expertise in tools is a key part of this skill. This is perfectly analogous to the work of a skilled trade like a carpenter. They take the requirements of the customer and make them reality. Giving a carpenter better tools may make him more efficient and effective but giving those same tools to a designer will not make him/her a carpenter. It's not that designers can't do carpentry or that business people can't learn to program but that tools don't make people skilled.
> In the > example I gave earlier, about the vendor I worked with > recently, the DSL fit perfectly for the task. It was a > tiny language using the users' jargon, a simple if-else > for branching, and a simple looping mechanism. The users > did great with it.
But someone with programming skills reviewed their work right? I predict that as time goes on, you will find that there are issues with what the users created.
I had an experience with a client years ago which has always informed my work with domain experts. I was given a task to automate a process that a domain expert was doing using spreadsheets. I was given 4 steps to automate. I was told to follow them exactly. They were very specific when read literally and there was no room for interpretation.
I implemented the 4 steps exactly as they were given to me. When the user tested the processes, his immediate reaction was "this isn't what I wanted!" He then began to rattle off all kinds of details about what really needed to happen.
Again an again I encounter this same issue. When the process is first defined, it's very simple and straightforward. Then as time goes on, I start hearing things that make me realize it's not so simple. By the time we are done it's pretty damn complicated. I see a lot of my job as getting from 'this really is simple' to 'this really is complex' as fast as possible. I spend a lot of time running through thought experiments with the domain experts to make that happen. I just don't see how that will happen if you plop a tool in front of them have them write what they think is the proper description of the process.
A lot of my maintenance experience has been with tools that were first given to users who ultimately failed at programming. This is a worst case scenario. The developers have to support and enhance what the users did with tools that don't address the needs of professional developers. I don't see how DSLs change anything.
This topic is something that I'm reminded of every time someone tries to introduce a "rules engine" that the business owners can maintain. Such efforts end in misery (or reclamation by IT support staff) because rules engines don't do the analysis that a technical human typically does. For example, I will never trust any rules engine unless it can say, "you told me that bananas are yellow, but this old one is brown and this young one is green. What do you want me to do about them?" And that's a simple scenario.
This gets into the issue of validators vs. generators, but that's a topic for a different, much longer, rant. (hint: I believe that tools that validate what you create are much more flexible and ultimately useful than tools that generate what you "want". Think CASE/UML.)
> > > Something I'm always trying to get into the heads of > > > people who are enamored by shiny new tools is that > the > > > language and the tools don't fundamentally change the > > > task. Just like a nail-gun doesn't make me a > carpenter, > > a > > > DSL isn't going to turn a business expert into a > > > programmer. > > > > Very true. However, the carpenter's value isn't in > knowing > > how to use the tools, it's in knowledge of how to build > > cabinets, a porch, a house, etc. The users are the > experts > > and we're trying to pull information from their heads. > > Trying to marry the two domains has been tricky. > > The skill of a business programmer is taking the ideas of > the expert and converting them into reality in the form of > a program. Expertise in tools is a key part of this > skill. This is perfectly analogous to the work of a > skilled trade like a carpenter. They take the > requirements of the customer and make them reality. > Giving a carpenter better tools may make him more > e efficient and effective but giving those same tools to a > designer will not make him/her a carpenter. It's not that > designers can't do carpentry or that business people can't > learn to program but that tools don't make people > skilled. >
The carpenter understands what a cabinet, a porch, a house etc., is because everyone knows what they are and the basic design of a cabinet etc., hasn't changed. When a customer asks for a chair, he is already implying a design. That's not always possible in software, however. Don't you think that's the fundamental problem?
In my humble opinion, if music can be expressed on a piece of paper, surely there must be a way to convey business requirements in a precise manner!
> The carpenter understands what a cabinet, a porch, a house > etc., is because everyone knows what they are and the > basic design of a cabinet etc., hasn't changed. When a > customer asks for a chair, he is already implying a > design. That's not always possible in software, however. > Don't you think that's the fundamental problem?
I mean, even commonly used terms/phrases like "distributed application", "thread", "process", "lock", "mutex", "enterprise software", "singleton" can mean different things to different people depending on the context.
> But someone with programming skills reviewed their work > right? I predict that as time goes on, you will find that > there are issues with what the users created.
Actually, no. What could have been reviewed? System issues weren't a consideration, the language took care of programming pitfalls for them. Application issues? They're the experts in it and they did all the testing. The vendor designed its product specifically so end users had control.
I'll let you know if there are any long term problems. To date, I've had zero emails about it. All support has centered around extracts from other systems and security.
> All right. Let's say you have a shop floor manufacturing > control system where you can define different lots. Each > lot defines carriers with raw material. For each lot you > can say which type of machine the carriers need to visit > in what order, what production "recipe" to use for the lot > for each machine type, and so on. All this can be defined > by the user with some DSL.
So what? Every computing task can be defined as a task within a DSL. Let's say image manipulation in Photoshop. Instead of using menus, rulers, selection dialogs, visual actions in the workspace etc. one can also provide a language of Photoshop commands. For some tasks this isn't even far fetched. Think about programmatic image creation using the dot-language of the graphviz tool. From simple forms to complex environments - there is nothing that can't be matched by a DSL.
The question is just whether or not it is a good idea to throw a programming language on a user who can also be served using nicely organized standard or custom UI elements whereas the programmer doesn't have to constrain his thoughts towards an end-user DSL for the purpose of communicating ideas?
Flat View: This topic has 26 replies
on 2 pages
[
12
|
»
]
Previous Topic
