I have been programming for a long time now. I have learnt many languages, and am even having a crack at designing one. This page collects my thoughts on languages, general programming practices, and specific hints for working with a few languages that I have a lot of experience with.

I am a great believer in getting the compiler to do as much work for you as possible. I always enable as many warnings as I can and I much prefer static typing over dynamic typing. I try to always unit-test my code, and generally provide lots of tests. I find that writing my tests at the same time is the best approach; sometimes the tests inform the structure or specification of the code, and sometimes writing the code makes me realise that the expected behaviour I wrote in the tests is wrong.

Haskell is a wonderful, statically typed functional language. The functional aspect is complemented by monads, which are a nice way (once you have got your head round them) of sequencing operations for things like I/O, or carrying around state. I find writing Haskell code fun; I seem to spend a lot more time writing code, and less time fussing over awkward aspects of the language. Here are my tips for Haskell:

• Give types to every function you write, top-level or inside a where clause. If you can't figure out the type, you probably don't understand exactly what your function is doing! For places where the type is awkward, you may need GHC's scoped type extension.
• Use GHC. To do much serious in Haskell, you'll almost certainly end up with GHC, so in practice you may as well abandon portability and just write code that GHC can compile, and make full use of all the GHC extensions.
• Use export lists in test modules, and export a single list of tests. This will help you spot if any of your tests are not being run (because you wrote them but forgot to add them to a test list).

C++ is an oft-misunderstood language. It is often thought of as either "C with classes" or "Java with bloat". My opinion is that it is a language that takes a very long time to master, but it is a powerful language that supports all sorts of different programming styles: OOP, functional, imperative, procedural, meta-programming and probably more besides. One problem is that (either because of their background, or because they need interoperability) programmers often write C++ in a C style. The best way to write C++ is making full use of the STL and Boost libraries, with all the power of classes and templating. I aim for my C++CSP2 library to follow this advice. In my opinion, problems with C++ are:

• Often I write classes with a lot of members, where I want the members to be initialised via the constructor. I end up writing the list of members three times; once to declare the members, once to declare the constructor arguments, and once to perform the initialisation. This is very awkward for maintainability too.
• Like many languages, C++ lacks an ability to easily define functions (or classes) on-the-spot, like the lambda expressions in Haskell (Boost's library notwithstanding) or anonymous classes in Java.

This is a quick run-through of languages and things I do and don't like about them:

• Java: good library, originally poor language (the foreach loop and generics helped).
• Prolog: good for what it does, but could do with a solution to the problems of I/O and state (like Haskell and its monads), and needs better support for data-types (e.g. records).
• occam: good idea, but traditionally lacked support for better data structures (such as maps) and templated (or similar) programming. Hopefully by building support for these into Tock (for Rain), we can add them to occam-pi too.

Languages I would like to learn but have not yet found a use for (I find I can only learn a language if I have a particular real task I need it for):

• Python
• Ruby
• C#
• OCaml
• Erlang