* Re: [Caml-list] F# weaknesses
2008-12-08 20:45 ` [Caml-list] " Dario Teixeira
@ 2008-12-08 23:52 ` Jon Harrop
2008-12-09 1:51 ` Jon Harrop
0 siblings, 1 reply; 4+ messages in thread
From: Jon Harrop @ 2008-12-08 23:52 UTC (permalink / raw)
To: caml-list
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
^ permalink raw reply [flat|nested] 4+ messages in thread