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?

  • 84
    That's because English has implicit typing - so yourPhoneNumber is implicitly typed as a PhoneNumber - humans also have dynamic memory allocation... ;)
    – HorusKol
    Commented Mar 21, 2016 at 0:16
  • 28
    You and Sam knows that a phone number consists of digits and you would be surprised to find a letter in it. Computers don't and need to be told. Commented Mar 21, 2016 at 0:18
  • 16
    And when I hear numbers like 1-800-JIMBO in movies, my thought is: How is that a number? O.o
    – muru
    Commented Mar 21, 2016 at 5:41
  • 103
    You shouldn't declare phoneNumber as int. In most programming languages this will delete leading zeros.
    – Aron_dc
    Commented Mar 21, 2016 at 7:31
  • 26
    @HorusKol: humans have not only dynamic memory allocation, but also a highly nonconservative garbage collector... Commented Mar 21, 2016 at 14:43

13 Answers 13


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.


  • 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
  • 2
    Plus one for explaining both type inference and dynamic typing (late binding)
    – dcorking
    Commented Mar 21, 2016 at 10:55
  • 37
    This is great info about misconceptions behind the question, but still leaves the question unanswered. The question, more properly, is why do we have to specify the data type when declaring variables in languages that require that? Why were they designed way? There are good answers to that question, and while elaborating on alternatives broadens the OP's horizons and is very good, that doesn't seem complete to me.
    – KRyan
    Commented Mar 21, 2016 at 20:55
  • 7
    @KRyan: if you want to know why a certain language designer made a certain language design choice, you will have to ask that language designer, I'm afraid. I cannot tell you why the designers of C♯ decided against type inference, nor can I tell you why they later changed their minds. Language design is heavily opinionated and often comes down to taste. If, OTOH, you want to know about the specific trade-offs involved, the answer would basically be a re-print of Prof. Pierce's Types and Programming Languages which is much too broad for Stack Exchange. Commented Mar 21, 2016 at 21:20
  • 2
    JörgWMittag: as @KRyan already said, the answer "you don't have to" is not very interesting (it is trivially obvious -- many languages allow to omit the type declarations in some cases). The question "why would you want to declare types" is much more interesting and better reflect the spirit of the original question (your answer reminds me of the joke: "where we are?" -- "you are in a hot-air balloon!"). You don't need to know what a designer of a specific language thought at the time, to provide some good reasons in favor of type declaration.
    – jfs
    Commented Mar 22, 2016 at 13:39
  • 1
    @Zaibis: auto i = 1 // i is inferred to type int, vector<int> vec; auto itr = vec.iterator(); // itr is inferred to type vector<int>::iterator and so on. If you want to know how exactly that works, you can look it up in the spec. Commented Mar 23, 2016 at 10:41

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.

  • 4
    RE the sad part: It is impossible to infer type of a publicly accessible member (public field, public method signature), because you can't predict when and how it will be used. Also, type annotations are documentation. Commented Mar 21, 2016 at 13:37
  • I think you should highlight/bold this line: Types are part of a system of checks that ... since it directly answers the OP on Why do we have to specify data type at all? ..
    – txtechhelp
    Commented Mar 21, 2016 at 20:04
  • Note: you answer assumes that a language used to specify types is somehow better at avoiding errors than your regular programming language. It is obviously not so e.g., consider C++ template language that is Turing-complete (and therefore allows to express many error checks) but it is almost unreadable compared to many other Turing-complete languages such as Haskell, Python, and even other parts of C++ itself. Ask yourself why won't you use the same programming language, to express the error checks as the rest of your program (there are good answers in some but not all cases).
    – jfs
    Commented Mar 22, 2016 at 5:47
  • @SergioTulentsev That's not true - in F#, you can have public methods without specifying their types explicitly. The compiler will infer the types from usage inside the method. For example, the following are valid public method definitions: static member add x y = x + y, member x.Append s = x.Text + s. In the first case, x and y will be inferred to be ints because of the addition. In the second case they'll be whatever is valid depending on the type of x.Text - if it's a string, then s will be a string as well. I do agree that type annotations are documentation, though.
    – Roujo
    Commented Mar 22, 2016 at 19:49
  • "Implicit local types, explicit interface types" is how a lot of people program, even in languages like Haskell that allow you to omit (nearly) all types while still having the compiler infer strict types. There are many people who don't consider it sad when a language enforces this practice (as C# does).
    – Ben
    Commented Mar 22, 2016 at 21:24

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.

  • 10
    True enough, but to really boggle your mind, realize that the computer is never capable of understanding what those bits mean—even when you tell it more type annotations. Your explanations just get turned into even more hex numbers, to "clarify" the first hex numbers. The significance is all created by people in order to put the intention into the electronics and get them to do what we intend. Now go say "thank you" to an engineer. :)
    – Wildcard
    Commented Mar 21, 2016 at 6:15
  • 1
    I spent many years programming on mainframes. With PL/1 this answer makes a LOT of sense. Quite regularly we would be used based storage based on a pointer that was set to the address of another variable of a different data type to access the bytes in a different way. For example PL/1 doesn't support a 1 byte binary numeric field, but we would base a 1 character variable at the address to allow us to store a 6 byte array storing 6 single byte binary fields (in this case allowing us to save 6 bytes per address - which was important when storage was expensive).
    – Kickstart
    Commented Mar 21, 2016 at 9:34
  • 1
    The computer is able to understand a lot of possibilities but even the clever compilers needs context to understand. It is not the same the number 0 or "0". Or the String "Dec 31" will be ordered before "May 1" treated as a String but not if treated as a Date. Or take 5/2. It is 2 as an enter but 2.5 as a double. Also, the type is a security measure against unwanted conversions. Null, NaN, and rounding or overflows might also become a problem. Strong and statically typed languages have some advantages. For example, the compiler helps you detect problems while refactoring.
    – Borjab
    Commented Mar 21, 2016 at 11:11
  • 1
    @Borjab Did you mean "It is 2 as an integer"?
    – Richard Ev
    Commented Mar 21, 2016 at 15:45
  • 1
    @RichardEverett Certainly that was a lapsus. Thanks but to late to edit it.
    – Borjab
    Commented Mar 21, 2016 at 16:02

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.

  • 3
    This is the closest answer. It all has to do with memory. You declare the type so the compiler knows how much memory to the application should request at runtime. Knowing how the bits should be interpreted is secondary. Commented Mar 21, 2016 at 10:07
  • @GregBurghardt true. For making sense of bits already present as well as putting the bits there in first place after converting given data to binary according to the data type. Commented Mar 22, 2016 at 6:36

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.

  • 5
    The var name = "Ali" style is actually common for modern statically typed languages. In statically typed languages, the type is fixed at creation, but it still can be determined by the initializer. The definition of a dynamically typed language is that types attach to values, not variables. Assigning a value to a variable therefore sets the variables's type as well.
    – MSalters
    Commented Mar 20, 2016 at 23:31
  • @MSalters: I made a slight adjustment to the wording. Commented Mar 20, 2016 at 23:35
  • 5
    The irony here is this includes C# with this exact syntax. Commented Mar 21, 2016 at 1:34
  • 1
    @MSalters Assigning a value to a variable therefore sets the variables's type as well. Or that the variable has no inherent type and the interpreter will attempt to apply whatever operation to the value of the variable. Are there any dynamically typed languages where code like the following (Javascript) would not be allowed var x = 5; x = ""; because the first statement causes x to have the "Number" type associated with x? Sort of conflicts with dynamic typing. And if not, what effect does the type associated with the variable have, beyond the type association with the value?
    – Zev Spitz
    Commented Mar 21, 2016 at 9:35
  • 1
    @ZevSpitz: The first kind of system isn't dynamically typed, but not typed at all. Your Javascript example isn't dynamically typed, precisely because the Number type cannot change. In a dynamically typed language, x = ""; changes the type of x to string, even if it was a number previously.
    – MSalters
    Commented Mar 21, 2016 at 12:40

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.


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.


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

"Ten characters."

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

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.


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

  • 1
    In C++ you can put "auto x=1" and it knows it's an int. auto y=1.2; auto z = 'Z'; etc
    – QuentinUK
    Commented Mar 21, 2016 at 18:51
  • @QuentinUK In C#, you can put var x=1 with similar results. But that's nothing; in Haskell, you can write your entire program with no type signatures at all, yet it's all statically typed, and you still get errors if you make a mistake... (Not exactly mainstream though.) Commented Mar 21, 2016 at 21:20
  • @QuentinUK But if you write for (auto i=0; i<SomeStdVector.size(); ++i) your linter is going to complain because it deduced a signed type and you proceed to compare it to an unsigned type. You have to write auto i=0ul (putting the type information in explicitly again, so should just write size_t i=0 in the first place). Commented Aug 29, 2019 at 18:38

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.


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.


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.


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.

  • this doesn't seem to offer anything substantial over points made and explained in prior 11 answers
    – gnat
    Commented Mar 21, 2016 at 18:43
  • 1
    Gnat you should once again read all the answers thoroughly and see that i've tried to answer this question in a much simpler manner which one can easily understand.
    – Atul170294
    Commented Mar 21, 2016 at 18:47
  • I just re-checked three most recent answers that were posted about an hour prior to this one and all three seem to be making the same point and per my reading explain it in a simpler manner than here
    – gnat
    Commented Mar 21, 2016 at 18:55
  • Although i didnt responded for the reward of your vote but i think you should get to know one thing,, you should downvote an answer because it may give useless or wrong information and if it contains anything offensive. All the answers which have most useful and relevent information will get higher number of upvotes which is sufficient to differentiate between an answer, a good answer and the best answer. Your childish activity of downvoting an answer without any strong reasons will only discourage other people who also want to share their opinion which they think might be useful to others
    – Atul170294
    Commented Mar 21, 2016 at 20:05
  • 1
    Your answer was most likely downvoted because it is not correct. Static typing is not required to help with memory management. There are many languages that allow for dynamic typing, and those languages / environments are able to deal with the memory management issues you mention.
    – Jay Elston
    Commented Mar 23, 2016 at 18:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.