> Adding static typing to a dynamic language mostly gives you the disadvantages of both, without a lot of benefits.
Can you elaborate? I don't share this experience, and I'm interested in bringing static typing to a language without static typing, so I'd like to understand. In new Python and JavaScript codebases, optional typing has had clear benefits for refactoring and correctness and low costs for me. Legacy codebases can be different.
I don't have a great code example at hand unfortunately, but I found that people often tend to write more "nominally" typed code (expecting explicitly named classes) rather than taking advantage of duck typing (interfaces, structural types), meaning the code becomes more rigid, harder to change and more time wasted on resolving all the type checks, even if the code otherwise is perfectly reasonable and free of bugs.
In other words, I found that the resulting code often looked more like Java but with weaker guarantees about types and much worse performance.
Part of it is because Ruby imo, have a very nice syntax. With type annotation, it's becoming "ugly", a lot more verbose. It's no longer English-like. I do agree type have some advantages, but we need to get the DX right.
I've been using Ruby for more than 10 years now, and I only started using LSP recently. To me it's a nice addition but I can live without it. Type is just one of the tools, not the only one imo. Not trying to sound negative but type is becoming more like a hammer analogy nowadays.
And it's not limited to Ruby. Javascript, Python, all similar languages. Not everyone is a fan of type. We won't reach consensus imo and that's ok.
> With type annotation, it's becoming "ugly", a lot more verbose. It's no longer English-like.
In our codebase that uses Sorbet I find this is really only true at function boundaries. Within a function it is pretty rare that anything needs to be spelled out with inline annotations to satisfy the compiler.
This is my biggest irk about Sorbet: because its signatures are wordy and because it can't infer the generic type of a private method, it slightly pushes you towards NOT extracting helper methods if they are going to be 2-5 lines. With Sorbet annotation, it'd easily become 10 lines. So it pushes towards bigger methods, and those are not always readable.
If only private methods would be allowed not having typing at all (with a promise of not being used in subclasses, for example), and Sorbet would be used mostly on the public surface of classes, it'd be much more tolerable for me.
Can you elaborate? I don't share this experience, and I'm interested in bringing static typing to a language without static typing, so I'd like to understand. In new Python and JavaScript codebases, optional typing has had clear benefits for refactoring and correctness and low costs for me. Legacy codebases can be different.