1. Charles can you tell us a bit about yourself and how you came start the Intentional software?
I had a long career at Xerox Palo Alto Research Center after which I went to Microsoft having decided that Xerox is not going to use the technology that has become the software for personal computers and at Microsoft we did some very interesting and popular applications, but I felt that new tools are needed for the future and to do this tool the intentional of the domain workbench I founded the company, Intentional Software Corporation in 2002 and we have been working on it ever since and now we are here at JAOO for the 2nd time enjoying it very much and we brought one of our customers, Cap Gemini, to show how the Intentional technology can be used at a real user problem.
2. What is the vision of Intentional Software for someone who doesn't know anything about it?
The most important thing for us is to separate the problem from the program, the description of the problem that is contributed by domain experts in form of domain code, using the domain workbench and then to use generative techniques to create the program that will run on that computer.
3. What is your implementations vision, what does it look like?
The generative techniques are widely used today and it's really the trend if you look at both domain specific languages and how domain specific languages are turned into running code using generators, there are many such languages and they are very effective in many areas, for example small languages to create a blog or a website are examples of domain specific languages that for example the output is HTML, the website itself. We are bringing domain specificity to a new level and involving domain experts integrate fully into the process so that they can contribute their knowledge in their own nomenclature using their own notations.
4. So what are some of the input forms that you're enabling for domain experts that are working?
This is quite interesting and it was part of the presentation by Henk Kolk from Cap Gemini, who's describing his experience in creating a pension system which are very complicated systems that are written under the tutelage and direction of pension experts. In the past this has been a manual process where pension experts of course had to talk to programmers to create a specification and to know more waterfall model was proceeding to create the final product. With our system the pension experts can express the pension plan in the notation that they are comfortable with. It is a notation that they had used in the past for informal communications, but now they can use it at domain work bench, they can create domain code, essentially a database which then is strong enough for a generator to generate code from.
5. So how were the pension planned costumers interacting with the tool?
The first interaction was to ask them what is the notation that they would like to use and what they would like to say in that notation and this is an approach that is very different from the past, where they were given a particular language, a particular notation and they were asked to contribute with some particular details about the plans. We turned it around, and because they now could say what they thought was important and they could say it in the way that they were comfortable with. That really changed the picture and they become very enthusiastic and created pension plans in a fraction of the time that was necessary in the past. The system is capable of handling practically any notation that are in general use, be it tables, specific nomenclature in several languages in a localized fashion, formulas, boxes connected by lines and so connections can be expressed in any number of ways, so it wasn't a very difficult process for us to accommodate the request from them both in what they liked to say and how they would say it and that made them very happy participants in the software creation process.
The circles and the bubbles are not in the domain code, they are a projection of the domain code and that's a very important piece of technology that the domain workbench provides: the projection editor, and in a projection editor the domain can be expressed in a way that is convenient for the computer to process, so it will be an easy input for the generator. It's very much like it has the power of databases, it uses very strong identities, it's very strong versioning and all the references between domains and all the strengths that only databases have today and uses do not edit this directly instead the system projects it into the desired notation, any number of desired notations, not just into a single notation, which is also an important aspect. So, by separating how things are stored from how things are looked at what the particular notation is we can essentially have our cake and eat it too. It can have the convenient database for the processing and we can accommodate the kind of notation that was desired by the particular pension expert. And I might add that different pension experts like different and are comfortable with different notations so the change, the evolution of domains is also a very integral part of the system.
The underlined representation is essentially a tree, we call it Intentional tree, it's a tree backbone with a graph like references that note relationships between entities. And the tree itself means that any quantity that has been specified in the past can have further attributes or further parameters, it can be parameterized to an arbitrary degree and that accommodates the evolution of the domain itself, so no matter to what precision the domain has been described, in the future further distinctions can always be made by adding more parameters and it's interesting that to do that is not enough to include those new parameters in the database, you also have to be able to use a notation that accommodates that particular extension and by having a projection editor it becomes a fairly simple matter. If you look for example in our experience when C turned into C++ we saw that a relatively simple addition of one parameter list of types into method class and method definitions created a very lengthy agonizing decision process of what notation should be used and a lot of problems were with ambiguity of the notation that was finally chosen and it was really unnecessarily difficult and it added just a relatively small feature to the language. If we want to deal with real domain experts and with their wishes we have to able to make changes like that to domain practically every day and it's only projection editors that have the ability to do that.
8. So how do you deal ambiguities in the notation?
Accommodating slightly ambiguous notations is very important. Human to human communication always includes minor ambiguities that we don't even notice because we can resolve the ambiguity either from the context or from other cognitive information and computers of course don't like that, but in a projectional editor the data is always unambiguous. The notation can be ambiguous and if a resolution is required by the user, the user can simply change the notation into a different notation and two ambiguous notations for example can resolve an ambiguity. And that is how CAD systems work. In a computer aided design system it's quite common to see a 2-dimensional drawing of a 3-dimensional object and that of course is not definitive at all. You have to use a different view of the same object in 2 dimensions to get an idea weather a circle for example means that there's a hole in a plate or weather it's a cross section of a shaft, or it's a sphere.
The programmers, the developers will produce a generator instead of producing the code that they did in the pasr, and the difference between the 2 can be very slight or it can be very great. In the simplest case you could simply include the code that you would have written into an output statement and that would be a very simple generator. The problem with that generator is that it's not parameterized, that it will always generate the same thing. Of course a valuable generator is one that includes more and more of the domain code as parameters to your production, so a typical generator would start by imagining what the output should be like and maybe creating a fairly simple instance of it and then parametrizing that simple instance with the input that is read from the tree. The reading of the tree is guided by a schema which defines kind of the shape of the domain, so the programmer has to be aware of what the problem is in general, has to be aware of its shape, has to be aware with what the degrees of freedom, the parameters are and using the schema can read those degrees of freedom from the domain code and then for example use those degrees of freedom in the appropriate way. It might be what the different commands are, what the different test cases are, what the variables are and so on and so forth, depending on, of course, both the domain and on the application and the particular platform that the application is implemented for.
10. So how was the domain schema like or unlike a domain model, an actual object model?
It is fairly similar, but it's not by itself, the schema is only a very small part of the domain code, so in addition to the domain schema there is always the domain code that gives instances of that schema and has the facts of the problem in itself. So for example the domain schema in the pension language might mention that there is such a concept as a pension rule or a time interval that a pension rule is valid for. These are all legal terms, are legally defined and specific to the pension system terms. The domain code itself might give specific rules and specific time intervals for those rules, so the total domain code is quite a bit more than just a schema, but yes, the schema is very similar to a model and of course this is an instance of domain oriented programming and it's just bringing the current trend of domain orientation to a higher level.
We acknowledge the trend and I think we all agree that this trend is important, it's the trend toward domain orientation and domain orientation means that we acknowledge that the problem is different from the program and it's not necessarily the same language that should be used for both purposes and in fact using the same language that might be perfectly well adapted and appropriate for one side, which is typically the implementation side because that's the side that always has to exist and existed historically, is not necessarily appropriate, in fact very often it's not appropriate for the problem side. Martin Fowlers paper on language workbenches is very important and he describes a list of very stringent requirements for what language work bench would have to be and the Intentional domain workbench is an instance of the language workbench that satisfies all of Martin's requirements, so that is a very strong connection. Having a domain workbench really reduces the cost of new DSLs and it makes just the space, degree of freedom that DSLs can occupy is just much greater
I am sure that problems will arise but I am not too worried about those, there are two important points to remember: one of them is that once you involve domain experts in the process and you can reasonably promise them to accept their notation, their existing notation, the notation they are comfortable with and they have used in their practice, of course they used it in human to human communications, or to communicate with themselves in terms of notes, if you can promise to them, we will get some very good results, it may not be the best language but it will probably be the best language to involve that person in the process at that time.
The second important point is that we have to take domain evolution into account and we have to design for the domain evolution from the outset. And domain evolution means that when the domain changes and there are new parameterizations in the domain and new refinements in the domain, there will be always a new thing that can be done, and there will be annotations to it. And further more, because of projection editors, the notation is independent of the domain code, so it can always change in the future.
I think that syntax and notation will be a little bit like fashion is today, that we can freely change without loosing our personalities. I am not worried about bad languages because they can be made better without loosing what you have already written. And that's a very important distinction. And the experience of Cap Gemini with the pension projects I think bears it out where they attempted one unified language that wasn't working out very well and they realized that different customers already had legacy notations that they wanted to accommodate. And they accommodated those notations, that's wonderful, and then one customer after being accommodated came back and said "That's great, but now we would like to improve our language, can you do that?" and of course that's part of the same process. So I think that the ability to change will erase these old problems of getting stuck with a bad language.
The two points here: one of them is the claim for increased efficiency and I believe that everybody here at JAOO believes that domain orientation is an important step forward to greater productivity, a faster and more precise way of generating software. I think that there is a general agreement that the question is how to bring this technology to an even higher level, and will that continue to yield the same sort of results as just domain orientation in general will? And I am not sure it will in any individual instance, but certainly the ability to adopt this would be known to be good in a much wider field, and with more people and involve domain experts directly. I think it must do more than what was done before.
We will return to that, because Brooks was saying the same, but with respect to end user programming it has been a dream and it's a dream that was probably not going to come true, because programming is inherently complex, it's a difficult profession and it requires a certain temperament and it requires a certain set of skills. And accountants do not have those skills they do not desire to have those skills, just like programmers may not have the skills of an accountant. We don't talk about domain experts writing programs, we talk about domain experts to make contributions to the creation of software that are direct contributions and when we ask them to contribute their knowledge and the facts of a problem, that's different of asking them to write a program. And one of them they can accomplish this with pleasure, and very easily and efficiently.
The other one they will do it very reluctantly, they will do it very poorly, and the problem would not be solved. So much about the end user programming and direct contribution doesn't need to be a program, it can just be the value of all knowledge of domain experts. In fact it is not only valuable, it's exclusive knowledge. The programmers don't read pension legislation and they don't know when pension legislation changes. And so we need the input from domain experts. As to Fred Brooks I think that this is a famous paper in 1984 (and maybe that's a famous year too). I always thought it was a very negative view of the world. He mentions that programmers have to handle this complexity that he has forced on them without trying or reason by the human institutions. It's the messiness of human life like insurance plans or pension plans that intrudes like an unwelcome visitor, that intrudes in the beautiful realm of software. And if it weren't for those complexities, than everything was going to be just fine.
I think it is a very negative view and we have to remember why we are into information technology, it is to solve the customer's problems, it's not an intrusion it is our livelihood. That's one comment. The second comment is about this obsession on complexity which is a valid obsession given that there are programs of millions of lines of code, but I believe that this complexity is a false complexity, an apparent complexity. When you look at the problem itself, it is not as complex as the produced code. And the amount of computer science knowledge that might be embedded in the generator is not as complex as the produced code. When you inter-mingle the two, when you look at the result of the process, that might be complex. But it is complexity that is generated by a computer so it's something that can be safely ignored.
I think that is a very cogent analysis for what's going on. Domain orientation is valuable so why isn't it done all the time? The answer is because of the upfront costs. And it's a simple analysis, when the value and the cost curve cross, then that's where it's worthwhile to do a domain specific approach. Right now the upfront costs are considerable, and it's not just generating the tools, sometimes the tools can be generated by meta-tools, it may not even be that much, but because people think of DSLs as programming languages there is a design cost there. And to invest it has to be parsable for example, now there is an unambiguous. it has to be usable, acceptable to the domain experts, and those are the real costs that add up and in many cases make it prohibitory expensive to use domain orientated techniques. We changed the cost equation completely; we also changed the value equations, in some ways I discussed before. But the cost equation is completely changed.
First of all the costs are much lower, because you inherit many things from the domain workbench itself and it has the capability of producing combinatorial large number of notations and all you have to do is choose from those notations. We haven't seen somebody yet who showed us a kind of notation and that was completely foreign to us. Most of the time there are tables and boxes and lines, formulas and various simple layouts. We can create all those notations but probably more importantly there is no design cost for the domain specific language, because we can take the most usable domain specific language, namely the informal notations of those domain experts themselves. And how come we can do that before? We can do that before because they weren't necessarily unambiguous. In fact I would bet you a dollar or maybe a lot of dollars that they were not parsable, they were probably a mixed bag of graphical and informal notations. So you have to have the projectional editor and you have to have the intentional tree representation. You have to have technology of that capability to avoid those very significant costs.
Right now we are only engaged with OEM customers and our focus is on the domain experts' side. But it is clear that programming is itself a domain. Maybe not general purpose programming, but definitely the domain of user interfaces, the domain of generator programming, generating specific languages like XML or HTML, and those languages themselves, HTML, XML, Java, they are domains that can be edited and displayed using the domain workbench. That one is a long term dream that might happen, the differential in value between what's offered by conventional integrated development environments and what's offered by the domain workbench is not that great. The great differential comes on the domain side, on the domain experts' side.
17. Last year you showed us SQL within Java code.
That's right, yes but we are not going to push it, I think it was very interesting as a technology and that's key the mixing of domains is one of those key properties to handle the pension domain for example or any other domain. Weather or not there is a great demand for referring to databases from Java that would allow us to concentrate on that. We can do that for sure, it's more of a marketing decision, because once you do that you have to be engaged in Java 100%. That means it's not good to do 90% with Java that kind that can also work with databases. You could do that right away but the value in that is not that great and the moment you do something 100% it becomes a serious commitment, and you really have to believe that particular combination has great value.
The three goals in mind, I wanted to contribute to civilian space flight, I think it's an important thing for the future, I wanted to help with the space station research and I wanted to involve kids to the magical space in learning about science.
19. In a few words, how was it?
It was excellent, it is truly an unforgettable experience, it's not that different than one would imagine that it would be, but the kind of details that you remember, the details that you find out, I think that's priceless.
I don't know if they are remarkable, but first of all from this low earth orbit vantage point which is only 400 km up, the Earth is incredibly big, it is every way to look, it's about as big as the sky is, when you are on a hill top and you look around you and you see this enormous sky and it looks like the sky too, it's all blue, it's amazing. When you look at parts of the Earth they all look familiar, it's not like on a map, but just in terms of texture, the lakes look like lakes and you can even see waves on them, and sometimes the lake is frozen and there are creases on the frozen lake. And until you realize they are not what you think they are, they are maybe 10 to a 100 times bigger, so that lake is half of an ocean and the waves are not waves they must be tidal movement of water in a very large scale. But it impressed me how nature has this fractal nature that on different scales it repeats itself.