Browse thread
Re: Why OCaml sucks
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jon Harrop <jon@f...> |
| Subject: | Re: [Caml-list] Re: Why OCaml rocks |
On Friday 09 May 2008 16:38:55 Jeff Polakow wrote: > Hello, > > > We investigated alternative languages to diversify into last year and > > Haskell > > was one of them. The single biggest problem with Haskell is that it is > > wildly > > unpredictable in terms of performance and memory consumption. > > This is only the case if you don't understand lazy evaluation. Simon Peyton-Jones told me that. I am sure you will agree that he understands lazy evaluation. > This is no > different from OCaml, or any language. One must understand the operational > semantics to write efficient code. Imagine how a C programmer feels when > writing OCaml without knowing to make functions tail-recursive. Tail calls have simple rules. Graph reduction of a lazy program with optimizing rewrites and strictness analysis does not adhere to simple rules. Simple rules => predictable. > I wonder if similar complaints (unpredicatable performance, memory use, > dearth of practical information) will arise about F# as it starts to be > widely adopted in the real world. F# has long since overtaken all other functional languages in terms of industrial uptake and I have not heard that complaint from anyone. Like OCaml, it follows simple rules and is predictable as a consequence. Some of the rules are very different in F#. For example, nested closures degrade performance in OCaml but improve performance in F#. This may well change as we transition to manycore and parallelism makes performance unpredictable. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e