From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 589DFBB84 for ; Tue, 9 Dec 2008 00:49:28 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4AADtBPUnUnw6RlGdsb2JhbACCO5EgAQEBAQkLCAkRBLBLCIoigXoIgQM X-IronPort-AV: E=Sophos;i="4.33,737,1220220000"; d="scan'208";a="20104491" Received: from ptb-relay01.plus.net ([212.159.14.145]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 09 Dec 2008 00:49:27 +0100 Received: from [87.115.10.107] (helo=leper.local) by ptb-relay01.plus.net with esmtp (Exim) id 1L9pqw-0008Lh-QK for caml-list@yquem.inria.fr; Mon, 08 Dec 2008 23:49:27 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] F# weaknesses Date: Mon, 8 Dec 2008 23:52:02 +0000 User-Agent: KMail/1.9.9 References: <750628.35610.qm@web111515.mail.gq1.yahoo.com> In-Reply-To: <750628.35610.qm@web111515.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812082352.02684.jon@ffconsultancy.com> X-Plusnet-Relay: a9fe036796f9ed6fcfd4770f8ddfb919 X-Spam: no; 0.00; ocaml:01 functors:01 variants:01 ocaml:01 functors:01 variants:01 lablgl:01 camlp:01 complained:01 compilation:01 ffi:01 compilation:01 stubs:01 run-time:01 polymorphism:01 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