3 ms·

Writing statically typed code will always be slower than writing dynamically typed code. People don't use static typing for writing code faster, they use it fo

Writing statically typed code will always be slower than writing dynamically typed code. People don't use static typing for writing code faster, they use it for code that can be READ (and understood) much faster, especially by somebody who doesn't work with that specific piece of code every day. I think it's generally agreed that in most situations, reading code is much more common than writing code, so static typing really make sense.

winter_blue 6y ago
> they use it for code that can be READ (and understood) much faster You nailed it. I agree, this is the biggest benefit of static types. I worked at on a several hundred thousand line JS code base at a company, and people were passing objects around, and it was extremely painful to trace code and figure what the structure of the object was. I had to set a breakpoint in the browser, and inspect the object during runtime. Moreover, some fields would randomly be missing, because the field wasn't necessary for that instance of the object. It was infuriatingly maddening. I ended up spending a lot of time adding Flow types to it, of the form: type Foobar = { someField1: string, someField2: number, someField3: Baz, fieldThatIsNotAlwaysThere: ?Qux ... } The untyped state of the code base gave me an extremely hard to resist to add Flow static types wherever I could. I also added a step to the pipeline (with my manager's support) that would break the pipeline and make it impossible to merge new code, if it didn't have Flow static types (and I used flow-coverage to make sure the "any" keyword wasn't being used excessively to side step Flow type checking). I was told by some of my teammates to stop forcing types down their throat. I eventually spent so much reworking large parts of the code base, and adding static types to it that my other work suffered (and I wasn't putting as much time as I should have into it), that I was told to stop spending so much time on adding Flow static types. But it was hard to resist the temptation. When I had to implement a new feature / change a file, I would add Flow types to it, and then be drawn to adding types to the various other files that it connects to (imports from, passes data to, etc). They fired me in the end, for that (not prioritizing the things I was supposed to do well enough) and other reasons (was going through relationship issues and eventually a bad breakup, which caused associated psychological/personal/self-care issues). I've learned my lesson. Dynamic types aren't my cup of tea, and I find dynamically typed code to be repulsive and quite nauseating.
- joelbluminator 6y ago
  Maybe the real lesson is you should have done your work instead of let management get pissed with you for horsing around with types the whole day?
  - valuearb 6y ago
    Maybe he should have looked for a job at a shop that wasn’t a bunch of Wild West hackers writing unmaintainable code?
- MaxBarraclough 6y ago
  > some fields would randomly be missing, because the field wasn't necessary for that instance of the object This problem can occur in statically-typed languages too, such as if you have a class to model your entity, but in this instance you only need certain fields to be hydrated. The other fields may be set to null. This might only a problem if the half-populated instance is 'leaked' to somewhere that expects a fully hydrated instance. Thinking about it though, it's possible that null could also be used to represent a null held on the database, rather than not hydrated. The ideal solution would I suppose be to roll your own type for this semi-hydrated data, but that's not always possible/convenient. Example: https://github.com/microsoftgraph/msgraph-sdk-dotnet/blob/dev/docs/overview.md#query-options https://github.com/microsoftgraph/msgraph-sdk-dotnet/blob/de...
  - xsmasher 6y ago
    Typescript makes it convenient to roll your own type- `let draft : Partial<Foo>;` says that 'draft' is shaped like a Foo, EXCEPT all of the fields are optional. If you try to access a field on draft that doesn't exist on Foo, it's a ts error. If you try to pass draft to a function that takes a Foo, it's a type mismatch.
mellow2020 6y ago
"most situations" don't apply to specific situations. I write code so the computer executes it most of the time, and the times I wonder what type something is is practically never. It's simply not an isse. The real hard bugs I encounter are always logic errors no compiler would catch. I would love to have static types in JS, but not at the expense of node.. and not just so people who are in different situations than mine are happy, because I act as if I was in their situation.
- sunaurus 6y ago
  > I would love to have static types in JS, but not at the expense of node.. What do you mean by this? I use TypeScript with node all the time.
  - mellow2020 6y ago
    I worded that badly, I meant "at the expense of having to run node".
    - mixedCase 6y ago
      What's the problem of running node for your developer tools?
hombre_fatal 6y ago
> Writing statically typed code will always be slower than writing dynamically typed code. Only in the beginning / short-term when the project is new, small, and fits in your head. IMO doesn't take much more code and complexity for it to switch over to statically-typed code being faster to write. As an extreme example, I run an online strategy game implemented in Elm. The game only supported three melee classes but the community made really good points about how ranged classes should work. I came back to a codebase I hadn't touched in over a year, picked a spot in the code where I knew my physics would have to be updated to handle projectiles, started implementing it, and I basically followed the compile errors until my physics system supported projectiles. Had it been dynamically-typed, this kind of refactor/overhaul would have required me to recredentialize in much more code and either rewrite tests and/or manually test my code branches at runtime to track down errors. It would have taken much much longer.

winter_blue 6y ago

> they use it for code that can be READ (and understood) much faster You nailed it. I agree, this is the biggest benefit of static types. I worked at on a several hundred thousand line JS code base at a company, and people were passing objects around, and it was extremely painful to trace code and figure what the structure of the object was. I had to set a breakpoint in the browser, and inspect the object during runtime. Moreover, some fields would randomly be missing, because the field wasn't necessary for that instance of the object. It was infuriatingly maddening. I ended up spending a lot of time adding Flow types to it, of the form: type Foobar = { someField1: string, someField2: number, someField3: Baz, fieldThatIsNotAlwaysThere: ?Qux ... } The untyped state of the code base gave me an extremely hard to resist to add Flow static types wherever I could. I also added a step to the pipeline (with my manager's support) that would break the pipeline and make it impossible to merge new code, if it didn't have Flow static types (and I used flow-coverage to make sure the "any" keyword wasn't being used excessively to side step Flow type checking). I was told by some of my teammates to stop forcing types down their throat. I eventually spent so much reworking large parts of the code base, and adding static types to it that my other work suffered (and I wasn't putting as much time as I should have into it), that I was told to stop spending so much time on adding Flow static types. But it was hard to resist the temptation. When I had to implement a new feature / change a file, I would add Flow types to it, and then be drawn to adding types to the various other files that it connects to (imports from, passes data to, etc). They fired me in the end, for that (not prioritizing the things I was supposed to do well enough) and other reasons (was going through relationship issues and eventually a bad breakup, which caused associated psychological/personal/self-care issues). I've learned my lesson. Dynamic types aren't my cup of tea, and I find dynamically typed code to be repulsive and quite nauseating.

joelbluminator 6y ago
Maybe the real lesson is you should have done your work instead of let management get pissed with you for horsing around with types the whole day?
- valuearb 6y ago
  Maybe he should have looked for a job at a shop that wasn’t a bunch of Wild West hackers writing unmaintainable code?
MaxBarraclough 6y ago
> some fields would randomly be missing, because the field wasn't necessary for that instance of the object This problem can occur in statically-typed languages too, such as if you have a class to model your entity, but in this instance you only need certain fields to be hydrated. The other fields may be set to null. This might only a problem if the half-populated instance is 'leaked' to somewhere that expects a fully hydrated instance. Thinking about it though, it's possible that null could also be used to represent a null held on the database, rather than not hydrated. The ideal solution would I suppose be to roll your own type for this semi-hydrated data, but that's not always possible/convenient. Example: https://github.com/microsoftgraph/msgraph-sdk-dotnet/blob/dev/docs/overview.md#query-options https://github.com/microsoftgraph/msgraph-sdk-dotnet/blob/de...
- xsmasher 6y ago
  Typescript makes it convenient to roll your own type- `let draft : Partial<Foo>;` says that 'draft' is shaped like a Foo, EXCEPT all of the fields are optional. If you try to access a field on draft that doesn't exist on Foo, it's a ts error. If you try to pass draft to a function that takes a Foo, it's a type mismatch.

mellow2020 6y ago

"most situations" don't apply to specific situations. I write code so the computer executes it most of the time, and the times I wonder what type something is is practically never. It's simply not an isse. The real hard bugs I encounter are always logic errors no compiler would catch. I would love to have static types in JS, but not at the expense of node.. and not just so people who are in different situations than mine are happy, because I act as if I was in their situation.

sunaurus 6y ago
> I would love to have static types in JS, but not at the expense of node.. What do you mean by this? I use TypeScript with node all the time.
- mellow2020 6y ago
  I worded that badly, I meant "at the expense of having to run node".
  - mixedCase 6y ago
    What's the problem of running node for your developer tools?

hombre_fatal 6y ago

> Writing statically typed code will always be slower than writing dynamically typed code. Only in the beginning / short-term when the project is new, small, and fits in your head. IMO doesn't take much more code and complexity for it to switch over to statically-typed code being faster to write. As an extreme example, I run an online strategy game implemented in Elm. The game only supported three melee classes but the community made really good points about how ranged classes should work. I came back to a codebase I hadn't touched in over a year, picked a spot in the code where I knew my physics would have to be updated to handle projectiles, started implementing it, and I basically followed the compile errors until my physics system supported projectiles. Had it been dynamically-typed, this kind of refactor/overhaul would have required me to recredentialize in much more code and either rewrite tests and/or manually test my code branches at runtime to track down errors. It would have taken much much longer.