Colin Howe

I’ve been trying to collect my thoughts on why I prefer Scala’s type system to any other that I’ve come across. To summarise: it has type safety and just the right amount of type burdening.

What is type burdening?

Type burdening is a consequence of type safety. The more you have to specify a type by hand the more type burdened a language is.

Some examples and numbers

Java

Java is very type burdened. I’ll arbitrarily give it a type burdening index of 1 (high values are bad).

Employee bob = new Employee();

Not only must you specify the type everywhere, but you must specify it twice in many cases.

This slows us down, makes code longer and adds no value.

ML

At the other end of the scale we have languages like ML. ML has full type inference. It will even infer the types of arguments on function calls. I’ll give it a type burdening index of 0 (low values can be bad).

fun fac 0 = 1
  | fac n = n * fac (n-1)

The above defines a function, fac, as a function that takes an integer argument and gives an integer result. This is statically typed – but there are no mentions of types anywhere. The types are inferred by the compiler unless you optionally specify a type.

The reason I say that low values can be bad (not must be bad) is that it forces you to think about what the types are whenever you look at this function. Arguably, if functions are well written and clear then this shouldn’t be hard – and you shouldn’t really care. However, we all know that bad code creeps in to any code base.

The other reason this is bad is that somebody could accidentally change the type of the function without realising (suppose they changed that multiply to a divide). This could be part of a public API and the consequences of accidentally changing a signature could be bad.

Scala

Somewhere in between we have Scala. You must specify the types of function arguments, but you don’t have to specify the types of variables (nor the return type in many cases).

def timesTwo(n : Int) = {
  val result = n * 2
  println("Result is ["+result+"]")
  result
}

Similar to ML, Scala will infer that the type of the variable result is Int. It will also infer that the return type of timesTwo is Int. However, you must specify that the argument n is of type Int. You can specify a return type if you wish, and you can specify a type for the variable result.

I like this because it forces you to specify your functions signature. If you want to change it – you have to be explicit and change it by hand.

I like this because you don’t have to specify the types of internal variables that the compiler could figure out for you.

I’m not going to give Scala a type burdening index because I can’t formally define how to come up with the number. Instead, I’ll say it is somewhere between 0 and 1 ;-)

Conclusion

I have purposefully steered clear of the argument of dynamic vs static typing. It’s a culture thing – some people like one, some people like the other, some people like both!

Type burdening gives statically typed languages a bad reputation. I think that some people have embraced dynamic typing because they have spent too long being type-burdened. Over time, I hope that more languages will reduce their type burdening and people will focus on the real strengths and weaknesses of dynamic/static typing and make a better choice for themselves.

In my previous post I discussed how working in a higher level of semantics than HTML can be beneficial when writing web pages.

To summarise, suppose you write pages like this:

section(name="Contents") {
  The contents go here.

  We use an empty blank line for paragraph spacing.
}
button(link="somelink", label="Click me!")

You can then map these constructs to HTML provided by a designer. I proposed that this is better for everybody.

But, there are more benefits to this beyond what I initially suggested.

Multiple Mappings

CSS was supposed to give us full control over layouts and make it easy to do things like user themes, printer themes and accessibility themes. Unfortunately, CSS hasn’t quite delievered – we’re still heavily restricted by what the HTML is.

By writing your pages at a higher level and mapping them to HTML you can benefit from multiple mappings. Perhaps you want a more accessible version of your page where buttons are just link elements and don’t have any non-meaningful tags around them. Perhaps you want an entirely different layout / structure for people browsing on mobile devices.

Perhaps, just perhaps, you don’t even want to output to HTML all the time. There’s no reason you couldn’t map the above to controls in a Windows form. When we write our web pages at a higher semantic level we give ourselves greater ability to have flexible output.

Improved Testability

When mapping a snippet such as the above you don’t have to map it to HTML. You could map it directly to XML. This simplifies testing as there are definite elements you can check for and any xpaths or regular expressions you use become far simpler.

This is an example of separation of concerns. Your pages are only concerned with high level structure and content. Your mappings are concerned with how a button as actually gets mapped to HTML. You can now test these separately.

You could even use this to drive browser testing. Use the high level structure, as above, to guide your browser. By looking at the high level semantics and understanding the mappings you can reduce some of the fragility that is common in browser testing.

Correctness

You could impose that certain constructs can only be used within certain other constructs. For example, a subsection can only be used in a section. This makes it easier for people to get things right, which leads to better quality pages and an improved user experience.

Your designers can also impose that the correct HTML is output every single time. Again, better quality pages and an improved user experience.

Does this exist yet?

Nearly ;-)

I have written something that implements this style of writing views. However, I haven’t yet got it all packaged up ready for an alpha release. Within the next week or two I’ll be following up with a blog post to share it.

I’m hoping that by writing these posts before the release I can share some of my vision and people understand where I’m going with it.

I’d love to hear any comments on this approach :-)

Writing web applications using HTML is like writing business logic in machine code.

When you write your web application using HTML directly you lose most of the benefits that the software development world has worked hard for:

1. No re-use
2. No compile time safety (type checking, validity of names, valid use of tags, etc…)
3. Hard to understand code

I’ll quickly explain what I mean by each of these.

No re-use

Most templating languages don’t allow you to re-use HTML snippets. If you want your buttons to be a span of text surrounded by two img blocks (e.g. the left/right ends) then you will have to copy and paste this snippet everywhere you want that style used:

<a href="somelink">
  <div class="button left" />
  <span>Click me!</span>
  <div class="button right" />
</a>

Even worse, as soon as you want to change that style you’re going to be changing a lot of HTML that is largely the same.

Some folks will want to tell me that this could be done with a single a tag and clever use of CSS. Unfortunately, this isn’t always supported by older browsers and it isn’t always easily cross-browser compatible. Sometimes, you just have to write horrors like the above.

Some templating languages allow you to re-use HTML by doing function calls:

<?php button("somelink", "Click me!"); ?>

This isn’t too bad, except it’s done at the cost of #3 – your code loses it’s clarity as you start to switch from HTML to PHP and back again (it’s not just PHP that suffers from this).

No compile time safety

Let’s take a trivial example:

<strong><em>Hello there!</strong></em>

Oops. We’ve just written bad XHTML. Not only is this bad XHTML but some browsers will struggle to make sense of this as HTML as it’s just confusing.

This isn’t the worst of it either. We’re prone to forgetting closing tags, using the wrong tags, using variables that don’t exist… and most of this isn’t found until runtime.

Hard to Understand Code

I’ll go back to my earlier button example:

<a href="somelink">
  <div class="button left" />
  <span>Click me!</span>
  <div class="button right" />
</a>

If you saw this amongst a lot of other HTML you’d have to stop and think about what this HTML is actually doing. Wouldn’t you rather just express yourself and say “I want a button that links to page X with label Y”?

The Root Cause: Working at the Wrong Level

I think that the root cause for these problems is that when we’re writing HTML we’re working at the wrong level. It’s like working with machine code. Instead of thinking:

I want a header here, some text here and a button here”

We’re thinking:

I want a h3 tag here. A div here with a few p blocks in with my text in. Another div here for my button, containing two images and some text… oh, and the hover text! Must not forget the hover text!

And this is very low level thinking – just like when working with machine code.

Bringing in the Semantics

How about we write our page more like the following?

section(name="Contents") {
  The contents go here.

  We use an empty blank line for paragraph spacing.
}
button(link="somelink", label="Click me!")

This could then be compiled and the output could use HTML snippets. HTML snippets carefully crafted by our lovely designers to ensure consistency throughout the app. For example, the button in the above could expand out to the HTML I specified above.

We’re now expressing our front end at the right level. Further, by having the above use HTML snippets provided by designers we maintain the ability for designers to edit HTML carefully and correctly – they then become similar to the machine code wizards who write the compilers :)

Where next?

I’ve been working on implementing something similar to this style of writing views for some time now. Within the next week or two I’ll be following up with a blog post to share it.

Until then, I’d love to hear any comments on this approach.

I spent some time a few months ago getting my development environment set up just right for development. I think I’ve got it cracked now so thought I’d share :)

Ubuntu 9.10

First up, put Ubuntu 9.10 on your box. I’ve learnt to love Ubuntu for development as it has a few things about it that make things smooth when developing. Proper multiple desktop support is the killer for me.

List of Simple Things to Install

Gnome-do

I press my ‘windows’ key and space, up pops gnome do. I then type what program I want and it launches. No more searching for programs in a start menu.

MS fonts

Most web sites use specific fonts that aren’t available in the default Ubuntu install. As a result they look a bit rubbish in many cases. Add MS fonts to solve this.

Echofon

Twitter in my browser. Just a personal taste thing.

Download status bar (firefox)

No need to have a downloads window that gets pushed behind your browser and forgotten about.

F.lux

Automatically changes the colour temperature of your monitor in the evening/very early morning. Much easier on the eyes. Link

Compiz

Allow configuration of lots of things about how things are displayed. You will also need the settings manager.

sudo aptitude install compizconfig-settings-manager

I add this setting under window decoration:

Decoration windows: !state=maxvert

This hides the title bar on any maximised screens, giving you back a bit more screen real estate.

Wmctrl

Window management tool that I have a very particular setup for. It allows me to hit my windows key and a number on the numpad and move windows around. E.g. win+4 will make a window take up the left half of the monitor.

sudo aptitude install wmctrl
sudo aptitude install compizconfig-settings-manager

Open the compiz settings manager. Then inside general settings open up commands.

Tip: enter a line into a terminal and change it for doing small tweaks.

I used the following settings for a 1680×1050 monitor. It’s not perfect but it’s pretty damn good :-)

Maximized:
wmctrl -r :ACTIVE: -b add,maximized_vert,maximized_horz
 
Left Side:
wmctrl -r :ACTIVE: -b remove,maximized_vert,maximized_horz;wmctrl -r :ACTIVE: -e 1,2,0,833,1050
Right Side:
wmctrl -r :ACTIVE: -b remove,maximized_vert,maximized_horz;wmctrl -r :ACTIVE: -e 1,849,0,831,1050
Top:
wmctrl -r :ACTIVE: -b remove,maximized_vert,maximized_horz;wmctrl -r :ACTIVE: -e 1,0,0,1680,472
Bottom:
wmctrl -r :ACTIVE: -b remove,maximized_vert,maximized_horz;wmctrl -r :ACTIVE: -e 1,0,525,1680,525
 
Top-Left:
wmctrl -r :ACTIVE: -b remove,maximized_vert,maximized_horz;wmctrl -r :ACTIVE: -e 1,2,0,831,472
Bottom-Left:
wmctrl -r :ACTIVE: -b remove,maximized_vert,maximized_horz;wmctrl -r :ACTIVE: -e 1,0,525,831,472
Top-Right:
wmctrl -r :ACTIVE: -b remove,maximized_vert,maximized_horz;wmctrl -r :ACTIVE: -e 1,849,0,831,472
Bottom-Right:
wmctrl -r :ACTIVE: -b remove,maximized_vert,maximized_horz;wmctrl -r :ACTIVE: -e 1,849,525,831,472

Fix bug in Nautilus for home folder link

https://bugs.edge.launchpad.net/do/+bug/290136/comments/48

Minor Tweak to Firefox

I move the toolbar (with the address and buttons) up alongside the menu. The net effect is one less row at the top of Firefox and more focus on web pages.

Wine 1.2 (beta)

Needed for…

Spotify

Music. ’nuff said ;-)

Mozilla Prism

I use this to put gmail on to it’s own workspace so that I don’t get distracted when looking up things in the web browser.

Eclipse

Vanilla Eclipse doesn’t work perfectly in a vanilla Ubuntu install. Buttons sometimes don’t response. A fix is here

That’s it

This is what I’m running now and I find I’m far more productive in this environment than any previous setup of mine. It’s particularly neat on laptops where vertical screen estate can be a premium.

When discussing val and var in Scala they are often seen as the alternative to Java’s more long winded way of declaring variables, e.g.

Employee bob = new Employee("Bob");
vs
var bob = new Employee("Bob")

The latter is clearly more succinct and has less repetition. This is normally where the discussion ends and we declare Scala the winner.

However, Scala gives you more than this added brevity. By forcing every single variable declaration to use val or var you are forced to make a design decision.

Scala forces a conscious decision about mutability of variables

In Scala, every time you define a variable you make a decision as to whether a variable is to be immutable or not.

Java has the option of adding the final keyword to variable declarations. However, you must remember to do this every single time and it is also more effort (not much, but let’s face it, we’re lazy ;-)). As a result, final is omitted from many places where it could be used.

With Scala, it’s far easier to remember to make things immutable.

So, why do we care about this?

Making local variables immutable can increase code quality

Immutable local variables are:

• Easier to debug: if a variable is initialised to a value at the start of a method then it will be the same value at the end. It’s one less thing you have to worry about
• Easier to maintain: someone new to the code cannot accidentally change the value of the variable (at least not without taking the effort to change it from a val to a var)
• Easier to test: if something can’t change during a method call then you don’t have as much to consider when testing

And that is why I think val and var rock :)

I’ve seen a lot of arguments lately comparing Scala to [insert any language here]. The arguments are normally based on some mix of conciseness, static typing, functional programming and the actor model. However, I’ve yet to see anyone arguing for the main reason I’m drawn to Scala: it’s fun to work in.

Some of this fun factor is a result of the above arguments but I’m going to illustrate 3 ways in which I find Scala more enjoyable than my normal language: Java.

Functional Programming is Fun

There. I said it.

I don’t mean the brain-bending functional programming examples you often get at university. I mean the practical sort:

val totalAge = list.foldLeft(0)(_ + _.age)

The Java alternatives to this are full of boiler plate: interfaces and anonymous inner classes or iterating over the list and summing. However, writing all that boiler plate code isn’t fun. Writing only the code that you want to write is way more fun than writing the code you want to write surrounded by a load of dross.

Forgetting multi-threading woes is Fun

The actor model allows you to remove a lot of your multi-threading woes as you can rely on the message-passing model to be safe. This removes all that boring time spent pondering whether each synchronized block is valid. It also removes a lot of the boring time spent debugging multi-threading bugs.

Explaining actors is even fun in itself. You can get a group of people together and they can be the actors and you can act out a scenario. Far more fun than trying to explain multi-threading.

Getters/setters are dull, dull, dull

public void setAge(int age) {
  this.age = age;
}
 
public int getAge() {
  return this.age;  
}

*yawn* I know this can be auto-generated by any decent IDE. However, I shouldn’t have to auto-generate it. I shouldn’t even have to see this stuff unless it is doing something exciting. In Scala you can do this in one line:

var age

If I need to do something more exciting in the getters/setters then I can. That option is still there. However, the default 90% case is covered off in one line. Goodbye dull code that offends my eyes every time I see it.

Conclusion

So, there we have it. 3 examples of why I find Scala more fun than Java – but, there are many more! I welcome any more examples of why Scala is more fun :-)

Having now had the pleasure of working with several people who I count as great developers I believe I have spotted a trend. This trend is what helps them become great.

The trend: great developers rebel

They rebel in a very specific and secretive way. When a great developer is given a task to do that they can finish with time to spare then they will take longer on the task.

I believe this is true of a lot of people. However, great developers use this extra time in an interesting way.

Great developer’s take time to learn

They will spend the extra time learning new things instead of finding other diversions.

This is their rebellion. Great developers steal time allocated for work and use it for learning.

Encourage the learning

Only by rebelling like this can they keep themselves on the cutting edge and constantly feeding in new ideas. Only by doing this can they really add the extra value that makes them great.

Not all great developers like doing research in their spare time. Nor should they have to. If it adds value to the business then it should be done in office hours.

Call to action

Managers: please, acknowledge that this happens and give your developers some time to actively and openly learn (and discuss with their peers).

Developers: if you do this (even if it’s just whilst you are “compiling”) then please leave a comment with your thoughts :)

If you made furniture, would you sell it without polishing it?

If you made a car, would you sell it without giving it a glossy coat of paint?

No?

Then why is it accectable to release code without that same level of perfection?

To me, refactoring is an essential step of the development phase that gives your code that polish, that gloss of paint. Yet, it is often overlooked.

Only after doing something do you really gain a good understanding of what you have done. It is at this point you can make your code really do it’s job well and reduce its technical debt for the future.

Many of you will have heard of Brook’s law – “Adding manpower to a late software project makes it later”. I’d like to explore the opposite action: removing manpower from a late software project.

80% of the work done by 20% of the people

From my personal experiences I have seen many projects where most of the work is done by a minority of people (the experts on the team). With the rest of the team either being inexperienced (and we accept that they have to get experience before they can become the minority), managing the team, or, in the worst case, dead wood.

I have also heard this observation made my many other people.

Hypothesis: Removing manpower from a late software project makes it earlier

Remove the dead wood

Most companies suffer from dead wood, we all know who they are but for some reason they still float around. Get them off your late running projects.

Ideally, stop them being dead wood when you move them to a different project.

Remove the Inexperienced

This reduces the time taken by the experts to correct mistakes, educate and train the inexperienced.

On a late project this makes sense. In a normal project – this is shooting yourself in the foot. You need to keep training your inexperienced folks if you hope to have more experts in the future.

Remove the management

If you’ve just removed people from your project then you can probably remove a manager or two. This reduces the communication and hierarchy overhead.

Overall Gains

By removing all these people you will have just sped up your experts by reducing their communication overheads and the time they are having to spend looking after other people. You’ve also given them more time by reducing the number of managers they have to explain things to.

You’ve probably not lost much either – as these other people weren’t directly contributing anyway.

Thoughts?

I’ve not had the opportunity to see this done before and it is pure speculation. But, I’d be interested to hear from anyone who has had experience of this.

I’ve been having a play with seeing just how far Scala can be bent before it is broken.

My latest finding is that you can implicitly convert functions to other types.

For example:

object Sickness {
  class WrappedFunction   
 
  implicit def functionWrapper(f : => Unit) : WrappedFunction = {
    System.out.println("Going to call the function")
    f
 
    // Essential! otherwise the conversion happens infinitely
    new WrappedFunction 
  }
 
  // Have to specify the type so that the function is converted
  def wrapMyFunction : WrappedFunction = { 
    System.out.println("Function called!")
  }
 
  // And to demonstrate...
  def main(args: Array[String]) {
    wrapMyFunction
    wrapMyFunction
 
    /*
     * The above outputs:
     * Going to call the function
     * Function called!
     * Going to call the function
     * Function called!
     */
  }
}

This allows for some pretty funky meta-programming-like gymnastics.

Now to find something useful for this :)