6 ms·

When static typing vs dynamic typing is discussed, i see that often a mistake is made and "static typing" is confused with "strong" typing, and "dynamic typing"

When static typing vs dynamic typing is discussed, i see that often a mistake is made and "static typing" is confused with "strong" typing, and "dynamic typing" is confused with "weak typing". Just FYI: If one wants his/her "programming language" to catch typing errors/violations/mismatches, one needs to use a language with strong typing, regardless of if the language itself supports static or dynamic typing. Dynamic typing relies on being able to infer the types; this can be often achieved at compile time but in any case at runtime, if the platform is strongly typed, any type error will be caught. Then, after being caught, what could be done about it depends on your platform -- some platforms will die with an error; some others will die but allow you to inspect what happened; then others allow you to patch (correct) the error and continue. Static typing requests you to explicitly declare types. This helps the compiler do as much checking as possible at compile-time. This has the added side benefit to increase the speed of the compile code, since less checking is needed at runtime. Some systems are dynamically typed but weakly-typed. Examples are PHP and ES/Javascript. Some systems are statically typed but fairly weakly-typed. The Kerninghan&Ritchie C language is an example. Some systems are dynamically typed and strongly typed. Python is one of them, although it also has what is so-called "duck" typing. Some systems support dynamic and (optional) static typing, and are strongly typed. Common Lisp is an example, as well as in Julia. In both cases (CL and Julia), static typing helps for increasing performance, and for achieving multiple dispatch (i.e. for Object-Oriented programming). CL is able to do compile-time checking as well, if the implementation supports it. Some systems have fairly complete strong typing which relies on extensive static typing facilities. Haskell is an example.

kazinator 9y ago
> often a mistake is made and "static typing" is confused with "strong" typing, and "dynamic typing" is confused with "weak typing". Do you identify that problem in this specific video? "Strong typing" is itself loaded. There is a definition of "strong typing" which means "no conversions occur between types without programmer requests". For instance, under this notion, a language in which we cannot use an integer expression in a floating-point context without putting in an integer-to-float coercion is more strongly typed than one in which the conversion is inferred and takes place implicitly. "Strong typing" has been used in reference to the facility, as in the Pascal family, for declaring type alias names for identical types (such as integers) such that the aliases are considered distinct types. The C typedef mechanism is weakly typed because a mode_t and pid_t, both perhaps just aliases for int, are considered to be indistiguishable from int and compatible. C++ has more strongly typed enum types than C, because a location of some enum type in C++ cannot be assigned a value of an integer type, or of a different enum type, without a cast. Sometimes "strong typing" means that there are no holes in the type system: no datum is being misused if there are no diagnostics about type. (This is related to the other senses of "strong typing" because if an implicit conversion is allowed in a program which is free of type diagnostics, that conversion could be unsafe and hide a software defect. The type system knows very well that here there is an expression of real type and the context requires a integer value and silently generates the conversion; but what if it is out of range? In, C, the behavior of an out of range floating to integer conversion, and vice versa, is undefined.) > Static typing requests you to explicitly declare types. Not in anything that can be called state-of-the-art static typing, except at module boundaries (where the compiler cannot always infer parameter or return types since some of the information is in another module that it doesn't know about). Types can be inferred implicitly from basic terms in the program syntax tree whose type information is known (like literal operands, standard functions and operators and such) and then from there by inference (which can also go in the other direction, like from known function parameters to unknown terms nested inside the function). https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy...
- fish_fan 9y ago
  > Sometimes "strong typing" means that there are no holes in the type system: no datum is being misused if there are no diagnostics about type. I have never heard this. I do, however, use "sound" and "soundness" for virtually rhe same thing. The reason why is because both of these terms are worthwhile as distinct, meaningul, well-defined terms. It also doesn't make sense: type correctness is a binary calculation. Strong is a comparative, which isn't super useful when there are only two values.
erokar 9y ago
> When static typing vs dynamic typing is discussed, i see that often a mistake is made and "static typing" is confused with "strong" typing, and "dynamic typing" is confused with "weak typing". A concern Smallshire spesifically addresses in the talk, pointing out the correct distinctions.
DonbunEf7 9y ago
You didn't watch the video, or you watched but didn't listen, or you watched and listened but didn't think. I can't tell which. I'm letting you know your mistake so that you can avoid being downvoted next time. Normally it's hard to tell when somebody hasn't read before commenting, but given that a non-trivial portion of this talk is explicitly laying out the different facets of type systems and doing compare-and-contrast analysis, it's really obvious that your reply was written without watching.
- coldtea 9y ago
  It's none of your business to scold people based on whether they watched the video or not or "read before commenting", even less to say things like "or you watched and listened but didn't think". From the HN guidelines: "Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that.". It's very probable and totally OK that the parent didn't watch the video. Or that they watched it but skipped around most parts. It's a 50+ minute video, and it's not required to watch it in full for participating in this HN discussion. People often get into the discussion inspired only by the title of the submission (which serves as a topic for the thread) and not the content in the linked article or video. That's just as well -- more often their contributions, even without having seen the article, can be way more informative and intelligence than what's in the article. And yes, sometimes they can even repeat what's already said there. I'm letting you know your mistake so that you can avoid being downvoted next time.
- flavio81 9y ago
  > You didn't watch the video, or you watched but didn't listen, or you watched and listened but didn't think. My post was about "discussions" and targeted to the comments that usually come whenever static typing vs dynamic is discussed. Not about the video.
msla 9y ago
I think it's more interesting to talk about the difference between "semantic types" and "representation types" (terminology my own, as I refine these ideas with help from the people around here): https://news.ycombinator.com/item?id=15083003 https://news.ycombinator.com/item?id=15083003 As chriswarbo said: > One reason for this is the tight coupling in developers' minds between what I'd call "types" and "representations" (these terms are very overloaded, so others may use them in different ways). > Just because, say, a function name and a string are represented in memory the same way, that doesn't mean they are the same type; in particular there are many strings which aren't function names, and there are many operations (e.g. append) which make sense for strings but not for function names. This is a well-known problem, called 'stringly typing': The language is enforcing the type system it knows about, but it only knows the representation of values, not the semantics, not what it is valid to do to them at a high level. Therefore, you can defeat the type system entirely by just passing everything as strings. I brought up the idea of having layers of representation: > Length is a type of value, whether it's expressed in inches or centimeters or light-seconds is a representation, and whether it's in ints or floats or strings is another layer to the representation. You can add inches to centimeters with the right conversion, much like you can add numerical values represented ints and strings with the right conversions. The conversions just have to be at the right layer of representation. This, to my mind, means that autoconversion is orthogonal to strong typing, in that it preserves the type system if it's done in a way which converts between different representations of values with the same (or compatible) semantics. Of course, if your type system is focused entirely or almost entirely on representations, autoconversion defeats it totally. Finally, the little historical note: > Your ideas sound a lot like the original Hungarian notation, BTW: If your language-level types are representations (as in, your type system says int and float, as opposed to semantic notions like pixels-from-edge or alpha-percentage) you can encode the real type information in variable names. People mutilated this to encoding language-level type information in variable names, which is utterly pointless and potentially harmful.
rkido 9y ago
> Static typing requests you to explicitly declare types. You are confusing explicit typing with static typing. "Static" means "compile-time checking". "Dynamic" means "defer checks to run-time". Some language implementations can disable run-time type checking if optional type annotations are added, such as in Typed Racket. In other words, all the following combinations are possible: - Implicit + dynamic + strong: Python - Implicit + dynamic + weak: JavaScript - Implicit + static + strong: Standard ML without type annotations - Explicit + dynamic + strong: Elixir with type annotations - Explicit + static + strong: Java - Explicit + static + weak: C I struggle to come up with examples for these... - Implicit + static + weak - Explicit + dynamic + weak ... but I'm sure they exist, perhaps as historical languages from when type systems were less sophisticated. After all, "strong" and "weak" are entirely relative, constantly in flux, and exist on a continuum. In a couple decades, anything lacking dependent types might perhaps be considered "weakly typed".
- evincarofautumn 9y ago
  For explicit+dynamic+weak, I think ActionScript 3 fits the bill. The language is dynamically typed by default (an un-annotated variable has the dynamic type, “*”), but you can add type annotations, which are used to guide the implicit dynamic type conversions inherited from AS3’s ECMAScript roots. And the type system has some inherent weakness, such as the fact that the “Function” type isn’t generic: it enforces that a value is a function, but doesn’t enforce anything about its parameter types or return type.
- continuational 9y ago
  Java is not strongly typed; I can add an int to a String, and I can compare Apples to Oranges. It's as weak as JavaScript, just statically typed.
- flavio81 9y ago
  > "Static" means "compile-time checking". "Dynamic" means "defer checks to run-time" It is not really about checking, it's about allocation/binding. Static typing, for binding a variable, requires declaring the type of the data, this can be explicit (as in C++) or inferred from another value where the type was declared (as in C++ with 'auto' or as in Haskell). Dynamic typing does not require a type declaration. You can bind an unassigned variable and then assign a value later, without having to declare the variable type.

kazinator 9y ago

> often a mistake is made and "static typing" is confused with "strong" typing, and "dynamic typing" is confused with "weak typing". Do you identify that problem in this specific video? "Strong typing" is itself loaded. There is a definition of "strong typing" which means "no conversions occur between types without programmer requests". For instance, under this notion, a language in which we cannot use an integer expression in a floating-point context without putting in an integer-to-float coercion is more strongly typed than one in which the conversion is inferred and takes place implicitly. "Strong typing" has been used in reference to the facility, as in the Pascal family, for declaring type alias names for identical types (such as integers) such that the aliases are considered distinct types. The C typedef mechanism is weakly typed because a mode_t and pid_t, both perhaps just aliases for int, are considered to be indistiguishable from int and compatible. C++ has more strongly typed enum types than C, because a location of some enum type in C++ cannot be assigned a value of an integer type, or of a different enum type, without a cast. Sometimes "strong typing" means that there are no holes in the type system: no datum is being misused if there are no diagnostics about type. (This is related to the other senses of "strong typing" because if an implicit conversion is allowed in a program which is free of type diagnostics, that conversion could be unsafe and hide a software defect. The type system knows very well that here there is an expression of real type and the context requires a integer value and silently generates the conversion; but what if it is out of range? In, C, the behavior of an out of range floating to integer conversion, and vice versa, is undefined.) > Static typing requests you to explicitly declare types. Not in anything that can be called state-of-the-art static typing, except at module boundaries (where the compiler cannot always infer parameter or return types since some of the information is in another module that it doesn't know about). Types can be inferred implicitly from basic terms in the program syntax tree whose type information is known (like literal operands, standard functions and operators and such) and then from there by inference (which can also go in the other direction, like from known function parameters to unknown terms nested inside the function). https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy...

fish_fan 9y ago
> Sometimes "strong typing" means that there are no holes in the type system: no datum is being misused if there are no diagnostics about type. I have never heard this. I do, however, use "sound" and "soundness" for virtually rhe same thing. The reason why is because both of these terms are worthwhile as distinct, meaningul, well-defined terms. It also doesn't make sense: type correctness is a binary calculation. Strong is a comparative, which isn't super useful when there are only two values.

erokar 9y ago

> When static typing vs dynamic typing is discussed, i see that often a mistake is made and "static typing" is confused with "strong" typing, and "dynamic typing" is confused with "weak typing". A concern Smallshire spesifically addresses in the talk, pointing out the correct distinctions.

DonbunEf7 9y ago

You didn't watch the video, or you watched but didn't listen, or you watched and listened but didn't think. I can't tell which. I'm letting you know your mistake so that you can avoid being downvoted next time. Normally it's hard to tell when somebody hasn't read before commenting, but given that a non-trivial portion of this talk is explicitly laying out the different facets of type systems and doing compare-and-contrast analysis, it's really obvious that your reply was written without watching.

coldtea 9y ago
It's none of your business to scold people based on whether they watched the video or not or "read before commenting", even less to say things like "or you watched and listened but didn't think". From the HN guidelines: "Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that.". It's very probable and totally OK that the parent didn't watch the video. Or that they watched it but skipped around most parts. It's a 50+ minute video, and it's not required to watch it in full for participating in this HN discussion. People often get into the discussion inspired only by the title of the submission (which serves as a topic for the thread) and not the content in the linked article or video. That's just as well -- more often their contributions, even without having seen the article, can be way more informative and intelligence than what's in the article. And yes, sometimes they can even repeat what's already said there. I'm letting you know your mistake so that you can avoid being downvoted next time.
flavio81 9y ago
> You didn't watch the video, or you watched but didn't listen, or you watched and listened but didn't think. My post was about "discussions" and targeted to the comments that usually come whenever static typing vs dynamic is discussed. Not about the video.

msla 9y ago

I think it's more interesting to talk about the difference between "semantic types" and "representation types" (terminology my own, as I refine these ideas with help from the people around here): https://news.ycombinator.com/item?id=15083003 https://news.ycombinator.com/item?id=15083003 As chriswarbo said: > One reason for this is the tight coupling in developers' minds between what I'd call "types" and "representations" (these terms are very overloaded, so others may use them in different ways). > Just because, say, a function name and a string are represented in memory the same way, that doesn't mean they are the same type; in particular there are many strings which aren't function names, and there are many operations (e.g. append) which make sense for strings but not for function names. This is a well-known problem, called 'stringly typing': The language is enforcing the type system it knows about, but it only knows the representation of values, not the semantics, not what it is valid to do to them at a high level. Therefore, you can defeat the type system entirely by just passing everything as strings. I brought up the idea of having layers of representation: > Length is a type of value, whether it's expressed in inches or centimeters or light-seconds is a representation, and whether it's in ints or floats or strings is another layer to the representation. You can add inches to centimeters with the right conversion, much like you can add numerical values represented ints and strings with the right conversions. The conversions just have to be at the right layer of representation. This, to my mind, means that autoconversion is orthogonal to strong typing, in that it preserves the type system if it's done in a way which converts between different representations of values with the same (or compatible) semantics. Of course, if your type system is focused entirely or almost entirely on representations, autoconversion defeats it totally. Finally, the little historical note: > Your ideas sound a lot like the original Hungarian notation, BTW: If your language-level types are representations (as in, your type system says int and float, as opposed to semantic notions like pixels-from-edge or alpha-percentage) you can encode the real type information in variable names. People mutilated this to encoding language-level type information in variable names, which is utterly pointless and potentially harmful.

rkido 9y ago

> Static typing requests you to explicitly declare types. You are confusing explicit typing with static typing. "Static" means "compile-time checking". "Dynamic" means "defer checks to run-time". Some language implementations can disable run-time type checking if optional type annotations are added, such as in Typed Racket. In other words, all the following combinations are possible: - Implicit + dynamic + strong: Python - Implicit + dynamic + weak: JavaScript - Implicit + static + strong: Standard ML without type annotations - Explicit + dynamic + strong: Elixir with type annotations - Explicit + static + strong: Java - Explicit + static + weak: C I struggle to come up with examples for these... - Implicit + static + weak - Explicit + dynamic + weak ... but I'm sure they exist, perhaps as historical languages from when type systems were less sophisticated. After all, "strong" and "weak" are entirely relative, constantly in flux, and exist on a continuum. In a couple decades, anything lacking dependent types might perhaps be considered "weakly typed".

evincarofautumn 9y ago
For explicit+dynamic+weak, I think ActionScript 3 fits the bill. The language is dynamically typed by default (an un-annotated variable has the dynamic type, “*”), but you can add type annotations, which are used to guide the implicit dynamic type conversions inherited from AS3’s ECMAScript roots. And the type system has some inherent weakness, such as the fact that the “Function” type isn’t generic: it enforces that a value is a function, but doesn’t enforce anything about its parameter types or return type.
continuational 9y ago
Java is not strongly typed; I can add an int to a String, and I can compare Apples to Oranges. It's as weak as JavaScript, just statically typed.
flavio81 9y ago
> "Static" means "compile-time checking". "Dynamic" means "defer checks to run-time" It is not really about checking, it's about allocation/binding. Static typing, for binding a variable, requires declaring the type of the data, this can be explicit (as in C++) or inferred from another value where the type was declared (as in C++ with 'auto' or as in Haskell). Dynamic typing does not require a type declaration. You can bind an unassigned variable and then assign a value later, without having to declare the variable type.