Introduction to the Elm Programming Language

Standard

designer drawing website development wireframeElm is an interesting new programming language. Its goal is to make web GUI programming a great experience. It compiles the source code to JavaScript, HTML, and CSS.

Elm is a functional programming language. Its main influences are Haskell, OCaml, SML, and F#. Elm is strongly statically typed and it uses type inferencing. You don’t have to specify the type for variables and parameters like in C# or Java. Elm is built on the Haskell platform and has a Haskell-like syntax, though semantics are closer to OCaml.

I want to show you some basic features of Elm in this post. I’ll write some more posts about Elm in the next few weeks.

Hello, world!

You will find an online editor on the Elm homepage where you can try out the programming language. Just click “Try” and you’ll get to the online editor. On the left side you’ll see the editor and on the right side the result when you run the program. You can run the program by clicking on “Compile” (below the editor).

We’re learning a new language and the first program in a new language is usually a “Hello, world” program. It looks like this in Elm:

    main : Element
    main = plainText "Hello, world!"

main defines the entry point of the program. It is of type Element which represents a rectangle on the screen with a known width and height. Elements are combined to define complex widgets and layouts. The type is defined in the library Graphics.Element which is imported automatically when the program starts.

The first line of our program is the type signature. It defines the name and its type separated by a colon. The entry point has the name “main” and Element is its type. The type signature is optional.

The second line is the code. "Hello, world!" is a string. The function plainText converts the string to an element. You can see, that you don’t need braces for calling a function.

Here is another version of the hello world program:

    main = asText "Hello, world!"

Did you notice the difference? The second program prints the string “Hello, world!” with quotes and the first program without quotes. The first version uses the function plainText to convert the string to an element. plainText takes a string and creates the Element from the string value.

The second program uses asText which takes any value and uses its string representation for creating the Element. The string representation of a string includes the quotes and the value does not.

    main = asText (4,5)

This program prints the string representation of the tuple, “(4,5)”. A tuple is an ordered list of elements. The tuple above contains two integer values, 4 and 5. If you change asText to plainText you’ll get a type error. plainText expects a string as parameter, but (4,5) is a tuple.

Elm is reactive

Elm has an interesting type called Signal. A signal is a value which changes over time. Let’s see it in action:

    import Mouse

    main : Signal Element
    main = lift asText Mouse.position

The first line imports a library for working with mouse input called Mouse. The second line is the optional type signature. As you can see the type of the entry point main has changed to Signal Element. This means that output of the program can change over time.

The Mouse module contains a signal called position of type Signal (Int,Int). Every time the mouse is moved its value changes. The value is of type (Int,Int) which is a tuple with two integer numbers. It represents the current mouse position on the screen.

The function lift takes a function as first argument and a signal as second element. Every time the signal is updated the new value is applied to the function and its return value is used as new value for the signal returned by lift. We use asText as function so that lift converts each tuple with the mouse positions to a string when the mouse position changes.

I showed you how a basic hello world program looks like in Elm and I introduced you to Elm’s concept of signals. I will focus on the functional nature of the language in my next post about Elm.

The 25 Most Interesting Links about ASP.NET vNext and the K Runtime

Standard

What is nextMicrosoft revealed its plans for the next generation of .NET at the TechEd North America in May. The next version of ASP.NET will bring some interesting features for ASP.NET web developers:

  • It will be fully open source.
  • ASP.NET MVC, ASP.NET WebAPI and SignalR will be integrated into one framework.
  • Multiple versions of the runtime can be installed side-by-side.
  • It runs on Mono, on both Linux and Mac OS X.
  • No dependency on System.Web.
  • Better support for development with text editor and command line tools.

I collected some links for more information and details about this topic.

Blog posts about ASP.NET vNext and the K Runtime

Videos about ASP.NET vNext and the K Runtime

Blog Reorganisation

Standard

BlogI migrated my blogs back to WordPress. I started blogging with self-hosted WordPress blogs about 8 years ago. Some years ago I began using Disqus for comments and switched one blog to Octopress. I migrated both blogs to Pelican one year ago. Now I’m back at WordPress. While I was migrating the blogs I decided to merge my two blogs andreas-schlapsi.com (English blog) and andreas-schlapsi.at (German blog) to one blog at schlapsi.com and redirected the URLs from my old blogs to this one. I plan to write here in English. Maybe I’ll write something in German here every now and then.

Why did I switch to WordPress again? Jeff Atwood said, a blog without comments is not a blog and not having a decent comments system was one of the biggest disadvantages when I used a static site generator. I didn’t want to save the comments on another system operated by a commercial company like Disqus.

I found a way to write my posts in Markdown on WordPress. Not being able to write in Markdown was the biggest issue I had with WordPress and the number one reason why I migrated my blog away from WordPress.

I wanted to improve the themes of my old blogs, but I didn’t have enough time to work on them. I guess it’s easier to use one of the available WordPress themes instead of creating my own theme.

But there are also some downsides: first I need to run server software which needs more server performance than a static site. There are solutions which can improve the situation.

Second I still don’t like the editor. There are blog editors out there. Maybe I’ll try out some of them.

Of course, I had a look at Ghost, but it wasn’t as mature as WordPress. It didn’t have a comment system, too. It looked very nice and promising, though.

Official End of the RowTest Extension

Standard

I published my RowTest extension for NUnit in 2007. I developed it to experiment
with the NUnit extension mechanism which was new in NUnit 2.4. It got some users
and the extension was included in NUnit 2.4.8. NUnit 2.5 had the new Test Case feature
which was built on the experience gained by the RowTest extension.

To switch from RowTest to TestCase you just have to replace the RowTest attribute by the TestCase attribute.

Since the RowTest extension isn’t needed anymore I stopped its development long time ago. I just didn’t publish an official statement about its end. I will remove the RowTest project page on my blog, but the project pages on Google Code and Launchpad will still be available:

Von Rot zu Grün – Green Bar Patterns

Standard

Ich wende testgetriebene Entwicklung bereits seit über 10 Jahren an. Kurz zur Erinnerung: Bei TDD (Test-Driven Development) erfolgt die Implementierung in vielen kleinen Iterationen, die aus drei Teilen bestehen:

  • Schreibe einen Test für das erwünschte Verhalten. Der Programmcode erfüllt diesen Test noch nicht oder es gibt ihn noch gar nicht. Manche Testrunner stellen diesen Zustand durch einen roten Balken dar. Daher wird diese Phase oft mit Red bezeichnet.
  • Ändere oder schreibe den Programmcode mit dem kleinstmöglichen Aufwand, damit er den Test erfüllt. Manche Testrunner stellen diesen Zustand durch einen grünen Balken dar. Daher wird diese Phase oft mit Green bezeichnet.
  • Refaktorisiere den Code. Entferne Code-Duplizierung, führe Abstraktionen ein, wenn nötig, usw. Danach führe die Tests nochmal aus. Der Code muss die Tests noch immer erfüllen. Diese Phase wird oft mit Refactor bezeichnet.

Ich habe am Beginn viel über TDD gelesen. Meistens waren es Artikel im Internet. Es gab noch nicht viele Bücher über dieses Thema. Eine Ausnahme war Kent Becks Test-Driven Development. Es ist ein vergleichsweise dünnes Buch, das ich sehr schnell gelesen hatte.

Vor kurzem habe ich das Buch wieder gelesen und dabei wurden mir einige Details wieder bewusst. Dazu gehören die sogenannten “Green Bar Patterns”. Diese Patterns beschreiben, wie wir den Programmcode ändern können, damit er die Tests erfüllt:

  • Triangulation
  • Fake It (‘Til You Make It)
  • Offensichtliche Implementierung

Triangulation

Bei der Triangulation verallgemeinern wir den Code erst, wenn wir zwei oder mehr Tests geschrieben haben. Daraus ergibt sich folgender Ablauf:

  • Zuerst schreiben wir einen Test.
  • Dann machen wir die kleinstmögliche Änderung am Programmcode, damit er diesen Test erfüllt, z.B. geben wir nur den erwarteten Wert zurück.
  • Dann schreiben wir noch einen Test.
  • Erst jetzt abstrahieren wir die Implementierung.

Nehmen wir an, dass wir eine Funktion schreiben wollen, die zwei Zahlen addiert. Der erste Test könnte so aussehen:

    [Test]
    public void Sum_3plus4_Returns7()
    {
      Assert.That(Plus(3, 4), Is.EqualTo(7));
    }

Dann würde diese Implementierung ausreichen, um den Test zu erfüllen:

    public int Plus(int a, int b)
    {
      return 7;
    }

Um den Code verallgemeinern zu können, benötigen wir einen weiteren Test:

    [Test]
    public void Sum_9plus15_Returns24()
    {
      Assert.That(Plus(9, 15), Is.EqualTo(24));
    }

Jetzt können wir die allgemeine Implementierung schreiben:

    public int Plus(int a, int b)
    {
      return a + b;
    }

Beide Tests müssen zu diesem Zeitpunkt funktionieren.

Triangulation wird gerne verwendet, weil die Regeln sehr klar sind. Kent Beck empfiehlt diese Methode nur dann, wenn man sich über die korrekte Implementierung völlig unsicher ist.

Fake It (‘Til You Make It)

Auch bei “Fake It” machen wir nach dem ersten Test nur die kleinstmögliche Änderung am Programmcode, um den einen Test zu erfüllen. Im Unterschied zur Triangulation schreiben wir kein zweites Testbeispiel, sondern verallgemeinern den Code im Refaktorisierungsschritt.

  • Zuerst schreiben wir einen Test.
  • Dann machen wir die kleinste Änderung am Programmcode, damit dieser den Test erfüllt, z.B. durch Rückgabe des erwarteten Werts.
  • Jetzt abstrahieren wir die Implementierung durch Refaktorisierung.

Der erste Test und die zugehörige Implementierung für das obige Beispiel sieht wieder so aus:

    [Test]
    public void Sum_3plus4_Returns7()
    {
      Assert.That(Plus(3, 4), Is.EqualTo(7));
    }

    public int Plus(int a, int b)
    {
      return 7;
    }

Im Refaktorisierungsschritt eliminieren wir die Code-Duplizierung zwischen Test und Implementierung und ersetzen sie durch den richtigen Code:

    public int Plus(int a, int b)
    {
      return a + b;
    }

Wichtig bei “Fake It” ist, den Refaktorisierungsschritt ernst zu nehmen. Nach meiner Beobachtung wird gerne aufs Refaktorisieren vergessen, obwohl es einen so wichtigen Beitrag zum Software-Design darstellt.

Offensichtliche Implementierung

Bisher bestand die Implementierung nach dem ersten Test daraus, dass wir den erwarteten Rückgabewert als Konstante zurückgeben. Aber müssen wir das tun, wenn doch ganz klar ist, wie die Implementierung aussieht? Vor allem in unserem Beispiel mit der Addition zweier Parameter? Natürlich nicht. Wenn vollkommen klar ist, wie die Implementierung aussehen soll, schreiben wir sie einfach.

In unserem Beispiel sieht das so aus:

    [Test]
    public void Sum_3plus4_Returns7()
    {
      Assert.That(Plus(3, 4), Is.EqualTo(7));
    }

Und dann schreiben wir gleich:

    public int Plus(int a, int b)
    {
      return a + b;
    }

Wann verwendet man welche Methode?

Viele TDD-Neulinge fangen mit der offensichtlichen Implementierung an und verzetteln sich dann, weil sie zu große Schritte machen. Andere tendieren zur Triangulation und wundern sich, warum TDD so mühsam ist.

Tatsächlich haben alle drei Methoden ihre Berechtigung. Wir können mit “Fake It” anfangen und zur offensichtlichen Implementierung wechseln, wenn wir merken, dass der Code sehr einfach ist. Wenn die Tests öfter unbeabsichtigt rot bleiben, dann sind wir zu schnell unterwegs und sollten zu “Fake It” oder Triangulation wechseln.

Oft wissen wir nach längerem Nachdenken noch nicht, wie der Code aussehen soll. Dann werden wir mit der Triangulation beginnen und wenn wir sicherer geworden sind, zu einer schnelleren Methode wechseln.

Wenn der Code Schleifen oder Verzweigungen enthalten soll, dann ist er sehr wahrscheinlich nicht mehr einfach. Offensichtliche Implementierung ist dann offensichtlich die falsche Methode.