Artima Developer Spotlight Forum - Martin Fowler on Business-Readable DSLs

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Artima Developer Spotlight Forum
Martin Fowler on Business-Readable DSLs

26 replies on 2 pages. Most recent reply: Dec 25, 2008 3:26 PM by Aslak Hellesøy

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 26 replies on 2 pages [ « | 1 2 ]

Oliver Plohmann

Posts: 13
Nickname: olli
Registered: Jun, 2008

Re: Martin Fowler on Business-Readable DSLs

Posted: Dec 17, 2008 12:40 AM

> 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?

No, this is exactly the point I was making. Complex functionality can only be represented in graphical way up to a certain extend. There is a point where the next little bit functionality can only be represented in a graphical UI with a lot of extra effort. The extra effort rises more and more and somewhen there is a point where you need to give up.

I'm not talking about my home grown theories here. This is what the development team I developed this shop floor control system with one day were faced with. Then we had to throw the graphical UI away and define a simple language for the end-user. And that was 10 years before anyone had invented the term DSL ...

Cheers, Oliver

Chris Agmen-Smith

Posts: 3
Nickname: agmenc
Registered: Feb, 2006

Re: Martin Fowler on Business-Readable DSLs

Posted: Dec 17, 2008 3:20 AM

There's a very specific type of DSL that offers a different perspective on where DSLs can be valuable: the automated testing tool FIT. Developers usually build a DSL on top on FIT.

FIT lets business people write specifications in HTML tables. These are executed as tests. The language conforms to a limited, business-related set of operations. The business can express themselves in a language custom-designed for them, where each term carries a specific meaning for the system under test.

Such tests provide a three-way communication interface between the business, developers and the system. This removes many possibilities for miscommunication. Incomplete specifications are harder to write, as inputs, outputs and interactions must be precisely enumerated for the test to run.

So the domain for FIT tests is customised to be that of the system under test. But the business aren't writing the system in this DSL, they're writing the tests that prove that the system works.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Martin Fowler on Business-Readable DSLs

Posted: Dec 17, 2008 6:51 AM

> > 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.

The problem I've run into is that I often have domain experts give me the most common sequence of steps or set of rules as 'the' answer. An if IT isn't watching for issues they start getting backlogged until upper management catches wind of it. Then IT gets blamed.

> 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.

A lot of it depends on the analytical skills of the people writing the code. Your users are programming. I'm very cautious about these things because I see incorrect requirements implemented all the time. A lot of this comes from the users telling us what to do and not what problems they are trying to solve.

Of course, the environment and problems we are trying to address are pretty complex and require a lot of technical acumen. We do provide ways for the users to create rules but it's very controlled. They don't have the power of a language.

Elizabeth Wiethoff

Posts: 89
Nickname: ewiethoff
Registered: Mar, 2005

Re: Martin Fowler on Business-Readable DSLs

Posted: Dec 17, 2008 9:07 AM

Some domains have had their own DSLs for a long time: baseball and softball. Take a look at these Major League Baseball scorecards from 1991: http://en.wikipedia.org/wiki/Baseball_scorekeeping. And this fast pitch softball scorecard tutorial from Australia: http://www.unibaseball.org/images/Softball/Beginning_Softball_Scoring.pdf. These are what the DSL of baseball and softball look like.

The rules are clear and known, the vocabulary is clear and known, and the notation for recording the game process is clear and known. Once you have detailed scorecards, you can generate line scores and box scores, and you can run stats. Computers are obviously good for stats. You can create Strat-O-matic fantasy teams and games. You can write an OCR-like program that reads handwritten scorecards. You can create scorecard software which runs on an iPhone. You can write a computer program that analyzes games for highlights and generates newspaper reports using stock phrases. Whatever.

The DSL of baseball/softball was not invented by a U.S. Naval officer at Remington Rand, or Joe Schmoe with a spreadsheet, or Martin Fowler with a copy of UML Distilled, or a Ruby programmer from Denmark, or the inventor of wikis. ;-) It was largely invented in the 19th century by a newspaper reporter--a language expert and baseball domain expert--with an amateur interest in statistics.

Makes me wonder who should be designing a language for a given domain and what it could possibly look like. And when I say "language," I don't mean just jargon-laden sentences. (I bet every domain has people who speak/write jargon in shop floors, boardrooms, seminars, and blogs.) No, I mean an unambiguous written notation. Being a crusty old fuddy-duddy, I would like to see the DSL tested and refined by people in the domain itself (or by ancillary people such as news reporters) long before a buzzword-happy software developer comes near. Until then, rules and processes aren't ready to be "computerized."

Bill Pyne

Posts: 165
Nickname: billpyne
Registered: Jan, 2007

Re: Martin Fowler on Business-Readable DSLs

Posted: Dec 17, 2008 9:34 AM

> The problem I've run into is that I often have domain
> experts give me the most common sequence of steps or set
> of rules as 'the' answer. An if IT isn't watching for
> issues they start getting backlogged until upper
> management catches wind of it. Then IT gets blamed.

I hear you. I wouldn't want to clean up the mess if we let the users write their own application from scratch in a DSL. Based on my experience with this particular implementation, I think there can be targeted areas users can express their knowledge more effectively than we can gather with our usual analysis techniques.

> A lot of it depends on the analytical skills of the people
> writing the code. Your users are programming. I'm very
> cautious about these things because I see incorrect
> requirements implemented all the time. A lot of this
> comes from the users telling us what to do and not what
> problems they are trying to solve.
>
> Of course, the environment and problems we are trying to
> address are pretty complex and require a lot of technical
> acumen. We do provide ways for the users to create rules
> but it's very controlled. They don't have the power of a
> language.

Our users are doing something narrowly focused with knowledge only they have and a tool that prevents them from doing any damage. They can make logic errors but not system ones. They went through extensive tests using a test document we helped them write.

Slightly off topic but my observation from being in the field since 1992 is requirements, requirements, requirements. You can have the best tools and knowledgeable developers, but it's the requirements that will kill you every time. Anything that helps get knowledge out of the users' heads more accurately is something worth trying IMO.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Martin Fowler on Business-Readable DSLs

Posted: Dec 17, 2008 9:40 AM

> The DSL of baseball/softball was not invented by a U.S.
> Naval officer at Remington Rand, or Joe Schmoe with a
> spreadsheet, or Martin Fowler with a copy of UML
> Distilled, or a Ruby programmer from Denmark, or the
> inventor of wikis. ;-) It was largely invented in the 19th
> century by a newspaper reporter--a language expert and
> baseball domain expert--with an amateur interest in
> statistics.
>
> Makes me wonder who should be designing a language
> for a given domain and what it could possibly look
> like. And when I say "language," I don't mean just
> jargon-laden sentences. (I bet every domain has people who
> speak/write jargon in shop floors, boardrooms, seminars,
> and blogs.) No, I mean an unambiguous written notation.
> Being a crusty old fuddy-duddy, I would like to see the
> DSL tested and refined by people in the domain itself (or
> by ancillary people such as news reporters) long before a
> buzzword-happy software developer comes near. Until then,
> rules and processes aren't ready to be "computerized."

A lot depends on the complexity of the problem at hand. Baseball games are very linear. The above is basically a shorthand for record keeping. It's not specifying any rules or logic or even process. In fact, that language is meaningless without prior understanding of the rules of the game.

I've seen some attempts by non-technical people to define languages. One example was an attempt to create a simple query syntax. It worked for really simple stuff but was ultimately inadequate. I was tasked with making it more usable but the mistakes of the initial creators made it impossible for me to correct without starting from scratch. Most people cannot clearly describe what they mean in plain language. Do you really think they will be able to design decent syntax and grammar? This is something that is difficult even for experts.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Martin Fowler on Business-Readable DSLs

Posted: Dec 17, 2008 9:52 AM

> Our users are doing something narrowly focused with
> knowledge only they have and a tool that prevents them
> from doing any damage. They can make logic errors but not
> system ones. They went through extensive tests using a
> test document we helped them write.
>
> Slightly off topic but my observation from being in the
> field since 1992 is requirements, requirements,
> requirements. You can have the best tools and
> knowledgeable developers, but it's the requirements that
> will kill you every time. Anything that helps get
> knowledge out of the users' heads more accurately is
> something worth trying IMO.

This really what I am getting at. By putting the language solely in the hands of the users, you eliminate at least on human from the requirements gathering process. My experience is that most users are unable to specify correct requirements without help. Often the people with the most knowledge need the most help explaining it properly.

I'm not talking about programming errors at all. I'm talking about incorrect specification. Most domain experts will give an approximation of the real requirements when first asked. The DSL isn't going to askk them if that's what they really mean, as I almost always have to. About 50% of the time, I find that what they initially said wasn't the full story. How do you prevent that from being what is written into the DSL?

In terms of testing, I find that most users do only the most superficial testing until they have had some experience missing bugs. In short, the business users make the same mistakes that everyone makes when they first start working in the field of software. I actually think most everyone in business will ultimately need to have some programming skills in the future and that the gui centric approach to software that has been in-vogue for decades now has actually held everyone back by minimizing the understanding of computers. But there are still skills to be learned.

Elizabeth Wiethoff

Posts: 89
Nickname: ewiethoff
Registered: Mar, 2005

Re: Martin Fowler on Business-Readable DSLs

Posted: Dec 17, 2008 11:16 AM

> Baseball games are very linear.

So are all sorts of things that happen in time.

> The above is basically a shorthand for record keeping.

That's what businesses do. They keep records. Businesses such as sports teams keep records.

> In fact, that language is meaningless without prior understanding of the rules of the game.

Yes, that's why it's domain-specific. You can't understand it without prior understanding of the rules.

> Most people cannot clearly describe what they mean in plain language. Do you really think they will be able to design decent syntax and grammar? This is something that is difficult even for experts.

Nevertheless, that's what a 19th century newspaper reporter accomplished for baseball. I never said just any Joe Blow can. But a good DSL can be successfully taught to Joe Blows all over the world, and is.

The brain of a knowledgeable person parses a scorecard and compiles it into another language, such as English, without lex, yacc, and so on. That's what the authors of the Wikipedia article on "Baseball Scorekeeping" have done with the example scorecard.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Martin Fowler on Business-Readable DSLs

Posted: Dec 17, 2008 1:51 PM

> > Baseball games are very linear.
>
> So are all sorts of things that happen in time.
>
> > The above is basically a shorthand for record keeping.
>
> That's what businesses do. They keep records. Businesses
> such as sports teams keep records.

That's one thing businesses do. It's not the kind of thing that we are talking about, though. Most businesses use databases for record keeping.

> > In fact, that language is meaningless without prior
> understanding of the rules of the game.
>
> Yes, that's why it's domain-specific. You can't understand
> it without prior understanding of the rules.

DSLs in the context of this thread are being used define rules (and/or processes). This is much harder thing to do.

It's quite simple to define a simple shorthand like the baseball example. Defining and enforcing the rules around what's a legal statement and making a computer understand it is a much bigger issue.

> The brain of a knowledgeable person parses a scorecard and
> compiles it into another language, such as English,
> without lex, yacc, and so on. That's what the authors of
> the Wikipedia article on "Baseball Scorekeeping" have done
> with the example scorecard.

That's great and all but what does it have to do with the problem at hand? It's easy to write something that other people can understand. The issue at hand is how you write something that a computer can 'understand'.

Elizabeth Wiethoff

Posts: 89
Nickname: ewiethoff
Registered: Mar, 2005

Re: Martin Fowler on Business-Readable DSLs

Posted: Dec 17, 2008 8:28 PM

> That's great and all but what does it have to do with the problem at hand?

I was deliberately thinking outside the box because sometimes doing so can be helpful.

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

semi-formal languages

Posted: Dec 19, 2008 1:11 PM

> I was deliberately thinking outside the box because sometimes doing so can be helpful.

I would concur: considering what sophisticated user-groups actually do must be worthwhile if you want to make something they would use.

I think of heraldry, and its semi-formal language, the blazon. It is not so precise and logically made as a programming language, but it is much more restricted than spoken language.

Trying to make a user-language completely well-defined and executable might be trying too hard -- the track record seems to support that, at least. Instead, it might be more pragmatic to go only part-way. It seems reasonable that a kind of 'requirements' in a quasi-logical language might be better than totally raw and unstructured.

Aslak Hellesøy

Posts: 29
Nickname: aslak
Registered: Mar, 2005

Re: Martin Fowler on Business-Readable DSLs

Posted: Dec 25, 2008 3:26 PM

I agree with Oliver P. Business people should focus on *what* needs to be done, not *how* it is done.

Cucumber's DSL is designed with this in mind. It provides a DSL for business people to descibe software's behaviour in the spirit of BDD (Behaviour Driven Development).

For more information, see
http://github.com/aslakhellesoy/cucumber/wikis

Flat View: This topic has 26 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic