Principal Data Scientist, Practice Lead for Data Science, AI, Big Data Technologies at Teradata. O’Reilly author on distributed computing and machine learning. ​

Natalino leads the definition, design and implementation of data-driven financial and telecom applications. He has previously served as Enterprise Data Architect at ING in the Netherlands, focusing on fraud prevention/detection, SoC, cybersecurity, customer experience, and core banking processes.

​Prior to that, he had worked as senior researcher at Philips Research Laboratories in the Netherlands, on the topics of system-on-a-chip architectures, distributed computing and compilers. All-round Technology Manager, Product Developer, and Innovator with 15+ years track record in research, development and management of distributed architectures, scalable services and data-driven applications.

Monday, April 1, 2013

Scala: a multiparadigm programming language

Scala is a language which supports multiple programming paradigms.

an overview of programming paradigms from wikipedia
First off, it allows you to describe your application or library using the  Object Oriented programming paradigm.

Orthogonally to this, you can describe your classes, types, and methods in either functional programming or imperative programming or even a combination of both.

Scala also provides a third level of orthogonality:  it is possible to describe the computation as a set of communicating entities, by using the actor-model paradigm.

Each of these styles has some pro and cons. From a mathematical perspective, Scala is  quite an interesting mix of components, since functional programming is formally defined in lambda-calculus while imperative programming is modeled by turing automata, and the actor model programming is very closely related to process calculus and closely related to non-determinism and relativistic programming (have a look at http://en.wikipedia.org/wiki/Actor_model_theory).

Furthermore, almost opposite to the actor model we have object programming model. While the one emphasizes the behavior (verbs) of modules and the dynamics of the system, the object oriented paradigm emphasizes the hierarchy (nouns) of the modules and the static view of the system.

Interestingly, despite the preferences and the pecularities of each of these paradigms, for practical uses they are all equivalent in terms of "programming power" (check http://en.wikipedia.org/wiki/Turing_completeness).

Since scala basically offers 4 programming models, it's up to the programmer to make the most use of it.

The purist functional programmer:

Scala is also a functional language. The purist programmer would write only pure functional code. However this approach requires quite advanced constructs when when dealing with otherwise trivial imperative constructs such as

  • variables -> state typeclass
  • recursion -> trampoline/free monad
  • nested structures -> lenses
  • threads -> futures and promises
Although trampolines, free monads and lenses and state typeclasses are  absolutely gems of computer science reasoning, they are way more complicated to digest then variables, heaps, and mutable nested structures. They do solve an important problem: they encapsulate mutable state, and reduce side effects in your application. So again, the pros are great, but the switch of programming paradigm might be challenging, at times.when it comes to threads vs futures: future might be a better pattern than threads, since conceptually they focus more on the processed result, rather than the processing agent.

The veteran programmer:

Mostly coming from imperative and OO languages, will be very pragmatic about actors and functional composition. Will mostly try those out in several place of the project. The drawback of this approach could be a lack of coherency or a less effective use of the actor or FP patterns available in scala.

The spatial programmer:

This profile belongs also to the purists. Such a programmer would be more inclined to visualize a program as a set of spatially communicating blocks rather then as a temporal list of command to be executed. The preferred model is a actor model maybe in combination with functional composition.

Final words

Well there is much more to tell but I will just point you to a number of great lectures about scala functional programming.

First two courses:
(practical) Scala: https://www.coursera.org/course/progfun
(theory) Category Theory:http://universityofreddit.com/class/36451/

If you want to know more about the actor model and communicating actors, check:
http://en.wikipedia.org/wiki/Kahn_process_networks
http://en.wikipedia.org/wiki/Actor_model

Since we are talking about scala, it makes a lot of sense to introduce typesafe and the fantastic akka library. Akka has the actor model at its core. Please check this one-pager on akka actors.

Now the uber stuff. Watch/Read this with a clear and open mind. Don't expect to understand it straight away, but believe me, it's really fantastic great stuff.

Scala: scalaz state typeclass
Haskel: Lenses (this is implemented in scala scalaz too)