Tuesday, September 23, 2008

A thought on F#

A while ago I read this blogpost by Phil Wadler. The post is a comment on an article from an issue of Journal of Functional Programming. In that, Yaron Minsky and Stephen Weeks from Jane Street Capital talks about their experiences with functional programming on Wall Street. Wadler quotes from the article:
When we first tried switching over from VB to C#, one of the most disturbing features of the language for the partners who read the code was inheritance. They found it difficult to figure out which implementation of a given method was being invoked from a given call point, and therefore, difficult to reason about the code. It is worth mentioning that OCaml actually does support inheritance as part of its object system. That said, objects are an obscure part of the language, and inheritance even more so. At Jane Street, we almost never use objects and never use inheritance. We use standard functional programming techniques and code reviewers find that style more comprehensible. In particular, they can reason by following static properties of the code (module boundaries and functor applications) rather than dynamic properties (what class an object is).

This made me think of F#, which is inspired by OCaml. Will users of F# tend to not use any OO, just as in Jane Street Capital? Or, put in another way, will F# users tend to only be consumers of OO code (i.e., the .NET framework) and provide a "nice" OO-style API for client code, but "underneath the surface" focus entirerly on the functional part of F#?

Media: Wadler does a funny thing, in the very last minute of his talk (Faith, Evolution, and Programming Languages).

2 comments:

MichaelGG said...

F# is much more object oriented simply because it's on .NET. Objects have a useful place, inheritance a bit less.

It's really going to depend on how F# gets adopted and for what usage. In C#, we rarely use inheritance anyways...

Flying Frog Consultancy Ltd. said...

FP is preferable in OCaml solely because of some great features that F# does not have. Indeed, you can do virtually nothing in F# without using objects. So there is no way F# will offer the same freedom from OOP.

However, this is simply because F#'s design has always heavily emphasized seamless interoperability with .NET and that, obviously, means lots of objects.

The OCaml-specific features I am referring to (like polymorphic variants) only work so well in OCaml because it has tons of libraries designed specifically for it that use these features extensively, like LablGTK and LablGL.