Skip to Content
Technical Articles

Functional Christmas

Dear Christmas Fans,

You are no doubt familiar with the concept of an “advent calendar” where you open a door each day in December leading up to Christmas and eat a chocolate of some such.

This December I have been following a series of posts on the following site:-

https://functional.christmas/

Each day there was an article trying to explain the basics of Functional Programming. As background Java and ABAP are “imperative” languages, JavaScript is supposed to be a “functional” language and there are other languages which are “pure” functional languages.

What’s the difference? I had no idea. I did know that in recent releases of ABAP new “functional” keywords like REDUCE and FILTER were introduced which supposedly do the same thing as their functional equivalents (do they? someone can answer that question if they so desire).

Why am I interested in functional programming? Two main reasons – firstly these days a working knowledge of JavaScript is becoming more and more important due to UI5 but secondly and probably the killer argument is that D.J. Adams says that writing programs in a functional language is fun and I like fun things.

The articles in the functional Christmas series mostly went over my head, and it did not help they used examples like A, B, C, X, Y, Z as variable names rather than proper business specific domain names like Monsters which anyone can relate to.

Academic articles always do that as well. It is so difficult to get your head round something like f(a) = b ~ c (d) * (e) / (f) as opposed to DATA(monsters_under_bed) = bed->monster_count( ).

Nonetheless I encourage everyone to have a read, one a day like I did, so your head does not explode.

One concept I finally got, it was so strange to me, was the idea of a function returning another function as a result. I just could not understand that one.

Now, in the real life example I just gave the variable MONSTERS_UNDER_BED is clearly the result of a call to a method. In such constructs the result is on the left hand side.

Now let us say, in a functional language we have a function that takes two arguments, colour and height and returns some important monster related information based on those two inputs.

As it turns out you can create a new function based on the old function by passing less arguments than it expects. It looks something like this:-

LET blue_monster_function = all_monsters_function BLUE.

The result is on the left hand side. You have a new function called BLUE_MONSTER_FUNCTION where you only pass in the height and the BLUE parameter is hard coded.

This, apparently, is called a “curried egg” after Professor Curried Egg who invented the concept and has fifty four functional languages named after him. Some historians argue however that the Russian Academic and Logician Professor Egginov Currinovlesky got there first a hundred years earlier.

The other interesting thing is something called “tail recursion”. In ABAP we usually process data using a LOOP over an internal table. In functional programming you generally use recursion instead and indeed in some pure functional languages that is the only means of looping possible.

In one article the author said such recursion can sometimes cause a “stack overflow” (hence the name of the website) so you have to mess with the code so that it looks like it is doing recursion but in the background the compiler is REALLY doing a loop just like in ABAP.

You can of course use recursion in ABAP, and I often have. You have to be careful not to cause an endless loop as you do not get a “stack overflow” error it just sorts of hangs there forever until you get a TIME OUT.

Lastly what might make ABAP programmers heads spin is the concept of immutability. In pure functional languages once you have given a variable a value it cannot be changed. That seems crazy at first glance. If I have an application to call up a sales order, or a monster master record, and change something then presumably I need to have a variable which has the initial value and then the new changed one based on user input.

To quote Robert Martin (Uncle Bob) rather than changing the existing variable you have to create an “entire new universe” which is exactly the same as the last one with just one small aspect changed. He did a series of blogs detailing exactly how to do this based on a Star Trek Captain Kirk vs the Klingon’s game he wrote using a functional language.

https://blog.cleancoder.com/uncle-bob/2018/12/17/FPvsOO-List-processing.html

What do the panel think about this? Do we need more functional programming constructs in ABAP? Do the ones already there work properly? Have you used functional programming in JavaScript? is it fun?

Cheersy Cheers

Paul

 

 

 

4 Comments
You must be Logged on to comment or reply to a post.
  • When I started writing about OO programming one of my pet gripes was that people who wrote about OO said “it is better because it is better” with no further clarification.

    This “immutability” thing is the same. In the articles I read it says that doing this avoids all sorts of problems without saying what those problems are and how immutability solves them.Presumably it is so obvious it is not even worth thinking about but it is not obvious to me.

    In the end – after many experiments – I concluded that OO programming was indeed better than procedural programming but I had to prove it to myself rather than relying on vague comments saying “this is what you should do, its really good” with no details as to why.

    I had suspected OO programming would give benefits. I also suspect functional programming gives benefits as well, even though I am not sure just what those might be right now, despite just reading 24 articles on the subject. This may well be because I am a complete idiot.

    Albert Einstein said if you cannot explain something to a five year old then you do not understand it yourself. So – pretend I have the mental age of five. This is, in fact, probably not so far off the mark,

    Given that precondition, can someone explain to my five year old self the benefits of immutability?

    • Hi Paul,

      Immutability is great and solves so many problems:

      • It’s easier to reason about your code: Functions don’t magically change your data, creating new data needs to be written explicitely. Your code becomes local in a sense: You only need to look at one specific area of your code to see what function changes what. This makes refactoring extremely easy. In functional programming, your function will not have any side effects, so given a certain input it will allways produce the same output, and nothing else (no logs to the console, no state changes in your database, etc.). It has never been easier to refactor that function. Or write unit tests.
      • When parallelizing your program you’ll immediately notice that mutations are the root of all evil: What happens when two threads mutate the same object? Chaos (race conditions, …). Rust has a fine way to handle this problem with the concept of ownership and borrowing but in most languages this is a big problem.
    • The five-year-old version: Immutable data is simple and predictable, changing data is less so.

      Martin Fowler touches on it several times in Refactoring, a good synopsis is that the scope of mutability should be as small as possible, ideally zero (=immutable). At the opposite end of the scale we have global variables, and uncontrolled mutability is the main reason why they are bad.

      Functional programming allows you to limit the scope of mutability, provide a function instead of the variable and you have more control over the content of the variable and encapsulated its scope of mutability to the function. David has given a great explanation of why this is good.

      An iterator is a good ABAP alternative to the recursion theory. There is an interesting discussion in the comments about it here.