Wilco Menge
Read all my blogsBack in 2006 when I started with SAP and ABAP development, people told me there was no future in ABAP: SAP would not develop new applications on the ABAP stack, but rather on the Java stack, possibly with ABAP as a data backend.
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 tricks
Now 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 Functional
ABAP 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 inline data with VALUE()
This is a rather cool trick borrowed from Javascript with its JSON notation. Rather than creating code that creates an internal table with some data, you can now just create that internal table:
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.
New itab[] syntax
Another cool trick borrowed from javascript is accessing table using brackets. This means you can simply access and modify data in a table in a very precise manner:
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.
Disclaimer
Be aware that these features are only available in Netweaver 7.4. Also, I have not covered all new syntax elements. See the following resources for more in-depth information:
2 responses to “How ABAP moves towards Functional Programming”
I cannot really claim to understand ABAP but I think I have a good enough grasp of FP – that said I cannot find any main ideas from FP in your examples:
FP is really all about "first class functions" – from there most include things like immutable values, pattern matching and "declerative programming" (http://en.wikipedia.org/wiki/Declarative_programming) … indeed I think you got this wrong messed up – what you are describing sounds a lot like "imperative programming" (http://en.wikipedia.org/wiki/Imperative_programming) and is indeed somwhat orthogonal to declerative programming …
SAP / ABAP might indeed some day introduce some FP caps (as it's really *IN* right now) but IMHO this will not happen on the (sorry) rather outdated ABAP languague but just by including newer Java features (yeah Java gets lambdas)
Thanks for sharing valuable information and it is useful for Sun it labs provides the best SAP ABAP Online Training classes.