“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
― Bjarne Stroustrup, The creator of C++ Programming Language
Just a few words in epistolary genre concerning the fate of the programming for ESSbase using CalcScript. Based on the article “Ten things, which I cannot stand in Object Oriented Programming (OOP)”. CalcScript is data calculation language for multidimensional model as one can see from its name. It has no connection to such alien programming paradigms as “procedurity = procedure based” (data + algorithm), “objectivity = object based” (objects + messages) and “functionality = function based” (functions + functions) – they all are foreign to the CalcScript language. Summary: CalcScript – this is the data work, work with data, which is functionally displaced in multidimensional model or just simply: “CalcScript – calculation of data”.
What this definition means from an application programming point of view? Well, the program of calculating functional values based on the reference values (metadata) of the model and strongly connected with the model. If one follow the definition above literally then it’s lead to the following: first implementations of a program written in CalcScript are adequate only to the current perception of the task by the programmer, in other words the calculation accomplished by a program happens to be in a state of “stillborn child” since it cannot fully adapt to the changes of the business requirements (just because of these limitations of the “picture of the world” required).
Fortunately, this is not a new situation and all these problems can be defined during “experimental-industrial” use (or pilot operation). There is a real possibility to put a life in this “stillborn child” if several conditions are performed: one should rely more on the metadata features (attributes, place in the hierarchy, composite element name). In other words, one should go away from development model “CalcScript – this is a data calculation” toward “procedurity –procedure based” (data + algorithm) or “CalcScript – this data taking and calculation”. The proposal in short is the following: one should artificially introduce the data management entity into the existing algorithmical region of calculation.
How this approach to the development: “CalcScript – this is data taking and calculation” can be described in real life?
On the documentation and functional requirements level: The part “Data source (data taking)” and the part “Calculation” described for each algorithm.
Step 1. Take turnover data (Form 0101 Movement of supplies).
Step N. Calculate the Balance at end = Balance at beginning + Movement of supplies
The primary data slice and calculation\correction slice should be distinguished on the model level. The analytics with corresponding elements should be distinguished for that (the closest analog of that is “Value” direction at Hyperion Financial Management).
A separate graphical rule (which consists of many scripts) should be distinguished for each algorithm.
The “Data source (data taking)” part in this graphical rule should be described like getting a data slice through functions of element’s relations in the hierarchy with predefined set of characteristics.
In other words: The functional part of the certain element (for example: all elements, marked as expense center and belonging to the region “East”) should be used for the selecting of the certain element , not it’s semantic value (“A1”, “A2”, …).
The “Calculation” part represented by a separate script which one encapsulates in a places of general rule where the need occurs. The script realization should describe the calculation algorithm itself, not an element’s positions in the model.
The approach described above requires a special discipline of development since there is nothing which prevents the programmer from falling into a pure “hardcode” programming.