There is a common perception that you should choose your type system based on the scale of your project. If you're writing a little program (i.e., a script), you should use a dynamically typed language like Python or Ruby. If you're building a large complicated piece of software, you're better off with a statically typed language like Java or (for the adventurous) OCaml.

I've always suspected that this is wrong; that static types improve your life even when writing small programs, although the advantage is clearly smaller. At least, this should be true for statically typed languages like OCaml and Haskell whose syntactic overhead is fairly low.

The beta version of Ocaml 3.12 has a couple of new features that relate to a post Stephen wrote a while back on how to ensure that a function definition is polymorphic. In this follow up post I will describe how one of those new mechanisms is essentially what you want for this purpose and the other is perhaps not due to a subtle interaction with how recursive definitions are type-checked.

Null is a pervasive concept in computing. Virtually all programming languages have a way of expressing nothing, nullity, no answer. But handling nulls correctly turns out to be tricky, and many of the contexts in which you find nulls, you'll also find confusing and error-prone semantics surrounding them.

The heart of the problem is that, in an attempt to make programming with null easier, nulls are often propagated implicitly through computations, allowing the programmer to write code that deals with nulls without explicitly contemplating how nulls should be dealt with.

My experience has been that this is a mistake; that if you want robust, easy-to-reason-about code, the programmer must think explicitly about how to handle null cases, and that programming languages would do well to provide programmers with good support for the requisite case analysis

The point can be illustrated by considering some of the contexts in which null arises.

Early in '09, I put up a post asking Private type abbreviations, what are they good for?. I got a lot of good answers to that question, but I thought I would mention one more: using private types for encoding subtyping relationships in phantom types.

CUFP is a yearly workshop for commercial users of functional programming. CUFP is aimed not just at industrial uses, but really at any uses of functional programming that are aimed at solving some pragmatic problem.

The workshop is co-located with ICFP, which is in Baltimore this year, and the scope of the workshop is bigger than usual. It spans two days rather than one, and in additional to the traditional talks, we will include a collection of invited tutorials and some Birds-of-a-Feather sessions as part of the schedule.

A couple of weeks ago I visited Northeastern and Harvard where I gave guest lectures on the subject of programming effectively in ML. In both cases, I was talking to a class full of undergraduates who had been studying ML for the semester. It was great fun, and in the Harvard case, the lecture was taped, so I hope to eventually be able to post a link to it here.

The lecture I gave was in part inspired by a book I read years ago called Effective Java, by Josh Bloch.

I'm pleased to announce that we now have ocamldoc generated documentation available for Type-conv, Bin-prot, Sexplib, and Core. You can find them here:

http://www.janestreet.com/ocaml/janestreet-ocamldocs/

The module paths in the documentation for Core and Core_extended are relative to Core.Std and Core_extended.Std

You can also find a tarball here:

http://www.janestreet.com/ocaml/janestreet-ocamldocs-2009-11-11.tgz

This post is meant to be the first in a series highlighting various interesting features of Core (although I should acknowledge that most of the continuing series I've started so far have not, when it comes down to it, continued.) This time I wanted to focus on how Core handles time.

With the latest release of Core, I've had occasion to think about how our libraries differ from INRIA's. One difference that's been there from the very beginning is in the List module: INRIA's list functions are not tail-recursive, and ours are.

We are proud to announce the second major release of Core, Jane Street's alternative to OCaml's standard library. This release also includes Core_extended, which adds new functionality such as subcommand style command line argument handling, a procfs interface, readline support, and more. Core_extended is used heavily at Jane Street, but not systematically code reviewed in the same manner as Core.