TypeScript cannot safely type all of JavaScript. That is evidence that there are circumstances where the exact types only emerge at runtime.
Yes, which is why I've lately started agreeing with the idea that union types (and other concepts of set theory applied to type theory) might just be a dumb idea.
For me the discussion revolves around the common misconception that dynamically typed languages do not have types; that only statically typed languages have types.
Then you're arguing based on the broader idea of what types are, which, as I pointed out, means that all languages do, to some extent, have types, so the whole concept of "typed" language is pointless, as there is no real example of an actual "untyped" language by that definition, other than possibly the occasional esolang.
I'm not familiar with a definition of types where JavaScript's data types would not classify as types.
A "type" in type theory has a role similar to a "type" in a programming language: it dictates the operations that can be performed on a term and, for variables, the possible values it might be replaced with.
Or from the introduction of the paper I linked above
Types are not sets. Types are a bit like sets, but types give syntactic information, e.g. [maths omitted] whereas sets give semantic information, e.g. [more maths omitted]
any is one of TypeScripts two top types.
any is just the unfortunate consequence of a typed language interacting with an untyped language and having to somehow figure out how to transfer untyped data into its type system. It also leads back into what I said above: Union types bad.
I still don't see that the argument that one of TypeScript's top types is JavaScript's only, singular type holds any water.
I find it plainly obvious. let foo What is the type of foo? Regardless of what you want to call it, whether "any" or "unknown", the fact remains: It's the one and only type that all expressions in javascript can have. There is no imaginable scenario where foo = bar would give you a syntax error because the types of foo and bar do not match.
It would have been a lot faster to state that types only exist at compile time by virtue of which any language that isn't statically analysed and compiled is automatically 'untyped'.
That is what types are. More precisely, I've been arguing this whole time, and I've said this repeatedly, that this is the stricter of two definitions that are commonly used in programming. It's the definition we get from type theory, which is still the predominant definition of "type" when talking about functional languages.
My two points here are:
This is the only definition of the two that needs to be considered, as the word "typed" holds no value under the other, broader definition.
According to this definition, JavaScript is, no matter how you look at it, an untyped language.
The core of the discussion really is that those ones and zeros exhibit behaviour that is consistent with being "typed" by virtue of the rules enforced by the runtime engine.
And as per 1., this applies to all programming languages, therefore all programming languages are typed, so we might as well never use that word again. Except most people usually understand that when distinguishing between typed and untyped languages, we're specifically talking about the kind of types we get from type theory, which can be statically analysed, where we can determine the type of an expression without running into the halting problem. And by that definition, see 2.
The confusion wasn't about whether or not JavaScript is compiled (it depends).
Again, this is a minor issue in phrasing. I say "compile time" because that's when most languages, including most implementations of JavaScript, would have a chance to do static analysis before running the code. It would have been more correct to phrase it as that: static analysis, but as I pointed out, that's a minor nitpick and easily fixed by replacing a single word.
Again, really? If you are a pure mathematician perhaps.
Again, what's the point? Sure, you can use the word "typed" in the sense that values can be classified at run-time, but at that point you're just not saying anything. It's like calling water wet. It's not wrong, but it just adds no value.
If someone tells me "That desk looks really solid", my first response (usually) won't be "Of course, did you expect it to be liquid? All desks are solid, duh!". Yes, that would be a completely valid way to interpret the sentence. But in context one just rules it out because it's obvious, so we assume the word must mean something else in this case.
This is why I don't get how someone, arguing in good faith, can point out that JavaScript is a typed language. Yes, it has values that do things, I knew that.
The issue is that "JavaScript is untyped" implies the absence of "type-equivalent behaviour" at runtime which is not true.
Is there any language where this isn't the case? Outside the realm of possibly some niche DSLs or esolangs that people came up with for fun, is there any language that neither has a static type system, nor some sort of distinguishing different kinds of values at runtime? Even languages that cast types around whenever remotely possible often offer some way of querying the type of a value.
So yea, back to 2, no programming language is untyped. By establishing this, we've gained absolutely nothing. Just like how pointing out that JavaScript is statically typed, because it has a single type that represents a tagged value doesn't really help us either.
JavaScript is dynamically typed. The term "dynamically typed" implies that types can in fact exist at runtime.
Yes. In so far as the word "solid" implies that a desk can be made of water. The term "dynamically typed" only underlines my point: There are two definitions of types being conflated here. And by one of them, all languages are typed, so we need to distinguish how they are typed.
All in all, I really feel like I need to repeat this core point:
There are two different definitions of what a "type" is.
The distinction between "typed" and "untyped" only makes sense with one definition.
The distinction between "dynamically" and "statically" typed only exists with the other definition.
Using the terminology of one with the definition of the other is pointless, confusing and dumb.
And lastly:
JavaScript is both typed and untyped, depending on what definition you use.
Neither claim is wrong, but only one conveys any actual information.
Thank You for your explanation which establishes the context from which the statement "JavaScript is untyped" makes sense.
This is why I don't get how someone, arguing in good faith, can point out that JavaScript is a typed language.
My interpretation of this article is that it is trying to address the case where the statement "JavaScript is untyped" is made while the not having the strict definition of "types" as you present it (and people reading and running with it).
I personally stick with statically and dynamically typed for practical reasons but all too often come across dubious uses of "weakly typed" and "strongly typed" where "untyped" isn't being used to state "without static analysis" but to imply so fundamentally unreliable, it might as well just be operating on a sea of strings.
Michael Feathers
@mfeathers
Amazing then that Erlang (a dynamically typed language) can give you better reliability than we have in most other systems. I like static typing but it obviously isn’t necessary for quality. twitter.com/knocte/status/…
12:19 PM - 05 Nov 2018
Andres G. Aragoneses⚡️
@knocte
@mfeathers dynamically typed is already a bad design: it's a can of (worms) potential irrecoverable runtime errors in itself
Erlang is a great example of this that exists purely in software. Its design is oriented toward making failure inconsequential (in a dynamically typed language no less).
08:11 AM - 11 Aug 2021
There seems to be an ongoing oversimplification
statically analysed = safe and correct (e.g. type safety)
dynamically typed = absolute garbage
My position is that I am constantly thinking in "types" even when working with a dynamically typed language.
Michael Feathers
@mfeathers
I like the idea of types as a thought tool more than I like type systems.
Thanks for the link. I'll take my time to contrast that with my own and try to contextualize how and when the each terms appear. Thanks once more for the discussion!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If it's the one I remember, then this gives a pretty good introduction to the concept.
I'm also aware that the HoTT book would be a much better source on this, but alas, that's still on my reading list; but I still wanted to mention it.
Yes, which is why I've lately started agreeing with the idea that union types (and other concepts of set theory applied to type theory) might just be a dumb idea.
Then you're arguing based on the broader idea of what types are, which, as I pointed out, means that all languages do, to some extent, have types, so the whole concept of "typed" language is pointless, as there is no real example of an actual "untyped" language by that definition, other than possibly the occasional esolang.
An example would be the one found on wikipedia:
Or from the introduction of the paper I linked above
anyis just the unfortunate consequence of a typed language interacting with an untyped language and having to somehow figure out how to transfer untyped data into its type system. It also leads back into what I said above: Union types bad.I find it plainly obvious.
let fooWhat is the type offoo? Regardless of what you want to call it, whether "any" or "unknown", the fact remains: It's the one and only type that all expressions in javascript can have. There is no imaginable scenario wherefoo = barwould give you a syntax error because the types offooandbardo not match.That is what types are. More precisely, I've been arguing this whole time, and I've said this repeatedly, that this is the stricter of two definitions that are commonly used in programming. It's the definition we get from type theory, which is still the predominant definition of "type" when talking about functional languages.
My two points here are:
This is the only definition of the two that needs to be considered, as the word "typed" holds no value under the other, broader definition.
According to this definition, JavaScript is, no matter how you look at it, an untyped language.
And as per 1., this applies to all programming languages, therefore all programming languages are typed, so we might as well never use that word again. Except most people usually understand that when distinguishing between typed and untyped languages, we're specifically talking about the kind of types we get from type theory, which can be statically analysed, where we can determine the type of an expression without running into the halting problem. And by that definition, see 2.
Again, this is a minor issue in phrasing. I say "compile time" because that's when most languages, including most implementations of JavaScript, would have a chance to do static analysis before running the code. It would have been more correct to phrase it as that: static analysis, but as I pointed out, that's a minor nitpick and easily fixed by replacing a single word.
Again, what's the point? Sure, you can use the word "typed" in the sense that values can be classified at run-time, but at that point you're just not saying anything. It's like calling water wet. It's not wrong, but it just adds no value.
If someone tells me "That desk looks really solid", my first response (usually) won't be "Of course, did you expect it to be liquid? All desks are solid, duh!". Yes, that would be a completely valid way to interpret the sentence. But in context one just rules it out because it's obvious, so we assume the word must mean something else in this case.
This is why I don't get how someone, arguing in good faith, can point out that JavaScript is a typed language. Yes, it has values that do things, I knew that.
Is there any language where this isn't the case? Outside the realm of possibly some niche DSLs or esolangs that people came up with for fun, is there any language that neither has a static type system, nor some sort of distinguishing different kinds of values at runtime? Even languages that cast types around whenever remotely possible often offer some way of querying the type of a value.
So yea, back to 2, no programming language is untyped. By establishing this, we've gained absolutely nothing. Just like how pointing out that JavaScript is statically typed, because it has a single type that represents a tagged value doesn't really help us either.
Yes. In so far as the word "solid" implies that a desk can be made of water. The term "dynamically typed" only underlines my point: There are two definitions of types being conflated here. And by one of them, all languages are typed, so we need to distinguish how they are typed.
All in all, I really feel like I need to repeat this core point:
There are two different definitions of what a "type" is.
The distinction between "typed" and "untyped" only makes sense with one definition.
The distinction between "dynamically" and "statically" typed only exists with the other definition.
Using the terminology of one with the definition of the other is pointless, confusing and dumb.
And lastly:
Neither claim is wrong, but only one conveys any actual information.
Thank You for your explanation which establishes the context from which the statement "JavaScript is untyped" makes sense.
My interpretation of this article is that it is trying to address the case where the statement "JavaScript is untyped" is made while the not having the strict definition of "types" as you present it (and people reading and running with it).
I personally stick with statically and dynamically typed for practical reasons but all too often come across dubious uses of "weakly typed" and "strongly typed" where "untyped" isn't being used to state "without static analysis" but to imply so fundamentally unreliable, it might as well just be operating on a sea of strings.
There seems to be an ongoing oversimplification
My position is that I am constantly thinking in "types" even when working with a dynamically typed language.
Thanks for the link. I'll take my time to contrast that with my own and try to contextualize how and when the each terms appear. Thanks once more for the discussion!