3 ms·
> That still doesn't say anything; is the action referentially transparent? is that a delay? a network call? All a Promise tells me is that the result will come
by spion 10y ago
> That still doesn't say anything; is the action referentially transparent? is that a delay? a network call? All a Promise tells me is that the result will come at a later point in time.
Promise<T> is like Haskell's IO<T> in terms of what it says. In short, "anything goes"
> My point was about side-effects and complexity in general which the static type-system is generally very clueless about. React is a runtime and dynamic solution to that problem; types aren't really useful here
> Besides, you're most likely using React with Immutable.js and having some pattern like Redux on top. Which is basically choosing immutability and hostility to state over static types :)
Why is everyone always making it an "either or" thing? The usefulness of types is in them describing the input/output dependencies in your code. Change the nature of your inputs, and it tells you what dependencies, or dependencies of dependencies (etc) will be affected. Change the nature of your output, and you get the same for your dependants. This is mainly what TypeScript gives you: it tells you how your modules are connected.
Immutability wont help you with the above. If in the return result of the exported function `f` from module `A`, I change this attribute from "firstName" to "name", who will be affected? TypeScript can tell you things like: `A.f` is called by `g` from module B, which then passes the data unmodified to `C.h` which then tries to access the `firstName` attribute. Voila, now you know. Now, how will immutability, hostility to state or unit testing help you with this question?
- jeremiep 10y ago> The usefulness of types is in them describing the input/output dependencies in your code. I agree, but I find types way too weak in that respect. Its not enough to know a function accepts ints; I want to know its range as well. I spent so many weeks hunting down overflow and out-of-range errors and null pointer exceptions that types feel like an illusion of robustness at best. > Now, how will immutability, hostility to state or unit testing help you with this question? Not that much, I'll give you that. But the same is true for a function whose range was 1-20 being refactored into a range of 1-10; types won't catch that. I used to like types, then testing, now I'm looking at specifications I can write once, compose and then generate assertions, documentation, test data and everything else from. Its by far the best ROI of the three.
- spion 10y ago> Its not enough to know a function accepts ints; I want to know its range as well. Types actually help with this too. Instead of changing the possible range of a thing, change its name too: the compiler will quickly let you know of all the places that depend on it. Now you know what to check.