functional programming

Monads – Asking the Right Question, with Pawel Szulc

On Monday, 1st June, I went to an evening presentation given by Pawel Szulc at Skillmatter regarding Monads in Scala (the videocast of it is here).

 
It’s an obscure subject and not one I really understand, and this presentation didn’t help much (too many cognative leaps, like reading a technical book with most of the pages stuck together).

Monads are a kind of contract or pattern, encapsulating a data type in a consistant interface. The interface consists of two functions: a “bind” or “flatMap” function that, given a translation function, allows another monad to be created from the first; and a unit function which creates the monad from the original type in the first place.

Pavel’s got a thing about monads and tried to explain how they can be used as a design technique, but I think it’s something that going to take a bit more than a presentation to explain. A monograph on the subject, perhaps. Clever bloke, though.

Scaling Business Application Development with Play and Scala

Yesterday evening, I went to see a presentation by Peter Hilton at Skills Matter on using Scala and Play for small-scale development.

In an affable and down-to-earth manner, Peter went through two case studies that his company had handled, both¬† web developments in Holland, where he is based. This is somewhat unusual for Scala in particular and any JVM-based language in general: normally much “lighter” technologies, such as ASP.Net or PHP, are used.

He highlighted the use of a stack of technologies, Play, Scala, Slick (for database connectivity and access), PostgreSQL and MySQL for the database and Bootstrap for the website layout. In particular, he went through the use of Slick, which he recommended, as it has an unusual, more SQL, feel compared to other ORM’s.

He also emphasised the speed of development and that the amount of code needed was much smaller than previous applications he’d developed: the first application was ~4000 lines and the second ~2000, which are both a lot smaller than the applications I’ve worked on. It was interesting to see how his team short-cutted: using social media for security (why not?) and Excel spreadsheet integration for record maintenance.

Overall, it was a good presentation about using Scala in a different way.

Android Livecode, RxJava Architectures on Android at Microsoft

This was an Android Livecode presentation I attended, hosted at the Microsoft offices in sunny Westminster.

After the introduction, the main presentation was given by a Berliner, Timo Tuominen from Futurice, concerning the use of Functional Reactive programming on Android. This centred around the use of RxJava, an open source library based on a Microsoft library and implemented by Netflix, the video streaming company.

(A well attended presentation, as you can see, but there was free beer and pizza).

RxJava is centered around the use of an Observable class i.e. an implementation of the Observer design pattern from the “Gang of Four” book, on which most event model are based. It seems that the difference between, say, the standard Java listeners and RxJava is that the listeners have to be implemented within the class as you’re coding it. Here’s something I’ve been working on for the College:

//custom event maintenance
//this is a list of events that have to
//be serviced when something happens
private List<SwitchListener> listenerList = new ArrayList<SwitchListener>();

public void addSwitchListener(SwitchListener listener) {
    listenerList.add(listener);
}

public void removeSwitchListener(SwitchListener listener) {
    listenerList.remove(listener);
}

private void fireSwitchListener() {
    //parcel up the state of the switch in a SwitchEvent object
    SwitchEvent e = new SwitchEvent(this, isSwitchOn());
    //then send it to every listener in the list
    for(SwitchListener listener: listenerList) {
        listener.switchChange(e);
    }
}

Listeners are all over Java components as it provides a way of passing messages between the components and their containers without the components having references to the latter (a problem known as “coupling”).

What RxJava seems to do is wrapper up listeners, or something like them, into a framework that can be applied to any other object. For example, if you want to “listen” to an object so that when it changes you can do something else, or react to it, you can use the Observable class to do it:

Observable.from(names).subscribe(new Action1<String>() {
    public void call(String s) {
        System.out.println("Hello " + s + "!");
    }
});

It does seem to be something that you would think was already in function programming languages, like Clojure and Scala, by default, but RxJava can be used by these, so maybe it isn’t?

London Java Community – Lambdas: Myths and Mistakes

On Wednesday evening I went to see the presentation by Richard Warburton at Skills Matter regarding the new functional features of Java 8.

A few words of explanation for those not familiar with the terminology.

The JSR mentioned is a Java Specification Request, which is what you create when you have a suggestion for how you want Java to change in the future. These are submitted as part of the Java Community Process, set up by Sun when they realised they had something big on their hands releasing Java. In theory it allows everyone to have a voice, but in practise it’s mostly those with very extensive knowledge of the language (such as Richard), although the Adopt-a-JSR he talks about is a move to allow the average code-cutter their ten-penn’th, as well as field testing the resulting change. The JCP has been criticised for slowing down changes to Java which might make it more competitive: Microsoft just releases their software to beta without any real consultation, while Google just seems to keep everything in permanent beta, killing it off when they get tired of it.

The “lazy” and “eager” he talks about are functional concepts that are easier to grasp by watching them in action rather than talking about them, but the nearest non-programming equivalent would be the just-in-time of logistics and manufacturing (a part is ordered to arrive just in time to be used, thus eliminating the need to store it and the resulting cost of doing so). The lazy algorithm is executed when it’s needed, whereas the eager one is executed completely. This is why there’s a problem when the different algorithms are mixed and why the lazy ones play havoc with profilers (software that tries to work out how efficient your code is, amongst other things).

Richard was quite eloquent, highlighting the changes and giving examples of the way in which they should be used, but it became clear that Java 8 is not the radical change that everyone thought it might be. The functional features, like interfaces and generics before them, look like they’ve been added onto the existing features and even create conflicts with them (the “streams” and collections Richard talks about).

While it’s looking as if they are not going to be usurping Scala and Clojure any time soon, the new features look very Scala-like, which does look a little ominous for the latter. Mind you, they also look a little Erlang-like as well, so make of that what you will.