Pseudo Code as a DSL

In the book the pragmatic programmer Andrew Hunt and David Thomas write:

When you listen to users of a proposed system, they might be able to tell you exactly how the system should work:

Listen for transactions defined by ABC Regulation 12.3 on a set of X.25 lines, translate them to XYZ Company’s format 43B, retransmit them on the satellite uplink, and store for future analysis.

If your users have a number of such well-bounded statements, you can invent a mini-language tailored to the application domain that expresses exactly what they want:

From X25LINE1 (Format=ABC123) {
Put TELSTAR1 (Format=XYZ43B);
Store DB;
}

I believe this is very idiotic. Since it is some what of a stupid way of talking requirements and making a pseudo code from them but do we really want code to every specific requirement?
Don’t we want to take a hold of the big picture and create a module to handle DB and one to handle formatting and one to handle conversions?
is this pseudo code a good design tool or a list of tasks with components is a better solution?
Looking at the task I can see:
Listening
Transaction identification
Translation (conversion)
Formatting
Transmition
Each one should support a standard but now I have a list of operations i can relate to.
The next time I will see a similar operation I will be able to judge if it is the same or in need of a new operation implementer.

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.