The reason alot of people like dynamicly typed languages is that they don't have to babysit the compiler. Small example, in JS, if you have a function that works on a "age" property of an object, it doesn't matter what kind of object you send in, as long as it has an "age" property. You can do this easily in staticly typed languages as well, but you have to write more code (generics, class/struct-definitions, interfaces ...).
> I mean, if I have a variable I ALWAYS know what kind of data I expect in it
Really? Why did people invent generics/templates, interfaces and class-inheritance then? You won't always know what type you are receiving, and alot of the time you don't really care either, as long as it meets your criteria.
> The problem is that you hardly have a choice nowadays
Course you do: C/C++, Haskell, OCaml, Go, Nimrod... Soon you'll have Rust to play with as well.
> <wait for GC... ok, done>
Depends on your usecase. As long as your active memory use don't number in multiple GBs, GC is quite fast. I have an application spawning 1GB of garbage a second, this takes 5ms (a second) to collect. Not bad IMHO. The work they are doing on the new G1 collector also seems promising. Btw, GC can in many cases have lower overhead than ARC (Python also does ARC btw).
> strongly typed but still allows generic object pointer (id)
Last I checked, most of Obj-C prefers dynamic typing. NSArray and NSDictionary for instance, can contain any type. Regarding (id), most languages allows this. "Object" in Java/C#, void* in C/C++, interace{} in Go etc.
In the end, it doesn't really matter what language you use, as long as it gets the job done. If your language isn't available, you're mostly able to use another language anyway. Almost every language nowadays has a JS-compiler. There exists a Java Bytecode -> Native code compiler, same with C#.
> "Small example, in JS, if you have a function that works on a "age" property of an object, it doesn't matter what kind of object you send in, as long as it has an "age" property."
Depends what operation you are performing. increaseAge function would probably require the object to actually increase the age, not just return an increased age value.
This is a poor example, i know, but the point is that while both is simple operations in both static and dynamically typed languages, dynamically typed languages allow you to do this without writing an interface, generic function, abstract base class or whatever and restricting the function to that particular use case.
The tradeoff is flexibility vs safety. I personally prefer dynamically typed languages as I've found that with a combination of discipline and unit-tests (which, IMHO, you should have anyway) I never really miss the static type-checker. But I understand those people who prefer static typing very well.
> I mean, if I have a variable I ALWAYS know what kind of data I expect in it
Really? Why did people invent generics/templates, interfaces and class-inheritance then? You won't always know what type you are receiving, and alot of the time you don't really care either, as long as it meets your criteria.
> The problem is that you hardly have a choice nowadays
Course you do: C/C++, Haskell, OCaml, Go, Nimrod... Soon you'll have Rust to play with as well.
> <wait for GC... ok, done>
Depends on your usecase. As long as your active memory use don't number in multiple GBs, GC is quite fast. I have an application spawning 1GB of garbage a second, this takes 5ms (a second) to collect. Not bad IMHO. The work they are doing on the new G1 collector also seems promising. Btw, GC can in many cases have lower overhead than ARC (Python also does ARC btw).
> strongly typed but still allows generic object pointer (id)
Last I checked, most of Obj-C prefers dynamic typing. NSArray and NSDictionary for instance, can contain any type. Regarding (id), most languages allows this. "Object" in Java/C#, void* in C/C++, interace{} in Go etc.
In the end, it doesn't really matter what language you use, as long as it gets the job done. If your language isn't available, you're mostly able to use another language anyway. Almost every language nowadays has a JS-compiler. There exists a Java Bytecode -> Native code compiler, same with C#.