.. 10 to 30 times more slowly under Mono, according to your posting here:
Do Microsoft produce a free (as in speech) .Net framework with
equivalent performance which runs under Linux? Will they continue to
make F# work with Mono? or indeed do they support it right now?
> > And somehow F# seems to be licensed under a very restrictive license
> In what way? I can sell programs that I write in F#.
The license, "Microsoft Research Shared Source License Agreement"
prevents commercial redistribution of the F# sources, and that means
for example that it could never be part of a free operating system
like Debian or Fedora.
In practical, day to day terms I'd better hope that Microsoft Research
continue to produce and support new versions of F#. If one day they
just abandoned it, or if they decided to drop support of Mono then I'd
be up a creek without a paddle (but with a lot of software which I'd
have to rewrite in another language).
> > (how did they get away with that one? - Did they pay INRIA for a separate
> > source license?)
> Besides legacy, F# has nothing to do with OCaml and INRIA.
So F# was a separate implementation? I thought it was derived from an
older version of OCaml - but with the licensing issues above I'm not
about to download the source to check that.
Discussion moved to caml-list. It's important to get any
misunderstandings about F# resolved.
Caml-list mailing list. Subscription management:
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
F# is a research language, with many of the same issues as other research languages (license, support, works poorly on some platforms). We never think of it as a replacement for OCaml, though it makes a reasonable alternative on Windows (less so on Linux). I guess as I researcher I think of both as stepping stones to other better and greater things. I want to see this class of languages live and flourish in many parts of the computing industry. Brian Hurt captured things well here.
There is a overlap between the two (e.g. with Jon's work), but there is also a lot of synergy: I know OCaml is gaining traction in some financial companies, and I can't help think that the existence of F# helps this more than it hinders it. For example, it helps people make stronger arguments to management: easier to recruit programmers, gives a way for Java and C# programmers to retrain in steps. Also, I think an OCaml/F# mix would make an excellent university course, where each language alone would leave interesting issues unaddressed. Perhaps there is also scope for a dual-track conference on both languages.
We've always tried very hard to avoid overlap. For example, you'll notice we don't announce F# releases on the OCaml list - this is out of respect for the OCaml community. Jon operates in both worlds and has books and products to sell, so will be naturally talking about and comparing both systems. I think that's a good thing, and I know he intends his comparisons to be informative rather than destructive.
F# is an independent implementation: it wasn't derived from an earlier version of OCaml (we would have avoided zillions of bugs if we'd done that!). We try to arrange the libraries to get a reasonable degree of compatibility with OCaml 3.08, but are imperfect. We also aim to support cross compilation, though not perfectly (local adjustments to code may be required, and missing features avoided). We do use OCaml to bootstrap F# for a variety of reasons, though we are moving away from that model.
Jon's assessment of performance under Mono hasn't been independently verified. Any particular performance problem really comes down to a Mono v. .NET issue. Jon should isolate the issue out in a C# program and report it to the Mono team: they will take it seriously. Other users of Mono do not report catastrophic performance problems (or else no one would use it!)
We understand the current license doesn't meet the standards of the open source community. We have permission to release the source under a more permissive license quite similar to Iron Python, and plan to do that. However we probably won't make a big song-and-dance about that, as the way we have the project set up now (binary releases) is really ideal for us as a small team. But emitting the source code under a permissive license now and then makes a lot of sense in order to address some of the issues you mention below.