[orange8]

I'm not a myth. Some of us started JS programming over a decade ago, with no strong typing and IDE to hold our hand and tell us every time you make a mistake. The key is just discipline, good design patterns and a good linter.

I see TypesScript as a VERY opinionated linter that affects how you think and write JS. JS is a dynamically typed language, which means you loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns. Yes, I get it, many programmers think best and are most productive using strongly typed languages, but for those of us that can think dynamic or both, TS just gets in the way.

>> Do they just magically decipher what interface an argument conforms to?

This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply.

>> What methods are accessible on a returned result from any random library they're using?

Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.

[giantDinosaur]

I don't even get this criticism - the problem with Typescript is that it's far too easy to bypass the type system and allow the dynamic parts of JS to do whatever you want. You can lie about your interfaces all day and <any> to your dynamic heart's content.

For what it's worth, my experience with programmers who think like you is that rarely they're actually genuinely talented and right, and mostly they just spew forth bugs which often sit dormant until they rear their ugly heads years later. Most people are better off thinking about their API's before they implement them, much like one would do in a real engineering discipline. Types are often (and yes, not always) a good way to draw the effort out to the front of your process.

[orange8]

Wow! What a mature, thoughtful response \s

Only the first and last sentences actually addressed the topic, the rest was just an angry emotional attack on those who think differently from you. Hope you're feeling better now.

[DonHopkins]

\s and not /s? I didn't realize there was such a thing a reverse sarcasm. Or is that some new fangled TypeScript string escape character?

[orange8]

\s or /s Dont care. Small minds, small arguments. Atleast you're consistent that way

[DonHopkins]

It's kind of funny how you boast that you don't want any hand holding from the compiler or IDE, yet you proudly proclaim and demonstrate that you're careless about syntax, spelling, and punctuation. And how you sarcastically complain about immature thoughtless responses, yet you're insulting and patronizing. ;) At least you're consistently self contradictory.

[orange8]

LOL!! |s

[boomlinde]

> Explore languages that follow different paradigms, where interfaces just don't apply.

Interfaces as a general concept applies whether there is a type system to ensure that they are satisfied or not. Do you have function parameter lists? Do you have expected shapes for function inputs and outputs? Do you have distinct types? Then you have interfaces. Your shit breaks when they aren't conformed to. It has nothing to do with strong typing or object orientation. Strong, static typing is just a way to ensure at compile-time that the expected interfaces are satisfied.

> Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.

Hearing this assurance from someone who just complained about their jenga tower of tooling causing issues, I'm not convinced.

[orange8]

> Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.

>>Hearing this assurance from someone who just complained about their jenga tower of tooling causing issues, I'm not convinced.

It wasn't me. Maybe a TypeScript compiler will help you correctly follow the comment threads? ;)

[orange8]

>> Then you have interfaces.

Not really. My definition of a language feature is something the compiler supports and checks for. JS does not have interfaces. What you're talking about are patterns and best practices, so you're getting there...

JS is a dynamic language. Just deal with it already... you sound smart enough to support both paradigms at the same time in your head.

[boomlinde]

> Not really. My definition of a language feature is something the compiler supports and checks for. JS does not have interfaces.

It doesn't matter what your definition of a language feature is. The person you responded to was obviously talking about interfaces in the general sense of the word and was asking a question about it.

> What you're talking about are patterns and best practices, so you're getting there...

Nope, what I'm talking about is interfaces. The nature of function signatures as interface points is not a matter of patterns and best practices. They simply are exactly that, whether it's spelled out for you or not.

> JS is a dynamic language. Just deal with it already... you sound smart enough to support both paradigms at the same time in your head.

This doesn't constitute an argument or an objection to anything I've said. It presumes that I won't "deal with it" when there is no evidence that I'm not. It supposes that "support[ing] both paradigms at the same time", whatever that means, is a matter of my intelligence. It doesn't argue for any of this.

[orange8]

> It doesn't matter what your definition of a language feature is. The person you responded to was obviously talking about interfaces in the general sense of the word and was asking a question about it.

Really? So now this has devolved into a debate about semantics? I thought this was about JS and TS, not the "general meaning of interfaces". Using that way of thinking, even HTML and CSS have interfaces. Arguing over semantics is a very common tactic by the way, if you just want to win a debate for arguments sake. Let us keep it specific. My point is JS, as a functional language does not have or even require many of the features and constructs of a strongly typed OOP language, interfaces being a good example. The inverse also applies.

Different programming paradigms = different patterns and best practices

>>Nope, what I'm talking about is interfaces. The nature of function signatures as interface points is not a matter of patterns and best practices. They simply are exactly that, whether it's spelled out for you or not.

Are you saying an interface is a function signature and is this what you mean by interfaces in general?

>>This doesn't constitute an argument or an objection to anything I've said. It presumes that I won't "deal with it" when there is no evidence that I'm not. It supposes that "support[ing] both paradigms at the same time", whatever that means, is a matter of my intelligence. It doesn't argue for any of this.

My responses do not have to be blow by blow objections to every single point you make. This is a discussion, not a computer program. And I stand by the sentiment: for optimal results, think functional when working in a functional language.

[boomlinde]

> Really? So now this has devolved into a debate about semantics?

You just reasoned on the basis of your "definition of a language feature" that I am wrong. Don't blame me for turning it into a discussion about semantics.

> I thought this was about JS and TS, not the "general meaning of interfaces". Using that way of thinking, even HTML and CSS have interfaces.

It is about JS and TS. A poster asked, about JS developers, "Do they just magically decipher what interface an argument conforms to?". There is a reasonable answer to that, and it isn't "This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply", which doesn't answer his question and instead assumes that the poster simply hasn't explored languages that for some unargued reason will change his question.

Obviously he is not talking about interfaces as a language feature, since he acknowledges that JS doesn't have explicitly defined interfaces.

You yourself have been talking about library APIs. I'm sure you know what the I stands for.

> Are you saying an interface is a function signature and is this what you mean by interfaces in general?

I am saying that they are interfaces. I am not saying that function signatures constitute the entirety of interfaces in general, and I'm not sure what I wrote that makes you even ask that question.

> My responses do not have to be blow by blow objections to every single point you make. This is a discussion, not a computer program.

It's a discussion, and I participate to discuss things, not to hear you tell me to "deal with it". But sure, I can't stop you from participating on whatever basis you prefer. I just want to point out that I get absolutely nothing out of it, so if you're writing that for my sake you can stop.

> And I stand by the sentiment: for optimal results, think functional when working in a functional language.

This is not about functional vs. non-functional. It's about JS and TS, as you've pointed out yourself.

[inertiatic]

>This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply.

I'm not sure whether you intended this to sound so patronizing, but wow. What languages should I explore while talking about Javascript?

You are called to edit a function that takes 2 arguments:

function handle_req(request, options):

What is request in this context and what is options?

What makes me more productive, going up the stack and seeing who might call this function and with what argument, or instantly knowing what the domain of values it operates on is and being able to treat this as a separate unit?

>Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.

A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen?

Okay.

[danShumway]

> that will ensure that these situations no longer happen?

Well... but Typescript doesn't ensure those situations won't happen, ironically because it's a superset of Javascript and it's not strict enough. Typescript is just documentation that compiles. If a library has bad documentation, it's likely to have bad Typescript as well, and bad Typescript can be a giant curse.

Typescript will happily allow you to force a typecast that doesn't reflect reality -- it will happily allow you to say that a method always returns a string when sometimes it returns a number, and it will happily compile in those scenarios.

Tracking those bugs down are a giant pain. I don't hate Typescript, but people who look at this and think, "I don't have to care about what libraries I'm using, I can just trust the interface" are fooling themselves. I've debugged plenty of errors in Typescript code that ended up being the result of me trusting an interface that didn't reflect the reality at runtime.

There's value in Typescript for some projects, but it does not remove the need to be careful about documentation and dependencies, because it's so easy for both dependencies and downstream code to circumvent the protections Typescript gives you.

[Udik]

> it will happily allow you to say that a method always returns a string when sometimes it returns a number

Just replace "say" with "assume" and you have the javascript situation: javascript is just typescript with documentation stripped off.

> Typescript is just documentation that compiles.

Exactly. And we're arguing whether code should contain documentation or not.

[danShumway]

This is kind of a subtle idea, but in some instances, the illusion of safety can be harmful. It is occasionally (not always) better not to give people the illusion of safety when that safety doesn't actually exist. Sometimes putting an ineffective railing along a mountain path increases accidents, because it's human nature for people walking on that path to watch their footing less when they see the railing.

>> Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.

> A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen?

I'm not here to hate on Typescript, I think it has its uses. I use Typescript in some places. I generally avoid it for personal projects, but I would probably encourage it for larger orgs.

But the idea that Typescript protects you from needing to care about interfaces is exactly the problem with over-reliance on Typescript, and is the source of a lot of really badly written code that treats interface design like an afterthought. If you're using Typescript for documentation and you're treating it like a tool, you can write some really elegant code, you can catch some shallow bugs around types and assumptions, you can integrate your documentation into your IDE. If you're looking at Typescript and saying, "this is an efficient way for me to document what my code does", then this is all very good.

But if you're using Typescript and saying, "now I can pull in any dependency I want", then Typescript is doing you more harm than good.

The specific advice orange gives in those two sentences is good advice. If Typescript is giving you a false sense of confidence about using random libraries, then that's a real negative.

I use both pure JS and Typescript almost daily, and I consume plenty of dependencies written in Typescript. I still occasionally need to debug the stack traces in those dependencies. I still occasionally need to read through their source code to figure out what they're doing. Badly documented dependencies are not a problem that Typescript solves.

[Udik]

> in some instances, the illusion of safety can be harmful

> you can catch some shallow bugs around types

> If Typescript is giving you a false sense of confidence about using random libraries

> Badly documented dependencies are not a problem that Typescript solves.

Seriously, what is your claim? That if you have a badly documented third party library with wrong typings then typescript doesn't help? Well, that's some news! Try the same library with no documentation at all then, so you won't get a false sense of safety. If that is your problem, why don't you just avoid importing typings for libraries?

And I don't get this insistence on bugs and safety. Sure, typescript probably prevents you from doing really stupid stuff sometimes, but that's not the main reason I use it. I use it because it both allows me to write much more complex code and speeds up dramatically the development- because the tool takes on itself what is otherwise a heavy cognitive load: remembering and inferring interfaces and signatures that are there all the time, even if implicitly.

[danShumway]

> If that is your problem, why don't you just avoid importing typings for libraries?

Yes? That's exactly what people are doing when they import a dependency written in Typescript into a pure JS project.

> A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen?

My claim is that Typescript does not solve the problem of joining a project with poorly written, undocumented libraries.

I'm not bashing on Typescript. If the primary way you use it is as an organizational tool to reduce cognitive load and make interfaces more explicit, then that's great. You're using Typescript as intended. And there are some scenarios where a compile-time type-checker is just obviously the right tool for the job.

You started this thread by asking how JS devs could manage 3rd-party interfaces without Typescript. I assume you genuinely want an answer to that question. The answer is that for some people on some projects, using well defined interfaces and keeping a reference page open with documentation is about as fast and about as easy as using Typescript, and that following that process doesn't increase their bug count or cognitive load to the point where they feel the need to introduce a compilation step.

[orange8]

> javascript is just typescript with documentation stripped off.

JS, at its core is a dynamically typed, functional language. Typescript aims to model a strongly typed, OPP language. The two programming paradigms have their own strengths, weaknesses and most importantly: patterns and best practices.

If the only difference between your pure javascript code and your typescript code is the annotations, you are doing it wrong.

[Udik]

> Typescript aim to model a strongly typed, OPP language.

Do you think? I just take TS for what it gives me, documentation and static code analysis. I can write down my knowledge and expectations about the code and have the tool keep track of it for me, removing the cognitive load of doing it myself- which I'd have to otherwise.

Can you give me an example of a pattern that is "good" in JS and not in TS, or the other way round? I'm curious.

[orange8]

A good indirect example is an actual feature added to JS recently, which are classes. Classes are the main unit of OOP, while functions are the main unit in the functional paradigm. The class syntax in JS is not a real new structure added to the language, but just syntax sugar. Underneath it all, the JS compiler just converts it to a regular JS function using a specific pattern. You could, if you wanted, save the compiler that work by just coding using that pattern to begin with.

When using TS the class syntax fits in perfectly for me, an in pure JS I'd stick to functions.

[iaml]

> Typescript aims to model a strongly typed, OPP language

That's a rather puzzling statement, to be honest. Strong type system is explicitly one of the non-goals[0]. I write typescript code everyday and most of it is functional. Things like fp-ts[1] make it even more enjoyable.

[0] https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi... [1] https://github.com/gcanti/fp-ts

[orange8]

Am comfortable using both OOP and functional styles, though I do enjoy the flexibility and terseness that can be produced from the functional approach.

What I meant by the comment is that when using TS, I just find it more easy and natural to go with the proper OOP approach. I think the very existence of a separate library to enable a more functional style in TS proves this goal has not been met yet.

[samhh]

It's not very strongly typed at all, and it absolutely doesn't force you into the OOP paradigm.

Why don't I consider it strongly typed?: Structurally subtyped as opposed to nominal typing, the pervasiveness of any, allowance for vanilla JS coercion, exceptions and promise rejections are untyped, etc.

[orange8]

I agree, that's why I said TS aims to model a strongly typed languange.

[manigandham]

Typescript won't save anyone from intentional writing bad code or using a broken library. Nothing will. I don't see how that's a criticism of TS itself.

[orange8]

> I'm not sure whether you intended this to sound so patronizing, but wow. What languages should I explore while talking about Javascript?

Why would the suggestion to explore non OOP, strongly typed languages sounds patronizing to you? The more different languages you play with, the broader your mental modelling toolset becomes. It is painfully obvious to me that someone worried about interfaces in JS is not very familiar with more dynamically typed or/and functional languages. JS is a VERY FLEXIBLE language which can be coded in any style, which is why I've suggest playing with something more opinionated to get the gist. Languages like XSLT, Erlang, LISP, Haskell etc.

> You are called to edit a function that takes 2 arguments:

> function handle_req(request, options):

> What is request in this context and what is options?

The fact that you can edit handle_req means it is application code. So how you figure that out comes down to the structure and patterns you and your team use (if any) and the available documentation (if any). You'd be surprised how far Eslint and JSDoc will take you. TypeScript accomplishes the same, and I've no problem using it within a team that needs it but personally, it feels like an overkill I don't really need to.

> A whole lot of the time, especially in JavaScript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen?

The decision to use TypeScript or any other tooling should really be made at the BEGINING of a project, so why are we talking about projects that already missed the boat, and even worse lack documentation and tests? This just proves my point, what you really need is discipline (documentation, tests, best praise etc) and a good linter, not a whole new language or programming paradgim.

[manigandham]

Typescript is as strongly typed as you want it to be. You can easily work with dynamic types and it will fill in where it can.

[danShumway]

Eh... people say this, and in theory it should be true.

If you actually use Typescript with a lot of dynamic/unsafe types, in practice you will very quickly end up with a lot of code littered with `any` casts, and those unsafe code blocks will end up (for lack of a better word) infecting the rest of your code and making the compile-time errors much less useful.

For whatever it's worth, my advice is in the instances where you decide Typescript is right for you, commit to it. For the most part, use interfaces, and use strict types that don't get recast a whole bunch.

You don't want Typescript to be guessing too much about your code, because some of those intuitions are fragile and can turn into bugs later if you assume Typescript just knows what you mean. I've had code that works until it gets refactored and Typescript stops being able to intuit what a type is. At that point, going back and retroactively trying to make things more explicit becomes a lot harder and a lot more error prone. The temptation there is to just shortcut the entire process and force Typescript to accept that a type is what you say it is -- and that can lead to very subtle bugs that are hard to track down.

The best Typescript code I've seen is code that embraces the rigidness. When I see a Typescript project with a lot of `any` casts, I start to get kind of nervous.

[DonHopkins]

>Some of us started JS programming over a decade ago, with no strong typing and IDE to hold our hand and tell us every time you make a mistake. The key is just discipline, good design patterns and a good linter.

A decade ago isn't very long ago. JavaScript is more than 24 years old, and we had to get along without good design patterns or good linters or good debuggers or good libraries or good documentation or good IDEs or good compilers or even good interpreters back then. It sounds like you were late to the party and missed all the fun! ;)

[orange8]

I may have shaved a few years here and there to calculate that decade ;)

I'm still waiting for a browser to come with an inbuilt server like netscaape 3.

[DonHopkins]

You do now understand that TypeScript didn't lose any of the flexibility, power, or paradigms of JavaScript, since it's by definition a strict superset of JavaScript, so it only adds programming paradigms, not subtracts them, right? Or do you disagree with Andrew Hejlsberg, its designer, or the definition of "strict superset"?

https://en.wikipedia.org/wiki/TypeScript

>TypeScript is an open-source programming language developed and maintained by Microsoft. It is a strict syntactical superset of JavaScript, and adds optional static typing to the language.

[DonHopkins]

>no strong typing and IDE to hold our hand and tell us every time you make a mistake

Ha ha! You remind me of Larry Wall:

https://news.ycombinator.com/item?id=22210073

>"I think IDEs make language developers lazy." -Larry Wall

https://www.youtube.com/watch?v=AO43p2Wqc08

To which James Gosling replied:

>"IDEs let me get a lot more done a lot faster. I mean I'm not -- I -- I -- I -- I -- I'm really not into proving my manhood. I'm into getting things done." -James Gosling

Andrew Hejlsberg also made some good points in that same discussion:

>Maybe I'll just add, with language design, you know one of the things that's interesting, you look at all of us old geezers sitting up here, and we're proof positive that languages move slowly.

>A lot of people make the mistake of thinking that languages move at the same speed as hardware or all of the other technologies that we live with.

>But languages are much more like math and much more like the human brain, and they all have evolved slowly. And we're still programming in languages that were invented 50 years ago. All the the principles of functional programming were though of more than 50 years ago.

>I do think one of the things that is luckily happening is that, like as Larry says, everyone's borrowing from everyone, languages are becoming more multi-paradigm.

>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".

>It's important to look at where is the research, and where is the new thinking, and where are new paradigms that are interesting, and then try to incorporate them, but do so tastefully in a sense, and work them into whatever is there already.

>And I think we're all learning a lot from functional programming languages these days. I certainly feel like I am. Because a lot of interesting research has happened there. But functional programming is imperfect. And no one writes pure functional programs. I mean, because they don't exist.

>It's all about how can you tastefully sneak in mutation in ways that you can better reason about. As opposed to mutation and free threading for everyone. And that's like just a recipe for disaster.

In the HN discussion of that talk, I wrote:

https://news.ycombinator.com/item?id=19568860

>Anders Hejlsberg also made the point that types are documentation. Programming language design is user interface design because programmers are programming language users.

>"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs.

>But if you start with a well designed linguistically sound language (Perl, PHP and C++ need not apply), then your IDE doesn't need to waste so much of its energy and complexity and coherence on papering over problems and making up for the deficiencies of the programming language design. (Like debugging mish-mashes of C++ templates and macros in header files!)

[DonHopkins]

I think what Andrew Hejlsberg himself, the designer of C# and TypeScript, said speaks to the claims orange8 is making about TypeScript being a "VERY opinionated linter" and that "you loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns".

Andrew Hejlsberg's point is that TypeScript is a "multi-paradigm" language: it's not just strongly typed, but also structurally typed, interface based, plus everything else JavaScript itself is: dynamically typed, duck typed, functional, imperative, event driven, class based, prototype based, object oriented, etc.

Even the term "object oriented" has a broad spectrum of independent meanings: JavaScript has many but not all of the a la carte menu of features or properties of "object orientation" that Jonathan Rees listed in response to Paul Graham's essay "Why Arc isn't Especially Object-Oriented".

http://paulgraham.com/reesoo.html

http://mumble.net/~jar/articles/oo.html

http://paulgraham.com/noop.html

Andrew Hejlsberg said:

>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".

It's a mistake to think that TypeScript restricts you to just one way of programming, and you have to give up the ways you used to program JavaScript. TypeScript ADDS to the number of ways you can program JavaScript. It's a superset of the multiple programming paradigms that JavaScript supports.

You don't "loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns" -- quite the opposite, you don't "lose" anything: you actually gain more "flexibility" and more "language" patterns.

[orange8]

>> you don't "lose" anything: you actually gain more "flexibility" and more "language" patterns.

You do not need TS to use OOP language patterns in JS. Remember TS is compiled down to JS, so all that flexibility comes from JS. The same flexibility that makes the concept of TS and the 100 other "compile to JS" languages possible. Some of that flexibility is lost because you let the TS compiler make some decisions for you as it generates the JS output.

[DonHopkins]

You're factually wrong: zero flexibility is lost. Not even any "flexability". (But I'm glad we're both using the same word now -- I was worried you had some completely different definition of "loose languange flexability" that you were arguing, because you don't seen to be making any sense, and your facts about TypeScript are wrong. Programmers who scoff at IDEs and compilers like you do should be more careful about your own spelling and punctuation and grammar and logic and facts and definitions and semantic arguments.)

The TypeScript compiler will BY DEFINITION compile any JavaScript code to equivalent JavaScript code that does exactly the same thing. So no flexibility is lost, which is obvious if you know TypeScript, or have bothered to read the second sentence of the first paragraph of the TypeScript wikipedia page. TypeScript is a "strict syntactical superset" of JavaScript. So it's impossible for the TypeScript compiler to decrease the flexibility of TypeScript, because all JavaScript is valid TypeScript. Understand?

https://en.wikipedia.org/wiki/TypeScript

>TypeScript is an open-source programming language developed and maintained by Microsoft. It is a strict syntactical superset of JavaScript, and adds optional static typing to the language.

Just the opposite of your claim, and consistent with what Wikipedia and Andrew Hejlsberg say, the TypeScript compiler "ADDS optional static typing to the language", which INCREASES the number of programming paradigms.

Yet you wrote:

>Remember TS is compiled down to JS, so all that flexibility comes from JS.

C++ is compiled down to machine language, but machine language is not object oriented, while C++ is. Do you claim that the flexibility of C++ comes from machine language's innate object oriented-ness, not the C++ compiler? That's simply wrong.

Somehow the C++ compiler is adding object oriented programming to machine language, just as the TypeScript compiler is adding generic programming and structured typing and static typing and other features to JavaScript, even though JavaScript doesn't have those features itself. They came from the compiler, not the target language. JavaScript simply isn't capable of checking types before running a program, and you know that.

You're really not getting the point, or just purposefully trying to avoid it. Read what Andrew Hejlsberg himself said about multi-paradigm languages, which I've quoted to you twice but you haven't acknowledged. Do you really so blatantly disagree with the guy who wrote TypeScript, about his own language?

If you so strongly disagree with Andrew Hejlsberg and the TypeScript manual, then why don't you go edit the Wikipedia articles about TypeScript and JavaScript, and remove the parts about TypeScript being a "strict syntactical superset of JavaScript" that "adds optional static typing to the language", and also remove the part about Javascript being a "multi-paradigm language", and see how long those edits lasts?

https://en.wikipedia.org/wiki/JavaScript

>JavaScript (/ˈdʒɑːvəˌskrɪpt/),[6] often abbreviated as JS, is a programming language that conforms to the ECMAScript specification.[7] JavaScript is high-level, often just-in-time compiled, and multi-paradigm. It has curly-bracket syntax, dynamic typing, prototype-based object-orientation, and first-class functions.