Erlang, for instance, is a dynamic language too (but strongly typed - like Python), it doesn't have any fancy type system and matches at runtime,

Hm. The Erlang people talk of "Pattern matching in function head and in case and receive clauses are optimized by the compiler." & "the compiler is free to rearrange the clauses. It will generate code similar to this".

but its function calls are a lot faster then those of both Perls

They do seem to have improve things substantially in that area in newer versions.

Hm. The Erlang people talk of "Pattern matching in function head and in case and receive clauses are optimized by the compiler." & "the compiler is free to rearrange the clauses. It will generate code similar to this".

Of course it's optimized. Like you would expect from a language where the only way to loop is recursion.

Yet, this works in Erlang:

f(1) ->
    io:format("I got one!");
f(X) when X rem 2 == 0 ->
    io:format("I got even!");
f(X) when X rem 2 == 1 ->
    io:format("I got odd! (but not one)").

...

f(random:uniform(1000)).
f("Now eat this!").  %% runtime error
[download]

Just for comparison (with Perls):

-module(fns).
-export([run_test/0]).

f(X, Acc) when X rem 2 == 0 ->
    Acc;
f(X, Acc) when X rem 2 == 1 ->
    Acc + 1.

run_test() ->
    TSeq = [random:uniform(10) ||
            _ <- lists:seq(1, 1000000)],
    {Time, Result} = timer:tc(fun() ->
             lists:foldl(fun f/2, 0, TSeq)
                              end),
    io:format("~w microseconds~nResult: ~w~n",
              [Time, Result]).
[download]

output:

93267 microseconds
Result: 500464
[download]

So, functions that actually do something in Erlang (count odd numbers) are three times faster then Perls functions that do nothing whatsoever.

Of course it's optimized. Like you would expect from a language where the only way to loop is recursion.

Sorry. My point was the mentions of "compiler". Whilst not an all-the-way-to-native-code compiler; it is substantially more optimising than Perl's interpreter.

And the fact that it has a strong type system -- as you pointed out -- means that it has far more opportunities for optimising pattern matching than Perl6 ever will have.

With the basic scalar argument being able to contain anything from undef through integers, floats and strings; to array & and hash references; P6 will pretty much always need to inspect every parameter to a function call at runtime in order to determine which multi-sub to invoke.

And there'll be little, if any, opportunity for the interpreter to change (pre-reorder; for performance reasons) the order in which the multi-subs are considered when attempting the runtime match.

I did a lot of playing with Q for a while. A very nice fully dynamic, compiled to bytecode then interpreted, FPL; but boy was it ever slow.

So slow that it had to be replaced by Pure in which "programs run much faster as they are JIT-compiled to native code on the fly".

My overall point is that adding the syntactic convenience of multi-subs to P6 -- which will probably never be able to benefit from such optimisations -- is another nail in its coffin for programming where performance is important.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this

In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked