3 ms·

I have always wondered why so many people like dynamically types languages... I mean, if I have a variable I ALWAYS know what kind of data I expect in it. If I

by annnnd 13y ago

I have always wondered why so many people like dynamically types languages... I mean, if I have a variable I ALWAYS know what kind of data I expect in it. If I try to use different kinds of data in the same variable then something is clearly wrong - either with me (for wanting that) or with the way I use the variable (and I would appreciate some warning about it). The problem is that you hardly have a choice nowadays. Python, JS and PHP are dynamic, Java is a great language but crappy concept (don't tell me it isn't slooo... <wait for GC... ok, done> ...ow). Ironically, the ugliest language I have ever coded in (ObjectiveC) has the best design decisions (IMHO). ARC instead of manual memory management or GC, strongly typed but still allows generic object pointer (id),...

Skinney 13y ago
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#.
- CmonDev 13y ago
  > "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." Shouldn't you just pass the 'age' property then?
  - Skinney 13y ago
    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.
pdonis 13y ago
I have always wondered why so many people like dynamically types languages Because you don't have to write a lot of boilerplate to tell the language things that it should be able to figure out for itself. I mean, if I have a variable I ALWAYS know what kind of data I expect in it. But that data might not always be of the same type. For example, in Python, I might want a variable to hold strings but also None, so that I can differentiate between, say, "the user explicitly entered an empty string" and "the user hasn't entered any string at all yet". Yes, there are ways to do this in statically typed languages (for example, Haskell's Maybe), but it's still extra code that I have to write.
- annnnd 13y ago
  > Because you don't have to write a lot of boilerplate to tell the language things that it should be able to figure out for itself. This is exactly my point; compiler can't figure out what kind of data I want, at least not in general. A good example is jQuery $.data() which tries to guess what kind of data you have in your HTML tag attribute. Guess what happens if you have a MongoDB ObjectId (as string), for instance "52259986890d6f24e9000000"? Exactly - it is a floating number. Believe me, it leads to some interesting debugging sessions... :) I agree with you however that it is beneficial to have a way to set the var to None/null/..., indicating "not initialized". Win some, lose some I guess.
  - pdonis 13y ago
    Guess what happens if you have a MongoDB ObjectId (as string) But that's a matter of semantics, not static typing. You're going to have to do type conversion on the string regardless, because "MongoDB Objectid" isn't a native type for the compiler. But with static typing, you need to tell the compiler the type of the variable in addition to telling it how to do the type conversion: for example, in C++, you might have to say... var MongoObjectid id = new MongoObjectid("somestring"); ..whereas in Python, for example, you could just say... id = MongoObjectid("somestring")
    - mathias_10gen 13y ago
CmonDev 13y ago
It's good to have dynamic typing as an optional feature in a language (e.g. how it is implemented in C#). It could be useful for some very specific scenarios - typically around integration of different systems. But I agree that it doesn't make much sense to use them all the time. I think people mean that they like decent type inference when they say they like dynamic languages. C# makes a distinction between 'var' and 'dynamic' to make it more clear.
- Fr0styMatt 13y ago
  ^THIS TIMES A MILLION! Static typing, with good type inference, is awesome. Old-school C static typing, is not.
pornel 13y ago
> ObjectiveC) has the best design decisions (IMHO). ARC instead of manual memory management or GC, strongly typed but still allows generic object pointer (id),... It's funny, because objects in Objective-C are dynamically and weakly typed, and as flexible as in JS. The syntax has unnecessary rigidity that doesn't map well to actual semantics of the language. Message passing in ObjC doesn't care about types (you can send any message to any object, and the receiver can capture the message and do whatever it wants). You can change/add methods (and "associated" properties) at run time, of instances and class definitions, just like in JS. e.g. Cocoa bindings will subclass your objects (create a new subclass at run time and swap identity of your object) to replace setters with ones that notify the UI. https://developer.apple.com/library/ios/documentation/cocoa/reference/ObjCRuntimeRef/Reference/reference.html https://developer.apple.com/library/ios/documentation/cocoa/...

by annnnd 13y ago

Skinney 13y ago

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

CmonDev 13y ago
> "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." Shouldn't you just pass the 'age' property then?
- Skinney 13y ago
  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.

pdonis 13y ago

I have always wondered why so many people like dynamically types languages Because you don't have to write a lot of boilerplate to tell the language things that it should be able to figure out for itself. I mean, if I have a variable I ALWAYS know what kind of data I expect in it. But that data might not always be of the same type. For example, in Python, I might want a variable to hold strings but also None, so that I can differentiate between, say, "the user explicitly entered an empty string" and "the user hasn't entered any string at all yet". Yes, there are ways to do this in statically typed languages (for example, Haskell's Maybe), but it's still extra code that I have to write.

annnnd 13y ago
> Because you don't have to write a lot of boilerplate to tell the language things that it should be able to figure out for itself. This is exactly my point; compiler can't figure out what kind of data I want, at least not in general. A good example is jQuery $.data() which tries to guess what kind of data you have in your HTML tag attribute. Guess what happens if you have a MongoDB ObjectId (as string), for instance "52259986890d6f24e9000000"? Exactly - it is a floating number. Believe me, it leads to some interesting debugging sessions... :) I agree with you however that it is beneficial to have a way to set the var to None/null/..., indicating "not initialized". Win some, lose some I guess.
- pdonis 13y ago
  Guess what happens if you have a MongoDB ObjectId (as string) But that's a matter of semantics, not static typing. You're going to have to do type conversion on the string regardless, because "MongoDB Objectid" isn't a native type for the compiler. But with static typing, you need to tell the compiler the type of the variable in addition to telling it how to do the type conversion: for example, in C++, you might have to say... var MongoObjectid id = new MongoObjectid("somestring"); ..whereas in Python, for example, you could just say... id = MongoObjectid("somestring")
  - mathias_10gen 13y ago

CmonDev 13y ago

It's good to have dynamic typing as an optional feature in a language (e.g. how it is implemented in C#). It could be useful for some very specific scenarios - typically around integration of different systems. But I agree that it doesn't make much sense to use them all the time. I think people mean that they like decent type inference when they say they like dynamic languages. C# makes a distinction between 'var' and 'dynamic' to make it more clear.

Fr0styMatt 13y ago
^THIS TIMES A MILLION! Static typing, with good type inference, is awesome. Old-school C static typing, is not.

pornel 13y ago

> ObjectiveC) has the best design decisions (IMHO). ARC instead of manual memory management or GC, strongly typed but still allows generic object pointer (id),... It's funny, because objects in Objective-C are dynamically and weakly typed, and as flexible as in JS. The syntax has unnecessary rigidity that doesn't map well to actual semantics of the language. Message passing in ObjC doesn't care about types (you can send any message to any object, and the receiver can capture the message and do whatever it wants). You can change/add methods (and "associated" properties) at run time, of instances and class definitions, just like in JS. e.g. Cocoa bindings will subclass your objects (create a new subclass at run time and swap identity of your object) to replace setters with ones that notify the UI. https://developer.apple.com/library/ios/documentation/cocoa/reference/ObjCRuntimeRef/Reference/reference.html https://developer.apple.com/library/ios/documentation/cocoa/...