Opinions on F#


I decided quite early on that I wanted to use F# for a piece of the Ioke implementation. Josh Graham (a colleague at ThoughtWorks) suggested using it for the pieces of code doing operator shuffling. I first did a C# implementation, since it was quicker to port form Java to C#, then got that working, and finally reimplemented it in F#. The resulting code ended up being not that much smaller, but definitely more readable. I like using functional idioms if possible, but the fact of it is that the operator shuffling code is extremely imperative.

I definitely like the experience. If I can, I will aim to replace more pieces of the implementation with F#. The main problem standing in the way of that is that there doesn’t seem to be any good way of handling joint compilation. For me to use F# for real, I would need a compiler that can handle mutual interdependencies between the F# and C# code. At the moment I’m using interfaces and factories and separate modules to handle it, but that only works since the op shuffling code is very separate from the rest of the implementation. I don’t have many such pieces, so a joint compiler would be useful.

The code ended up being very clean due to the lack of type annotations and indentation for structure. This is nice. Pattern matching work very well, although the documentation on how you can combine patterns seem to be on the weak side. I had to guess my way forward.

Type annotations ended up being necessary in most code that took .NET types as arguments. This made it a bit hard to see the structure, since I ended up having to add type tags in many places. Most code will probably not be using so much .NET types, so this was a problem with what I was trying to do, I think.

The Emacs support for F# indentation ended up having trouble with the “else” in if-else statements, so I avoided if statements and went wild with patterns instead. I like the way it looks, actually.

One of the main properties of a functional language is obviously the focus on using functions for things, and this was of course one of the nicer aspects. In F# I could remove a full implementation of the Strategy pattern, and just go with curried functions instead. Instead of loops, I ended up using locally defined recursive functions. This reads really well, and feels natural for me.

The fsc compiler is extremely slow – at least on Mono. This made the turnaround cycle a bit longer then ideal. Another thing to take note of is that – just like for all other ML implementations – the error messages for type problems are way more then cryptic. Totally inscrutable, not very helpful, and generally pointing at the wrong line. This is one area where I think the F# team need to improve matters a bit. I know it’s hard with the algorithms used for type inference, but if it’s going to be part of Visual Studio 2010, good error messages and error handling is obviously important.

Oh, and the fsc –help text is totally unhelpful, and very out of date.

All in all, I really liked the experience, with the caveats above noted. I hope I can figure a good way to replace more of my internals with F#, and I am going to take a second pass at the op shuffle algorithm and see if I can make it more functional.

If you’re on the .NET platform, I recommend that you take a look at F#. It’s very nice, and allow different ways of expressing algorithms that can make your code much clearer.



Some .NET reflections


I used to do .NET, when it was new. I’ve been away from it for several years though, so coming back to it feels like jumping in to a new environment. I’ve been using C# and F# for the new Ioke implementation, and during this time I’ve collected some thoughts and opinions. These are all framed in my regular use of Java, of course. And if this is obvious stuff to anyone else, please feel free to ignore me.

I won’t write everything in this post, though. I’ll split it up a bit. This is just the folio.

Incidentally, if you have seen tweets from me sounding pissed of, chances are good you will get explanations for it from these posts. At the moment I will write three posts: Opinions on F#, Opinions on C# and .NET, and .NET and interface madness. That is what I have planned right now, at least.



Ioke for the CLR released


The last two weeks I’ve been furiously coding away to be able to do this. And I’m finally at the goal. I am very happy to announce that the first release of Ioke for the CLR is finished. It runs on both Mono and .NET.

Ioke is a language that is designed to be as expressive as possible. It is a dynamic language targeted at several virtual machines. It’s been designed from scratch to be a highly flexible general purpose language. It is a prototype-based programming language that is inspired by Io, Smalltalk, Lisp and Ruby.

Homepage: http://ioke.org
Download: http://ioke.org/download.html
Programming guide: http://ioke.org/wiki/index.php/Guide
Wiki: http://ioke.org/wiki

Ioke E ikc is the first release of the ikc Ioke machine. The ikc machine is implemented in C# and F# and run’s on Mono and .NET. It includes all the features of Ioke E ikj, except for Java integration. Integration with .NET types will come in another release.

Features:

  • Expressiveness first
  • Strong, dynamic typing
  • Prototype based object orientation
  • Homoiconic language
  • Simple syntax
  • Powerful macro facilities
  • Condition system
  • Aspects
  • Runs on both the JVM and the CLR
  • Developed using TDD
  • Documentation system that combines documentation with specs

There are several interesting pieces in ikc. Among them I can mention a new regular expression engine (called NRegex), a port of many parts of gnu.math, providing arbitrary precision math, and also an implementation of BigDecimal in C#.