Boy, where they wrong. For several reasons ABAP is still very much alive and relevant, even more than Java. (Well at least in the SAP ecosystem).
- There is simply too much existing legacy code written in ABAP. Millions and millions of lines and thousands of screens. Along with this mass is also a large workforce of skilled software engineers. This mass just can’t be ignored or be put aside.
- Java had suddenly become a less obvious choice when it was acquired by Oracle. By that time however, SAP had made already significant investments in Java that cannot be put aside either.
This means that the two technology stacks (ABAP/Java) will both be here to stay. Only where the technologies overlap, choices will be made (an obvious example is the death of Java Web Dynpro).
Teach the old dog new tricksNow the cool thing is that SAP is still actively evolving the language. At first, the Object Orientation paradigm was introduced and supported heavily by SAP. And now ABAP is making some very early steps into the world of functional programming.
Declarative vs FunctionalABAP is now mostly a declarative language. As a developer you tell the program the steps it needs to perform to complete a task. This has a number of side effects:
- The intent of code (what are you trying to achieve) only becomes clear when you read it or execute it in your mind.
- The code relies more on state (content of variables). In the examples below, you will see that the declarative examples rely on helper variables needed throughout the routine. The more a program relies on state, the more difficult it will become to understand what is happening.
The functional paradigm puts the emphasis on what your intent is: What are you trying to achieve? It should let the developer focus on what he is trying to achieve and let the compiler fill in the details on how to achieve this goal.
The end result is more concise code that is easier to understand and easier to maintain.
Show me the code!The following tricks are not really functional programming per se, but are interesting none the less, even more so as they are available in current ABAP releases and can actually be used today:
Inline declarations DATA() FIELD-SYMBOL()It is no longer needed to explicitly define a variable when the type can be inferred from the context, for example when looping over a table or when executing a method.
|Inline data declarations old versus new|
The code samples above do the same thing. The old example needs three explicit variable declarations. The new example infers the type from the context. In this case, we have made the program 50% shorter. (In this example you could also use method chaining but that is beside the point).
The same can be done with Field Symbols:
|Inline field symbols, old versus new|
|Creating data, old versus new|
In the old example, there is some tedious code that moves data into work areas and moves those work areas into a table. In the new example, you can just specify the contents of the new table. The compiler will then take care of the implementation details.
|Itab syntax, old versus new|
On the left you see a nested internal table. The goal is to read the the contents of the cell with value 13. In the old style some tedious code is needed to move data from the internal tables into work areas and to move the data from the field to a variable.
In the new style, you can simply specify what lines and field you would like to access. I think the second example is better in simplicity and clarity of intent. This syntax does not only work with indexes but also with search parameters.