Use TypeScript, and nonsensical things like adding arrays to objects will be compile-time errors.
By that logic what we really need is a modernization of Ada, where there are no compiler warnings and anything that would generate one in another language is instead a compiler error, everything is strongly typed, etc, etc.
If you aren’t familiar with Ada, just imagine Pascal went to military school.
Pascal went to military school.
I’m not in love with the idea, but a language that cuts out the BS has a sudden appeal when on a group/team project.
That analogy was chosen for a reason. Ada was originally developed by DOD committee and a French programming team to be a programming language for Defense projects between 1977 and 1983 that they were still using at least into the early 2000s. It’s based on Pascal.
It was intended for applications where reliability was the highest priority (above things like performance or ease of use) and one of the consequences of that is that there are no warnings - only compiler errors, and a lot of common bad practices that will be allowed to fly or maybe at worst generate a warning in other languages will themselves generate compiler errors. Do it right or don’t bother trying. No implicit typecasting, even something like 1 + 0.5 where it’s obvious what is intended is a compiler error because you are trying to add an integer to a real without explicitly converting either - you’re in extremely strongly-typed country here.
Libraries are split across two files, one is essentially the interfaces for the library and the other is it’s implementation (not that weird, and not that different than C/C++ header files though the code looks closer to Pascal interface and implementation sections put in separate files). The intent at the time being that different teams or different subcontractors might be building each module and by establishing a fixed interface up front and spelling out in great detail in documentation what each piece of that interface is supposed to do the actual implementation could be done separately and hypothetically have a predictable result.
Yup. The libraries underneath will still allow nonsense at runtime, though, and it will now be harder to see, so it’s a partial solution as done in standard practice.
An all-TypeScript stack, if you could pull it off, would be the way to go.
The libraries underneath will still allow nonsense at runtime
Only if you use a badly written library. Most libraries have types provided by DefinitelyTyped. Those who don’t are (in my experience) so tiny that you probably aren’t using them; or, if you really wanted, can check yourself.
In the end, if you encounter a bug, it’ still 99% of the time not a library’s fault, even if it’s written in plain JS.
Like I said to the other person, those are just types over top of JavaScript that can still fail if/when coercion happens under the hood.
I don’t even know how to search it now, but a specific example came up on here of a time when JavaScript libraries will cause problems, and problems you can’t even see very well if you’re expecting it to act strictly-typed.
Yeah, ideally TypeScript would be natively supported. Or maybe just Python, which is sort-of strictly typed, and definitely won’t do “wat”. Alas, it’s not the world we live in, and browsers take JavaScript.
If there was an easy way to use rust or something on webassemly and use that instead of JS. I’d be so happy, but I can’t find how to do it without npm.
Most libraries have TypeScript types these days, either bundled directly with the library (common with newer libraries), or as part of the DefinitelyTyped project.
DefinitelyTyped is the exact kind of thing I’m talking about. You put TypeScript definitions over things, but under the hood it’s still JavaScript and can fail in JavaScript ways.
