41–50 of 210 posts
Earlier quoted context omitted.
if someone invented a typed superset of JS life could be so much easier Oh wait ...
Typescript doesn’t actually do runtime checking though does it? So if I wrote a library in ts and someone called the built js directly it wouldn’t have any type checking would it?
Earlier quoted context omitted.
You can insert whatever level of validation you need at the untyped interface between the two... just as you would with dynamically typed languages.
So using static typing doesn't help you in other words since you need to do the same runtime validation as with dynamic languages?
Static types are great because they make certain classes of bug impossible to write, but they have their limits. There are escape hatches, like casts and Object types, even in statically-typed languages, though fewer of them in languages with more advanced type systems. There are reasons to like PureScript over TypeScript, just as there are reasons to like Haskell over Java. TypeScript doesn’t give you a way to ban s…
Even those don't have to be escape hatches as such, in the same way e.g. List.head doesn't have to be partial, that was an explicit decision.
When casting from rust's Any trait to a concrete type, you get an option. There's no subversion of the type system, there is no runtime error unless you as the developer decide to generate one.
The article builds a strawman. It's not the types that fail, but the type system and its misuse. > This is like pretending really hard No, that's not pretending — static typing is literally about theorem proving, type theory being equivalent with math logic. This is the famous Curry-Howard isomorphism, types corresponding to propositions. Of course, you can have situations in which your type system cannot describe th…
I agree that defensive checks may clutter code, but in the current landscape of constant security issues, to not use a battery of defensive checks whenever dealing with input is simply naive, no matter the IDE, compile language or runtime language.
I think as time goes on type checking will be the least of our issues. Checking for different types of abuse (technical, social, semantic), context sensitive boundaries, setting tripwire-esque traps to control abuse etc will make any current concerns over type checking seem elementary.
We need to give up on the idea of coding 3 line, beautiful functions that look great on Twitter and realize we live in a time where defense and privacy are a priority, while (some how) simultaneously pushing innovation.
I hate it, trust me, but if you talk to typcial corporate/business clients, this is where their thoughts/concerns are currently. I realize it’s a bigger conversation than what I’m mentioning here.
Broken promises in Javascript? ... unsurprising ... Here is an imaginary article that I would read: "New web platform runs entirely in webassembly generated by well-typed languages". Subtitle: "When hand-written Javascript is detected, continuous integration activates subdermal shock-collar that each of the developers is contractually obliged to have".
Err...you're talking about promises from the community, not Promises in code.
> in various cases the types are wrong and the compiler doesn’t care It's disturbing how often I encounter this in TypeScript. Or its inverse: the types are correct and the compiler is wrong. Or a third common problem: the types for a library are incorrect. The unsoundness of TypeScript is not merely theoretical. The compiler is frequently just wrong. For that reason, I am mystified by the amount of enthusiasm for Ty…
I have been using Flow (mostly) and TS (occasionally, including counter-checking problems in Flow to see what TS does in a similar case). Overall I would not go back to the time without a type checker, however, I too am mystified by the enthusiasm. Anyone who wants to check the state of static type checking for Javascript should take some time and read through
- https://github.com/Microsoft/TypeScript/issues
- https://github.com/facebook/flow/issues
I do that quite a lot myself and have also contributed a tiny bit to both projects (no core code, things like definitions, small doc improvements, quite a bit of answering to issues and often checking the posted code for myself, often in both Flow and TS).
Ignore the issues posted by people who really would just need a forum to ask questions, there are plenty of real issues left. Worst part: Many of them won't be solved (too hard, too much work, too many issues overall). You have to change your coding style and write in a way that the type checker can actually help you with. Also, it's easily possible to end up with types that are far more complicated than the code they are supposed to describe.
I spent more time working on the types than on the actual code. What makes it worth it is that one, I get some control over the code other people write using my library, if I insist they too use the type system I can prevent them from misusing the API to a degree. Two, those other people also includes myself in future incarnations. Three, refactoring can be significantly easier, if you have good types the checker will tell you all the places you missed changing.
So overall, at least for my situation, mostly for writing a library with few external dependencies (so I don't need the more or less unreliable external type definitions) that the business heavily relies on in many products, adding the very considerable additional effort is worth it. Still, I very much disagree with all the enthusiasm.
The type checkers are software trying to understand software, and that software that it's attempting to check is not just an already complex dynamic language, but in addition on top of it is people's code that comes in a million styles. Those type checkers can be valuable, but they are far (very far) from perfect, and they come at a considerable price (mostly in the time it takes to create and maintain the types, I think the additional step to remove type annotations for production code is pretty insignificant in comparison).
Static types are great because they make certain classes of bug impossible to write, but they have their limits. There are escape hatches, like casts and Object types, even in statically-typed languages, though fewer of them in languages with more advanced type systems. There are reasons to like PureScript over TypeScript, just as there are reasons to like Haskell over Java. TypeScript doesn’t give you a way to ban s…
[string]$String = "Dog";
$String = 5;
Cannot convert value 5 to type "System.Objects.String"Earlier quoted context omitted.
It's nothing to do with "a dose of common sense" so much as it is the reality of dealing with humans. Humans make mistakes. Static typing is automated checks to make sure you didn't. When doctors start using checklists their patients do better [1]. Static typing is checklists for programmers. In theory weak dynamic typing works great. In practice humans suck. Hence checklists. [1] https://www.newyorker.com/magazine/2…
How would static typing help you if it's two different applications like the post you reply to is talking about?
Then again, if both ends use schema, then comparing schemas is easy and gives you fair chance to fingers the place that differ between systems.
If there is one place or lib as a source of schema on both ends, then mismatch is just a result of different version being imported by them - something easy to check.