DEV Community


Posted on

TypeScript Is a Language [RESPONSE]

I just finished the 6-minute read Is TypeScript Really... a Language? by Adam Nathaniel Davis. Now his article sums it up in the last sentence. I don't know. It's probably a pointless distinction...
Thanks, short but pointless

Now I am not here to pick on Adam alone, this is a subject that angers me and I have seen argued to death. So let's see what the dictionary says. From Wikipedia "A programming language is a formal language, which comprises a set of instructions that produce various kinds of output. Programming languages are used in computer programming to implement algorithms." While this could work with my argument just fine, I want a more defined answer that should be accepted.

I here define programming languages as "A set of instructions defined with a preset arrangement of characters, grammar, keywords, and operators to get a user-defined output."

Notice I say nothing about compilers and interpreters. We will leave those as irrelevant for now. Before we explain why this is how TypeScript works, let's look at another language that got the same smack in the past. Vala.

The Vala Language

In short, Wikipedia says it is a " object-oriented programming language...", and while yes Wikipedia is imperfect, the fact people like me go on and correct every small incorrect statement, even irrelevant ones, I will consider it a good source. An article on the GNOME blog site, not endorsed by GNOME (the developer foundation behind the GNOME desktop/tools and Vala) so do not make mention of that, by Daniel Espinosa titled Vala is not a Programming Language states in short two main things. "Its “compiler” is not a compiler, is a C code generator." and "Vala doesn’t require to develop a “core library” in order to provide its features.", and this is an incorrect statement, we will get into why in a minute, but let's first compare to TypeScript.

Compare this idea to TypeScript

Now the core library idea isn't even in JavaScript. NodeJS uses the C/C++ libraries as that is where the runtime is made. Other than JavaScript for the core libs, NodeJS uses C++, Python, and C. Almost in the same way Vala uses it, except one issue. JavaScript isn't compiled, it is 100% interpreted. So using the logic used by Daniel Espinosa, JavaScript and TypeScript wouldn't be languages. Now...

Why the article is incorrect here

Add Python to that list too along with JavaScript and TypeScript, as it is the same as JavaScript just pre-developed for the desktop. It interprets with C code, using the C core libraries to make everything run. Almost every interpreted language by that logic would not be a programming language, which is not correct. Most interpreted languages use another language to run the interpreter, often using their libraries to help make development easier. The reason you take the "core libraries" from the other language is that it keeps the functionality constant. Let's even say I got this entire section here incorrect, for the sake of argument. The idea that Vala or TypeScript not being languages makes zero sense still, as programming languages have a core set of functions to even work as they do.

How Interpreters/Compilers work.

The difference between them is lightly debated, but fairly stable. We will say compilers are "Apps that translate one language into another to run after it is compiled", and interpreters are more "Apps that translate, and runs as it goes." This is why interpreted languages are always slow, compared to compiled languages. We will jump into this later however, I will get into how both work.

Basic compiler/interpreter information

Ignoring what they both do, they always have the same things. Parser, Lexer, and Assembler. Most include AST's as well, however, some might not, so we will not worry about that. However, this is the basic functionality behind Compilers and Interpreters. These give languages function. This is the case for all languages and this means that if it includes this in some form factor, it is a language. We can go deeper too.

The definitions I use

These are derived from books I read while learning to make compilers for Keter. Notice when talking about compilers I defined it as "Apps that translate one language into another to run after it is compiled", this wasn't an accident or random. So let's mention another thing Compilers do. They translate to any language to be a compiler. So a "C Code Generator", the term used to describe Vala in Why Vala Isn't a Programming Language mentioned earlier, well that is a compiler. Specifically a Vala-To-C compiler. Fun fact, not a single compiler (that I know of) translates to byte/bit code. They don't turn to 1's and 0's. Compilers target another language. The language that changed programming history in 1949: Assembly. Which form of assembly depends on the compiler and the CPU. Most often the supported versions are x86, amd64, i386, and ARMv* (v* being the specific ARM version). Each one is a different set of Assembly instructions, so something compiled on one cannot be sent to another. If we think about it, these kinds of compilers to languages to be compiled then or later with a different supported compiler makes sense as it'd only be compiled once, then recompiled with another language without having to implement all the architectures at once.

TypeScript is a language [CONCLUSION]

Back to TypeScript. In short, it is near inarguable that TypeScript isn't a language. It follows all the proper needs.

  • Grammar / Syntax
  • Functionality (through the compiler and JavaScript)
  • Compiler/Interpreter (to get the code to proper JavaScript)


I am imperfect, some of the information I use isn't 100% perfect, but this is what I currently understand. If I am incorrect in some way, please explain.

Top comments (1)

bytebodger profile image
Adam Nathaniel Davis

I'm glad to see that I've inspired some hatred!!! (Just kidding - the article's great - and I can easily handle being "targeted" with some earnest debate.)

I don't disagree with anything you've written here. In fact, I don't think I disagree with any of the wonderful feedback ("pro-language" or "anti-language") that was left on my original post.

I think there's one key item that I didn't properly communicate in my post. And, IMHO, much of this debate still glosses over this item.

I don't deeply "care" whether TS is-or-is-not a "language". I guess I'm just a little perturbed sometimes by the inconsistencies I perceive when we talk about JS-Based Technology X as a "library" or "framework" but we talk about JS-Based Technology Y as a "language". Programming is usually based upon precise ideas. Exact nomenclature. Careful definitions.

But when I hear people talk about TS as a "language", I think of at least a half-dozen other JS-based technologies that seem (to me) to fit the exact same criteria.

TS is a language??? Fine. Sure. I truly have no problem with that. But if we use the exact same set of definitions, then it seems (to me) like there are numerous other JS-based libraries/packages/frameworks that should, in fact, be called "languages" as well.

All that being said, this is far from being a subject that will cause me to lose even two minutes of sleep at night.