11 ms·
I almost see static typing as an alternative to exhaustive testing. If you're working on a large project written in JS, you need a strong test suite to have an
by skohan 5y ago
I almost see static typing as an alternative to exhaustive testing. If you're working on a large project written in JS, you need a strong test suite to have any confidence you code will be robust at runtime.
As you say, with ADT's and null safety, you can be a lot more judicious about testing to get to the same level of confidence.
When working with Rust or Swift, I'm honestly usually getting away with some integration tests, and whichever unit tests came about organically when a particular section was particularly well suited to TDD. But "code coverage" is a much less pressing concern.
- zarzavat 5y agoIf you are writing a new large project in JS without TypeScript, you are doing it wrong period. Bare JS is a cute language for personal websites but it's not feasible for anything more than a few thousand SLOC.
- dimitrios1 5y agoTell that to the mountain of "few thousand line SLOC" javascript projects that existed and continue to exist before Anders Hejlsberg embarked on his mission to C#-ify javascript. I am not opposed to adding strong type checking to JavaScript, but Typescript ain't it.
- morgancmartin 5y agoI agree that TypeScript leaves something to be desired, but it is far and away a better alternative to pure JS. TS may not be total, but it comes close enough to get the job done for the dynamic environment it's meant to target assuming operators competent enough to lean on what it offers. I should also note, I've attempted OOP in TS and it wasn't pretty. It is much more suited to a functional style IME, although I will concede I have seen some open source projects that use it in a Java-esque OOP style presumably to good effect. Personally it wasn't my cup of tea.
- wing-_-nuts 5y ago>Typescript ain't it. Expand please?
- jamil7 5y agoI think what the parent is getting at that Typescript doesn't try to give you the kind of guarantees that something like Rust, Swift, Elm etc. can. They are upfront about this though and it's stated here in the design goals as a non-goal https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals#non-goals https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...
- k_ 5y ago> I am not opposed to adding strong type checking to JavaScript, but Typescript ain't it. If you are curious about this, you might be interested in checking out Haxe [0]. It has static typing, type inference, pattern matching [1] (maybe not on par with ML languages, but still good), and can transpile to multiple targets [2] including JS. [0]: https://haxe.org https://haxe.org [1]: https://haxe.org/manual/lf-pattern-matching.html https://haxe.org/manual/lf-pattern-matching.html [2]: https://haxe.org/documentation/introduction/compiler-targets.html https://haxe.org/documentation/introduction/compiler-targets...
- xvilka 5y agoThere are also notable Rescript [1], Melange [2], Reason [3], PureScript[4]. [1] https://rescript-lang.org/ https://rescript-lang.org/ [2] https://github.com/melange-re/melange https://github.com/melange-re/melange [3] https://reasonml.github.io/ https://reasonml.github.io/ [4] https://www.purescript.org/ https://www.purescript.org/
- paavohtl 5y agoTypeScript has nothing to do with C#, apart from its creator. The structural type system with explicit nulls, sum types and very powerful generics makes it feel much closer to the ML family of languages than C#, despite using the C-like JS syntax. The teams I've used it in have never really used it to build complex OOP hierarchies or even used classes for anything other than React components, though there are probably many who do.
- zarzavat 5y agoBoth are true. The original TypeScript v1 was a lot more like C#-in-JS and was very class-oriented, however over the years the type system has grown into a mature ML-like structural type system as a side effect of trying to type the wide variety of dynamic JS out there. Anybody who last looked at TypeScript a few years ago and dismissed it needs to have another look.
- bwship 5y agoActually Typescript is it.
- claytongulick 5y agoIf you're wasting your time with needless datatypes you are doing it wrong period. See what I did there?
- Zababa 5y agoI'd personally reach for something else than TypeScript. TS tries to type the existing JS world which makes it really big and complex.
- lolinder 5y agoThe advantage TypeScript has for front-end over something that compiles to JS is that you pretty much know what your code will compile to: with a few exceptions, you just strip out the type annotations. Knowing this, you can accurately predict things like performance. In contrast, a compiles-to-JS language can produce code that behaves unexpectedly in its non-functional requirements, and in the worst cases crashes where it shouldn't. That will be less of an issue as compilers get better, and WASM should help a lot, but in the current ecosystem TypeScript produces more predictably good results.
- Zababa 5y agoThat may be true in theory, but I find that people write radically different code in JS and in TS. TS code looks a lot more like C# compared to regular JS code, people use a lot of classes over plain functions and data structures.
- nawgz 5y agoTypeScript is not really big and complex, it's just a type system. The only real pain with TypeScript vs. a language with native static types is that TypeScript requires a bit of extra work to fiddle with the compiler, otherwise when it comes to the code it's flexible but can be used in a very simple manner.
- Zababa 5y ago> TypeScript is not really big and complex, it's just a type system. It's a very complex type system though.
- nawgz 5y agoCan you say some ways it is more complex than other type systems? I think type systems are inherently complex. From my perspective, I feel user-facing complexity is quite low in TypeScript in some key ways. You can write your type declarations anywhere, you can import and export them in a familiar JS-module way, you don't need to explicitly type anything in particular so you can be anywhere on the spectrum from very rigorous types to no types at all / `any` everywhere, and finally it has really good error messages so you rarely are stuck with a type mismatch that makes no sense.
- lpapez 5y agoI would say this is the case even in C++ world. When modern stuff is used correctly (etc. optional, variant, constexpr + static_assert), most of the tests you will ever need are integration tests, basic smoke tests or feature-documenting-tests.
- missblit 5y agoAlso fuzz tests! I cannot stress enough how important fuzz tests are if your security model solely relies on your C++ being memory safe (a lot of code should be sandboxed as well but that's another discussion...). Even when using modern stuff correctly on a mature codebase fuzz testing will find bugs. So if you don't fuzz test and someone evil has your binary then they'll fuzz test for you...
- pydry 5y agoStatic typing is an alternative to invariants in dynamic languages, not testing. Testing can't really substitute for types. They're two diametrically opposed approaches to impeding bugs.
- ninkendo 5y agoHow do you express invariants in dynamic languages? (In a way that doesn’t require test coverage to check those invariants?) I thought the only way would be to write some assertions in the prod code, and then write the unit tests to cover them… but you seem to be implying that you can “do” invariants in dynamic languages in a way that doesn’t require testing.
- eru 5y agoI guess you can sort-of use design-by-contract and call it an alternative?
- pydry 5y ago>In a way that doesn’t require test coverage They obviously work best when "combined with test coverage" but then again, I dont consider test coverage to be "optional" in any language. This idea that "if it compiles it works" that some haskellers seem to believe, for instance, is complete horseshit. If somebody argues that static typing works great because without tests it catches more bugs than dynamic typing does when you also dont write tests, it's notionally true, yes, but theyre telling you more about themselves than they are about types. Namely that they're not in the habit of writing tests. If you've got enough of the right kind of testing coverage to validate an app written in a statically typed language you will have enough to trigger invariants in a dynamically typed langauge. I have successfully had invariants usefully triggered in prod and by manual testers in big balls of mud without test coverage (failing fast isnt just for test environments) but I considered that to be a form of emergency programming CPR and damage limitation that isnt a substitute for fixing your testing "diet".
- shadowgovt 5y agoAgreed; "if it compiles it works" tends to tilt too far in the other direction. (... I once had a professor who believed that phrase as nearly a point of religion, and his project work was maddening. No documentation on any functions either, because "the types are self-documenting." Then you'd get hit with a 'division' function that takes (number,number) but he put the denominator as the first argument. Ugh.)