151–160 of 243 posts
Earlier quoted context omitted.
Just write tests and suddenly refactoring is possible without static typing. Those tests will also cover type checking concerns implicitly.
If you add a new value to an enum, or a new argument to a method, you have to know all the places where you do switches on the enum or call the method, which is hard to do without static types.
Earlier quoted context omitted.
People who like static typing seem to really like static typing. I'm honestly not convinced it helps that much. And it seems to cost a lot to me. I like database and API schemas though. And I like clojure.spec and function preconditions a lot.
I hated statix typing until I used Rust. Rust has Sum types (super powered enums), which provide what I was missing from dynamically typed langauges in languages like Java, C#, etc: namely the ability to have an "or" type (e.g. this is an integer or a string, and I want to be able to branch on that at runtime). That, plus type inference makes the static typing pretty painless.
These data types are much more powerful than the fancy arrays that wowed me back in the day :)
Earlier quoted context omitted.
It helps a lot with refactoring and many other things even early in the project. For example I‘m using TypeScript with a GraphQL code generator. Now let‘s assume I add a new value to a GraphQL enum. I run codegen, then fix everything until the compiler is happy. Afterwards, all places where this enum was ever touched will take it into account correctly, including mappings, translations, all switch statements, conditi…
You could do the same process if you used dynamic typing and good test coverage. Just make your change and keep fixing tests until everything is green.
I wish it would be possible to have better studies for that. I believe that static typing has huge benefits as software scales. I also believe that the type system of TypeScript is actually stronger in practice than the Java or C# one (despite theoretical weaknesses). It has the right tradeoffs (e.g. structural equivalence, being able to type strings, being able to check that all cases are handled, etc.) It would be…
People who like static typing seem to really like static typing. I'm honestly not convinced it helps that much. And it seems to cost a lot to me. I like database and API schemas though. And I like clojure.spec and function preconditions a lot.
There's also the case that I find the type systems of Rust, Elm, etc to be much more helpful than the type systems of C++ or Sorbet (type system for Ruby).
I think the best takeaway from this is that the software industry makes lots of claims about development processes, but so little actual research is done in trying to validate those processes. It's all mostly based on opinion.
The value of new methodologies, languages, and techniques is partly that the enthusiastic proponents of them are given a chance to prove out that there is value, and so become motivated to go the extra distance to achieve the project specific outcome.
This value is destroyed if people are forced to use the technique, instead of championing its introduction. So measurement is made even harder!
Earlier quoted context omitted.
It doesn’t account for the communication value of static types. Personally, I consider static types primarily a communication tool, so IMO the review’s interesting but not very useful per se . Also the main point of it seems to be “research on this topic is mostly bad, so far, so who the hell knows what’s true”. It could be that the research has sucked, not that there’s little discernible difference between the two o…
It seems to me that tests are equally good as a communication tool.
They serve very different purposes and generally are not first and foremost good communication tools the way static types are, for a bunch of reasons. That doesn’t mean tests aren’t very useful and welcome things to have, however.
Earlier quoted context omitted.
It doesn’t account for the communication value of static types. Personally, I consider static types primarily a communication tool, so IMO the review’s interesting but not very useful per se . Also the main point of it seems to be “research on this topic is mostly bad, so far, so who the hell knows what’s true”. It could be that the research has sucked, not that there’s little discernible difference between the two o…
It seems to me that tests are equally good as a communication tool.
Earlier quoted context omitted.
I think it gives people a sense of satisfaction in modeling real world in the relations between classes. The assertion seems to be that if to solve a problem it has to be correctly modelled into the type system of the language. Once the modelling is done correctly solution will arise by itself. On the other end people who prefer weakly typed languages see problems as primarily that of data transformation. For example…
Please don't use weak/strong to denote type systems. Those terms are highly subjective and even non-technical people would quickly form an opinion about which is better. (Strong is good, weak is bad.) Static/dynamic is more accurate and less opinionated terminology.
I wish it would be possible to have better studies for that. I believe that static typing has huge benefits as software scales. I also believe that the type system of TypeScript is actually stronger in practice than the Java or C# one (despite theoretical weaknesses). It has the right tradeoffs (e.g. structural equivalence, being able to type strings, being able to check that all cases are handled, etc.) It would be…
Earlier quoted context omitted.
If you add a new value to an enum, or a new argument to a method, you have to know all the places where you do switches on the enum or call the method, which is hard to do without static types.
Why couldn't you just search for where that enum is referenced and add the cases?
Static typing makes both of those trivial if your language (or linter) has enum-exhaustiveness checks for switch statements.