OOF Platforms

Recently, a question from one of my colleagues at work got me thinking. His question or rather statement was: "we should be using Functional as opposed to OO for building applications". As we discussed, certain interesting ramifications emerged, worth discussing.

There are two language camps: the functional (Scala, Javascript, SQL) and the object oriented (Java, C++). The main differences lies in that OO languages work on data encapsulation (hiding) principles and Functional languages work by passing function pointers (behavior).

In this sense, Functional languages are more white box in nature - that is to say, clients exert higher behavioral control of the execution. When a functional API is invoked, clients can not only change parameters, but also influence behavior.

OO languages are more black box in nature, clients typically rely on the invoked API doing the correct thing. Client can influence behavior by instantiating the right class (from an inheritance tree) - pretty limited in extent.

What ramifications do these different styles (functional, OO) bring to the middleware/ platform developer?

Typically, web services (SOAP/ Rest), are naturally suited for OO style decomposition. Client developers call into a blackbox API with a known interface. The server developer is responsible for making sure that the API is well behaved - does not send uncertain results, not have any published side effects etc. This style allows the client and server teams to be geographically dispersed (with awesome API documentation of course).

Could there be a better way? this could be the sweet spot where functional languages can shine on their own. Similar to SQL (a functional language too), we can imagine declarative API's which are controlled behaviorally from the client instead of the server. Clients now determine behavior of the API as well as the transaction requested. For example, clients may add in aggregations - similar to the way SQL does through column and table names.

Similar to bad database SQL queries allowing client developers bring the database down, the downside of this approach is that unprotected behavior modification can bring down the entire application server in production. This can be offset a little bit by today's servers being stateless (hence an easy restart from operations is all that it takes to get it up and running again) - this is as opposed to a database server, where entire data access is interrupted.

I along with my work colleague will be working on an open source project for exploring this functional style of platform development. Stay tuned for update on our learnings.