Hacker News new | past | comments | ask | show | jobs | submit login

There's no agreed upon definition of "strong" vs "weak" so you'll have to elaborate a bit.



The only other use I'm familiar with where strong types are used to describe the equivalent of static types, but we've made clear distinction between the two here. What other definition is there?

Usually: A strong type system does not allow types to change after being established. A weak type system allows types to change. This is also described in the original article.


C++ has casts. I don't regard those as making it a "weak" type system. I regard it as "strong type system with escape hatches", which is not the same thing. A strong type system should not be a straightjacket. (Languages that try to make types bulletproof tend to get used less than languages that allow escape hatches, and rightly so. The language designer never knows what the union of all use cases will be. Good language designers know that the user may have a case the designer didn't think of, and allow some flexibility to hopefully handle it.)


My personal notion of a strong type system is one built around function type signatures.

In order to have that, you need static typing of variables and constants, like most statically typed imperative languages have. But you also need a method to specify required input types and expected output types of all functions.

In a purely functional language like Haskell where there are only functions, and functions are first class and can be both inputs to or outputs from other functions, then the entire operation of the program is encapsulated in its function type signatures.

The entire flow of data and logic through the program can be type-checked by the compiler, and function implementations checked against their type signatures.


You can't change the type of an object in C++ so I'm not sure how your definition applies.

Generally "strong" vs "weak" typing[1] is an ill-defined an mostly useless definition.

[1] as opposed to static vs dynamic or safe vs unsafe.



Casts don't change the type of an object. They might create a new object of another type from the first one.

edit: I guess what you want to say is that implicit casts make a type system weak. But even there there is plenty of wiggle room: I think that everybody agree that implicitly converting the string "1" to an integer is bad (which is not allowed in C++). Narrowing conversions are arguably bad (they are sometimes allowed in C++), but some other implicit conversions are hard to argue against (int to long for example, or derived to base).


> A strong type system does not allow types to change after being established. A weak type system allows types to change.

For dynamic types, sure, that's a reasonable enough definition. But it doesn't really make sense for static types: they're attached to expressions in your source code, not runtime values.


>A strong type system does not allow types to change

so... like in c++?


No. C++ does allow types to change. That's exactly what casts are for.


no. c++ allows you to convert a value of one type into a value of another type (in a very limited number of cases) but you cannot change the type of an object.


How is that different from static typing?




Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: