Python and PHP both have type hints that are natively ignored by the language if present, but can be checked if you have enough of them, if that's what you mean.

No, I mean it lacks strong typing. C and C++ also lack strong typing even with static typing being a core feature and checked at compile time.

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.

How is that different from static typing?

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

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

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.

What about with type conversion?

https://en.cppreference.com/w/cpp/language/explicit_cast

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.

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.

C++ lacks strong typing? I'm curious what the type system is missing to qualify.

Or do you mean that the C-based escape hatches like casting pointers make the type system inherently weak? You don't have to use them though...

You don't have to make type errors either :-)

Sure. But you have to deliberately use a cast; people rarely make deliberate type errors.

C++ has chosen a special place in the hellscape of language design by allowing you to silence the compiler using casts, where almost anything you do with the resulting object is undefined behaviour no diagnostic required.

Said UB is observationally indistinguishable from miscompilation under some toolchains under some optimisation controls.

It also has various bolt on weirdness like const doesn't mean the thing won't be changed by some other pointer so you can't constant propagate based on it, unless it's written on the global, at which point attempts to mutate it anyway may succeed under the usual UB challenges.

Maybe that's a "strong" type system, but you'd only define it like that if you started by taking C++ as axiomatically reasonable.

Static typing is already quite a help, as it makes whole categories of errors compile-time errors.

> I'd like to see Javascript die in the fiery pits of hell as much as the next guy

Part of the problem is that some of those "next guys" don't have the experience and/or vision to realize that it needs to die. Perhaps we should emulate Cato in our subsequent HN posts:

And furthermore, I consider it necessary that Javascript be replaced with WebAssembly so that we can use well-designed languages in the browser.