The Artima Developer Community
Interviews | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

Programming Close to the Domain
A Conversation with Andy Hunt and Dave Thomas, Part VI
by Bill Venners
April 7, 2003

Page 1 of 3  >>


Pragmatic Programmers Andy Hunt and Dave Thomas talk with Bill Venners about the benefit of programming in a language close to the business domain.

Andy Hunt and Dave Thomas are the Pragmatic Programmers, recognized internationally as experts in the development of high-quality software. Their best-selling book of software best practices, The Pragmatic Programmer: From Journeyman to Master (Addison-Wesley, 1999), is filled with practical advice on a wide range of software development issues. They also authored Programming Ruby: A Pragmatic Programmer's Guide (Addison-Wesley, 2000), and helped to write the now famous Agile Manifesto.

In this interview, which is being published in ten weekly installments, Andy Hunt and Dave Thomas discuss many aspects of software development:

When to Build a Tool

Bill Venners: In your book, The Pragmatic Programmer, you say, "Program close to the domain." What are the tradeoffs of creating a new domain language? I tend to like to do that myself, to build tools that make me more productive. When I suggested a particular tool to a particular manager, he discouraged me with, "but then we'll need to support and maintain the tool." Terence Parr, who wrote ANTLR, said, "Why spend 5 days coding something by hand that you could spend five years automating?" When is it worth it to build a tool?

Dave Thomas: Many people read our advice about domain languages and think we're talking about writing a parser or interpreter, manipulating an abstract syntax tree—as if we're recommending rewriting Java from scratch. We're not. For me, a domain language could be as simple as a half dozen C macros that let me create initial values and data structures. If I'm using a language with decent reflection, a domain language could be something that allows me to configure the system by constructing classes on the fly at runtime. Creating a domain language does not have to involve serious amounts of parsing. In fact, I prefer domain languages that have almost no parser, ideally none at all. So we're not talking about big up-front investment. I think you only do a domain language if the pay back is greater than the investment. It's really that simple.

Andy Hunt: One reason programming is hard in general is that you have to zoom in and out to different levels of detail. You might be groveling around in low-level bits and pointer arithmetic, then zoom out to an abstraction that's close to the business domain. You're always bopping back and forth. That's hard. It's much easier if the user gives you business rules in their domain language. It's easier if you don't have to map the business rules down to very low levels, like a compiler would do. Dave and I are big on using automation. That's why the computer is there. I am very against any technology that requires me to act like a compiler. If I can do a task with a couple of macros that match what the user is saying, as Dave suggested, hey that's a win. Let the compiler take it to the next step. Don't make me do that. Allowing me to stay at a high level is to me the real big advantage of domain languages.

Dave Thomas: But there is a danger of going too far. With some technologies, in particular C++ templates, people sometimes go too far the other way. They try and think of clever ways of using templates to generate compile-time behaviors. Yes, you can do it. Yes, you get real good geek points for doing it. But you end up with totally unmaintainable applications. You've got to be very careful to keep that balance in mind.

Andy Hunt: If you're doing obscure tricks and hacks with templates, that's one thing. If you've got a very nice, clean, 10-line YACC or ANTLR grammar, you're using more tools, but it's also very easy to follow. And it is very easy to maintain, because you've done it cleanly, instead of doing some set of obscure hacks. I think it's OK to introduce complexity, so long as it is actually clean and easy to follow. But going for geek points will kill you.

Page 1 of 3  >>

Interviews | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use