In this case study presentation, SumAll's CTO, Todd Sundsted, and Senior Software Engineer, Michael Ho, will discuss the move from Java to Haskell along two parallel paths. First, the business/political story — how SumAll convinced the decision makers, fought the nay-sayers, and generally managed the people impacted by the transition. Second, the technical story — how they actually replaced their Java code with Haskell code. Along the way, they will address their hopes and expectations from transitioning from Java to Haskell, and will conclude with the results they've gained and seen to date.

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.

Let's Lens presents a series of exercises, in a similar format to the Data61 functional programming course material. The subject of the exercises is around the concept of lenses, initially proposed by Foster et al., to solve the view-update problem of relational databases.

The theories around lenses have been advanced significantly in recent years, resulting in a library, implemented in Haskell, called lens.

This workshop will take you through the basic definition of the lens data structure and its related structures such as traversals and prisms. Following this we implement some of the low-level lens library, then go on to discuss and solve a practical problem that uses all of these structures.

Abstract: I wrote a distributed (mostly) Functional Compiler in Scheme, OCaml and Elixir that incorporates knowledge of Computational Linear Algebra and domain specific knowledge to generate highly optimized linear algebra code from specification of problems. This talk is about lessons learned in the process.

The problem:
In every domain that uses computational linear algebra (which is all of engineering and science), we encounter the 'how to optimize a linear algebra expression into an optimized sequence of BLAS (or LAPACK or $linear_algera library) kernel calls' problem.

Example: (if the math equations make you want to tear your hair out and go jump off a cliff, don't worry, it is just an example, you don't have to grok it. Just skim the equations The basic problem being addressed here is that solving such equations with code takes up a lot of effort and time from experts in computational linear algebra)

Here is a linear algebra expression from a genetics problem , specifically GWAS -Genome Wide Association Studies, looking for significant associations for millions of genetic markers- where the essence of the problem [1] comes down to generating the most efficient algorithm possible that solves these equations

This in turn involves solving a 2 dimensional sequence of Generalized Least Squared Problems of the form

The algorithms to solve these can be directly coded up in Matlab or Julia. But there are problems with this approach, with this specific problem.

1. For different input sizes, different algorithms give the most optimal performance. Which algorithm do you code up?

2. Even for a given input size, there are multiple algorithms that compute the same result, but have differing computational characteristics depending on the hardware etc. How do you generate the optimal algorithm for your hardware ?

3. Most importantly the structure of *this* specific problem allows optimizations that are specific to the problem which are not built into generic linear algebra routines. (Obviously, one can't expect MATLAB to incorporate problem specific information for every scientific/engineering problem ever). The GLS problems are connected to others, thus saving intermediate results can save hours of computation vs calculating every GLS problem from scratch

In practice, one needs to be an expert in Computational Linear Algebra to come up with the optimized algorithm for a domain specific problem, and then write (say Fortran) code to use BLAS, LAPACK etc optimally to actualize this algorithm, often with much iteration, often consuming 100s of hours.

The Solution:

Incorporating this 'expert knowledge' into a compiler speeds up the time taken to arrive at the best solution (often by a factor of 100 or 1000), and allows Computational Linear Algebra experts to do more interesting things, like focus on their research.

For this particular problem, the above equations, and additional knowledge of the problem domain are the input into an expression compiler. The output is highly efficient and 'proved correct' code

In compiler terms, incorporating domain knowldege into the compilation process results in being able to apply optimizations to the generated Syntax Trees/Graphs, resulting in optimal algorithms. (note: the output of the compiler is a program in another language- say Matlab).

In essence, "Domain Specific Compilers" consume knowledge about the structure of a problem and generate optimized code that solves that problem.

Shin is one such compiler. It consumes a problem description and outputs highly efficient Julia code that solves the problem.

This talk focuses on the engineering challenges I faced in building this compiler, with a special focus on the approaches that failed [5]

Trivia:

"Shin" is the Hebrew letter, not the English word meaning 'front of the leg between knee and ankle' ;-).

Every company uses names from a common theme to name their servers and components - Athena, Zeus, Hercules , or Thor, Loki, Odin, or Jedi, Sith, Skywalker etc. We use Hebrew words, so we have Ruach, Melekh, Malkuth etc..