Programming paradigms

[nomssi]

I take issue with two subsection titles:

• Prefer object orientation to imperative programming
• Prefer functional to procedural language constructs

because you can do imperative programming in OO and the new syntax is not functional but expression oriented. I think better suited names (meaningful) would be

• Prefer object orientation to procedural programming
• Prefer expressions to statements

The second subsection should be clarified by promoting expressions only for functional code without side-effects. JNN

[nomssi]

https://answers.sap.com/questions/12672544/how-to-rewrite-into-for-loop.html?childToView=12674127#answer-12674127

[HrFlorianHoffmann]

Fixed the first part by replacing "imperative" with "procedural", which really is the more accurate term here.

Need to figure out what the precise nomenclature is for expressions/functional statements. The documentation talks about both.

[nomssi]

In https://blogs.sap.com/2017/11/30/5-use-cases-of-group-by-for-internal-tables/ I once wrote: •A statement does something: statements work on data; they are imperative and applied in sequence. •An expression returns a value: pure functions (without side effect) are composable. But note ABAP does not try to be a functional language, the type system does not support complex/algebraic data types

I think a statement could return something and must have side effects. An expression must return something and could have side effects.

I think the subsection "Prefer functional to procedural language constructs" has no solid rationale. I would prefer if it was along the "Don't mix stateful and stateless in the same class" rationale: there is a difference between side effect free functions (pure functions) and functions with side effects or procedures. My only advice here should be to extract side effect free operations to expression oriented syntax.

For other case, I would not give a recommendation. You might be tempted to replace TRANSLATE with translate( ) until you realize both do not handle spaces in the same way.

[HrFlorianHoffmann]

There were several issues in the past that dealt with misunderstandings of the term "functional". I come to the conclusion that the term was not chosen very wisely...

ABAP is of course not a functional programming language, and seems to have no aspirations to ever become one. What is called "functional expression" here is nothing more but a (built-in) method that returns something, in contrast to "procedural statement", an extra reserved ABAP keyword to invoke an effect.

Thus, the benefit of functional expressions is not that they are free of side effects, support the lambda calculus or anything in that direction. Their benefit is simply that they usually make your code shorter and clearer.

For example, one aspect they all share is that they enable inline data declarations, where statements often force you to add an extra line to declare variables beforehand:

DATA(variable) = 'A'.

as opposed to

DATA variable TYPE string.
MOVE 'A' TO variable.

Another key benefit is that they often express the intent more clearly. For example,

IF line_exists( value_pairs[ name = 'A' ] ).

is easier to grasp than the two not clearly related statements in

READ TABLE value_pairs TRANSPORTING NO FIELDS WITH KEY name = 'A'.
IF sy-subrc = 0.

Yet another benefit is that they allow doing the same with fewer reserved key words, i.e. they reduce the grammatical complexity of the language. This is not obvious for experienced ABAPers, but newcomers find it easier to memorize a function like replace( ... ) than to memorize the different additions of the REPLACE statement: all function calls look alike, so there is no extra grammatical structure to memorize at all, and while in statements, the order of the clauses often matters, the parameters of a function can be given in any order.