The biggest power of functional programming comes from the ability to treat functions as first class objects and the power to compose them incrementally to evolve larger functions out of smaller ones. Designing such functions as referentially transparent enables us to treat functions in programming just like functions in mathematics - side-effects are carefully abstracted through “effects” and delayed till the algebra of our program gets submitted to the run time system.

In this talk I will discuss a few idioms and patterns on how using the power of composition can lead to development of modular abstractions. Instead of committing to an implementation prematurely we can define abstractions that focus on “what” it does deferring the “how” part to later stages of the lifecycle. In functional programming terminology we call the “what” part the algebra of our abstraction, and the “how” part the interpreter. Decoupling the two is one of the basic recommendations in functional programming. 

I will use Haskell and Scala for the examples. I will discuss common functionalities that we use everyday in programming our domain models like validations, database interactions, managing exceptions, talking to external services etc. and show how to use the power of typed functional programming to make them more compositional.

John Carmac once mentioned on twitter that "Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function." In this talk we will discuss the power of functions in modeling real world applications on the JVM. When we say functions, we mean "pure" functions as in the world of mathematics.

Functions model behaviors, functions compose to build larger functions, and combined with a powerful type system allow us to abstract over the generalities in defining real world domain models. The combination of functions along with algebraic data types has proven to be extremely useful in designing large scale systems that are modular and extensible.

Scala is a typed functional (well, almost) language on the JVM. In this session we will discuss how the functional features of Scala offer many of the above benefits in designing large scale systems. If you are coming from an OO background, you will appreciate how an alternative approach to programming can make your systems simpler to design, implement and maintain.

When we talk about domain models, we talk about entities that interact with each other to accomplish specific domain functionalities. We can model these behaviors using pure functions. Pure functions compose to build larger behaviors out of smaller ones. But unfortunately the real world is not so pure. We need to manage exceptions that may occur as part of the interactions, we may need to write stuff to the underlying repository (that may again fail), we may need to log audit trails and there can be many other instances where the domain behavior does not guarantee any purity whatsoever. The substitution model of functional programming fails under these conditions, which we call side-effects.

In this session we talk about how to manage such impure scenarios using the power of algebraic effects. We will see how we can achieve function composition even in the presence of effects and keep our model pure and referentially transparent. We will use Scala as the implementation language.

In discussing effects we will look at some patterns that will ensure a clean separation between the algebra of our interface and the implementation. This has the advantage that we can compose algebras incrementally to build richer functionalities without committing to specific implementations. This is the tagless final approach that offers modularity and extensibility in designing pure and effectful domain models.

Using a programming language that supports first class functional programming doesn’t necessarily imply that the code you write is functional. Functional programming has the nice properties of being compositional - you design smaller abstractions and then reuse them to build larger ones. You use the power of algebraic properties that these abstractions offer to build larger elements of your model out of smaller ones.

However often we find that many code bases designed in a functional programming language are inherently imperative, especially when you are using a multi-paradigm language like Scala or Java. There’s nothing wrong with imperative code, but it lacks the niceties of expression based composition that makes reasoning about your code so much easier. Also assignments used in imperative code are inherent side-effects that are best avoided (or at least minimized) in an expression oriented language.

In this session I will discuss some of my experiences of mining imperative code and refactoring them into functional patterns. You will be surprised to see how much functional goodness can be derived through functional thinking. Algebraic structures like Monoids, Monads and Kleislis are just buried within the reams of imperative statements crying to come out. In an exercise of half an hour we will liberate them and see how the code quality improves from the point of view of modularity, compositionality and simplicity.

The slides of the talk has been uploaded at https://www.slideshare.net/debasishg/mining-functional-patterns.

Domain modeling is usually implemented using OO design. In this approach of "nouns-first" we design object hierarchies using subtyping to model the various elements of the domain. In this talk we will take a different approach using Scala:

1. Start with focus on verbs first
2. Think how we can model domain behaviors using pure functions grouped within extensible modules
3. Use an algebraic approach towards evolution of modules,the algebra being composed of functions,types & laws
4. See how the domain algebra can be constructed from categorical structures like monoids, functors & monads
5. Discuss how the functional patterns lead to compositionality - an extremely important quality that scales your domain model.
   
   

Manual testing is something that's error prone, incomplete and impossible to replicate on a large scale. We have instead been using xUnit style of testing for quite some time now. This approach has a number of drawbacks like (a) We need to write test cases by hand which again doesn't scale for large systems (b) We may miss out some of the edge cases (c) Safeguarding missing cases with coverage metrics doesn't help, since metrics are mostly based on heuristics (d) maintaining test cases and test data is a real pain.

In property based testing we write properties and not low level test cases. And let the system generate test cases which validate such properties. There are 2 main advantages with this approach:

1. You think in terms of properties (or specifications) of the domain model which is the right granularity to think about
2. You don't need to manage test cases, which is completely done by the system that generates a large collection of test data

This approach is ideal for the functional programming paradigm, which focuses on pure functions. Using functional programming it's easier to reason about your model - hence it's easier to test functional programs using properties. In this talk I will take some real world examples of property validation and verification using scalacheck (the property based testing library for Scala) and a real world domain model.