It's a matter of the way the data is stored. Your interaction with Sam would make a better comparison if you were asking so your could write it down but only had eight characters' worth of paper.
"Sam, give me the phoneNumber."
"Oh no I'm out of paper. If only I had known ahead of time how much data I was asking for I could have prepared better!"
So instead, most languages make you declare a type, so it will know and prepare ahead of time:
"Sam, how long is a telephone number?"
"Ok, then let me get a bigger piece of paper. Now give me the phoneNumber."
"Got it! Thanks Sam!"
It gets even hairier when you look at the actual fundamental ways that the data is stored. If you're like me, you have a notebook with miscellaneous notes, numbers just scribbled down, no context or labeling for anything, and you have no clue what any of it means three days later. This is a problem for computers a lot of times, too. Lots of languages have "int" types (int, long, short, byte) and "float" (float, double) types. Why is that necessary?
Well first let's look how an integer is stored, and generally represented within the computer. You're probably aware that at the basic level, it's all binary (1's and 0's). Binary is actually a number system that works exactly like our decimal number system. In decimal, you count 0 to 9 (with infinite implied leading zeroes that you don't write), then you roll over back to 0 and increment the next digit so you have 10. You repeat until you roll over from 19 to 20, repeat until you roll over from 99 to 100, and so on.
Binary is no different, except that instead of 0 to 9, you count 0 to 1. 0, 1, 10, 11, 100, 101, 110, 111, 1000. So when you type in 9, in memory that's recorded in binary as 1001. This is an actual number. It can be added, subtracted, multiplied, etc, in exactly that form. 10 + 1 = 11. 10 + 10 = 100 (roll over 1 to 0 and carry the 1). 11 x 10 = 110 (and equivalently, 11 + 11 = 110).
Now in the actual memory (registers included), there's a list, array, whatever you want to call it, of bits (potential 1's or 0') right next to each other, which is how it keeps these bits logically organized to make a number greater than 1. Problem is, what do you do with decimals? You can't just insert a piece of hardware in between the two bits in the register, and it would cost way too much to add "decimal bits" in between each pair of bits. So what to do?
You encode it. Generally, the architecture of the CPU or the software will determine how this is done, but one common way is to store a sign (+ or -, generally 1 is negative) in the first bit of the register, a mantissa (your number shifted however many times it needs to be to get rid of the decimal) for the following X number of bits, and an exponent (the number of times you had to shift it) for the remainder. It's similar to scientific notation.
Typing allows the compiler to know what it's looking at. Imagine that you stored the value 1.3 in register 1. We'll just come up with our own fancy encoding scheme here, 1 bit for sign, 4 for mantissa, 3 for exponent (1 bit for sign, 2 for magnitude). This is a positive number, so the sign is positive (0). Our mantissa would be 13 (1101) and our exponent would be -1 (101 (1 for negative, 01 = 1)). So we store 01101101 in register 1. Now we didn't type this variable, so when the runtime goes to use it, it says "sure, this is an integer why not" so when it prints the value we see 109 (64 + 32 + 8 + 4 + 1), which is obviously not right.
But it's a lot easier on the compiler, interpreter, or runtime--and often results in a faster program since it doesn't have to spend valuable resources sorting through the typing of everything--to ask you, the programmer, what kind of data you're giving it.