Contour (a Scala+GWT framework) Tutorial

In my spare time I've been writing a client+server web-framework in Scala + Google Web Toolkit. It is in a very early stage right now, but is already enough to make the code of the GWT's tutorial two times shorter, yet easier to read and understand.

I mean two times shorter when compared to the Scala version of the StockWatcher tutorial from the previous article, which itself was shorter and easier to read than the original Java version of the code.

The framework is called Contour (github.com/kazachonak/contour). It is worth mentioning that it uses reactive programming under the covers. Here is a Contour-based version of our app in action:

Scala + Google Web Toolkit. Tutorial.

Today we'll rewrite a standard Google Web Toolkit (GWT) tutorial translating Java code to Scala code line by line. In the next article we'll rewrite this example one more time using a more idiomatic Scala API on top of GWT. Here is our Scala+GWT app in action:

Google Web Toolkit + Scala. Pros and Cons.

The last article here was "Reactive Programming Tutorial in Scala + GWT". Now is the time to become more familiar with GWT in general.

developers.google.com/web-toolkit/overview

Google Web Toolkit (GWT) is a development toolkit for building and optimizing complex browser-based applications. Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript. GWT is used by many products at Google, including Google Wave and the new version of AdWords. It's open source, completely free, and used by thousands of developers around the world.

The best GWT pros and cons list I could find on the web is a post by Ganeshji Marwaha, a JavaScript lover. I decided to cite it here and put my comments in the Cons section with regard to GWT + Scala.

Reactive Programming Tutorial in Scala + GWT. Signal.

This is the second (and last) part of the tutorial. All those Scala live examples have been compiled to JavaScript and are running inside your browser. The first part of the tutorial is here.

-----

Signal

Introduction

While EventStream represents a stream of discrete values over time — that is, each value only exists instantaneously (in practice that means that you can never say "what is the current value?"), Signal represents a continuous value. In practical terms, a Signal has a current value, and an EventStream that, whenever the Signal's value changes, fires the new value.

Reactive Programming Tutorial in Scala + GWT

Reactive programming is quickly gaining popularity with more libraries popping up such as KnockoutJS, EmberJS, JavaFX, C# Rx, Flex, etc. So now that we know what is reactive programming and have deprecated the Observer pattern, it's time to write some code.

Let's look into reactive-web.co.cc library written in Scala by Naftoli Gugenheim. I like its support of incremental updates. As Naftoli states: "you can have a set of items transformed it in all sorts of ways and rendered, and when the set of items changes, only the necessary changes will be made to the DOM." Reactive-web has two parts: reactive-core (a general-purpose reactive programming library) and reactive-web (adds reactive-core support to Lift web-framework). You can find a tutorial with live examples on its site.

I've modified some bits of reactive-core (code) to make it work when compiled to JavaScript by Google Web Toolkit (Scala+GWT). Below is the text from the reactive-core tutorial with live examples converted to work with GWT. It means that all those Scala examples are running inside your browser.

Deprecating the Observer Pattern

This is the title of the 2010 paper by Martin Odersky (Scala creator, Java compiler author), Ingo Maier and Tiark Rompf. It shows how the ideas of reactive programming we discussed in the previous article can be implemented in Scala. Here is an excerpt from it:

lambda-the-ultimate.org/node/4028

Abstract

Programming interactive systems by means of the observer pattern is hard and error-prone yet is still the implementation standard in many production environments. We present an approach to gradually deprecate observers in favor of reactive programming abstractions. Several library layers help programmers to smoothly migrate existing code from callbacks to a more declarative programming model. Our central high-level API layer embeds an extensible higher-order data-flow DSL into our host language. This embedding is enabled by a continuation passing style transformation.

Reactive Programming

The last time we've been thinking "Are Variables Evil?" Now let's try to understand the ideas behind reactive programming.

The author of the Haskell library Reactive-banana writes:

apfelmus.nfshost.com/blog/2011/03/28-essence-frp.html

At this point, I should probably explain the design philosophy that makes it all work. What led me to my library is the following question:

What is the essence of functional reactive programming?

A common answer would be that “FRP is all about describing a system in terms of time-varying functions instead of mutable state”, and that would certainly not be wrong. This is the semantic viewpoint. But in my opinion, the deeper, more satisfying answer is given by the following purely syntactic criterion:

The essence of functional reactive programming is to specify the dynamic behavior of a value completely at the time of declaration.

For instance, take the example of a counter: you have two buttons labelled “Up” and “Down” which can be used to increment or decrement the counter. Imperatively, you would first specify an initial value and then change it whenever a button is pressed; something like this:
...
The point is that at the time of declaration, only the initial value for the counter is specified; the dynamic behavior of counter is implicit in the rest of the program text. In contrast, functional reactive programming specifies the whole dynamic behavior at the time of declaration, like this:
...
Whenever you want to understand the dynamics of counter, you only have to look at its definition. Everything that can happen to it will appear on the right-hand side. This is very much in contrast to the imperative approach where subsequent declarations can change the dynamic behavior of previously declared values.

Are Variables Evil?

Now that we know that "Software Engineering is Engineering", let's get back to Scala. Scala is often called a postfunctional or object-functional language. Its designers noticed that object orientation and functional orientation do not contradict each other. Look, for example, at these assumptions:

Object orientation

• Every value is an object
• Every operation is a method call

Functional orientation

• Every operation is a function call
• Every function is a value you can assign to variables or pass to other functions

Scala

• Every value is an object
• Every operation is a method call
• Every method is a function
• Every function is an object

But there is more to what is meant by words "functional programming". Sometimes it means programming without variables. Or at least without changeable variables. Again there is no contradiction to OO programming. We can program without changing variables in a pure OO language, but special languages usually make it much easier. I bet you've already benefited from an absence of variables. Think SQL. Or even Java. Look at this example from the book:

Software Engineering is Engineering

Ultimately, real advances in software development

depend upon advances in programming techniques,

which in turn mean advances in programming languages.

-- Jack W. Reeves, 1992.

I hope you liked the previous article "Why We're Writing the Same Code Over and Over". I think the idea of Abstraction cost is very useful in particular for understanding the progress of software development industry. Another important thing in that regard is seeing the right parallels to other industries.

There are a lot of people arguing what is software development: engineering or craftsmanship? But it is a false dichotomy.

The usual argument is that there are software development projects the exact outcome of which is hard to predict, so software development must not be engineering. But engineering projects in more traditional industries also differ greatly in predictability of exact outcome.

c2.com/cgi/wiki?WhatIsSoftwareDesign

Years ago I read an article that completely changed how I thought about software design.
...
The name of the article is What Is Software Design? It was written by JackReeves and published in The C++ Journal Vol. 2, No. 2. 1992.
...
Essentially the point is this. When the original phases of software development were laid down, they were just plain wrong. Requirements, Design, Implementation, and Test are not what we think they are. Design is not something that you do only before you code. Implementation is not the act of coding. We can see this if we look realistically at what they are in other engineering disciplines.

Why We're Writing the Same Code Over and Over

As we saw in the previous article "Understanding at a lower price", Scala provides more fine-granular code reuse than a Java-like language. When in Java you either reuse a whole module as-is or write a new similar one from scratch, in Scala you often just reuse smaller sub-modules.

You can think "What stops me from doing the same thing in Java?" Well, actually you can define similar sub-modules. But defining and using them often will be so much more complex than just doing some copy-paste that it is not worth it.

Let's continue with the collections processing example. There are libraries for Java collections that allow you to assemble your collection processing part of code from predefined parts similarly to what you find in Scala. But almost nobody uses them. Let's write an equivalent to the one simple line of Scala from the previous article. This Java code is written using Guava (former Google Collections) library: