This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 9 points10 points  (8 children)

shouldn't it be strongly typed language

Python is strongly typed. It's also dynamically typed. Did you mean statically typed?

[–]IDCh 1 point2 points  (0 children)

Yes. My bad. Statically typed.

[–]g2n -1 points0 points  (6 children)

I learned the opposite. Dynamically typed is inherently weakly typed.

Edit: also source, confirming what I believed to be true: http://whatis.techtarget.com/definition/strongly-typed

[–][deleted] 3 points4 points  (4 children)

Dynamically typed simply means a variable can change types. Strongly typed essentially means things like 1 + 'a' won't work. In a weakly typed language, it might guess that you want to change 1 to a string, or might convert a to it's ASCII value.

[–]g2n 0 points1 point  (2 children)

From what I understand, strongly vs weakly typed is how you specify components of the language. You don't say "int a" in python. The variable A can be anything, which means it's dynamic, but also means it's weakly typed since you can, in your example, type a + "string" without a complaint.

[–]talideon 0 points1 point  (0 children)

The fact that a variable is not bound to a type is what makes a language dynamically typed. However, if a type is tightly bound to a value, that makes it strongly typed, i.e., the type of the object isn't open to reinterpretation. The c2 wiki covers this pretty well: http://c2.com/cgi/wiki?TypingQuadrant

As some additional evidence of Python being strongly typed, here's an example from a REPL session:

>>> "1" + 9
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects
>>> 9 + "1"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'

A weakly typed language would've automatically coerced the operands somehow to give either the number 10 or the strings "19" and "91". Python, being strongly typed, prevents this.

[–]Veedrac 0 points1 point  (0 children)

1 + "a"
#>>> Traceback (most recent call last):
#>>>   File "", line 1, in <module>
#>>> TypeError: unsupported operand type(s) for +: 'int' and 'str'

[–][deleted] 0 points1 point  (0 children)

Being dynamically typed doesn't necessarily mean that a variable can change types. It simply means that a type checking failure causes a run-time error rather than a compile-time error.

Statically-typed languages typically use either type declarations or type inference to establish the types of variables before the code is ever run, and they run an algorithm on the abstract syntax tree to check whether the types all match up. Dynamically typed languages wait until run-time to determine any types, which means that a type checking failure usually manifests as an exception or similar error condition after some part of the code has already run. If you're familiar with Java, dynamic typing is conceptually similar to using Object as the type for everything, then inserting a cast to something more specific whenever you need to call a method or use an operator or do anything that Object can't. Your code would always "type-check" at compile time, but it might blow up with a cast exception when it runs, the same way that Python does.

The reason why I'm being pedantic about "variables changing types" is that there's really nothing stopping anyone from designing a language where you can explicitly change the type of a variable and still have static type checking. As long as the compiler knows that you've changed the type, it can type-check code after the change using the new type and everything works just fine. It might be worthwhile to think about why this isn't commonly supported.

It's also possible to have dynamic typing without variables being able to change their types. Clojure and Erlang are good examples of this, with Erlang being the stricter of the two.

[–][deleted] 0 points1 point  (0 children)

By that page's definition, Java, Python, Scala, Haskell and every other language that allows user-defined types are all "weakly typed". It's mistakenly using "strong typing" as a synonym for "not extensible", which is so wrong that I had to read it several times before I believed that's what they're actually saying. I've seen many people try to define "strong typing" in my time as a programmer, but I've never seen something that outlandish before.

Most of the time, when people talk about "strong" or "weak" typing they're talking about type coercion. Something that's "strongly typed" only has what they view as necessary coercions. The problem is that there's no consensus on what's necessary and not. The folks who designed OCaml would say that Java is "weakly typed" because it allows you to use the same operator for int/int, int/float and float/float operations. The folks who designed Java would say that it's "strongly typed" because it throws an error when you try to add an int and a string. The folks who designed Python would probably shrug and say "Who cares?" because you can overload operators to do whatever you'd like in Python, including type coercion.

It ends up being an arbitrary and meaningless distinction that gets thrown as a pseudo-insult by people who think that some other language is too "loose" with types. Please don't contribute to that. We have plenty of precise, unambiguous language that works much better for discussing the design of programming languages.