Why do you have to specify the data type when declaring variables?

Question

In most coding languages (if not all) you need to declare variables. For example in C# if its a number field then

int PhoneNumber

If I'm using normal English language I do not need to declare PhoneNumber as int to use it. For example if I ask my friend Sam to give me his phone number I say:

"Sam give me the phonenumber"

I wouldn't say

"Char(20) Sam give me the int phoneNumber"

Why do we have to specify data type at all?

Answer 1

In most coding languages (if not all) you need to declare variables.

[…]

Why do we have to specify data type at all?

Those are two independent questions:

• Why do we need to declare variables?
• Why do we need to declare types?

Incidentally, the answer to both is: we don't.

There are plenty of statically typed programming languages where you don't need to declare types. The compiler can infer the types from the surrounding context and the usage.

For example, in Scala you can say

val age: Int = 23

or you could just say

val age = 23

The two are exactly equivalent: the compiler will infer the type to be Int from the initialization expression 23.

Likewise, in C♯, you can say either of these, and they both mean the exact same thing:

int age = 23;
var age = 23;

This feature is called type inference, and many languages besides Scala and C♯ have it: Haskell, Kotlin, Ceylon, ML, F♯, C++, you name it. Even Java has limited forms of type inference.

In dynamically typed programming languages, variables don't even have types. Types only exist dynamically at runtime, not statically. Only values and expressions have types and only at runtime, variables don't have types.

E.g. in ECMAScript:

const age = 23;
let age = 23;

And lastly, in a lot of languages, you don't even need to declare variables at all. e.g. in Ruby:

age = 23

In fact, that last example is valid in a number of programming languages. The exact same line of code would also work in Python, for example.

So,

• even in statically typed languages where variables have types, you don't necessarily have to declare them,
• in dynamically typed languages, variables don't have types, so obviously you can't even declare them,
• in many languages, you don't even have to declare variables

Answer 2

When you use natural language to refer to information, it is not very precise, and in particular, doesn't communicate to others much about your intent. Similar problems occur when trying to do math in natural language: it just isn't precise enough.

Programming is complex; errors are all too easy to come by. Types are part of a system of checks that are designed to prevent illegal program states, by detecting error conditions. Different languages use types differently: some languages use types heavily to detect errors at compile time. Almost all languages have some notion of incompatible types as a runtime error. Usually a type error indicates a bug of some sort in the program. When we allow programs to continue despite errors, we likely get very bad answers. We prefer to stop the program rather than get bad or incorrect answers.

Put another way, types express constraints on the behavior of the program. Constraints, when enforced by some mechanism, provide guarantees. Such guarantees limit the amount of reasoning necessary to think about the program, thus simplifying the task of reading and maintaining the program for programmers. Without types, and their implication of tools (i.e. the compiler) that detect type errors, the programming burden is considerably higher, and thus, more costly.

It is true that (many) humans easily distinguish between a European, United States, and international phone number. However, the computer doesn't really "think", and would, if told, dial a united states phone number in europe, or vice versa. Types, for example, are a good way to distinguish between these cases, without having to teach the computer how to "think". In some languages, we can get a compile time error for trying to mix a European phone number on an American phone system. That error tells us we need to modify our program (perhaps by converting the phone number to an international dialing sequence, or, by using the phone number in Europe instead), before we even attempt to run the program.

Further, as the computer doesn't think, the name of the field or variable (e.g. phonenumber), means nothing to the computer. To the computer, that field/variable name is just "blah123". Think about how your program would be if all variables were "blahxxx". Yikes. Well, that's what the computer sees. Providing a type gives the computer a inkling into the meaning of the variable that it simply cannot infer from its name alone.

Further, as @Robert says, in many modern languages we don't have to specify types as much as we did in the old days, as languages like C# perform "type inference", which is a set of rules to determine the proper type for a variable in context. C# only provides for type inference on local variables, but not on formal parameters, or class or instance fields.

Answer 3

In addition to the other answers, there is one thing that should be included. Remember that computers are just bits. Say I give you the bytes:

26 3A 00 FF

What does that mean? It's stored this way by the computer, but without any interpretation, it's just bits. It could be 4 ascii characters. It could be an integer. It could be some bytes in an array. It could be part of an object. It could be a pointer to where that cat video is buffering. Pretty much all programming languages from assembly on up need something to know how to interpret the bits to make them do meaningful computation.

And since the computer can't know the meaning of those bits, it needs you to tell it - either explicitly via type annotations, or implicitly via type inference mechanisms mentioned in the other answers.

Answer 4

The answer to why the computers need this information has to do with Data Representation.

The name of the "data type" is a reference to rules that help the computer store and retrieve information from it's raw state of 0's and 1's in the computer memory.

For an example, your regular 8-bit ASCII character would be stored in the computer memory (either RAM or Disk) as 01000001 (the uppercase character "A", ASCII code 65) or 00001000 (the percent sign), or any combinations of 0's and 1's in those 8 bits.

For another example, some 8-bit unsigned integer may be stored as 00000101 (the number 5) or 00001000 (the number 8)

Notice how binary representation of 8 and the % character may be the same, but they mean different things because their types are different.

Even the languages which infer the data type, they may not have the rule that "all varibles' types must be declared by the programmer", they have rules like "if your series of characters is enclosed in quotes, it is a string" and many more rules for each data type.

So even these need data types to make sense of what the 0's and 1's mean, so they can for example do the string concatenation function if you try to "add" two characters, or do integer addition if you're trying to add two integers.

In your story too, let's say you didn't ask Sam for the phone number but Sam gives you a piece of paper that has "1123581321" written on it. You couldn't be certain if Sam is just a fan of first eight Fibonacci numbers, or if that's a phone number. To make a guess you'll have to take into account the context and cues you have available, like perhaps you asked Sam for a phone number a day ago, or the note says "Call Me", or if you count the digits and find it matches patterns of most phone numbers. Only then you'd know that it's a phone number that you can call and not some digits that you'd punch into a calculator.

Note how these hints that led you to a guess that the number was a phone number are similar to how hints lead a computer language that doesn't require declaration to deduce the type of a value.

Answer 5

In some languages, you don't have to specify the data type.

Languages that support type inference can usually figure out the data type from your usage. For example,

var name = "Ali"

is internally typed as a string, because the value is surrounded by quotes.

Some languages don't require you to declare the variable either; the variable is created when it is first used. However, it's considered a best practice to specifically declare your variables, for a number of important reasons; mostly because doing so better expresses your intent.

Answer 6

Because that is what the language design specifies. So to answer your question, we need to look at the intent behind explicit typing in languages like C# and C++. (Well, C# does it because C++ does it because C does it, so we need to look at the intent way back then).

First, explicit and static typing provides rigour in coding - specifying a variable to be an integer means that the compiler and software should be surprised and throw an error when you assign a character or string to the variable. Dynamic typing can cause headaches for the unwary (simply look at PHP or javascripts approach to truthiness of things like arrays and empty strings).

You can have static with implicit typing - initializing a variable as a string means that variable should only ever be a string, but my feeling is that this can cause problems for humans reading the code (I tend to assume dynamic typing when there is implicit typing).

Also, it is possible, in some languages, to write something like this pseudocode to initialise a class from a string input:

PhoneNumber phoneNumber = "(61) 8 8000 8123";

Second, explicit typing also goes hand in hand with memory allocation. An int is always so many bytes. A PhoneNumber is so many bytes. The compiler can assign an appropriate sized memory block that can then be used later without having to see how much space it will need when you assign a value.

PhoneNumber phoneNumber;
...
phoneNumber = "some value from somewhere";

Finally, it removes confusion... is 123 an integer or an unsigned integer? They need the same number of bytes, but the maximum value stored in variables of either type is very different...

This is not so say that explicit is better than implicit - but the language design relies on these kinds of choices, and C# would work differently with implicit typing. PHP and javascript would work differently with explicit typing.

Answer 7

Because Sam is smarter than compilers. For instance, when you say give me the phone number, you don't specify whether you want the country prefix or the the area code whether it is work number where only the last 4 digits are required. Also, you if you ask for the number of the local pizza joint, you would be able to deal with the answer "pizza4u".

Sam, figures it out from context. While the compiler can also figure it out from context, Sam will be better at it (and is capable of interrupting the process to ask for clarification).

There are two basic approaches to types and variables, either the variable has a type, in which case actions that aren't allowed by the type are forbidden and prevent compilation, or the value has a type and actions that aren't allowed by the type are caught at runtime.

Each approach has it's advantages and disadvantages. In general, compiler writers try to minimize the disadvantages and maximize the advantages. Which is why C# for instance allows var phoneNumber = GetPhoneNumber(); and will deduce the type of phoneNumber from the signature of GetPhoneNumber. That means you have to declare the type for the method, but not the variable that receives the result. On the other hand, there are various type hinting/enforcing projects for javascript. Everything is a tradeoff.

Answer 8

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."

"5555555555"

"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?"

"Ten characters."

"Ok, then let me get a bigger piece of paper. Now give me the phoneNumber."

"5555555555"

"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.

Not every language requires you to explicitly type, though. C# has a keyword "var" that causes a variable's type to be interpreted at compile time, and other languages like Javascript are totally dynamically typed, to the point that you can store an integer in a variable, then assign it to a boolean, then assign it again to a string and the language keeps track of it all.

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.

Answer 9

There are programming languages where you don't have to declare data types for your variables. There are even programming languages where you don't have to declare variables before-hand; you can just use them, immediately.

The trouble with not declaring variable names is that if you accidentally misspell the name of a variable, you've now accidentally created a new, completely unrelated variable. So when you run your program, you can't figure out why the hell that variable you set up suddenly has nothing in it... Until, after many hours of debugging, you realise you typed the damned name wrong! GRRR!!

So they made it so you have to declare the variable names you're going to use before-hand. And now when you type a name wrong, you get a compile-time error, which immediately tells you exactly where the bug is, before your program even runs. Isn't that so much easier?

Same deal with data types. There are programming languages where you don't have to declare what type things should be. If you have a customer variable that's actually just a customer's name, not the entire customer object, trying to fetch the customer address from a plain ordinary string... isn't going to work. The entire point of static typing is that the program won't compile; it will loudly complain, pointing to the exact place where the problem is. That's much faster than running your code and trying to figure out why the hell it's not working.

All of these are features to tell the compiler what you were intending to do, so it can check what you actually did and make sure it makes sense. That makes it possible for the compiler to automatically locate bugs for you, which is a Big Deal.

(Far back in the distant past, you didn't have to declare subroutines. You would just GOSUB to a particular line number. If you wanted to pass information between subroutines, you would set particular global variables, call your subroutine, and then inspect other variables when the subroutine returns. But that makes it frighteningly easy to forget to initialise one of the parameters. So now almost all modern programming languages demand that you declare what actual parameters a subroutine takes, so we can check you've specified them all.)

Answer 10

If I'm using normal English language I do not need to declare PhoneNumber as int to use it. For example if I ask my friend Sam to give me his phone number I say:

"Sam give me the phonenumber"

I wouldn't say>

"Char(20) Sam give me the int phoneNumber"

Why do we have to specify data type at all?

Pop over to MathOverflow or Theoretical Computer Science and read for a while to get an idea of how humans communicated alogrithms with one another when they want to insure that there is no possibility of misunderstanding. Or read the standard for some mature programming language.

You'll find that defining what kinds of values are allowed to a term is part of really precise communications practice even human-to-human.

What you've noticed is that day-to-day interactions are fairly regular and human are pretty fault tolerant, so a misunderstanding about phone numbers is generally avoided by the shared knowledge of the participants.

But have you ever tried to take down a phone number for someone in another country? Did they tell you explicitly how many times to push zero to get to international addressing? Did they tell you their country code? Did you recognize it as such? How many digits did you expect? How many did you get? Did you know how to group the digits? Or even if the grouping has significance?

Suddenly the problem is a lot harder and you probably took a lot more care to explicitly check that the number recieved was understood the way the sender meant it.

Answer 11

Another reason for declaring types is efficiency. While an integer could be stored in 1 byte, or 2 bytes, or 4, a program using a very large number of variables might use 4 times the needed memory, depending on what's being done. Only the programmer knows if a smaller storage space is viable, so he can say so by declaring the type.

Also, dynamically typed objects allow for many possible types, on the fly. That could incur some overhead "under the hood", slowing down the program compared to sticking with one type all along.

Answer 12

A number of early programming languages (especially Fortran) did not require you to declare variables before use.

This led to a number of problems. One really obvious one is that the compiler can no longer catch simple typographical errors nearly as dependably. If you have code that's supposed to modify an existing variable, but has a typo, you still have perfectly legitimate code that just created (and assigned a value to) a new variable:

longVariableName = 1

// ...

longVaraibleName = longvariableName + anotherLongVariableName

Now, looking at this in isolation, with my already having mentioned a typo as the source of the problem, it's probably pretty easy to find the typo and the problem here. In a long program, where this is buried in the middle of lots of other code, it's a lot easier to miss.

Even currently with many dynamically typed languages, you can still get the same basic problem pretty easily. Some have some facility to warn you if you assign to a variable, but never read it (which heuristically catches quite a few problems like this) both others don't have such things.

Answer 13

When you declare any variable some space is allocated in the memory,, but the machine( computer in this case )doesn't already know that how much space has to be allocated for that variable.

Example :- you create a program which asks the user to input any number, in this case you have to specify a datatype to store that number, otherwise the machine cannot judge by itself that it should allocate 2 bytes or 2 gigabytes, if it tries to do allocation by itself then it may result in inefficient memory usage.. On the other hand, if you specify the datatype in your program, then after the compilation the machine would allocate proper space according to the need.