3 ms·

Not all of that research was done with public code. But they had other flaws. I should have prefaced that with "IMO". That particular sentence comes from my ex

Not all of that research was done with public code. But they had other flaws. I should have prefaced that with "IMO". That particular sentence comes from my experience/career, so YMMV. When I'm reading code, I know what types I'm dealing with. Even more so if I'm creating that code. But then again, I worked with dynamic languages for a long time and this could be a skill I picked up because of it.

littlestymaar 3y ago
> When I'm reading code, I know what types I'm dealing with. Even more so if I'm creating that code. Even when dealing with third-party code, or joining an existing project?
- Draiken 3y ago
  That's the first thing you do: read/learn the data structures you're working with. As Linus said once: > Bad programmers worry about the code. Good programmers worry about data structures and their relationships. Of course I still have to read and learn that. But that's the same with or without a typed language. Whether your data is an unstructured hash or a carefully typed structure, you need to know it. Way too many people rely on ctrl+space based programming, figuring out everything as they go. One aspect that dynamic typed languages forces into us (at least it does to me), is to learn the data structure and relationships more thoroughly.
  - destriaero 3y ago
    That's great unless you are working with a codebase that spans decades and tens of millions of lines of code. At that point if for every assignment you are tracing through your data types manually - you are out of a job. Also, if I am using an API another team is providing - I don't want to have to go and trace through their code.
    - Aeolos 3y ago
      And that's assuming you even have access to said source code. In many cases, you just receive a semi-documented JSON object and a prayer. Anecdotal story: We recently went through an effort to introduce strict-type checking for our typescript backend. As part of that effort, we introduced concrete types for every API accessible across a service boundary, which caught 6 mismatches between the documentation and the implementation (e.g. return Promise<bool> vs Promise<Instance>) and several hundred issues with missing null or type checks that would result in an "InternalServerError" instead of a meaningful error message. We started rolling the strict version out this week, and we can already see a meaningful improvement in the sentry logs.

littlestymaar 3y ago

> When I'm reading code, I know what types I'm dealing with. Even more so if I'm creating that code. Even when dealing with third-party code, or joining an existing project?

Draiken 3y ago
That's the first thing you do: read/learn the data structures you're working with. As Linus said once: > Bad programmers worry about the code. Good programmers worry about data structures and their relationships. Of course I still have to read and learn that. But that's the same with or without a typed language. Whether your data is an unstructured hash or a carefully typed structure, you need to know it. Way too many people rely on ctrl+space based programming, figuring out everything as they go. One aspect that dynamic typed languages forces into us (at least it does to me), is to learn the data structure and relationships more thoroughly.
- destriaero 3y ago
  That's great unless you are working with a codebase that spans decades and tens of millions of lines of code. At that point if for every assignment you are tracing through your data types manually - you are out of a job. Also, if I am using an API another team is providing - I don't want to have to go and trace through their code.
  - Aeolos 3y ago
    And that's assuming you even have access to said source code. In many cases, you just receive a semi-documented JSON object and a prayer. Anecdotal story: We recently went through an effort to introduce strict-type checking for our typescript backend. As part of that effort, we introduced concrete types for every API accessible across a service boundary, which caught 6 mismatches between the documentation and the implementation (e.g. return Promise<bool> vs Promise<Instance>) and several hundred issues with missing null or type checks that would result in an "InternalServerError" instead of a meaningful error message. We started rolling the strict version out this week, and we can already see a meaningful improvement in the sentry logs.