Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Orange Wizard]

perl for president 2k16

I dunno, that sounds pretty much the same as Python in terms of dynamic-ness. Way more convenient though - especially with bless and but.

[Rose]

Dynamic typing is that thing where you can assign any type to any variable, right?

Why would you want that?

[Orange Wizard]

Convenience, mostly, though at the cost of occasionally sticking a string where you wanted a float.

[Levi]

Some days I just want to put an Integer, a string, a Banana, a nothing, and another array inside an array.

[itisnotlogical]

The reason I liked it in Python is that it wouldn't flip a shit when trying to concatenate strings with various other things. And when using a strong-typed language, "forgot the type declaration" is usually the first stupid mistake I make.

[Bauglir]

Dynamic typing is that thing where you can assign any type to any variable, right?

Why would you want that?

Same reason you want modular functions that you don't need to know the inner workings of in order to use, just how to call them, what they expect as input, and all that other neat stuff abstraction brings.

Dynamic typing means that types aren't checked until runtime; I think it's a prerequisite for ducktyping, which means that types aren't strictly enforced but you'll get runtime errors when you try to call a method that isn't defined for a particular type. I'm not sure which one allows you to suddenly change a variable's type whenever by something like

Code: [Select]

a = 1
a = 'alpha'
But anyway, the reason you'd want it is so that you no longer have to worry about types. Instead, you trust that everybody who defined a type did their job properly, so that the methods you call are defined as you expect, and that everybody who uses your code does their job properly, so that they don't feed your code objects without the methods you need. Same way that when you write a function, you trust that the functions you use do what the documentation says, and you trust that users of yours will read your documentation, without anybody needing to dig into anybody else's source code. The idea is that you can say, "Okay, I'm not going to write a different function for adding integers than for floats, I'm just going to use exactly the same logic and assume that adding means basically the same thing for either one".

It adds convenience, and reduces the amount of stuff you need to understand in order to make your code function, provided nothing goes wrong. Of course, things always go wrong, and ducktyping can be an absolute nightmare to debug (for example, somebody unwittingly passes a string to your function, which cheerfully says, "Oh, you mean to concatenate these things!" and moves on until something three functions up breaks because how the fuck am I supposed to square root the string 'foobar').

If understanding your code is the hardest part of your job, ducktyping helps. If debugging is the hardest part of your job, it will quite possibly make things worse. At least, that's my understanding of the question.

[Rose]

C# has static typing and doesn't have a problem with adding things to strings.

"One" + 1 = "One1"

[Bauglir]

Yeah, that's because they overloaded the operator. That's a hardcoded version of the same sort of thing - "+" figures out what it's supposed to be doing based on the types of the operands. Duck typing lets programmers do that sort of overload with their own code. Say you write a screen_update() function that takes as an argument an object obj, checks several bits of context like whether it's onscreen, behind some other bit of the GUI, etc., and then calls obj.draw(), passing it those bits of context to influence what it does on the screen.

With duck typing, you can write that function without knowing anything about those objects's types, because you don't actually care. You just need to be able to trust it has draw(), get_position(), get_size(), and so on, methods defined. You only need to write the function once, you don't need to mess around with any fancy argument declarations, and you don't even need to be able to anticipate every possible type that might get added when scope bloat inevitably occurs because an executive had a "great idea". Moreover, the user doesn't need to worry about any of that stuff either - they can just file the function away in headspace as "Thing what makes the pixels dance" and get on with whatever their job is.

Now, I don't know why it would be structured that way - maybe you're in charge of screen layout while the other stuff is being handled by an art asset team or something? It's a bit of a contrived example, like they almost always are. The point is, we've overloaded screen_update() to execute the same basic idea for any object type it makes sense to shove into the function, which makes it more convenient to use and simpler to grok.

[Rose]

That's why you have generic functions, where you can say that "This input can be any type as long as it supports these functions"

So if you try to pass in a variable of a type that doesn't support draw(), get_position(), and get_size(), you'll get an error right there.

[Putnam]

ain't that

...

duck typing

[Skyrunner]

It seems fairly similar...

[Rose]

Going by Bauglir's post, duck typing seems to not have any protections against passing in the wrong type.

[Orange Wizard]

I think implicit type conversions got mixed in there somewhere. Python's both duck and dynamically typed, but "5" + 3 = TypeError, whereas some other languages will give you an 8 or a "53".

[Antsan]

Yeah, that's the difference between strong and weak typing.

[Putnam]

okay i was about to complain about strong typing being a really vague term with basically no meaning but then i did this in lua

Code: [Select]

("3"..5)*"2"
> 70
and i was like "yeah i guess that's what it means"

also, since we're talking about typing

Python 3.5's got type hints now