3 ms·

> It returns Promise<T> That still doesn't say anything; is the action referentially transparent? is that a delay? a network call? All a Promise tells me is th

> It returns Promise<T> 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. > It doesn't. React does that. ;) 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 :) > "This cycling helmet doesn't protect your knees and elbows and spine, so its completely useless and you can remove it!" That's not what I meant, its more like "why wear winter clothes in the summer?"

Too 10y ago
Because winter is coming. It's easy to read code you wrote yourself 5 minutes ago, try again in 6 months.
- jeremiep 10y ago
  Simplicity will help me understand my code 6 months down the road; everything else is superficial and noise in comparison. You can't hold more than ~7 things at once in your head; once things are that simple you can see bugs a mile away, types or not. The inverse is not true; types won't help you juggle 15 things at once and bugs will happily slide through the cracks. You're going to forget your codebase, types or not, and when you come back to it only simplicity will help you quickly figure out what you were doing with it.
  - spion 10y ago
    I used to think like this, and I was wrong. As you add code to a software project, some of this code will be written when the problem is not well understood; thats inevitable. The solution will then need to be refactored or rewritten, the first of which is extremely painful in a dynamic language, even if you keep things simple. For example: if you implement a store that only sells electronic books will have a lot of assumptions regarding the selling and delivery process. Later the business wants to start selling physical things and needs to handle stuff like shipping costs, tracking and so on. For problems like online stores, the possible directions in which they can develop are well understood and its easier to plan ahead. For most other things, its not, and the ability to reorganise code to be usable in different ways is invaluable.
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.
  - 10y ago

Too 10y ago

Because winter is coming. It's easy to read code you wrote yourself 5 minutes ago, try again in 6 months.

jeremiep 10y ago
Simplicity will help me understand my code 6 months down the road; everything else is superficial and noise in comparison. You can't hold more than ~7 things at once in your head; once things are that simple you can see bugs a mile away, types or not. The inverse is not true; types won't help you juggle 15 things at once and bugs will happily slide through the cracks. You're going to forget your codebase, types or not, and when you come back to it only simplicity will help you quickly figure out what you were doing with it.
- spion 10y ago
  I used to think like this, and I was wrong. As you add code to a software project, some of this code will be written when the problem is not well understood; thats inevitable. The solution will then need to be refactored or rewritten, the first of which is extremely painful in a dynamic language, even if you keep things simple. For example: if you implement a store that only sells electronic books will have a lot of assumptions regarding the selling and delivery process. Later the business wants to start selling physical things and needs to handle stuff like shipping costs, tracking and so on. For problems like online stores, the possible directions in which they can develop are well understood and its easier to plan ahead. For most other things, its not, and the ability to reorganise code to be usable in different ways is invaluable.

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.
- 10y ago