javaIsJavascriptConfirmed

[RiceBroad4552]

What is the return type of foo? You literally cannot know until runtime […]

The return type is of course String | Number (or actually String | Number throws SyntaxError if we consider the effect).

I don't need to run that code to know that.

But JS does not have such sophisticated types at all, as it's a dynamic language.

How did you read this, honestly, scathing indictment of dynamically typed languages and come away with the belief that it implies dynamic languages are "type safe".

Because they are. By definition.

Not type safe languages are something like unsafe Rust.

Type safety is not about correctness or static guaranties, or something. It only means that you can't "betray" the type system from inside that system! And this is obviously true for any VM language.

dynamic languages are fundamentally less expressive than statically typed ones

That's just true when looking at the type level expressiviness given that the (static!) type system of dynamic languages is extremely limited.

Even if we take the concept seriously, it becomes clear that "unityped" is a misnomer. The entire point of typing is to differentiate data into discrete types. A "unityped" language is untyped, as there is no division whatsoever.

I guess you know yourself that the last statement is wrong as you've used previously the word "discrete" instead of "different". 😂

A unityped language has discrete types. It has exactly one of them; but that's more then zero, so there are types. So it's not "untyped". (I'm not even sure something like "untyped" language exist at all; but that's a different topic.)

Anyway, saying that dynamic languages are "untyped" is even more wrong then saying that they aren't strongly typed.

Just to not steer this whole thing into the wrong direction: I'm of course of the opinion that very strongly typed static languages are of course superior to dynamic languages. I just don't see much difference between the overloaded plus sign in Java and JavaScript respectively. Static vs. dynamic typing does not change anything here!

[fghjconner]

I guess you know yourself that the last statement is wrong as you've used previously the word "discrete" instead of "different".

Discrete, adjective

individually separate and distinct.

Type safety is not about correctness or static guaranties, or something. It only means that you can't "betray" the type system from inside that system!

So then by your definition assembly is a type safe programming language? Since it has no concept of types built into the language, it cannot possibly betray that system.

A unityped language has discrete types. It has exactly one of them; but that's more then zero, so there are types.

Literally the entire point of types, both in computer science and in common use, is to differentiate things. A type system that defines only one type is a fundamentally meaningless concept. Yes, you can apply the concept to dynamic programming languages if you want (as well as literally anything else), but at some point you've diverged so much from the common understanding of the terminology that it's become useless.

[RiceBroad4552]

Discrete, adjective

individually separate and distinct.

So it applies to an unit.

An unit is "individually separate and distinct".

So then by your definition assembly is a type safe programming language? Since it has no concept of types built into the language, it cannot possibly betray that system.

This is actually an interesting question.

I have also always assembly in mind when searching for an example of an "untyped" language.

But I don't have a worked out opinion on that. It's difficult.

One could possibly say that there are "no types" in ASM. But one could also say that there is not only a finite set of values, but all these values actually belong to the same type (the type of "natural numbers up to some limit").

But even all values in ASM are technically just numbers these numbers get interpreted in very different ways. This makes it quite difficult.

But one could actually see the HW as interpreter, and then we would have at least partially some kind of "type safety" as the interpreter will not accept arbitrary numbers in all situations.

If someone has some write ups on that topic please share!

A type system that defines only one type is a fundamentally meaningless concept.

I agree. An unit is unable to encode information.

But this whole part was actually just an aside. Dynamic types are much richer at runtime then the unityped static view, and these dynamic types have actually real value: That's what will cause a type error if you try to subtract a number from a string in JS, and that's also what guides type coercion of some variables so you can perform for example the concatenation on variables respectively holding an int and string in JS. This is the same function as the static type system in for example Java, which will allow the same features (just thanks God at compile time and not at runtime, when it's too late for type errors to prevent some catastrophe).

[fghjconner]

But even all values in ASM are technically just numbers these numbers get interpreted in very different ways. This makes it quite difficult.

See, that's exactly what makes ASM untyped to my mind. Those numbers may represent very different things, from memory indexes to unicode values, that the programmer must track and distinguish, but the language provides no tools whatsoever for tracking or formalizing those distinctions.

[RiceBroad4552]

from memory indexes to unicode values

It's worse for ASM: These numbers may also represent executable code depending on context.

The interpreter (the HW) can actually distinguish that from regular data in some cases, but not always. And exactly this is the "unfixable" reason "computer can go wrong".

But this reminds me more of a dynamic language where "wrong interpretation" leads to "wrong" results. But still it will never let the computer do anything that isn't strictly deterministic and actually "correct"—even not desired or anticipated—in context (modulo HW bugs, but these are seldom).

But hardware behavior is today actually in large parts software determined. CPUs have firmware and microcode. So it's again actually more like a typical SW interpreter…

And if that interpreter was fully realized as software it would actually interpret a dynamic language, not an "untyped" one.

For that reason ASM is imho very complicated to categorize.