|
Title: Badly Designed Languages, Consistency and Tools Post by: Stephen Taylor on July 28, 2007, 09:44:32 AM Most commercial languages and community based languages are easy to understand and use. You may however find yourself in a position where you have to use an inelegant proprietary language that is annexed to an application you have been engaged to support. The language may be used as part of a customisation process. Now for the worst case scenario:
The syntax of the language is extremely irregular and the documentation provided for it is worse! Having to employ a language that has excessively awkward syntax and unreasonably defined routines you know two things: * The language perforce must be consistent for the interpreter to work. * There are syntactic rules to the 'proper' construction of a clause or a routine. Even the untidiest rules with some perspiration and serious mental effort will eventually reveal a consistent approach to constructing a routine to achieve a desired result. To understand what the language's rules are and how they are applied: * Read the documentation very carefully to see if it can shed any light upon how to construct an instruction. (As mentioned sometimes the documentation is of no use). * Graphically map out example language constructs into flow charts or ER diagrams. Graphical representations of routines constructed from a badly designed language can vastly improve your understanding of what the language is saying. Charts and diagrams remove the clutter of curly braces, formatting and keywords. The graphic will present you with an abstracted clear view of the flow of the language and the way it instructs an application to do something. The next step is to write out a similar routine using your graphical representations as a guide and see if you can simulate a similar result to what is expected. If you are successful then you have solved some of the language's mystery. Once you have a handle upon the language, your next step, if you have time, is to create some kind of interface between the language and yourself. By this I mean divorcing yourself from direct contact with the language by either: * Creating a Graphical User Interface through which you create forms or design flowchart diagrams that are then translated to the language's code. * Creating a markup language and a system to convert the markup language to the awkward syntax of the proprietary language. Both options will need an interpreter that will convert your language to the proprietary language and vice versa. You start by breaking down and mapping the components that make up the proprietary language: * Sub-routines * Properties * Composite keys * Definitions * Variables etc. Begin by breaking down the independent components from the largest to the smallest for instance: * Publicly declared variables and constants and then * large components like routines which have dependent components within them and * then breaking down each dependent component. For example: property x:5 [independent component] property t:10 [independent component] definition "my test property" [large component] { property "prop one" [dependent component of definition] { edit oneof "property two" relate by "is keyed by" READONLY [dependent component of property within definition] } ASGRID LENGTH 1200 } The tools at your disposal to help break down the proprietary code are: * Editors that allow you to create customised colouration of the syntax, like Crimson Editor which is free. * Regular Expressions to help break up the code efficiently and accurately. * Character reading tools. * Text manipulation functions within the language from which you will be building your interfaces interpreter. Once you have learned the proprietary language's break-down and can represent scripts written in it within your interface, you can then work upon reversing the process so that you can create a proprietary script from your interface. Things you may want your interface to do for you: * Remove the clutter of curly braces and common constructs when converting from the proprietary language to your interface. For instance, there may be a set of words that must always appear together like 'relate by "is keyed by"' you can simply represent it as a tag or a graphic symbol of a key. * Add helpful comments when converting back from your language to the proprietary one. For example, should you have to view the proprietary script where there might be nested curly braces, it might be helpful to comment those braces to show the end of each section, for example: do 1{ code do 2{ code do 3 { code do 4 { } // end do 4 } // end do 3 } // end do 2 } // end do 1 To convert the code the interface might break down the components into a database. A table for sub-routines, a table for properties and variables etc. Each component could be ordered by recording the starting position of a component's first character in the code block (script). This provides the ability to convert the code in both directions as it was originally written or re-write the code in order of component. For example: You start with a script that looks like this: property x:5 definition "def One" { display dialog x } property t:6 definition "def Two" { display dialog t } Splitting the code into it's respective tables: Properties Line=1; Name=x; Value=5 Line=8; Name=t; Value=6 Definitions Line=3; Name=One Line=10; Name=Two Definition Clauses Line=5; display dialog x Line=12; display dialog t You can either re-write the lines of code in their respective line/character number order or re-write them by their object order like so: property x:5 property t:6 definition "def One" { display dialog x } definition "def Two" { display dialog t } Once you have decomposed the code into a more manageable format you can manipulate it how you would like. In recapitulation, when dealing with a badly designed language you carry out the following steps: * If possible abstract out some examples of its use into a flowchart or diagram. This will go far to improving your understanding of the language. * Create an interface between the language and yourself to make programming in it easier. This will really pay dividends to your use of the language and give you an intimate understanding of it's quirkiness. Duane Hennessy Senior Software Engineer and Systems Architect. Bandicoot Software Tropical Queensland, Australia (ABN: 33 682 969 957) Your own personal library of code snippets. http://www.bandicootsoftware.com.au Moderator of http://groups.yahoo.com/group/AccessDevelopers |