lpw25

Indeed using the improved OCaml inliner (http://www.ocamlpro.com/blog/2013/07/11/inlining-progress-re...) on the original OCaml gives a speedup of 2.75.

By replacing the distance function with:

    let distance (a1 : int array) (a2 : int array) =
      let open Array in
      let len = length a1 in
      let acc = ref 0 in
      for i = 0 to len - 1 do
        let v1 = unsafe_get a1 i in
        let v2 = unsafe_get a2 i in
        let d = v1 - v2 in
        acc := !acc + d * d
      done;
      !acc

the OCaml goes 3 times faster. This is what would be produced if OCaml's inliner had triggered on the original definition of `distance`, so that is probably the main difference in the two language's performance. If you inline some of the other functions by hand (and tidy up some of the sillier parts of the OCaml code) it easily runs 4 times faster than the original.

It's "mu" not "miu". I think they gave a talk on it at CUFP one year.

I think that js_of_ocaml 2.0 added support for compiling mutually recursive functions using trampolines. So that compiler is back to being right again.

> Functional programming is about programming with functions

Actually I think the etymology of "functional programming" comes for programming with functions as first-class objects. So a "functional programming language" is one that supports higher-order functions.

> It should be obvious that Functional means functions, and "function" has fairly precise meaning which predates computation, and certainly didn't include anything about side-effects.

It also doesn't say anything about non-termination. If you want to program with mathematical functions I suggest you use something other than Haskell (e.g. Coq, Agda).

Lisp is the original functional language. Functional language traditionally meant a language that emphasised functions as values, in particular supporting higher-order functions. Hence the word "functional".

More recently, people have confused "functional" with other features of languages like Haskell (sometimes called "purely functional"), leading to some confusion about what defines functional programming.

Here's an interesting post about the more recent changes in the phrase's meaning:

http://wcook.blogspot.co.uk/2012/07/day-functional-programmi...

> Ocaml's compiler is also slow

Umm, no it isn't. I'm not sure I'm aware of a faster compiler. It's so fast most people don't even realise that they are running the byte code version (ocamlc) rather than the native code verison (ocamlc.opt).

I rather think lambdas, generics and type inference are straight out of ML, especially as hack is written in OCaml.

I think they mentioned something in the browser using js_of_ocaml at CUFP last year.

Also, only some things in OCaml are structurally typed (modules, objects, polymorphic vairants), others are not (records, variants). For example:

    # type meters = I of int;;
    type meters = I of int

    # let meters i = I i;;
    val meters : int -> meters = <fun>

    # type newtons = I of int;;
    type newtons = I of int

    # let newtons i = I i;;
    val newtons : int -> newtons = <fun>

    # let f b = if b then newtons 12 else meters 12;;
    Characters 36-45:
      let f b = if b then newtons 12 else meters 12;;
                                          ^^^^^^^^^
    Error: This expression has type meters but an expression was expected of type
             newtons

Abstraction provides the equivalent of nominative typing. It is easy to differentiate between 12 meters and 12 Newtons with OCaml's type system.

In general, it is easy to get nominative behaviour out of a structural system. It is much harder to get structural behaviour out of a nominative system.

Pull requests welcome:

https://github.com/ocaml/ocaml.org/tree/master/site/learn/tu...

Note that using `unsafePerformIO` is more unsafe than that, because the compiler assumes that functions are pure and will make transformations which alter the semantics in the presence of side effects. The OCaml compiler does not do these optimisations because it has to assume everything is impure.

And `inlinePerformIO` is much more unsafe, because it requires that you do no memory allocation inside it. This property is specific to the Haskell implementation, and is certainly not easy to guarantee.

It's not a strawman. Just look at the code for reverse-complement in Haskell. It is full of strictness annotations (unidiomatic) and uses inlinePerformIO (unsafe). It also uses a few inlining pragmas (unidiomatic).

The fact that this code is fast tells you nothing about whether idiomatic Haskell is fast. wrong evidence < no evidence.

> So, fast code. Which is what is at question.

No the question is about whether fast code is easy to write, if it has to be highly tuned then it is not easy to write.

> I'm pretty sure the language shoot-out is of greater value as evidence than personal anecdote is.

Actually, I think that the shoot-out causes a lot of harm to people's attempts to understand whether a language is fast or not.

When people ask: "Is language X fast?" what they mean is "if I write my programs in it will they be fast". They do not mean "is the highly tuned code of an expert fast".

The question of whether a language is fast is about whether code written in the natural idioms of the language is fast, not about whether you can coerce the compiler into producing the precise assembly code you are aiming for. If you are going to do that you might as well write the assembly code directly and call it using an FFI. Many implementations on the shoot-out bare no resemblance to the code people naturally write in those languages.

> No he didn't. He took the time to learn ocaml.

Not before writing his initial benchmarks, which is what we're talking about.

> The closest thing to evidence I can find suggests that it is no more difficult to write fast code in haskell:

> http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te....

That measures ridiculous highly tuned implementations of the benchmarks, often written by the creators of the languages themselves. It contains absolutely no evidence of how hard it is to write fast programs in a language.

Besides, I'm pretty sure citing the language shoot-out is an automatic disqualification in any argument about language speed.

> Even if you were to erroneously say that, it isn't type classes that is the problem.

I'm pretty sure it is. For example, see section 3.7 of "Type classes: an exploration of the design space" by SPJ et al.

> He literally didn't learn haskell and copy and pasted random stuff from stackoverflow and irc

But that's the point right. He did the same for OCaml and got faster code. Obviously you can write fast code in Haskell, but that is not the same as it being easy.