Tuesday, September 21, 2004

Domain Specific Languages

Domain specific languages (DSL) are, I believe, the future of software development, well at lest as far as human computer interaction is concerned.

In a world where the majority of the people have at least some rudimentary technical skills, not necessarily computing skills, just technical, DSL will become the mechanism for interacting with the fundamental applications supporting not only their technology, but also their interaction with other technologies. However, making DSL viable will require that the DSL be more than a mini-language, as DSL success will depend on several factors:

  1. DSLs must be application, platform, and framework independent

  2. DSL will be combinable into another DSL or a super-language

  3. Different DSLs may have conflicting terms requiring resolution methods

  4. DSLs verbiage will be a realization of the Suggested Upper Merged Ontology (SUMO)

  5. DSLs will be syntactically identical allowing multiple DSLs in an application

  6. More to come...


Why Domain Specific Languages?

Let’s face it. Different people perceive things differently, even though their knowledge may be grounded in the same field. Problems have multiple solutions, and people adopt the solutions that they best understand. The natural evolution of human-computer interaction should be toward interfaces that are user-driven rather than program driven [1].

Suppose the process of using an ATM to withdraw cash from your bank could be controlled by you, the user, rather than by the programming of the ATM. The ATM must retain its ability to enforce such business rules as necessary, provide appropriate security, etc., the HCI should be controlled by you the end user. And, it should be the same sequence of events across all of the ATMs regardless of the ATM manufacturer or controlling institution. Personally, I only use an ATM to withdraw cash from a checking account. I don’t want to answer all of the other questions. My process would be something like this:

  1. Insert card

  2. Authenticate me

  3. Prompt for the amount (default to $200)

  4. Accept the amount

  5. Automatically accept charges that are < 1.5% of withdrawal

  6. Give me my money

  7. Show me my balance

  8. e-mail me my receipt

  9. Be done

Since this is a process, what does it have to do with DSL? The business process execution language (BPEL) is a domain specific language. For the above example, BPEL could be used to define the process flow. However, BPEL correctly doesn’t step out of the process domain, which leaves something missing from the picture. The builder the BPEL process must know which end-points to invoke, thus rendering BPEL useless to the average person engaging with domains outside his or her own. DSL would not provide the end-points, but would rather provide the verbiage necessary for the average person to take charge of their HCI. The realization of the DSL would be accomplished in the developer’s choice of language/platform, but the DSL would provide the developer with some portion of the program specification.

For the purposes of this discussion, let’s term the point at which a user is attempting to interact with a system the point-of-application (POA) [2].

The POA would receive DSL inputs from the user, and dynamically determine the appropriate end-point to bind with the interaction. The person creating the DSL process needn’t know the endpoint, they only need to be able to indicate the type of endpoint they wish to interact with.

To be continued...

[1] For the purposes of this article, we are concerned with the end-user interacting with their domain. This is not to say that validate machine driven human-computer interactions do not exist, they most certainly do. Maybe the second type should be referred to as computer-human interaction.

[2] This could also be termed the point-of-interaction, but the user could actually be physically removed from the system the are trying to interact with (say via cellular phone), so I think the point-of-application is more suitable.

0 Comments:

Post a Comment

<< Home