Monday - Designing and Developing Reactive User Interfaces

This evening, I attended a presentation of an implementation of reactive technologies in .Net by Lee Campell and Matt Barrett.

This centred around a trading application written by Lee, Matt and their team, and, perhaps, best to see this as a continuation of the presentation I saw last week at Microsoft. The application, which, they said, will be open sourced, was pretty slick, a combination of Windows Presentation Foundation and the original Microsoft Rx library.

It was a very good and well thought out presentation about an interesting, a prescient, subject.

Wednesday - Android Livecode, RxJava Architectures on Android at Microsoft

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

Yeah, I didn't get it either, and the Microsoft people were not exactly convincing in their reasons for hosting what is, essentially, a presentation for the competition. (For those who don't know, Android is the mobile phone\embedded operating system owned by Google and in competition with Microsoft's Windows 8).

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 models 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?

Overall, the presentation wasn't brilliant as Timo is not a natural presenter, plus he seemed unaware of any of the alternatives (although his boss was there and stepped in to answer the awkward question or two that arose), which was a shame because it does seem like an interesting subject.

Real World Comparison of Scala and Clojure

Tonight, I attended a presentation by Robert Rees (the podcast available here), from the Guardian Newspaper group, comparing his experiences with both Scala (which is being rapidly adopted by the Guardian, along with MongoDB, to replace their Java/Oracle technology base by the years' end) and it's functional competitor Clojure.

I'll just write a little bit of context for those who aren't too familiar with what all the fuss is about.

Usually, when you make a piece of software that runs on an operating system, such as, say, Windows or Android, you have two pieces of software, a compiler and a linker, that turn the code into an executable, which you can then run. Most pieces of software are done like this, from my noddy little exercises in C for college up to Microsoft's Office suite. About fifteen years ago, a group of programmers at Sun Microsystems, in the U.S., came up with the idea that you can separate the executable into two halves: the first bit would be the specific code to do a particular job and the second bit to be more general that would manage the communication between the specific bit and the operating system (the idea wasn't theirs, exactly, but the way they were going to use it was). This bit, or layer, was called a "virtual machine" and it could be re-written for any operating system in such a way that the specific program could be run on any virtual machine without having to be re-compiled, what Sun called "compile once, run anywhere". Thus the Java Language and the Java Virtual Machine (JVM) were created. The Java compiler produces something called "bytecode", a sort of half-way house between code and executable, that can be run by the JVM. In theory (although not an idea immediately taken up by Sun) any language, not just Java, can be turned into byte code by a suitable compiler to be run by the JVM. Unfortunately, Sun jealously guard the definition of byte code, which is the interface to the JVM and how it works, so that no-one can produce another language which runs on the JVM (and can compete with Java, and Sun), unless Sun say so. The same also goes for the JVM itself, thus the first JVM for Linux was made by Sun, not the open-source community.

Skip a few years and up come Microsoft. They've adopted the same idea a few years earlier for their Visual Basic language, but it's not particularly well done. They have a word with Sun about creating a version of Java for Windows. Sun say "ok, but we're watching you!!" (Microsoft being a large corporation with a somewhat mixed reputation, both technically and commercially). Microsoft create their own version of Java, called J++, and a virtual machine to match, but there's a few cross word from Sun (in the form of a legal suit) as they don't like what they see (surprise, surprise). In the fallout, Microsoft create .Net, which is their collective name for both the new Windows virtual machine, the code libraries that go with it, and a load of related (and, some might say, unrelated) technologies. The .Net "VM", called the Common Language Runtime (CLR), is so optimised for Windows, and so pervasive, that almost every executable on Windows now has to use it. Microsoft, like Sun before it, also produced a Java-like (and improved) language, C#, as well as adapting Visual Basic and Visual C++ for use with this new technology.

"OK", says you, "but what's this got to do with Scala and Clojure?". Well, one of the things that Microsoft did is open up the .Net interfaces and, in particular, the definition of the .Net byte code, called Common Intermediate Language (CIL). This means that anybody with sufficient skill can implement a .Net compatible language compiler. This didn't have much of an impact, at first, but in reaction, Sun decided to go one further and open-source most (but not all) of the JVM, an almost complete reversal of the previous policy. It's a bit baffling as to why, but Sun were having financial problems at the time and were subsequently taken over by Oracle, so it might have been something to do with that. Anyway, this openness means that, like .Net, people with sufficient skill can produce new languages for the JVM, and this is what Scala and Clojure are.

Both Languages implement functional programming, but Scala implements both functional programming ideas and object oriented ideas, like those in Java, C++, C# and Delphi. Clojure, on the other hand, is an implementation of Lisp, a mathematics-based language using something called Lambda calculus (invented by Alonzo Church and the basis for functional programming) and one of the oldest programming languages.

Robert's presentation, done in a friendly and relaxed style, took us through the two languages and compared their various features. Although he seemed to prefer Clojure, he admitted that it had some problems which might be difficult to overcome in an environment where Java, or a similar language such as C#, was established. In that case, Scala might be more easily adopted, despite it's more compromised implementation of functional programming.

However, he also highlighted the future release of Java 8, which is puported to have Lambda extensions, and might make adopting Scala or Clojure moot. Also interesting was his theory that if Microsoft implemented similar features in C#, F#, it's functional programming language, would similarly be redundant.

Java and C#

A recent conversation reminded me of the debate about Java and C#. The subject is not as clear cut as might appear and there are things to consider beyond the purely technical reasons for using either.

Java's Age

Java has been around for a while now, since 1995, and was one of the first major commercial object-oriented languages designed as such. C# is relatively new, released in 2002, and has features, such as reflection, that have been invented since Java was released. Java has either only partially included these new features or not at all. The reason for this conservatism in language design is that Sun has been focused on backward compatibility, even at the byte code level, and has been reluctant to implement new features that break this. Microsoft has had a reputation for being somewhat careless about backward compatibility, although this has changed somewhat as they've tried to promote .Net as an open standard.

Java's age, however, is also a head-start and there are many application frameworks and tool suites for Java, such as Spring, Hibernate, and the Apache Jakarta project, which are very mature. C#, or rather .Net, equivalents are only just starting to develop, and some of those that exist are actually ports of Java systems, such as Spring.Net and NHibernate.

Web Enabled

From the start, .Net has been designed for use in web applications. The effect of .Net on ASP, for example, has been almost revolutionary. In particular, .Net has libraries which make the development of web services and SOA much easier than before. Java, on the other hand, has had web services introduced retrospectively, through changes to J2EE and frameworks like Spring and languages like JSP.

UI Applications

Like web applications, .Net has been geared up to produce Windows applications right from the start, although not to the degree that Delphi has. Java has the Swing library, which, although cross-platform, produces very poor applications. It may be worth noting, however, that Vuze, one of the most popular bittorrent clients, is implemented in Java.

Cross Platform

From the start, Java was designed to be cross-platform. The Java slogan has always been, "build once, run anywhere" and Java applications can be built on a Linux box and run on Windows. .Net applications can only be run on Windows and .Net web applications only on IIS, Microsoft's web server. There are ports of .Net to other platforms, such as Mono, but these are not compatible with .Net to in the same way that different implementations of Java are.

The cross-platform limitation of .Net also makes it easier to take advantage of features only available in Windows and nowhere else. This is particularly true of Windows applications.

Politics

Java has evolved in a very open culture at Sun, Java going open source in 2007. Even though Sun held the licences to Java, it included interested groups in it's decision making process, what Sun called the Java Community Process. This is probably because the focus at Sun was hardware, which is where it made the bulk of it's money, rather than software. With the buyout of Sun by Oracle, this may change as Oracle are a software vendor, like Microsoft, although not development tools.

In contrast, .Net is very proprietary. Microsoft have not developed a port for .Net to Linux, for example, because of the licencing problems involved with the GPL and because Microsoft has no control over the development of the Linux operating system. In other words, if you want to use .Net, you are stuck with Windows and Microsoft. In anti-pattern terms, this is known as "vendor lock-in".

Conclusion

The choice between .Net and Java is not an easy one. There are a lot of technical factors to be considered, as well as the one's I've listed above. I tend to go for Java, but this is based on the cross-platform nature of Java, in addition to it's maturity and the vendor lock-in aspect. There are good arguments for .Net, however, including Microsoft's considerable support for it for the for the foreseeable future, and it's close relation with the Windows operating system. It also depends on the nature of the work being done. If it's going to be mostly Windows applications, then .Net is the obvious choice. With web applications, it's more complex, but, again, if it's going to be based on Windows, .Net seems to be the right choice. There are other choices than .Net and Java for the web, however, Ruby and PHP for example.

Another consideration is how much is it going to cost to move to these development languages from wherever you are now. Java and C# are syntactically very similar (the claim that C# is a clone of Java has some truth), so the jump from, say, Delphi or Visual Basic, would be the same to some extent.

A good idea is to look at other companies and see the choices they made, but understanding why they made those choices. For example, why do Google use C++, Java and Python, especially Python? Wikipedia is made using PHP, which is also cross-platform independent.

And, of course, the worst choice is one made from blind ignorance.