Toluu

Martin Fowler's Bliki

A cross between a blog and wiki of my partly-formed ideas on software development

RulesEngineYesterday

Should I use a Rules Engine?

A rules engine is all about providing an alternative computational model. Instead of the usual imperative model, commands in sequence with conditionals and loops, it provides a list of production rules. Each rule has a condition and an action - simplistically you can think of it as a bunch of if-then statements.

The subtlety is that rules can be written in any order and the system can evaluate them in any order. A good way of thinking of it is that the system runs through all the rules, picks the ones for which the condition is true, and then evaluates the corresponding actions. The nice thing about this is that many problems naturally fit this model:

if car.owner.hasCellPhone then premium += 100; if car.model.theftRating > 4 then premium += 200; if car.owner.livesInDodgyArea && car.model.theftRating > 2 then premium += 300;

A rules engine is a tool that makes it easier to program using this computational model. It may be a complete development environment, or a framework that can work with a traditional platform. Most of what I've seen in recent years are tools that are designed to fit in with an existing platform. At one time there was the notion of building an entire system using a tool like this, but now people (wisely) tend to use rule engines just for the sections of a system. The production rule computational model is best suited for only a subset of computational problems, so rules en

DslExceptionalismDecember 22 2008

One of the tricky things about writing about external DomainSpecificLanguages is that I'm walking through territory already heavily tracked by the programming languages community. Programming language research has always been a popular area of academic activity, and I'm the first to admit that I don't have anywhere near the depth in this topic as many people who've been studying in this space for years. So inevitably the question comes up as to why such a noob as me thinks he can write a book in this well trodden ground?

The primary reason is that nobody else has written a practitioner-oriented book on DSLs. I like topics like this that are well-trodden but not well written about. However as I've spent time walking these pathways I think there's another factor in the works.

There's a lot of work on programming languages out there, but almost all of it has concentrated on general purpose programming languages. DSLs are seen as a small and simple subset of general purpose programming thinking. As a result people think that what's true for general purpose languages is also true for DSLs (with the implication that DSLs are too small to be worth thinking much about).

I'm increasingly of the opposite conclusion. The rules for DSLs are different to the rules for general purpose languages - and this applies on multiple dimensions.

The first is in la

AcademicRotationDecember 17 2008

A while ago I was chatting with a post-doc on his way to an academic career. He was asking me about research topics wanting my input as he felt I could inform him on what would be research of practical use. I wasn't very helpful, but I did mention that the best way to do this would be to spend some time in industry to get a feel of how software development works in the wild and what problems could do with some research effort.

His answer to this thought was very troubling. He said he'd be up to do that, but if he spent time in industry that would ruin his chances of getting a job in academia. Competition for academic jobs is high, and what they look it is your publication history. A year or two in industry would create a gap in your publication history that would be lethal to your job prospects.

The divide between academia and industry has always been an awkward one for software (as indeed for other professions). My contacts with academia have been stilted at best. The academics I respect are, I'm told, not highly regarded within academia because the things that I count as useful are usually dismissed by the academic community.

A good example of where this came to a head is the patterns community. Those involved in the patterns world were keen to look at practice to discover, package, and document techniques that had been proved through experience. But this is in direct opposition to academic standards which conside

UpcomingTalksDecember 15 2008

Pramod Sadalage is one of the leading innovators of evolutionary database design.

Our profession seems to be constantly hampered by the communication barriers we erect for ourselves. For enterprise systems one of the most annoying barriers is the one between application developers and database people. Although much of my early years involved databases and data modeling, my involvement with object-orientation cast me firmly into the application development side. As a consequence I haven't spent much time talking to people from the database community.

On January 9 I get a rare opportunity to fix that as I'll be speaking at my local chapter of DAMA with my colleague Pramod Sadalage. Pramod played a central role in the development of evolutionary database design techniques in ThoughtWorks as a DBA who closely works with development teams. His also written valuable books on Refactoring Databases and Continuous Database Integration. So, as you might have gathered, he knows all the material backwards and I'm glad to be invited along for the ride.

We'll be talking about database refactoring and techniques for evolut

BusinessReadableDSLDecember 15 2008

Will DSLs allow business people to write software rules without involving programmers?

When people talk about DSLs it's common to raise the question of business people writing code for themselves. I like to apply the COBOL inference to this line of thought. That is that 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.

I do think that 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. It's also why many "non-programming" environments end up breeding their own class of programmers-in-fact.

That said, I do think that the greatest potential benefit of DSLs comes when business people participate directly in the writing of the DSL code. The sweet spot, however 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 s