Functional Programming Exchange 2013

After slightly disappointing FPX 2012, this year’s edition of Skills Matter-run one day gathering of functional programming enthusiasts bounced back with promising speaker line-up. The participant numbers were up compared to last year and seem to have even exceeded the excellent 2011 edition.

Adventures with Types in Haskell

If anyone had any doubt about the reputation Simon Peyton Jones enjoys in fuctional programming community, the enthusiastic welcome he received must have dispelled it. His talk was, as usual, entertaining and fast-paced, but at no expense of clarity.

Strong typing is the most succesful method of formal verification of program semantics. Despite their unquestionable success, type systems are not without issues: their job is to restrict the set of allowed programs, but this restriction does not always coincide with the intents of the programmers:

Programs allowed bythe type system Programs we wantto write

It is particularly frustrating when the type system gets in our way by disallowing a working program. Simon ran through a number of examples where this happened and prompted advances in Haskell’s type system. The features discussed were:

  • type classes: some functions, e.g. sort :: [a] -> [a], are “nearly polymorphic”, i.e. in order for us to be able to write them polymorphically, we need to restrict the set of admissible types to ones that support specific operations (comparison in the case of sort). Type classes provide this mechanism: if we write the type of sort as Ord a => [a] -> [a] we can make use of the operations provided by Ord type class in sort’s definition.
  • higher kinds: we would like to abstract the notion of mapping values over arbitrary “container”, e.g. instead of having two separate functions, mapList :: (a -> b) -> [a] -> [b] and mapTree :: (a -> b) -> Tree a -> Tree b we would prefer map :: Functor f => (a -> b) -> f a -> f b. Functor here is a type class whose instances are not types (of kind *), but type constructors (of kind * -> *).
  • GADTs (generalised algebraic data types): when defining data type for terms we would like to be able to say what type the term evaluates to, so that writing evaluation function is straightforward. GADTs enable us to do that by allowing individual data constructors to produce arbitrary types, as long as the outermost type is the type being defined:
  • type families (type functions): type classes with multiple parameters enable us to specify that e.g. addition can operate on arguments of two different types; but how can we say what the result type of such addition should be? With type families we can declare that such a type can be derived from the type class parameters:

In recent years there has been an explosion of innovation in type systems. The ultimate goal of all this work is enabling programmers to say what they mean. In Simon’s opinion, one of the main reasons for recent growth in Haskell’s popularity is its rich, but still usable, type system.


Lift 3.0: Across Time and Address Space

David Pollak delivered a preview of what can be expected from next major release of Lift web framework. Not dealing with web development on day-to-day basis I am not best qualified to judge how much of an improvement Javascript sources, cross-HTTP actors, markdown templating or dynamic reload of changed classes are going to be. What is clear is that Lift is quite different from most other web frameworks out there, not least as a result of strong opinions held by its creator: according to David, Akka actor and future implementations are of poor quality, hence the need for Lift’s own version of these abstractions. Another mark of David’s personality on the new Lift is integration of his other recent project, dataflow language Visi, into Lift page templates. While this strong-mindedness does alienate some in the wider Scala community, Lift is still one of the most popular Scala web frameworks and has a dedicated following, so it must get some things right.


Elnode: The Evented IO Web Server

Emacs afficionados sometimes go to such great lengths to get their beloved piece of software to perform as something it was not originally designed for, that it is really difficult to explain their motivation to the non-initiated. One such case is definitely Nic Ferrier’s implementation of web server inside Emacs. In an entertaining talk Nic explained how Richard Stallman’s stepping down from long held post of Emacs maintainer opened the floodgate of innovation: a package system (M-x package-install), lexical scoping in Emacs Lisp and server sockets. This last addition enabled Nic to implement elnode – a web server framework in Emacs Lisp. As Emacs is single-threaded, asynchronous processing of HTTP requests is based on callbacks, in the style popularised by Node.js. The audience could experience the joys of Emacs web first hand, by using a chat application served from elnode instance running on Nic’s laptop.

But why turn Emacs into a web server? To quote George Mallory: “because it’s there”.


Comparing Scala and Clojure

Robert Rees is one of the founders of London Clojurians community and codes in Scala on daily basis as a part of his job at Guardian. In the table below I attempted to summarise his experiences and impressions of the two languages aspiring to be “the next big thing” in JVM world.

Scala Clojure
Java++ Lisp with Java interoperability
complex, academic – see the type system simple, practical – see the data structures
enterprise-friendly: curly braces, strong Java interoperability hippie: no objects, Lisp syntax
good tooling: Eclipse and IntelliJ both have feature-rich Scala plugins poor tool support, most clojurians use Emacs
performance comparable with Java performance sometimes weird
used by companies and teams with large existing Java investment, big codebase, binary sharing of artifacts used by teams that are already polyglot, for software that is service-orientated and communicates over HTTP
Lift, Scalatra, Play2 and other rich, complete frameworks rudimentary web development support from Ring middleware and Compojure
SBT is one of the best build tools out there Leiningen 2 is catching up with SBT
makes working with existing Java codebase easier makes one a better Scala programmer

Overall it was clear that Robert’s sympathies lied with Clojure, but the talk was balanced and did give Scala credit where it was due.


Developing With F# in The Cloud

Adam Granicz, the CEO of IntelliFactory presented his company’s latest product, CloudSharper – a web-based IDE for developing web and mobile applications. On initial launch, planned for April 2013, the IDE will support F#, with server-side compilation, intellisense, multi-project capability and other modern conveniences users of development environments are accustomed to. While the videos of interaction with the IDE – there was no live demo – looked impressive, Adam struggled to explain convincingly the advantages of his solution over existing stand-alone .Net IDEs such as Visual Studio or MonoDevelop. Overall, along with the Lift talk, this one was the least interesting session of the day. In both cases the previews of the products could have been made more relevant to the subject of the conference if the presenters focused on the value added by functional techniques, rather than highlighting specific features that were of interests only to the intended audience of the products.


Reducing Cognitive Bias in Design With Scala

In the course of his work as the principal architect in Elemica, Paul Dale learned to appreciate the importance of good communication between the programmers and domain experts. Cognitive bias in its various forms – ambiguity effect, anchoring, attention bias, availability, false consensus, framing effect – presents a major obstacle to achieving this mutual understanding. As a solution to the communication problem, Paul recommended the framework offered by Domain-Driven Design: building and carefully maintaining common vocabulary that reduces the chance of misunderstanding resulting from the aforementioned forms of bias. This is where Scala comes into the picture: case classes are an excellent tool for modeling domain concepts in concise and uncluttered way. Paul’s observation was that this had an empowering effect on the domain experts, who, having realised that they had no trouble understanding the code, were eager to provide relevant business logic in the form of code that built on the model developed in this way. Paul’s other recommendation was to start with the UI as early as possible – an approach facilitated by Lift’s view-first development model.


LexiFi: Describing Financial Contracts and Extending OCaml

Ever since learning about composing contracts paper I wondered if anyone has commercialised the idea. It turns out that yes: one of the authors, Jean-Marc Eber, founded LexiFi – a company producing derivatives pricing and management software. Alain Frisch, LexiFi’s CTO, talked about the product and how algebraic modeling of financial instruments and construction of term sheets from few generic building block and combinators enables them to add new product treatments to the system in the matter of days.

LexiFi being a French company, OCaml was the natural choice for implementation language. In the course of development of the system, the company had to modify the compiler to support features they needed, contributing the patches back to the official distribution. Presently, LexiFi’s system is distributed together with the complete, customised OCaml toolchain that allows building and execution of their models on Windows and Unix systems without any additional dependencies. Even the Windows GUI is written in OCaml, utilising a bi-directional OCaml-.Net bridge built specifically for this purpose.


F# in the Open Source World

F# was designed by Don Syme of Microsoft Resarch and over the years has progressed from an experiment to a first-class citizen of Visual Studio offering. As with .Net in its entirety, there is the perception that Microsoft has full control over the language and its implementation. Don appeared at FPX to try and alter this impression, and present the vision of F# ecosystem where Microsoft is just one of many contributors. While the compiler development is not yet open, the drops of source code of official releases are available on Github, as are editor bindings that enable authors of editors and IDEs to provide integration with the compiler. This has resulted in environments such as MonoDevelop, Xamarin Studio and Emacs offering excellent support for F# development. On top of the compiler infrastructure, there is now NuGet – a repository of libraries and extensions that work across development environments. An impressive example of community-built extensions was F# binding to R, built as a type provider, so that R functions could be seamlessly invoked from F# code – including opening a window with scatterplot matrix.


Functional Data Storage

Greg Young delivered what probably was the best product demo of the day – and one in which the name of the product has not been mentioned even once. The entire concept of functional data storage, in Greg’s interpretation, was a derivation of ideas from functional reactive programming, NoSQL and event sourcing: what is being stored is not mutable state, but the sequence of events observed by the system. These events can then be interpreted as function invocations: e.g. obtaining current state is possible by taking an initial state and then applying to it in sequence functions represented by all events. In a similar fashion, queries over event stream can be represented as folds (catamorphisms).

This model makes easy certain queries that are difficult in relational, document and key-value databases; one example could be temporal queries, such as “find all people who tweeted Starbucks and then, within 4 minutes, Happy and Coffee”. However, it also calls for a new query language. Greg presented some operators of such language, with demo based on aptly named Event Store – an event database. While many in the audience might have questioned the choice of Javascript as the query language, there is a precedent for that in the form of popular MongoDB; besides familiarity, another point raised by Greg was ease of debugging queries issued via web interface using Javascript debugger built into modern browsers.