Hacker News Reader

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

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.

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.

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

I'm no expert on type systems so my definitions are not meant to be theoretically correct, just to describe the practical implications of static and dynamic typing.

What you're talking about seems to be more related to how type systems are implemented, i.e. that dynamically-typed languages are "unityped", such as the one and only "static type" of Python being the PyObject. Thus, when you "bind an unassigned variable and then assign a value later", you're actually implicitly declaring the type to be PyObject.

But it is deceptive to define type systems purely in terms of this implementation detail, because then it would appear as if dynamically-typed languages are untyped (i.e. "everything is one type" is the same as saying "there are no types"). Since we know languages like Python do some type-checking at run-time despite everything being a PyObject, it is more useful, I think, to think of these languages in terms of the practical result rather than in terms of the implementation.

But if that's not what you're saying, I apologize.

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

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

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.

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

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

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.

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.

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