While most of our current projects focus on .NET we also love Arduino - an electronics prototyping platform based on open-source hardware, an easy-to-learn programming language called Processing and a simple software development environment. Evolved from ideas explored in the Aesthetics and Computation Group at the MIT Media Lab, Processing defines a procedural subset of Java together with a lean but effective high-level library. Primarily designed to simplify visual computing on desktop machines, Processing and its philosophy could be successfully ported to the embedded world.

Sites like Instructables, MAKEzine, Tinker.it! and Liquidware show the enormous momentum of the rapidly growing Arduino community. The technical reason that Processing is quite easy to support by hardware vendors like Arduino is the fact that it can be translated to C almost one-to-one. So, after thinking about this whole story, Marc came up today with an elegant way to run Processing on even more devices, namely all those supporting the .NET Micro Framework. As a proof of concept, here is a (partial) port of the Processing library and the original Hello World in Processing - or is it C#?

// Processing.cs

using System.Threading;
using Microsoft.SPOT.Hardware;

partial class Processing {
  const bool HIGH = true, LOW = false;
  const int OUTPUT = 0;

  object[] pins = new object[128];

  void delay (int ms) {
    Thread.Sleep(ms);
  }

  void digitalWrite (int pin, bool value) {
    (pins[pin] as OutputPort).Write(value);
  }

  void pinMode (int pin, int mode) {
    pins[pin] = new OutputPort((Cpu.Pin) pin, false);
  }

  static void Main () {
    Processing p = new Processing();
    p.setup();
    while (true) {
      p.loop();
    }
  }
}

// Program.cs

partial class Processing {
  int ledPin = 13;

  void setup () {
    pinMode(ledPin, OUTPUT);
  }

  void loop () {
    digitalWrite(ledPin, HIGH);
    delay(1000);
    digitalWrite(ledPin, LOW);
    delay(1000);
  }
}

The .NET Micro Framework, a variant of .NET radically scaled down for embedded systems, does not include the System.Linq namespace and does not provide any LINQ functionality. Because its implementation is based on generics, LINQ requires version 2.0 of the CLR. The Micro Framework on the other hand is restricted to the CLI, a standardized specification of Microsoft's CLR 1.0.

Fortunately, the other relevant language features such as lambda expressions, extension methods and list comprehension can all be seen as syntactic sugar. Introduced with C# 3.0 - and due to the genius of Anders Hejlsberg - those features can be compiled to IL instructions already implemented by any CLI-compliant virtual machine. And, as Marc Frei and Cuno Pfister prove with the following code, the lack of generics barely affects the undeniable elegance of LINQ.

// Linq.cs

using System.Collections;
using Microsoft.SPOT;

namespace System.Runtime.CompilerServices {
  [AttributeUsageAttribute(
    AttributeTargets.Assembly
    | AttributeTargets.Class
    | AttributeTargets.Method)]
  sealed class ExtensionAttribute: Attribute {}
}

delegate bool Predicate (object o);

sealed class Enumerator: IEnumerator {
  IEnumerator e;
  Predicate p;

  internal Enumerator (IEnumerator e, Predicate p) {
    this.e = e;
    this.p = p;
  }

  object IEnumerator.Current {
    get { return e.Current; }
  }

  void IEnumerator.Reset () {
    e.Reset();
  }

  bool IEnumerator.MoveNext () {
    var b = e.MoveNext();
    while (b && !p(e.Current)) {
      b = e.MoveNext();
    }
    return b;
  }
}

sealed class Filter: IEnumerable {
  IEnumerable e;
  Predicate p;

  internal Filter (IEnumerable e, Predicate p) {
    this.e = e;
    this.p = p;
  }

  IEnumerator IEnumerable.GetEnumerator () {
    return new Enumerator(e.GetEnumerator(), p);
  }
}

static class Program {
  static int Count (this IEnumerable e) {
    var n = 0;
    foreach (var o in e) {
      n++;
    }
    return n;
  }

  static IEnumerable Where (this IEnumerable e, Predicate p) {
    return new Filter(e, p);
  }

  static void Main () {
    var a = new int[] {1, 2, 3, 4, 6, 8, 9, 9, 9};
    var n = a.Where(v => (int) v % 2 == 0).Count();
    var m = (from v in a where (int) v % 2 == 0 select v).Count();
    Debug.Print(n + " " + m);
  }
}

While the designers of C# introduced them with good intentions, enums also add a surprising amount of complexity to the language. And some serious sources of errors. The C# Specification states that:

An enum type declaration defines a type name for a related group of symbolic constants. [...] a runtime decision is made from a fixed number of choices that are known at compile-time.[...] The use of enums makes the code more readable and self-documenting.

But in a system with more than one assembly, there is not necessarily a single time of compilation. As a result, modifying a public enum can break client assemblies. Consider the following example:

// E.cs

public enum E {A, B, C}

// P.cs

using System;

class Program {
  static void Main () {
    Console.WriteLine(E.A);
  }
}

Running the program P.exe outputs the string A. After changing E.cs to public enum E {B, C} the output of the same program is now B. The error remains hidden until P.cs is recompiled. Hence, we use a sealed class with a private constructor and static readonly (not const) values instead:

public sealed class E {
  E () {}
  public static readonly int A = 0, B = 1, C = 2;
}

Note that this approach is no less type-safe than an enum would be, as it is always possible to assign arbitrary values to an enum variable using a typecast. Even the self-documenting nature of enums can be preserved, with the following pattern:

public sealed class E {
  E () {}
  public static readonly E A = new E(), B = new E(), C = new E();
}

Such an approach is slightly less concise than an enum, but it eliminates the class of errors described above. Those still unconvinced might want to read the plethora of caveats, dos and don'ts regarding enum design at Krzysztof Cwalina's blog.

If we expose a constant value in a public (or internal) class we use the modifiers static readonly instead of const, to be able to change the value in the future. The C# Specification states that:

A constant is a class member that represents a constant value: a value that can be computed at compile-time. [...] constants are considered static members

Given a system with more than one assembly, this means that values are inserted in place at compile­time of the client rather than looked up at run-time. Changing the constant thus has no effect on client assemblies until they are recompiled. Worse, without recompilation clients will not even notice that a const member has been entirely removed. Consider the following example:

// C.cs
		
public class C {
  public const int c = 7;
}

// P.cs

using System;

class Program {
  static void Main () {
    Console.WriteLine(C.c);
  }
}

Running the program P.exe outputs the string 7. After deleting public const int c = 7; from C.cs the output is still 7. Replacing const with static readonly in the above example leads to a System.MissingFieldException as soon as the client tries to access the deleted variable. Note, that such an exception is a good thing because the client code is already broken anyway.

Besides deleting constants there are many other types of breaking changes in .NET, but there seems to be no specification as to what exactly is considered breaking and what is not. The closest thing to a complete list of breaking changes in .NET can be found at the .NET BCL Team Blog.

Exploring caves does not come to mind as the most high tech of activities. But Beat Heeb, our CTO and a passionate caver, is about to change this. On his mission to revolutionize the field of caving, he already engineered a software-based cave radio capable of transmitting short text messages out of a cave (!) as well as a sensor based on a PIC controller to count people squeezing through a tunnel.

His current project is a paperless cave surveying system. A laser distance meter communicates over Bluetooth with a mobile device. There, the measured distances are rendered into a 3D model of the cave. Besides the cave surveying software written in C# on the .NET Compact Framework the main engineering task consisted of adding a 3D compass and Bluetooth to the distance meter, a relatively cheap, off-the-shelf Leica Disto A3. Striving for simplicity, Beat managed to create an add-on board that fits into the original housing and can be attached by soldering a mere four wires to the Disto.

Alan Kay on predicting the future:

[...] the best way to predict the future is to invent it.

Dynabook (1968), Kindle (2007)

The C# language unfortunately does not provide a module feature. Nevertheless, the access modifier internal makes implementing Oberon-style module semantics quite straightforward. On the binary level an Oberon module comes very close to a .NET assembly. In code, the C# modifier internal limits member accessibility to a single assembly, so we can use it to designate module wide visibility.

Module members that are marked as exported in Oberon become public in C#. Further, for better readability the MODULE keyword can be emulated with a C# namespace keyword - as long as every assembly is assigned one unique namespace. To import another module, reference its assembly and insert a using statement for the corresponding namespace.

Here's an example of a module M in Component Pascal. Note that comments are also in Component Pascal syntax. All procedure and method bodies are empty for the sake of brevity.

(* M.odc *)

MODULE M;

  IMPORT Q; (* imported module *)

  TYPE
    T* = POINTER TO RECORD END; (* exported class *)
    U = POINTER TO RECORD END;

  VAR
    i*: INTEGER; (* exported module variable *)
    j: INTEGER;

  PROCEDURE (t: T) A*, NEW; BEGIN END A; (* exported method *)
  PROCEDURE (t: T) B, NEW; BEGIN END B;

  PROCEDURE F* BEGIN END F; (* exported procedure *)
  PROCEDURE G BEGIN END G;

BEGIN
  (* module initialization ... *)
END M.

The same module could be implemented in C# as follows

// M.cs

namespace M {

  using Q; // imported module

  public sealed class T { // exported class
    public void A () {} // exported method
    internal void B () {}
  }
  
  sealed class U {} // internal by default

  public sealed class M {
    M () {} // private by default
    public static int i; // exported module variable
    internal static int j;
    public static void F () {} // exported procedure
    internal static void G () {}
    static M () {
      // module initialization ...
    }
  }

}

Now look at the interface definition generated out of the compiled Component Pascal module

DEFINITION M;

  TYPE
    T = POINTER TO RECORD 
      (t: T) A, NEW
    END;

  VAR
    i: INTEGER;

  PROCEDURE F;

END M.

And the public interface of the compiled C# code as generated by Lutz Röder's Reflector

namespace M {

  public sealed class T {
    public T ();
    public void A ();
  }

  public sealed class M {
    public static int i;
    public static void F ();
  }

}

To sum things up: Implementing modules is possible and quite easy thanks to Anders Hejlsberg who - familiar with units, Delphi's module feature - presumably sneaked the internal modifier into C#.

Before we switched to C#, we used our own programming language Component Pascal, a dialect of Niklaus Wirth’s Oberon. Published in 1988, Oberon’s feature set is similar to those of the early Java and C# versions, with an important exception. The module concept which Wirth officially introduced with Modula-2 and later refined in Oberon to provide language support for modularization.

The Component Pascal language report states that

A module is a collection of declarations of constants, types, variables, and procedures, together with a sequence of statements for the purpose of assigning initial values to the variables. A module constitutes a text that is compilable as a unit.[…]

A module also defines a scope of visibility for it's members. To be accessible outside of a module, a member must be marked as exported. To access the exported members of another module, a client module must refer to the other module as imported. Mutual imports of modules are not allowed. As modules are the only unit of compilation, every valid program is structured into one or more modules with clearly stated dependencies.

In his classic paper On the Criteria To Be Used in Decomposing Systems into Modules the software engineering pioneer David Parnas introduces modularization as

a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time.

He identifies information hiding as the key criterion for a successful decomposition. Individual design desicions are confined to a single module each. The interface or definition of a module should reveal as little as possible about its inner workings, thereby minimizing dependencies and facilitating change.

Since 1972 when the paper was published, a lot of fancy software development methodologies have been coming and going. Nevertheless, we are convinced that modularization as described by Parnas is still the most important engineering skill to learn and master in order to develop good software.

Information hiding is essential in object oriented as well as in modular programming. C# provides the access modifiers private, internal, public, protected and protected internal to give a programmer fine grained control over the visibility of a member in a specific context. Those contexts are namespace, class, struct, interface and enum. A member would be e.g. a field, an event, a delegate, property or method. But, as Marc's table shows, this does not really matter. A member's context alone determines if a modifier can be applied at all (□), and which modifier is the default (■).

	namespace	class	struct	interface	enum
private		■	■
internal	■	□	□
public	□	□	□	■*	■*
protected		□
protected internal		□

*) Because members of interface and enum are always public by default, the modifier must not be applied in those contexts.

The individual access modifiers are defined in the C# Language Specification as

private	Access limited to the containing type
internal	Access limited to this program
public	Access not limited
protected	Access limited to the containing class or types derived from the containing class
protected internal	Access limited to this program or types derived from the containing class

Note: the term this program can be replaced by the containing assembly.

Using a state of the art software development environment might boost your productivity - at least if it’s measured in lines of code. However, to understand what is going on behind the scenes using the command line C# compiler csc may be the better choice. Consider this example resulting in a library A.dll and a client program B.exe that references it.

// A.cs

using System;

public sealed class A {
    
  A () {}

  public static void P () {
    Console.WriteLine("A.P");
  }

}

// B.cs

using System;

sealed class B {

  B () {}

  static void Main () {
    Console.WriteLine("B.Main");
    A.P();
    Console.ReadLine();
  }

}

To compile, save the above .cs files and run the following batch file.

REM make.bat

PATH C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\
csc /checked /t:library A.cs
csc /checked /t:exe B.cs /r:A.dll
PAUSE

Note the /checked compiler option, which should be the default but unfortunately is not.

To get a good overview over the .NET library, download Lutz Röder’s Reflector. We use it daily to browse assemblies (e.g. mscorlib.dll in C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\) with the visibility setting View > Options > Browser > Visibility set to Public Items only. The few namespaces worth becoming familiar with at first are System, System.Collections, System.IO, System.Drawing and the System.Windows.Forms namespace. Framework Design Guidelines, a book by Krzysztof Cwalina and Brad Abrams from Microsoft, provides further insight into the main design decisions behind the .NET library. And finally there is the very Google friendly MSDN online documentation. Just enter a particular type or method name and feel lucky (e.g. IEnumerable).

Recently Mete, a longtime friend and hardcore C++ coder, asked which book he should consider to learn the C# programming language. Having piles of C# related books on my shelf the only one I use regularly is the excellent book C# to the Point by Hanspeter Mössenböck. On a mere 200 pages he explains C# in astonishing depth, focusing on underlying concepts and concise examples rather than hand waving and Visual Studio screenshots. For additional information on specific language features, check the C# language specification ECMA-334.

To illustrate the sort of nit-picking we spend our energy on, consider this example from back in the days when we programmed in Component Pascal and foreach was not an option (example in C#).

Given an array

object[] a;

A straight forward approach to iterate through it would be

int i = 0;
while (i < a.Length) {
  Process(a[i]);
  i++;
}

Preventing multiple calls to the property method a.Length leads to

int i = 0;
int n = a.Length;
while (i < n) {
  Process(a[i]);
  i++;
}

If there's no fixed processing order we can further eliminate a variable

int n = a.Length - 1;
while (n >= 0) {
  Process(a[n]);
  n--;
}

And finally, reordering the decrement we can get rid of the ugly -1 and >=

int n = a.Length;
while (n > 0) {
  n--;
  Process(a[n]);
}

The latter two examples use the variable name n rather than i to emphasize the iteration direction.