Rename TypeScript to LintScript

[calimeroteknik]

Suggestion

🔍 Search Terms

rename
typescript name
project name

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.
• This feature would be necessary to agree with TypeScript's Design Goals, and in particular:
  • Non-goal 3: Apply a sound or "provably correct" type system. Instead, strike a balance between correctness and productivity.

⭐ Suggestion

I suggest to name the project in a way that is faithful to its design goals. This is not in jest. I fear this proposal will anyhow be rejected as such.

📃 Motivating Example

• Seeing the name of the language, I thought it intended to be a type-checked language, which it is not; it only checks it partially, aka lints it.

• After reporting or actively following several issues that were closed as "won't implement", I finally figured out that TypeScript didn't actually fully intend to be a typed ECMAScript, unlike the name claims, just a linted one covering most but not all cases. Two examples of consequences of this misunderstanding which I'm not alone having: Add a --strictNaNChecks option, and a NaN / integer / float type to avoid runtime NaN errors #28682 Reduce without an initialValue should be illegal on a potentially empty array #34736

💻 Use Cases

This would make it clear for people who expect type-checked JS that they should not, and instead that it is a JS linter, because there are TypeErrors that make it to the runtime (e.g. #34736).
Indeed, "to strike a balance between correctness and productivity" is the job of a linter, not that of a static type checker, which makes no such compromise as having type errors pop up at run time.

[calimeroteknik]

To the inevitable reactions with emoji, for or against: please do provide your reasons. I believe in argumented discussion.

To show good will, I will state an argument against my proposal: it is an effort.

The question I ask is: is the effort worth it?

• It will keep away people like me who were mislead by the name TypeScript.
• It will also save the maintainers the trouble of dealing with bug reports and RFEs aiming to make the typing complete, as I mentioned.

[jcalz]

This is a bizarre quixotic take. Even if everyone agreed with your sentiments and reasoning, it would still be far too late to make such a change. I strongly suggest you close this issue before anyone from the TS team has to deal with it.

[calimeroteknik]

Why is it (far) too late?

Projects bigger than this one did change names, although I suspect never for such a reason.

I hear your sentiment that you (I think) find this futile despite my arguments that make it only at most relatively so, but why are you trying to intimidate me into retreating my suggestion?

P.S. I don't understand "quixotic" (as this proposal comes from pragmatic reasons); this is rather a Camusian take:
"Naming things wrong is adding to the world's unhappiness." --Albert Camus

As for "bizarre", I am at a loss, so I'll assume that comes from personal aesthetics.

[jcalz]

I was asking you to retract your suggestion because it's not going to happen, and I'm not inclined to spend very much effort explaining why. Either you already understand that this is not going to happen, in which case it's bad faith to pretend otherwise. Or you do not understand this, in which case the likelihood that someone outside the TS team can convince you is very low. Either way I regret saying anything.

[calimeroteknik]

I indeed do not know of any other reason it would not happen, than the one I gave: it is an effort.
This alone did not deter me indeed, not thinking it was a huge one.

The likelihood of convincing me otherwise is however very high: either provide another compelling reason, or explain that renaming the project in the way mysql→mariadb did (only the brand, not the executables) is indeed the tremendous effort I don't know it to be.

An alternative idea would be to clarify the incompleteness (linting) aspect of the project in a slogan that immediately waters down the name.

Yet another idea would be to have a --no-unsafe-types option or so, that hides type signatures which would become annotated as such, when by their very nature they would allow some runtime TypeError to happen despite static checks passing.

[nmain]

static type checker, which makes no such compromise as having type errors pop up at run time.

But that's simply not true. The spectrum of "typing" and what qualifies as a "typed language" is a very broad one. Many other languages with types, even languages that are generally referred to as "strongly statically typed", have limitations and soundness holes through which runtime errors can happen that the compiler is unable (or unwilling) to check or prove.

I did not expect the word "Type" in "Typescript" to imply that my code could never again fail, and I think many other developers would agree with me as evidenced by the popularity and longevity of the language.

[fatcerberus]

This would make it clear for people who expect type-checked JS that they should not, and instead that it is a JS linter, because there are TypeErrors that make it to the runtime

Lots of type-related errors can make it to runtime in, say, C# too. That doesn't mean we should call the C# compiler a linter.

Incompleteness is a fundamental property of type systems (and, for that matter, mathematics in general). No type system can prevent all errors while still remaining usable; you pay for it in false-positive errors.

[calimeroteknik]

No type system can prevent all errors while still remaining usable

This is indeed true if your notion of "usable" mandates Turing-completeness, IIRC.
As a counter-argument, I have never produced a program that required unconditional Turing-completeness (and I doubt you have, as well). They all fell under the slightly smaller category of https://en.wikipedia.org/wiki/Total_functional_programming (and this does not mean "looking like Haskell")

[Yokozuna59]

...or explain that renaming the project in the way mysql→mariadb did (only the brand, not the executables) is indeed the tremendous effort I don't know it to be.

I think there is confusion; mariadb is a community-developed fork of mysql; it's not renaming.

And still, I can't really see the idea of renaming, the effort needed to rename and rebrand isn't worthy. I'll list some:

• deprecate the existing typescript package and create a new one named lintscript, forcing +11M users to migrate to the new one.
• stop the development and make maintainers put their effort into changing and reviewing 50K+ files to make sure it is backward compatible, it's not a F2 shortcut to rename.
• losing issues/PRs references, users and maintainers refer to issues/PRs inside and outside the repo, when renaming, github will redirect users to 404 page.
• possibly losing and making the log unclear.

And the list goes on...

[calimeroteknik]

@Yokozuna59 Yes, the way you envision this is too brutal. Do it the mysql way… just rename the repo, keep the issues, keep the code, keep the history… that is a matter of pressing F2. Oh and keep a redirect from the previous repo so nothing breaks. Microsoft literally owns github, they can do it.

Even in my craziest dreams, I don't expect any more than having a lsc executable that allows all the iffy stuff, and meanwhile tsc will be able to take more liberties adding stricter checks, as people can always be told to use lsc if they want to take risks.

@nmain I just want to quote https://www.typescriptlang.org/ a little bit:

TypeScript is a strongly typed programming language
A Result You Can Trust
Safety at Scale
Catch errors early in your editor.

This should clearly be watered down, at the very least:

• "catch errors" should be "some classes of errors"
• "A Result You Can Trust" should be "A Result You Can Trust more than before"

[benasher44]

It's not just used for scripts though anymore. What about calling it Lint for Scripts and Programs, aka LISP?

[jcalz]

also see #9825 (comment)
and especially #9825 (comment)

[fatcerberus]

"A Result You Can Trust" should be "A Result You Can Trust more than before"

…I, um… I don’t think this issue is worth engaging with further

[RyanCavanaugh]

I've raised this up with the appropriate leadership and we have decided not to do this.