4 ms·
> 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 se
by 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 agoMaybe 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 agoMaybe 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 agoTypescript 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.