Design

At some point we will want to realise our beautiful designs and write code, so we need to decide what language to use. Languages such as Java and C++ are convenient, they are often too inconsistent because they contain a mix or pre/post/infix (and or often know as “mixfix”).

For example, this is a legal code snippet in Java.


i++; ++i; i+i;

j=i+++++i;

Yes, that is five + symbols in a row! In that code, if i started with the value 3, it would finish with 5, while j would have the value 8. Hard to see why? Well, that’s partly why we’re not going to use Java! Similarly, there is always a bunch of extra syntax, things like


public static void main(String[] args)..

This appears in virtually every single Java program, but we still have to put it in. This is sometimes referred to as “syntactic sugar”: it doesn’t do anything to improve the semantics and is just there to make the program (allegedly) easier to read. However, too much sugar is neither useful nor good for you!

Java isn’t the only language guilty of this, of course. Many languages suffer from it. For this book we will use functional programming, which is a style of programming based on expressions and functions. Functional programs are often tiny and can be very efficient. For example, here’s another Java program:


class myfirstjavaprog

{

public static void main(String args[])

{

System.out.println(3 + 1);

}

}

The source code is 133 bytes. That’s not entirely awful, but when we compile it we get a whopping 14,578 bytes. Here’s the equivalent program written in a functional programming language:


> (+ 3 1)

Seven bytes!

We’ll look at functional programming in the next section.