Monday, December 7, 2009

Problem Domain Languages

It seems that I have gotten into a discussion of "problem domain languages" which is a language that only relates to a specific area such as controlling a robot. A problem domain language would let you move the robot and would consist of statements such as "go forward 3 feet" and "turn left".

Firemox, Wagic, and Forge have each created their own problem domain language for cards. The problem is "How to efficiently encode a Magic card into a computer programming language?" and the solution is to invent your own "little" computer language. Please note that problem domain languages are the opposite of general purpose languages such as C++ and Java.

All problem domain languages have approximately the same pros and cons. On the plus side the problem domain language will be more precise and shorter than a general purpose language. Problem domain languages can be parsed during runtime which promotes "late binding" and is more flexible than statically compiled code.

The negative side of problem domain languages is that they are hard to write because you have to take into consideration EVERYTHING that you want to do. If you make a mistake when you are creating your problem domain language, you might have to completely change your language and start again.

Creating a problem domain language is often very fun. You can use the Interpreter and Command software patterns to create a nice, little language for yourself. The easiest way is to make your own computer language is to create command objects that implement variable declarations, "if" and "for" statements. Now just put a few command objects together and *voila*, you have just invented your own (crappy) computer language.

Typically you would create a different command object for each part of the problem domain. The problem domain language for a robot would have a TurnLeftCommand and GoForwardCommand.

And what would this world be without Wikipedia? They have a pretty good explanation of problem domain languages here.

12 comments:

EOL (Eric O LEBIGOT) said...

Thank you for sharing!

In my experience, the main difficulty with problem domain languages is not that you have to plan with enough flexibility so that you can satisfy every need you will have; in fact, your program, whether it uses a problem domain language or not, will have to satisfy all the needs of the problem at hand, and this has to be planned anyway.

The main difficulty I encountered was to not make the problem domain language too general. For one thing, this complicates the implementation. Another drawback is that it makes solving your particular problem harder.

Thus, my experience is that using a problem domain language forces you to walk on a thin line, between creating a language that's too specific and restrictive (changes can become onerous), and a language that's too general (the implementation can become onerous, and the domain specific code too convoluted).

Anonymous said...

Never liked those concept. Forth, Factor and other syntax-less languages can do same things, yet with more effcicency and flexibility.

Bill Christian said...

Actually had some initial success with Ruby. Ruby supports mixins, which allow you to introduce functionality at runtime when needed. Cuts out some of the complexity you describe.

Forge said...

I like the idea of problem domain languages but I haven't really ever used or created one.

I'll check out Forth and Factor. I've heard good things about Ruby also.

On Wednesday I'll talk about how MagicEngine and Incatus encode Shock and Royal Assassin. The programs use a general purpose language but the syntax is so short it seems like a problem domain language.

nantuko84 said...

Bill Christian>
hm, could you bring any examples how mixins can help with domain language or any language in your application?

I've just read about mixins in Ruby and really liked them, moreover I found that Groovy has mixins as well that is great as I use it in my program. any examples then?

telengard said...

Slowly, over the past year or two, I seem to be creating a DSL for creating abilities from XML. I started out with hardcoded pieces in C++, then broke the abilities out into C++ classes, now I have broad generic abilities that take lots of conditions to tailor their behavior.

Slowly becoming a ability building toolkit. I just wish I could do this with scripts (don't want to pay the performance penalty).

This is an example of what a piece definition looks like now.

http://pastebin.org/61941

Anonymous said...

I've created a C# include for 'generically' creating problem domain languages, so that general functionality is pre-implemented, and that only specific functions and types have to be encoded. It works pretty well, and I'm currently using it to make a generic mini-language as well. :) Once the initial effort is put in, the following effort-to-effect ration is pretty good. Although converting ~3K cards could be a real pain. If Forge was in C#, I would help (ie, donate code), but as it is, I don't know enough.

Rob Cashwalker said...

Yesterday I suddenly realized that there would be a syntax conflict between the parameter delimiter "/" in the P/T of a Pump ability keyword and the Count$ function.
Luckilly, there are very few current cards that need Count$ in the P/T field for pump abilities, and they don't require any delimiters.

I designed the Count$ function while doing Draw and Damage spells, where "/" wasn't already used for something. Now, trying to apply the technology to another keyword I realize the flaw of my design process.

PsudoBuddha said...

Actually with JRuby, it would not be hard for you to add support for loading cards from a file. The developers report that the Java version is 2-5x faster than the native C version because it can rely on Javas runtime rather than the standard one.

Forge said...

I thought the problem how to encode Magic cards but I think the real problem is the complicated rules engine. The first problem is that you have to understand the rules to program them, duh I know but it is hard to know ALL of the complexities. And the second problem is that the rules engine is just going to be complicated no matter how you slice it.

Anonymous said...

Dear Author mtgrares.blogspot.com !
It agree, rather the helpful information

Ailsa blog said...

Hey There,

I like your blog post.Great work.keep it up.My blog is also getting good rank in search engine.Can we share a link together? If yes, please let me know at ailsalinksupport@gmail.com.

Thanks
Ailsa