Sadek Drobi interviews Don Syme about the history of F#
Jon Harrop
http://www.infoq.com/interviews/F-Sharp-Don-Syme
Sadek Drobi has interviewed many interesting people in the past and his
interviews are of particular interest because Sadek is not afraid to ask
difficult questions.
Sadek recently published an interview with Don Syme, a lead developer
of .NET generics and F#. In particular, Sadek asks why the experiments at
Microsoft Research in writing SML and Haskell implementations on top
of .NET led Don to build an eager language rather than a non-strict
language like Haskell. Don describes the "dissonance" between non-strict
evaluation and .NET that culminates in excessive use of monads making it
unnecessarily tedious to reuse the framework, as well as the efficiency and
debugging problems imposed by non-strict evaluation.
Don then goes on to discuss some of the other features of Haskell that F#
does draw upon, such as type classes. In particular, Don explains how he
carefully separated the proven foundations of such features, such as the
use of type classes for overloading as they were originally intended, from
the experimental aspects that bring a "surprising number of technical
problems".
Overall this was an extremely interesting interview that touched upon many
fascinating aspects of state-of-the-art language design in the context of
industrial-strength programming language implementations.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
Paul Rubin
> Don then goes on to discuss some of the other features of Haskell that F#
> does draw upon, such as type classes. In particular, Don explains how he
> carefully separated the proven foundations of such features, such as the
> use of type classes for overloading as they were originally intended, from
> the experimental aspects that bring a "surprising number of technical
> problems".
Neil Mitchell's blog post and Vesa Karvonen's comments about F# vs
Haskell are also interesting, and somewhat less favorable to F#'s type
system:
http://neilmitchell.blogspot.com/2008/12/f-from-haskell-perspective.html
namekuseijin
> http://www.infoq.com/interviews/F-Sharp-Don-Syme
>
> Sadek recently published an interview with Don Syme, a lead developer
> of .NET generics and F#. In particular, Sadek asks why the experiments at
> Microsoft Research in writing SML and Haskell implementations on top
> of .NET led Don to build an eager language rather than a non-strict
> language like Haskell. Don describes the "dissonance" between non-strict
> evaluation and .NET that culminates in excessive use of monads making it
> unnecessarily tedious to reuse the framework, as well as the efficiency and
> debugging problems imposed by non-strict evaluation.
His relevant quote here:
"it would be unusual to make a language on .NET lazy; it would lead
you to very many challenges. I think that's an open question. In the
last 20 years, the world has become very platform centric, framework
centric."
Yes, it turns out most software today is assembled rather than written
and assembling from essentially imperative parts is not an option for
Haskell.
Really, despite the dozens of languages available for the Common
Language Runtime, all code looks the same, because calling functions
is pretty much always the same but for minor syntatic details. And
calling functions is all you do in framework-based programming.
The real deal here is to sell frameworks, not languages: let them
write them for you as long as you get into the straight jacket of one
single conformant way of doing things. Syntax is irrelevant,
semantics is not.
namekuseijin
> http://neilmitchell.blogspot.com/2008/12/f-from-haskell-perspective.html
"The F# language is based on ML, with the addition of indentation
based layout, and many of the weaknesses in F# come from ML. F# is
certainly more verbose than Haskell: in some places you need an extra
keyword (often a let); pattern matching is not nearly as complete; the
indentation isn't as natural as Haskell."
Haskell got let too, what's the point? And are we really beginning
now to wonder which language has the best meaningful whitespace?
Python still gets detractors for that!
Jon Harrop
There are many problems with that discussion.
Neil begins by stating that he has had "little exposure to ML" and then
makes the incorrect claim that "many of the weaknesses in F# come from ML".
In reality, F# inherited very little from ML because its creator, Don Syme,
was a Haskell programmer and not an OCaml programmer.
I am surprised Neil describes F# as "not small" when I think it is tiny
compared to OCaml or (GHC's) Haskell.
Neil says "F# is certainly more verbose than Haskell" but that is not true
for many basic features and is entirely wrong for performant or interop
code.
Neil says "pattern matching is not nearly as complete" but F# has several
valuable pattern matching features like or-patterns that Haskell does not
have.
Neil states "standard .NET libraries work with arrays, but for a functional
program the list is a more natural type". If you think lists are natural
then you suck. Indeed, better support for arrays is one of the major
advantages of OCaml over SML (and one that was only added to F# relatively
recently at my request).
Regarding arrays vs lists, Neil states "it was never clear which I should
use where" which I think is a really stupid thing to say. The relative
advantages and disadvantages are bloody obvious. If you want flexibility in
F# then use seq and the real problem is that too few .NET libraries support
IEnumerable. Moreover, this problem is solved in modern MLs with functors
but Neil would not know about them because he does not know ML.
Then Neil says "The .NET libraries are very powerful, but often are overly
imperative. For example, the XSD libraries (Xml Schema Description) are
very imperative - you have to create objects, mutate properties, then make
calls." but he fails to mention F#'s pure-looking syntactic support for
setting properties on an object at construction.
Vesa incorrectly states that something like this will not compile in F#:
let f _ = invalid_arg ""
Vesa makes the silly claim:
"This collection of deficiencies is inherited from both O'Caml and .NET.
First of all, O'Caml's syntax allows one to omit parentheses from tuples
(in both patterns and expressions) in a number of places, which can be
quite confusing."
There are many more OCaml programmers than SML programmers, of course, and
they are not confused by the lack of superfluous parentheses. This isn't
Lisp, after all...
Overall, I found that discussion quite dull because it failed to recognise
any of the serious problems in Haskell, SML and OCaml and failed to discuss
how F# solved most of those problems. Indeed, the discussion of some of
these topics was the single most interesting aspect of the interview that I
cited here!
ross...@ps.uni-sb.de
>
> [... some good points...]
>
> Vesa incorrectly states that something like this will not compile in F#:
>
> let f _ = invalid_arg ""
You should at least try to understand Vesa's example before you accuse
him. It includes signatures. And it indeed fails due to F#'s
restrictive semantics for signature matching.
- Andreas
Jon Harrop
Sure but it is not a "signature" in the same sense. Indeed, there is no
literal F# translation of Vesa's SML code. You might as well compare
functors in SML and C++.
F# just reused the popular terminology and syntax from OCaml to dress up
Haskell's module system, i.e. this is another weakness F# inherited from
Haskell.