F# weaknesses

F# weaknesses

[Gabriel Kerneis]

Hi,

here is an (IMHO) interesting comment about F#:

http://neilmitchell.blogspot.com/2008/12/f-from-haskell-perspective.html?showComment=1228688580000#c5972141541999023235

I don't know how annoying the described weaknesses are in a dayly use but
people wanting to switch from OCaml to F# should certainly take this into
account. Did anyone tried F# and have some feedback to share about this
issues?

Regards,
-- 
Gabriel

Re: [Caml-list] F# weaknesses

[Dario Teixeira]

Hi,

> I don't know how annoying the described weaknesses are
> in a dayly use but people wanting to switch from OCaml to F#
> should certainly take this into account. Did anyone tried F#
> and have some feedback to share about this issues?

I'm curious as well.  I've never used F#, but the fact that they've
removed functors and polymorphic variants -- two of the most
interesting Ocaml features -- gives me at first glance an impression
that F# is a castrated Ocaml.  (Though I understand that some
of these changes were necessary to integrate into the .Net world).

I would like to hear the other side: features new to F# that
would also be welcome in Ocaml, especially those that are not
implemented already by some Camlp4 extension.

Cheers,
Dario Teixeira

Re: [Caml-list] F# weaknesses

[Jon Harrop]

On Monday 08 December 2008 20:45:30 Dario Teixeira wrote:
> Hi,
>
> > I don't know how annoying the described weaknesses are
> > in a dayly use but people wanting to switch from OCaml to F#
> > should certainly take this into account. Did anyone tried F#
> > and have some feedback to share about this issues?
>
> I'm curious as well.  I've never used F#, but the fact that they've
> removed functors and polymorphic variants -- two of the most
> interesting Ocaml features -- gives me at first glance an impression
> that F# is a castrated Ocaml.  (Though I understand that some
> of these changes were necessary to integrate into the .Net world).

Actually, .NET may well facilitate those features as it did for units of 
measure. I believe they are not implemented because they are not valued by 
the creator of F#. Don't forget that F# often has a different set of 
solutions to the same problems.

For their primary use, functors are awful compared to the alternatives. Just 
compare code using Set or Map in OCaml with F#. Functors can catch errors in 
more complicated abstractions but I have found that I do not make those kinds 
of errors anyway, so F#'s OOP-based equivalent that does not provide the 
static checking is not a disadvantage.

Polymorphic variants are great in OCaml but only because OCaml has libraries 
like LablGL that were specifically designed with polymorphic variants in 
mind. In a language that mainly inherits existing OO libraries, polymorphic 
variants make less sense.

> I would like to hear the other side: features new to F# that
> would also be welcome in Ocaml, especially those that are not
> implemented already by some Camlp4 extension.

F# has a *lot* of features that OCaml would benefit enormously from! I'll 
enumerate some here but I think the interesting question is "how might we 
accomplish this" because so many of these are just obvious improvements.

1. DLLS: F# is commerce friendly and its ability to compile your code to a DLL 
that you can sell is a major part of that. We sell two F# libraries and both 
make more profit every month than all of our OCaml software products combined 
ever. Being commerce-friendly attracts people with money who can afford to 
fund further development. Consequently, F# will become a platform that people 
(like me) will build upon whereas OCaml will not.

2. Robustly deployable executables: 80% of the users of our 
OCaml/OpenGL/Linux-based software complained of random crashing. 0% of our 
F#/WPF users have. We are never likely to develop commercial software in 
OCaml again following that failure but we are desperately trying to build 
more F# software products.

3. JIT compilation

a) F#'s FFI is a dream come true compared to OCaml thanks to JIT compilation 
of the interface code (no C stubs, yay!). Look at the tiny amount of code I 
gave here to call FFTW from F#:

http://fsharpnews.blogspot.com/2007/04/foreign-function-interface-ffi.html

b) .NET type specializes during run-time compilation, so there is no cost 
associated with polymorphism. For example, "Array.fold_left ( + ) 0.0" is ~5x 
faster in F# than in OCaml.

4. Concurrent GC and Task Parallel Library

a) Parallelism across multicores is easy and efficient in F#.

b) Concurrency is easy and efficient, e.g. GUI applications can be developed 
on-the-fly from an F# interactive session out of the box.

5. Overloaded operators: makes numerical code much more readable, particularly 
with more types, but less compositional (e.g. cut and paste is likely to 
break the code because it becomes reliant upon earlier type annotations).

6. Subtyping: containers implement IEnumerable in order to present a uniform 
API for sequences that may be handled using Seq.map and friends. The syntax 
a.[i] is used to index any indexable container including strings, arrays, 
hash tables, maps, trees etc.

7. No silly limitations like the 16Mb limits in 32-bit OCaml.

8. A full set of types including 32- and 64-bit floats, 8/16/32/64 bit signed 
and unsigned integers and so on. In OCaml, you couldn't reasonably have 
enough operators even if it did support all of these types.

9. Value types: allow arbitrary types like complex numbers to be stored 
unboxed => FFT over a complex array can be 5.5x faster in F# than OCaml. All 
of the above types are stored unboxed in arrays.

10. A decent stdlib bundled with the language. No more stack overflows from 
built-in functions.

11. Optimizations: .NET handles a lot of the "usual" optimizations like mod by 
a constant and hoisting of bounds checks, e.g. i mod 3 is 20x faster in F# 
than OCaml.

12. Reflection: if you get stuck in F# you can often resort to reflection. 
The "box" function is a bit like a type-safe Obj.magic. This is particularly 
useful at interface code, like RPCs.

13. Active patterns: let you safely dissect an alien data structure as if it 
were a variant type. There is a Camlp4 macro but it does not support 
exhaustiveness and redundancy checking.

There are many other features that I have not benefitted from: first-class 
unicode strings, type checked units of measure, asynchronous workflows etc. 
The final benefit is, of course, easy access to some awesome libraries.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] F# weaknesses

[Jon Harrop]

On Monday 08 December 2008 23:52:02 Jon Harrop wrote:
> I think the interesting question is "how might we accomplish this"...

I have been giving this question a lot of thought recently. The problem is 
that the goal is quite obvious and objective but the route is not at all 
obvious.

I think the best way to proceed is to build a DSL that is initially useful 
(e.g. for numerics) and use macros and LLVM to get it JIT compiled. Then grow 
the language and garner users until it is feasible to create a stand-alone 
version of the language.

I believe it is quite feasible to create a MiniML with its source quoted 
inside OCaml programs using Camlp4 and an LLVM backend for it that beats 
OCaml's performance on some tasks. That alone would be useful and it can be 
improved incrementally from there until it is a full-blown language 
implementation.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e