Deno will stop using TypeScript

Oh, wow, given this unnecessarily combative start, am I about to finally read conclusive proof that will stop that over sixty years old flamewar?

> I think we are seeing a people abandon loose typing because the industry has observed that loose typing is harmful to even small, a few thousand lines, projects.

People are not abandoning or adopting anything, both static and dynamic typing have existed for as long as computers have been a thing. Hell, LISP is older than pretty much every statically typed language still widely used, methinks.

> Static typing catches bugs. It makes your code easier to maintain. It makes your code safer to refactor. It checks your code to ensure correctness. It provides documentation about variables. It reduces the amount of code you have to read in order to understand a specific piece of code. These are empirically good things that you do not get in loosely typed languages.

Where's this empiric evidence of all these advantages you mention? I'm a bit shocked that I managed to miss it... And that so did half the industry. Such conclusive study would have ended that and the industry would have coalesced into this unquestionably superior type system you mention.

> An untyped value does not carry any information or explicit assertions about the variable. Take a URL for example: A "string" URL does not carry any information about weather or not the url string is a valid URL.

Can't do that with static languages either. Call it a type (or class), call it a parsing function, ultimately the result is the same. You need something to ensure that it is an url. Those exist in dynamically typed languages and are not obviated in static ones.

> Types dramatically reduce the amount of code you have to read in order to understand a given piece of your application.

Conversely, types substantially increase the amount of overall code one has to write.

These has never been a matter of opinions. The flamewar still rages after decades because what's the factually best type system hasn't been found. Hell, we might be likely closer to prove that that question has no answer.

In short, ultimately everything you said was just, like, your opinion, man.

In a loosely typed language you cannot have compiler-level enforcement that a variable has been produced by a factory function that ensures that the passed in variable has been parsed and determined valid.

Additionally in a loosely typed language you do not even get the OPTION of labeling a value as "validated/unvalidated", you only have one option: Pass a string, and expect the new developer to read upstream code to understand where the variable came from.

> In short, ultimately everything you said was just, like, your opinion, man.

Is it my opinion though? Or did I pull it straight out of Building Secure and Reliably Systems, a book written by Google engineers to express industry best practice for developing software at a scale?

> Conclusion This paper described an experiment comparing static and dy- namic type systems for programming tasks in an undocu- mented API. We gave 27 subjects five programming tasks and found that the type systems had a significant impact on the development time: for three of five tasks me measured a positive impact of the static type system, for two tasks we measured a positive impact of the dynamic type system. Based on the previous discussion, our overall conclusions for the use of static/dynamic type systems in undocumented APIs are the following: 1. There is no simple answer to the static vs. dynamic typing question: The question of whether or not static types are helpful for developers cannot be generally an- swered without taking the programming tasks into ac- count. In fact, this is completely consistent with the results of previous experiments, such as Prechelt and Tichy’s [22], or our own experiments[10, 28]. 2. The type system has an influence on the development time: The choice of the static or dynamic type system had an influence on the development time for all program- ming tasks in the experiment. Again, this is consistent with previous experiments (such as [11, 22, 28]). 3. Dynamic type systems potentially reduce develop- ment times for easier tasks: Although we are currently not aware of how to determine exactly what “easy” and “hard” means, it seems that if a dynamic type systems has a positive impact, it is for easier tasks (which is consistent with the experiments described in [10, 28]). Although there was one counter example in the experi- ment (task 1), we think that the result for this task is a consequence of the chosen subjects’ low familiarity with the dynamic language, Groovy (despite the presence of a warmup task). 4. Static type systems reduce development times if (a) the type annotations explicitely document design de- cisions, or (b) the number of classes to identify in the programming tasks is relatively high.

https://www.researchgate.net/publication/262317340_An_empiri...

Given the challenges to getting a good result identified in the study how do you think it could have been done better today?