JavaScript's popularity
At the time of writing this post (Jun 2022), JavaScript is #3 in the PYPL index, only beaten by Java and Python in popularity. In the latest Stack Overflow Developer survey, it came out as the most used language for the tenth year in a row. Being the main language for programming web applications in a connected world, it's not that of a surprise that programmers of all levels of experience work with it, both for learning and professionally.
Cover by Fiona Art from Pexels
But JavaScript is a peculiar language. Designed for running on web browsers, some people wanted to use it out of them so much that they even created NodeJS for that. JavaScript has contributed to create things like AJAX and JSON (they liked greek myths) that would still be used even if another scripting language appeared someday to replace it, something that won't happen soon. So it's clear that people love it.
Love it? When you listen and read about it, you'll quickly notice that people tend to have very strong opinions (maybe it's a common trait in developers) on this language. They either love it or hate it. And a lot of people have an opinion, just because depending on what part of the industry you work, it's just inevitable to use it daily. Yet, it is so error prone and unsafe, unless you have really consolidated good practices, that it's unbelievable that it's still a standard.
Tech-influencers
What calls my attention the most is the fact that lots beginners are so centered around it. In fact, the same phenomenon goes on with Python. Their high level, dynamic nature, makes them easy to start with. Dictionaries are primitive types, functions are first class citizens... they are just so flexible! And it's so easy to write listicles about JavaScript, 30 secs tutorials or make 3 slides explaining how great it is compared to other languages to get traffic on your posts, videos, etc.
Some tech-influencers even build their brands specifically on this kind of JavaScript content. The damage that these tech-influencers do in general is not the matter of this post, but there's something very specific that's wrong and that I've read a lot that I would like to explain.
Is JavaScript an untyped language?
If there's something new programmers hate is error messages. I guess that's why I've seen listed as one of its advantages over other languages that JavaScript produces no type errors because it's an untyped language.
This is just wrong
Yes, JavaScript raises less errors than other languages in the same context. Is this good? If the infamous "ba" + +"a" + "a" == "baNaNa" is not a red flag for you... Anyways, that's not the matter of this post either. The point I really want to make is: JavaScript is a typed language.
There was a discussion on Stack Overflow in 2015 on this topic (and I'm sure in many other sites over the years) where the top answer summarizes the problem very well. The key is what you mean as "untyped". Well, Brendan Eich himself used this term to describe JavaScript, meaning that it's not statically typed. However, one thing lots of programmers missed is that even he pointed out that the term is used differently in academia and that JavaScript, in fact, had typed values.
It's important for professionals to use standard terminology, and like it or not, "untyped" is not appropiate to describe a non statically typed language. If "untyped" already has another use: a programming language with no types; and what you are saying also has an unambiguous term associated: "dynamically typed", then the more clear and distinct option should be preferred.
Let's consider the following points:
- A programming language with types is a typed language. No matter if statically-typed or dynamically-typed: it is typed.
- Types impose semantic restrictions: type errors occur.
- JavaScript might perform almost every possible casting (this means weakly typed) to prevent this errors, but the can still raise. Examples:
null[0]undefined[0]null(1)undefined(1)1(1)
All of these operations could silence their errors with more castings, like turning null and undefined into empty dictionaries, or any non-function value to a bottom function that always returns a nullish value. But even for JavaScript that would be too much of a bad decision. Because type errors are not there to annoy you, but to help you. Type safety is a good thing.
Conclusion
JavaScript is a typed language that can raise type errors and the fact that a lot of implicit castings may be happening all the time is just a feature of the language that demands extra attention from the programmer.
Let me know your thoughts on the comments!
EDIT
There have already been several people asking the same things in the comments so I'm going to write here the answers for anyone going to ask the same things again:
- Where have you read that JavaScript is untyped?. Scroll up a bit. As I say in the post, Brendan Eich (creator of JS) uses that word to describe JS, in the SO discussion linked above there people saying the same thing, tech-influencers I don't want to promote do so too and finally some users in the comment section.
-
There are no untyped languages, that makes no sense. Using the description of untyped languages as languages without a type system (a definition used by authors like L. Cardelli or R. Harper very different from dynamically or weakly typed), untyped languages do exist.
- A lot of Turing complete formal languages are untyped, from the Turing machines themselves to cellular automata.
- Assembly languages are untyped. Some may provide syntax sugar to work with primitive typed-like values, but there is not a type system that imposes restrictions on operations based on types (in most of them).
- Some shell languages are untyped. The type-like restrictions come from subprocesses, not from a native type system.
- Pure Prolog is untyped. Without the IO stream entities, everything is a Horn clause that can be evaluated to true or false, without type restrictions.
- Some esoteric languages are untyped. Brainf*ck being the most popular, lots of languages, usually minimalistic, don't have a type system.
Yes, I know typed languages are more present in the industry (except for assembly and shell languages), but that doesn't make the distinction pointless. Remember the software industry came way much later than computer science itself and both still develop in separate streams.
-
That's not how type systems work. If you read the thread in the comments with @darkwiiplayer, you'll find that there doesn't seem to be a consensus on whether types are syntactic or semantic information, so depending on the sources you use, all this will make sense or not. The paradigm I'm adjusting to is that types are semantic information, not syntactic. It's a complex topic so instead of elaborating further I'll link some references.
- L. Cardelli & P. Wegner (1985) On Understanding Types, Data Abstraction, and Polymorphism (PDF)
- R. Harper (2016) Practical Foundations for Programming Languages (2nd ed.) (PDF)
- Is type-checking "syntactic" or "semantic"? Computer Science Stack Exchange (link)
To be fair with the opposite paradigm, here's their reference too.
- H. Geuvers (2019) Introduction to type theory (PDF)
Thank you to all those who have participated in the comments!
Recommended reading
Let's connect!
Top comments (45)
JS has types and the simplest proof is the existence of the
typeofoperator. Still, if someone says JS is untyped, I'll know what they mean and won't do a "well akshually ..." because it's unproductive and pedantic.You have to be careful. Being too accepting of "you know what I mean" can easily cascade over time into communication that is so ambiguous that it is useless.
Like it or not, as software developers we have to communicate effectively with our colleagues and machines. With machines for the most part we stare at a syntax error or unit test run time error (if we're lucky) when we are imprecise or plain wrong.
The presumably self-correcting nature of communication among colleagues is at best unreliable. Too many times I've seen two parties agreeing with one another simply because they were hearing what they wanted to hear, not what was actually being said.
This is why for example in DDD ubiquitous language is so important.
So the trick is to correct in the service of keeping communication as accurate as possible without being pedantic about it and being tolerant of the fact that at times we all make mistakes.
Just yesterday in the context of JSX I was talking about markup 🤦.
There's no avoiding misunderstandings, they can happen regardless of how precise your language is. There are times when correcting someone can be beneficial, and other times when you're just telling them things they already know, not doing anyone any good, and looking pedantic. Ultimately, that's a judgement call based on the unique circumstances of the situation. If someone says "JS doesn't have types", I think it's extremely likely that they are in fact aware that JS has strings, numbers, null, and undefined. There may be times when launching into a detailed explanation about it is helpful, but most of the time it's probably not.
I think there's also cultural issue; "correction" as a means asserting superiority but I think we need to move beyond that.
And perhaps in lieu of a "detailed explanation" sometimes it may make more sense to ask some questions in order to establish whether certain assumptions are actually shared.
You're right. Just notice that my problem arises when some people are telling beginners that there are no type errors in JavaScript and that's a good thing.
Types are more than just "you can't multiply text with a number". Javascript has exactly one type: "any".
EDIT: I also want to point out that JS could have no casting whatsoever and it would still be an untyped language. Say, for example, you have this pseudo-code in some JS-like language:
Say addition is only defined on numbers and you can only print text. Without any conversion, that would result in a runtime error for any imaginable input value. But can you point out the type of
valuein this code? That's why it's untyped.Any error in JS is a runtime error, naturally.
What you're saying is that the only way a language can be typed is if it's a compiled language with all of the type info known at compile time.
Which leaves you with like... three programming languages or so.
You can trivially write code similar to your example in both C and Java, with the same runtime error. Not because they're untyped, but because their type system is unsound, which is, to me, a wholly different can of worms.
Could you elaborate? What else are types supposed to be? As far as I understand, types are semantic information attached to values (all values, not only variables) that determine in what context they can be used.
If you mean that any variable can have any type... wouldn't that be precisely talking about just a little part of what types are?
Btw, I'm sure you know in JS you can multiply text and numbers (results in NaN, but you can).
No. At least not in the strict sense. Types are syntactic information attached to expressions.
In the less strict sense, types are... yes. All languages general purpose are necessarily "typed" because you just can't get any work done if you can only ever support one kind of value. But that's not what people talk about when they say a language is typed or untyped, because it'd be a pointless distinction.
Yes, as I mentioned, that was a hypothetical JS-like language to illustrate my point (
printisn't a thing in JS either)I think the strict sense would be interpreting types as semantic information. Expressions can't have a type attached as syntactic information precisely because of polymorphism. Something that's present even in statically typed languages.
Consider C++ for example, that has multiple inheritance and where inheritance behaves as subtyping. You might know at least one type of a value thanks to it being statically typed, but if a you can have an undefined number of types attached to a value at any time, how can you say that the other types are syntactic information? To say that those types are not relevant... is to talk in a less strict sense.
A pointless distinction... depends on the context too. There are languages without type systems, that may or not be general purpose, but that still need to be called "untyped" and don't fall in the same category as JS.
It seems you're fundamentally misunderstanding what types are, because being attached to expressions is exactly what they're all about. You can compute the type of any expression at compile-time simply by looking at its components.
If you have an expression
f(a)and you know thata : Aandf : A -> Bthen you know that the result type of that expression isB.Javascript does this too, in a sense, except that there's only one type, so any program is valid by default.
C++ is a rather bad example because the inheritance complicates things quite a bit. Being a good object-oriented language comes with the side-effect of making it a not-so-good typed language.
Types are not necessarily inferred at compile time, in fact that's what dynamic typing means.
Object-oriented languages are perfectly valid from type theory perspective and inheritance has been formalized more than once [a][b 6.1].
Expressions can have types attached in the sense that they are evaluated to a value, which has type. But when that evaluation doesn't depend on the structure of the parsed phrase, then the expression hasn't a type per-se (
3 + 4has a valuea + bno). Edit: Function overloading is a perfect example for this.A similar discussion on this one.
OK, using that notation
AandBsimply look like parameterized types which simply express type constraints, not full-blown types.The thing is there is no "compile-time" with JavaScript. It's V8 that uses just-in-time compilation (Sparkplug, TurboFan) but that's just an implementation detail.
After a quick online search I have to come to the conclusion that 'untyped' is a pointless term just like 'weakly typed' or 'strongly typed'. Without a clear definition people just assume that their interpretation is the correct one, leading to endless, pointless debates.
Can't agree there.
anyis simply TypeScript's way of throwing its arms up in the air when it doesn't know what is going on. JavaScript has clearly documented types:(
nullwas introduced as a primitive value to represent the absence of an object for a Java interop bridge—it really shouldn't exist)An actual
anytype would be something like a Visual Basic Variant and JavaScript doesn't have anything like that.All values in JavaScript have a type. The issue with dynamic typing is that the resulting type of any expression or (variable) name is only computed at runtime rather than statically analysed at design time.
Conceptually everything in JavaScript it late bound however for the sake of performance V8 may JIT some of the unproductive late binding away when it can get away with it.
That's not entirely true; almost all modern scripting languages have some sort of compilation step that turns the source code into some sort of (virtual) machine code.
I'm not aware of any language that's directly interpreted and has a proper type system, but if such a thing existed, you could just replace "compile time" with "parse time" and the statement would still be work.
I think that's kind of what's happening here. But I still think my statement holds true: there's not much of a point in distinguishing "typed" and "untyped" languages when "typed" just means the VM tags its values and keeps track of their "type" at runtime. By that definition, untyped languages just don't make sense unless we're talking about DSLs or esolangs.
Depends on how you define types. Using a loose definition, that may be true. But then, once again, you end up at every language in existence being typed, so the whole categorisation becomes pointless.
In a stricter sense, no, JavaScript has exactly one type. Whether you call this "any" or something else doesn't really matter, but since "any" is what most languages use for a union of all types, that's what I called it. (Some might say union types shouldn't exist at all, and to be honest, I'd even agree with that to some extent.)
Values. Don't. Have. Types. That's just not what types, strictly speaking, in the sense of type theory, are. And again, I'm okay with calling them "types" in a broader sense, but then we end up back at all languages are always typed. I call them types too, when the context makes it clear what I'm talking about, but really, they're just tagged values. You can't type-check a JS program. Or rather, you can, and it's always valid, because there is only one type.
So in summary: There is two ways we can define "type".
In the strict sense, types are decided during compile (or parse) time, and languages are either typed or untyped. Untyped languages can technically be considered typed languages where every expression has the same type.
In the broader sense, types are just information about what kind of thing a value represents, and can be handled either by compile-time type checks or by run-time value tagging. In this sense, all languages are typed, but some are statically typed, while others are dynamically typed.
And lastly: Anybody arguing in good faith will normally use "typed" and "untyped" only in the context of the first definition, because that's the only way for the definition to make sense.
Calling JavaScript a "typed" language according to the second definition is technically true, but a) adds no value whatsoever and b) should be accompanied by an explanation pointing out that this definition is being used.
So yea, Javascript is an untyped language. It's also dynamically typed. But it definitely isn't typed.
That really is just an opportunistic optimization for dynamic languages that should have no bearing on the type system.
TypeScript cannot safely type all of JavaScript. That is evidence that there are circumstances where the exact types only emerge at runtime.
In fact statically typed languages implement polymorphism with late binding, so they don't even know the exact type at "compile time", only the type constraints that have to be satisfied at runtime.
For me the discussion revolves around the common misconception that dynamically typed languages do not have types; that only statically typed languages have types. There's the common oversimplification that the lack of type declarations implies the absence of types which is simply not true. (The illusion that static typing automatically implies total type safety is a separate discussion).
I'm not familiar with a definition of types where JavaScript's data types would not classify as types.
anyis one of TypeScripts two top types.The top types
anyandunknownin TypeScriptIn many ways
unknownis the more accurate top type. Just because a type isunknownat design time doesn't imply that a value won't have an exact type (which could be the wrong type for what you are trying to do) at runtime.I still don't see that the argument that one of TypeScript's top types is JavaScript's only, singular type holds any water.
Oh boy … sum types
Is this what you are talking about: "You can say that 'Type' is the data type of the expression used at compile time."
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'.
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.
The confusion wasn't about whether or not JavaScript is compiled (it depends).
There it is …
Again, really? If you are a pure mathematician perhaps.
But as software developers and engineers we are more interested in the runtime behaviour even if we like to have some compile time assurances.
If I was given that for review I would edit it to:
"JavaScript has types".
Stating "JavaScript is typed" sets certain expectations it cannot live up to. The issue is that "JavaScript is untyped" implies the absence of "type-equivalent behaviour" at runtime which is not true.
JavaScript is dynamically typed. The term "dynamically typed" implies that types can in fact exist at runtime. I'm not touching "untyped" with a ten foot pole.
Thanks for elaborating.
@darkwiiplayer could you please refer me to where hve you learned about types? The books on PLT I've read all consider types semantic information. I understand you don't agree with that definition, so I would appreciate if you could share with me where are you getting yours from. Thanks for your elaborated responses, truly!
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!
I'm sorry, but this feels totally like a strawman argument. Whoever said that JavaScript is "untyped"? Whoever said that ANY language is "untyped"?? In fact, what in the heck are you even referring to when you say "untyped"??? I've never heard of such a thing. There are strongly-typed languages. And there are dynamically typed languages. But every single language I've ever heard of has types.
Please read the whole post and other comments. Thanks for your comment.
While I really appreciate the condescending reply, the simple fact is that I did read the whole post. And I don't need to read all of the comments before I supply my own comment.
I'm sorry, Adam, some answers to your questions are in the post, so I thought you didn't read it. Answering your questions:
Lots of people classify Javascript as untyped, from people in this comment section to people in the linked SO discussion and Brendan Eich himself (which I mention in the post).
Lot of computer scientists have talked about untyped languages, that don't have a type system, and some examples are found in formal languages like Turing machines, to some shell languages, assembly languages, esoteric languages or pure logic languages, where the absence of type restrictions makes them fall in the untyped category.
Strong, weak, static and dynamic are terms applicable to languages with a type system, so when a language just lacks one, they don't apply.
I hope to have answered your questions.
About the strawman, I guess I just had bad luck to stumble upon people that you have not, saying things that made me write this. No need to invalidate my point.
"Mmmmmmmmmmmm"
This may be useful for future reference:
"Scheme is dynamically typed. The lack of a type system means that we don’t have to spend energy on finding and explaining type errors with the same care with which we explain syntax errors. Better yet, when we use Scheme to teach design principles we can informally superimpose a type system and use the types for program design."
The Structure and Interpretation of the Computer Science Curriculum (2004)
i.e. the actual message is that dynamically typed languages are typically designed with a certain level of "type leniency" (for resiliency) which reduces the number of type errors the learner is faced with.
That's very different from "no type errors".
PS: It's interesting that it is a commonly held belief that statically typed languages are better for beginners given the additional guardrails that static type analysis can provide.
However it seems that dynamically typed languages may be better because REPL-driven programming provides a much more fluid feedback loop than the usual edit-compile-run loop can.
Thanks for your comment and support in general, @peerreynders. I've bookmarked several links you already shared, it's useful material.
Thanks again and sorry for the late reponse!
JavaScript has types, but instead of trying to make type safety a priority and throw TypeErrors every time when they don't add up (and not only if you try to use them in cases when they cannot be coerced), it aims for robustness. If you know the rules of type coercion, you can make them work for you.
Exactly. That's part of what I mean to say.
Thanks for your comment!
I want to add, that js in fact has many typesystems.
Although I'm talking about vanilla JS, I guess you could talk about extended versions of the language, using other frameworks and utilities.
Thanks for commenting!
If that’s your definition of a typed language, ok. I’ll take typescript any day….
That's the definition you'll find in PLT books and papers. TypeScript is definitely worth taking, sounds great.
Thanks for your comment!
I don't understand why to write this post. AFAIK there are no untyped languages. There are no such things. Every language has types. Maybe except some esoteric languages like BrainF*ck. They can be static or dynamic but they're always there.
Primarily because there's a certain sloppiness in the current discourse.
I've seen people repeatedly talk about TypeScript being "strongly typed" when they (as you have correctly observed) should state "statically typed".
Erlang for example is a strongly typed language but it's also dynamic.
This is what the article is all about.
Lets get the terminology straight so that we can all communicate in a more precise and effective way.
Please, read the whole post.
About untyped languages: some shell scripting languages are untyped (type-like restrictions come from subprocesses and not from a native type system), some esoteric languages are untyped, assembly languages are untyped, pure Prolog is untyped, Turing machines are untyped. There might be other examples I don't know personally.
Thanks for your comment.
Is there an actual accepted definition of 'untyped' somewhere or is it one of those terms that only carry meaning within a very specific context?
My main references for the subject are Programming Language Theory textbooks written by L. Cardelli or R. Harper. They and other authors (I would need to check again the bibliography for the names) use 'untyped' to refer to languages where values have no types, or a single type, and therefore don't apply type restrictions of any kind.
I only know one formal name "untyped lambda calculus". But only because there is typed lambda calculus. So obviously normal lambda calculus is untyped.
Assembly have strings (sequance of ASCII characters) and numbers so I don't think it's untyped unless you treat strings are sequence of bytes that are numbers. Prolog probably is untyped since it only have sentances and words.
I was mainly refered to modern languages that are commonly used. No one will compare JavaScript to Prolog or Shell language.
Assembly is not a language, it's a family of languages, and the ones that use characters and numbers, do it as syntax sugar, but in the end don't have a type system that imposes restrictions on how you operate them, so they still adjust to the definition of un typed languages.
Shell languages are modern, thousand of developers use Bash daily.
And that of no one will compare that languages, it depends. I personally have seen comparisons between all kind of languages that I have found relevant. "Modern languages" is something really, really unspecific.
Such a nice and interesting conversation here in the comments, thanks for provoking that @miguelmj 👍
Thank you for reading! ❤️
Were did you get the definition of Javascript to be an untyped language?
I believe the official definition is it has dynamic types (is weakly typed).
Please read the whole post. Thanks for your comment.