The Perl 6 student begins:

    sub add(\number1, \number2) { number1 + number2 }

If you call `add` with simple numbers it works:

    say add(1, 2) # 3

Other types of number too:

    say add(0.1, 0.2) == 0.3 # True

It works even for newbie definitions of "number":

    say add('0.1', '0.2') == '0.3' # True

A sufficiently determined newbie can of course break `add`:

    say add('foo', 'bar') == 'waldo'

The program stops with a suitable error message ("Cannot convert string to number ...").

----

The student moves on to a more advanced course...

----

Type annotations are introduced:

    sub add(Numeric \number1,
            Numeric \number2) { number1 + number2 }

Everything still works as expected:

    say add(1, 2) # 3

But we get better error checking:

    say add('foo', 'bar') == 'waldo'

This generates a compile-time type-checking error ("Calling add(Str, Str) will never work with declared signature (Numeric \int1, Numeric \int2)").

So, reason 1 for using types: get type-checking that catches errors at compile-time.

You can use native types for closer-to-the-metal speed (compact representations, no automatic overflow checking, etc.):

    sub add(num64 \number1,
            num64 \number2) { number1 + number2 }

`num64` corresponds to C's double float datatype representation. This sub will likely outperform the versions of `add` that do not have natively typed parameters.

A third reason for explicit types is to take advantage of C interop:

    use NativeCall;
    sub add(int32, int32) returns int32 is native("calculator") { * }

If you've got a local C library (called "libcalculator.so" or somesuch) then this:

    say add(1,2)

will call the function with the symbol name `add` in that library.

And so on.