Over the past couple of weeks SAP have been quietly showcasing a new programming model called River Description Language (RDL) or just River for short. Some people have described it as Vishal Sikka’s vanity project, as River has been in the works for quite a while now (something called River has been with us for at least 3 years) and Vishal does not want to give up on the idea. I personally don’t see this as a vanity project, but as a sign of belief in the idea….so what is the big idea.
The concept of River is linked to the idea of ‘Timeless Software” – and if it can deliver on its promises it could deliver just that – a language to that you can use to describe the business logic of your Business Software, separate from implementation.
River and Java
For those developers out there, you might be crying out “but isn’t that what Java does for us already ?”, we write the business logic in Java, compile it and then run it on (almost) any Java Virtual machine (JVM).
Where River is different is that it is trying to separate the intent of the program from the complier, in the River paradigm each platform will (might) have its own compiler that will take the RDL which holds the business logic intent and compile this to the most appropriate artefacts that that platform has to carry out the task that has been requested.
So for example if the target platform supports column store databases then these could be used by the complier, for those that did not offer this feature then the compiler could use a row store. Perhaps most importantly it is the complier that makes these decisions not the developer.
So imagine what would be possible if R/3 had been defined in RDL and then deployed to an ABAP server via an RDL complier (note at the time of writing no such compiler exists). It would all now be OO-ABAP and take advantage of the In-Memory capabilities – just by re-compiling !
Where are we now ?
The first version of River only has one target platform – you guessed it – HANA. It is possible via the HANA Studio to create an RDL model and then compile this to HANA artefacts – The developer does not choose if the logic is created as Java Script, SQL Script etc, they just define the intent and the compiler decides what to do.
So is it a good idea ?
As a general concept, I think that River is a really good idea. I also think that using HANA as the first platform is a good idea for two reasons. The first is that not so many developers really know how to get the best out of HANA and the second is that the capabilities of the HANA platform are evolving quickly – so best practice today will not be best practice in 6 months time. RDL will take care of both of these potential issues by removing implementation decisions from the developer and a quick recompile will make sure your application is using the best HANA features.
Personally, I would like to see other target platforms at least committed to, as without this I can see that we run the risk of HANA specific “extensions” finding their way into the RDL specification – at which point it becomes a HANA Description Language. Only time and adoption will tell.