4 ms·

> "That's just like, your opinion, man." So sick of opinion in this industry. We should not accept such lazy arguments anymore. Oh, wow, given this unnecessari

by luord 6y ago

> "That's just like, your opinion, man." So sick of opinion in this industry. We should not accept such lazy arguments anymore. 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.

honkycat 6y ago
> 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. 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?
- luord 6y ago
  My previous comment was merely an attempt to mention how participating in this flamewar leads nowhere. I'm certainly not about to get into it by discussing details of the good and the bad and even the necessity of compile time checks of whether a string is a url. Hundreds of books have been written on the matter, and the results are still inconclusive. > 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? Yes and yes, you happen to share their opinion. Now, should we pretend that appeals to authority turn an opinion into fact now? If so, to whose authority should we appeal? Theirs? The different google engineers who work in more dynamic languages? Hell, designers of dynamic languages who have worked at Google? The people who designed and work in LISP or any of its derivates? Whose authority weighs more? Or maybe we should acknowledge that appeals to authority hold no real decisive value in deciding something like this, and instead contribute to studies trying to gauge how effective different type systems actually are. Except that even those turn into flamewars: https://www.hillelwayne.com/post/this-is-how-science-happens/ https://www.hillelwayne.com/post/this-is-how-science-happens...
michaelmrose 6y ago
What do you think about this study that compared task completion in java and groovy from which I will paste the conclusion. > 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_empirical_study_of_the_influence_of_static_type_systems_on_the_usability_of_undocumented_software 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?
- luord 6y ago
  Yup, that conclusion, specially number one, is pretty much a formal detailing of what I tried to say in my previous comment: Results inconclusive, depends on the task, etc. And, of course there are exceptions in both directions for all of findings 2, 3 and 4; and those exceptions would also contribute to 1. It's for findings like those that I wish people stopped treating type systems like religions. And paradigms, for that matter.

by luord 6y ago

honkycat 6y ago

> 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. 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?

luord 6y ago
My previous comment was merely an attempt to mention how participating in this flamewar leads nowhere. I'm certainly not about to get into it by discussing details of the good and the bad and even the necessity of compile time checks of whether a string is a url. Hundreds of books have been written on the matter, and the results are still inconclusive. > 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? Yes and yes, you happen to share their opinion. Now, should we pretend that appeals to authority turn an opinion into fact now? If so, to whose authority should we appeal? Theirs? The different google engineers who work in more dynamic languages? Hell, designers of dynamic languages who have worked at Google? The people who designed and work in LISP or any of its derivates? Whose authority weighs more? Or maybe we should acknowledge that appeals to authority hold no real decisive value in deciding something like this, and instead contribute to studies trying to gauge how effective different type systems actually are. Except that even those turn into flamewars: https://www.hillelwayne.com/post/this-is-how-science-happens/ https://www.hillelwayne.com/post/this-is-how-science-happens...

michaelmrose 6y ago

What do you think about this study that compared task completion in java and groovy from which I will paste the conclusion. > 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_empirical_study_of_the_influence_of_static_type_systems_on_the_usability_of_undocumented_software 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?

luord 6y ago
Yup, that conclusion, specially number one, is pretty much a formal detailing of what I tried to say in my previous comment: Results inconclusive, depends on the task, etc. And, of course there are exceptions in both directions for all of findings 2, 3 and 4; and those exceptions would also contribute to 1. It's for findings like those that I wish people stopped treating type systems like religions. And paradigms, for that matter.