yminsky's blog

I'm on the program committee for CUFP this year, so I'm a bit biased, but I feel very good about this year's program. For the first time, CUFP will be broken up into three parts:

• CUFP Tutorials on Friday October 1st. This is really the descendent of last year's DEFUN workshop. The tutorials were picked carefully, both for the interest of the topic and the quality of the teacher.
• CUFP Talks on Saturday October 2nd. Having been involved for a few years now, I really think it's an unusually strong group of talks. I would be pretty happy if we had a schedule populated with the best of the talks that we rejected, much less the ones that we ended up accepting.
• CUFP BOFs on the evenings of Thursday and Friday (Sep 30th and Oct 1). I'm really looking forward to these. These BOFs are still being organized, so you should follow the link and see if you have ideas to contribute. The BOFs should hopefully attract people from outside the usual CUFP audience, and we're hoping it will be a good way for FP developers to get together, talk about issues important to the various and sundry FP communities, and really get some work done.

A while back I mentioned that I'd given a guest lecture at classes at Harvard and Northeastern, and that the Harvard class had been taped. I finally got and uploaded that video:

You can click here for a higher resolution version. Sadly, the code samples are in spots a little hard to see here. If there's enough interest, I'll post the code samples here.

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.

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.

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.

Just thought I should point out another post, this one from Patai Gergely, summarizing events at the JSSP end-of-summer meeting, this one including pictures!