8 Design Process
Figure 6: Design Process
This section describes the process that we used in the design
of Hancock and discusses the lessons we learned from our experience.
Designing a domain specific language involves
developing a model of the domain and then embodying that model in a
language.
The language should capture the commonalities of the domain
effectively and let the domain experts worry about the details
specific to an individual application.
Figure 6 depicts the process we followed; it can be
viewed as an elaboration of the first box of the FAST process
[GJKW97].
First, we alternated talking with domain experts about sample
signatures and constructing models of the domain that captured the
common elements of these signatures. By iterating, we got feedback on
the models and developed a common vocabulary.
Once we had a good model for signatures, we applied this model by hand
to construct a few sample applications. This experience led us to
replace our model with one based on more primitive abstractions
because the original abstractions were too high-level to
serve as the basis for a programming language. We eventually used these
hand-written signatures to establish that the code we expected to
generate automatically would perform adequately and to
evaluate whether a library-based solution was sufficient.
After we had revised our model based on the hand-written signatures,
we translated it into an actual language design. This translation was
not straightforward because although the model revealed what concepts
needed to be expressible in the language, it did not give much
guidance as to how they should be expressed. Then we wrote sample
applications using our design, evaluated the resulting programs, and
revised the design as appropriate. We found that we needed to iterate
through this process many times. We discussed these sample
applications with the domain experts to confirm that we had captured
the essential elements of the domain.
Finally, we implemented a compiler and runtime system for Hancock and
evaluated the signatures written in Hancock.
This evaluation led us to refine many aspects of the original design,
including the stream model, the view operator, the sig_main annotations new
and exists, support for user-supplied compression functions, the record
construct, and the implementation of maps.
8.1 Lessons Learned
Our goal in this project was to design and implement a language that
would be adopted by signature researchers. While this project is not
yet finished and so we cannot claim complete success at this time, we
believe that we are on the right path because the signature
researchers have become advocates for Hancock. We believe that three
things that we did were responsible for our success and could be
useful to others who want to design domain specific languages.
First, we were open to constantly revising our models based on many
different kinds of input. Figure 6 highlights the many
sources of feedback that we employed in our design process. In
addition to consulting with the domain experts at many points in the
process, we also built artifacts at several intermediate stages.
These artifacts proved useful even though they are not the final
product of our work.
Second, we worked closely with domain experts and valued their
input. This point deserves elaboration, as it seems quite obvious
that language designers should heed their experts. The fact that
domain experts may not be expert programmers leads to a temptation to
dismiss their comments. Sample implementations they provide may be
written badly. Consequently, it is easy to leap to the erroneous
conclusion that they do not know what they are doing. For example,
signature researchers had developed a map representation that drew a
lot of criticism from others outside the domain. When we investigated
their representation, we learned that although their implementation
had some problems, the basic structure provided very good random
access time. Such access is crucial to their clients, but it had been
ignored by other onlookers. As language designers, we had to be very
careful to separate crucial domain constraints from irrelevant details
in the existing implementations.
Finally, gaining credibility with domain experts was essential because
they are the potential users for the language. By designing concrete
models in response to our discussions with them, we established that
we were serious about helping them and that we understood their
domain. It also gave us a focus for our discussions. By handwriting
signatures in C, we established that we could satisfy their
performance requirements. By choosing C as the basis for Hancock, we
kept Hancock close to their usual programming environment. By using
signature representations consistent with the ones the domain experts
had designed, we demonstrated that Hancock programs could manipulate
their existing data without difficulty.
Most importantly, by consulting with the domain experts at every point, we
improved the design and got them excited about using Hancock.
