12 ms·

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 sys

by quonn 6y ago

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 nice to have proper studies, but it‘s difficult to control the other variables ...

whatl3y 6y ago
I've recently learned and ported a few projects from Javascript to TypeScript and I'll vouch that, so far, it is much better and easier to reason about my code and what it's doing. I also feel I need less test cases to adequately test my code. In saying that, I'm interested in if there is any accepted, peer reviewed literature with quantifiable data as to whether strongly typed languages are "better" (whatever the study might define as better such as being faster, more scalable, etc). From what I've heard and read, most of the better-ness that strong typing provides is related to people problems and being able to scale a team, not necessarily scaling a system or making the system better. When learning Go and TypeScript after primarily writing Ruby and Javascript, I'm convinced of the better-ness strong typing provides whether it's related to readability, better IDE intellisense, or speed (although Go for example is faster then Ruby and JS not just because it's strongly typed, but compiled), I'm just interested in if there's real data to support using them instead of anecdata.
- j_m_b 6y ago
  How much would you attribute that to the fact that you rewrote the code? I know my second pass is always better.
  - jdm2212 6y ago
    JS -> TS is usually just a matter of adding types, so I think by "ported" the previous commenter just meant adding types and tweaking as needed to make the type system happy.
- lioeters 6y ago
  Here's the closest thing I could find: The TypeScript Tax: A Cost vs. Benefit Analysis - https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b https://medium.com/javascript-scene/the-typescript-tax-132ff... The author leans against TypeScript, but does cite some relevant studies on the benefits. --- One of the cited articles: To Type or Not to Type: Quantifying Detectable Bugs in JavaScript - http://earlbarr.com/publications/typestudy.pdf http://earlbarr.com/publications/typestudy.pdf (PDF)
GlennS 6y ago
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.
- nafey 6y ago
  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 from HTML Form to Http Request to SQL Db to CSV File and so on. Both approaches are differentiated by the perspective on the problem.
  - quonn 6y ago
    But I rarely use classes in TypeScript. I do think of things as data transformations but the types certainly help a lot.
  - protonfish 6y ago
    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.
    - albntomat0 6y ago
      They are not the same, at least according to the definitions I'm familiar with. Static/dynamic is whether type checking is done at compile time or run type. Strong/weak is how flexible the language is with type conversion. Another explanation: https://en.hexlet.io/courses/intro_to_programming/lessons/types/theory_unit https://en.hexlet.io/courses/intro_to_programming/lessons/ty...
pixelrevision 6y ago
I think it’s the wrong metric to look at. Static typing still leaves plenty of room for bugs. The capability and discipline of the team would likely be more of a factor than the type system so the studies would be hard to get right. However I do think static typing provides an enormous benefit to picking up code that is 5 years old and written by someone else. The ability to see “this is a nonnullable int32 value type” greatly reduces the amount of paths you have to go down when you have to change something or understand what’s going wrong with it. Tradeoff is you end up with a lot more code to maintain...
- quonn 6y ago
  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, conditions, lists where some of the other values are mentioned and so on. This is something that‘s not possible in a dynamic language and it‘s not even possible in Java, really. I rely on this daily.
  - archarios 6y ago
    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.
    - wtetzner 6y ago
      But how could you have written tests against that new enum value if it didn't exist before? You would need to know in advance which places needed to be tested for it.
    - Ar-Curunir 6y ago
      Then you essentially are implementing a type checker in your tests, but worse
doctor_eval 6y ago
I much prefer static typing - but the metric used in the article is around bug reduction. Regardless of static (Go or Java), dynamic (JS), or a bit weird (plpgsql), I don’t generally get the type of a variable or object wrong - because when I’m using the object I necessarily must already have a mental map of what it represents. It’s pretty rare to try to call the “fill()” method on a “line” object, so to speak, because I know it’s a line when I access it. So I’d guess that the number of type related bugs in dynamic languages is just a little bit greater than in static languages, simply because it is harder to make that kind of mistake in a typed language. But as a category, they aren’t common mistakes in the first place. I can confidently say that I’m a bit of an expert at writing bugs :) and of all the kinds of bugs I write, type related bugs are probably no where near the top of the list. That’s not to say that static typing isn’t better - I definitely think it is. But I can also believe that it doesn’t necessarily reduce the bug count by a huge margin. (For whatever it’s worth I think the main benefits are documentation and refactoring...)
- the_af 6y ago
  On that note, I've heard many times dynamic typing advocates say (or write) "I've seldom wrote a bug that was a type error". But a lot of the time, their language is simply unable to encode certain properties as types, so by definition they don't think of some classes of bugs they do write as "type errors". Maybe in a statically typed languages they would have been type errors indeed! It's as if the tool you use sometimes reinforces your blind spots: "you don't know what you don't know". PS: anecdote is probably irrelevant, but I've written plenty of dumb type errors with Python. Things that would have been caught by a test or an external tool, sure, or the type checker of a statically typed language could have caught for me for free, leaving the more relevant logic tests to me. I tend to write type errors left and right. Maybe I'm simply not a good Python programmer, of course!
jdm2212 6y ago
The study IMHO is reality. Every large, actively maintained system I've ever heard of uses a strongly typed language, or was written in a dynamically typed language but has converted to a gradually typed language. You can't safely refactor without compile time type checking, and you can't maintain a non-trivial system over the long-term if you can't refactor it.
- zimpenfish 6y ago
  A contrary anecdata - I've worked at a bunch of places and know people who work at others that have large, actively maintained, decades-old systems using, e.g., Perl. The only one I know that was actively trying to migrate recently was looking at node instead.
  - jdm2212 6y ago
    If you're able to share, I'm curious what kinds of systems these are (and also, I guess, how development velocity compared to statically typed projects you've worked on).
    - zimpenfish 6y ago
      Net-A-Porter is probably the prima Perl in London at the minute and have been for decades - although I think they started migrating to Modern Perl with microservices in 2018ish. Photobox were still on a 10+ years old Perl system in 2018 when I left - development velocity there was only really hampered by an insane belief that rewriting into node.js microservices would solve every problem and the ORM + Object system being a ~10yr old handcrafted abomination from someone who had left 5+ years ago.
      - jdm2212 6y ago
        How do they do refactors and dependency upgrades safely? Just a really strong unit testing culture, specialized tooling or <something else>?
therufa 6y ago
In my personal opinion (based on personal observation) static typing helps to become more lazy and trusting since it enables features such as autocomplete, type hinting and so on where one basically gives away understanding of detail. Don't get me wrong! I love being lazy and trusting because it allows to leverage more code than I'd be able to produce on my own, but usually it's also the source of many of my own mistakes and failures. I strongly believe that I'm not the only one.
- the_af 6y ago
  This is a surprising argument to me. In my opinion, the opposite is true: thinking about types makes you understand your building blocks better, whereas the danger of dynamic typing is that you can go a long way being "lazy" and not understanding/caring about the types involved, "it just works". Sometimes this speed is welcome, but (in my opinion) you end up crashing and burning sooner or later...
- JAlexoid 6y ago
  And I feel that I'm wasting time on understanding the stuff that I need to pass and have to remember 100 times more things, than I need to. I want my code to be clear and with certain expectations fulfilled, rather than a mystery in front of me. I'm not there to learn what could be passed into my functions - I'm there to create functionality.
catdog 6y ago
> 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, especially after it outscales what one person is able to (fully) overview. Static types are something a program can reason about so it allows so much more productivity boosting tooling to be created. This also goes way beyond simply catching type errors at compile time vs. runtime (a downside which can largely be mitigated by test coverage). Just look what an IDE for e.g. Java can do simply in helping you navigating a big codebase. Then throw in refactoring which is in many cases can even be a completely automated operation and in much more cases is at least greatly assisted by the tools. Tools for dynamic languages can often at most guess, making good guesses is hard so in practice you get mostly stuff which is pretty limited in its usefulness.
archarios 6y ago
I've contributed to large codebases that have static typing (C++ and TypeScript) and dynamic typing (JavaScript) and I've come to the conclusion over the years that static typing isn't really worth it as long as you have the discipline to write tests for your code. The most basic unit tests cover type checking concerns. Refactoring might require a bit more search/replace but I don't see how that is a big deal. Tests make refactoring safer than with just types. Tests act as good documentation of how you expect your code to behave and what expected inputs/outputs there are. You just don't get autocomplete which is a pretty overrated feature imo.
wolfadex 6y ago
I'd love for the study to include various types of static types. Testing against only C#/Java style type systems seems fairly narrow compared to the various kinda of static type systems available.
root_axis 6y ago
I just can't imagine how strong types can be viewed as anything other than an immense benefit. Maybe on some personal projects or a throwaway prototype or simple scripts it might not be worth the effort, but if you're working on any kind of software that needs to be maintained over a period of years, having strong types is always better than not having them. Strong types encode extremely valuable information about the composition of application data structures, omitting them can save time up front, but it's just a form of technical debt that every engineer on the project will have to pay back when they're tasked with debugging data errors in code they didn't write. So many engineering-hours wasted by developers stepping through a debugger trying to figure out why some complex object is arbitrarily missing certain properties or why the same property is sometimes a string but other times its an object with its own potential superposition of states. It's a nightmare.

by quonn 6y ago

whatl3y 6y ago

I've recently learned and ported a few projects from Javascript to TypeScript and I'll vouch that, so far, it is much better and easier to reason about my code and what it's doing. I also feel I need less test cases to adequately test my code. In saying that, I'm interested in if there is any accepted, peer reviewed literature with quantifiable data as to whether strongly typed languages are "better" (whatever the study might define as better such as being faster, more scalable, etc). From what I've heard and read, most of the better-ness that strong typing provides is related to people problems and being able to scale a team, not necessarily scaling a system or making the system better. When learning Go and TypeScript after primarily writing Ruby and Javascript, I'm convinced of the better-ness strong typing provides whether it's related to readability, better IDE intellisense, or speed (although Go for example is faster then Ruby and JS not just because it's strongly typed, but compiled), I'm just interested in if there's real data to support using them instead of anecdata.

j_m_b 6y ago
How much would you attribute that to the fact that you rewrote the code? I know my second pass is always better.
- jdm2212 6y ago
  JS -> TS is usually just a matter of adding types, so I think by "ported" the previous commenter just meant adding types and tweaking as needed to make the type system happy.
lioeters 6y ago
Here's the closest thing I could find: The TypeScript Tax: A Cost vs. Benefit Analysis - https://medium.com/javascript-scene/the-typescript-tax-132ff4cb175b https://medium.com/javascript-scene/the-typescript-tax-132ff... The author leans against TypeScript, but does cite some relevant studies on the benefits. --- One of the cited articles: To Type or Not to Type: Quantifying Detectable Bugs in JavaScript - http://earlbarr.com/publications/typestudy.pdf http://earlbarr.com/publications/typestudy.pdf (PDF)

GlennS 6y ago

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.

nafey 6y ago
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 from HTML Form to Http Request to SQL Db to CSV File and so on. Both approaches are differentiated by the perspective on the problem.
- quonn 6y ago
  But I rarely use classes in TypeScript. I do think of things as data transformations but the types certainly help a lot.
- protonfish 6y ago
  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.
  - albntomat0 6y ago
    They are not the same, at least according to the definitions I'm familiar with. Static/dynamic is whether type checking is done at compile time or run type. Strong/weak is how flexible the language is with type conversion. Another explanation: https://en.hexlet.io/courses/intro_to_programming/lessons/types/theory_unit https://en.hexlet.io/courses/intro_to_programming/lessons/ty...

pixelrevision 6y ago

I think it’s the wrong metric to look at. Static typing still leaves plenty of room for bugs. The capability and discipline of the team would likely be more of a factor than the type system so the studies would be hard to get right. However I do think static typing provides an enormous benefit to picking up code that is 5 years old and written by someone else. The ability to see “this is a nonnullable int32 value type” greatly reduces the amount of paths you have to go down when you have to change something or understand what’s going wrong with it. Tradeoff is you end up with a lot more code to maintain...

quonn 6y ago
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, conditions, lists where some of the other values are mentioned and so on. This is something that‘s not possible in a dynamic language and it‘s not even possible in Java, really. I rely on this daily.
- archarios 6y ago
  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.
  - wtetzner 6y ago
    But how could you have written tests against that new enum value if it didn't exist before? You would need to know in advance which places needed to be tested for it.
  - Ar-Curunir 6y ago
    Then you essentially are implementing a type checker in your tests, but worse

doctor_eval 6y ago

I much prefer static typing - but the metric used in the article is around bug reduction. Regardless of static (Go or Java), dynamic (JS), or a bit weird (plpgsql), I don’t generally get the type of a variable or object wrong - because when I’m using the object I necessarily must already have a mental map of what it represents. It’s pretty rare to try to call the “fill()” method on a “line” object, so to speak, because I know it’s a line when I access it. So I’d guess that the number of type related bugs in dynamic languages is just a little bit greater than in static languages, simply because it is harder to make that kind of mistake in a typed language. But as a category, they aren’t common mistakes in the first place. I can confidently say that I’m a bit of an expert at writing bugs :) and of all the kinds of bugs I write, type related bugs are probably no where near the top of the list. That’s not to say that static typing isn’t better - I definitely think it is. But I can also believe that it doesn’t necessarily reduce the bug count by a huge margin. (For whatever it’s worth I think the main benefits are documentation and refactoring...)

the_af 6y ago
On that note, I've heard many times dynamic typing advocates say (or write) "I've seldom wrote a bug that was a type error". But a lot of the time, their language is simply unable to encode certain properties as types, so by definition they don't think of some classes of bugs they do write as "type errors". Maybe in a statically typed languages they would have been type errors indeed! It's as if the tool you use sometimes reinforces your blind spots: "you don't know what you don't know". PS: anecdote is probably irrelevant, but I've written plenty of dumb type errors with Python. Things that would have been caught by a test or an external tool, sure, or the type checker of a statically typed language could have caught for me for free, leaving the more relevant logic tests to me. I tend to write type errors left and right. Maybe I'm simply not a good Python programmer, of course!

jdm2212 6y ago

The study IMHO is reality. Every large, actively maintained system I've ever heard of uses a strongly typed language, or was written in a dynamically typed language but has converted to a gradually typed language. You can't safely refactor without compile time type checking, and you can't maintain a non-trivial system over the long-term if you can't refactor it.

zimpenfish 6y ago
A contrary anecdata - I've worked at a bunch of places and know people who work at others that have large, actively maintained, decades-old systems using, e.g., Perl. The only one I know that was actively trying to migrate recently was looking at node instead.
- jdm2212 6y ago
  If you're able to share, I'm curious what kinds of systems these are (and also, I guess, how development velocity compared to statically typed projects you've worked on).
  - zimpenfish 6y ago
    Net-A-Porter is probably the prima Perl in London at the minute and have been for decades - although I think they started migrating to Modern Perl with microservices in 2018ish. Photobox were still on a 10+ years old Perl system in 2018 when I left - development velocity there was only really hampered by an insane belief that rewriting into node.js microservices would solve every problem and the ORM + Object system being a ~10yr old handcrafted abomination from someone who had left 5+ years ago.
    - jdm2212 6y ago
      How do they do refactors and dependency upgrades safely? Just a really strong unit testing culture, specialized tooling or <something else>?

therufa 6y ago

In my personal opinion (based on personal observation) static typing helps to become more lazy and trusting since it enables features such as autocomplete, type hinting and so on where one basically gives away understanding of detail. Don't get me wrong! I love being lazy and trusting because it allows to leverage more code than I'd be able to produce on my own, but usually it's also the source of many of my own mistakes and failures. I strongly believe that I'm not the only one.

the_af 6y ago
This is a surprising argument to me. In my opinion, the opposite is true: thinking about types makes you understand your building blocks better, whereas the danger of dynamic typing is that you can go a long way being "lazy" and not understanding/caring about the types involved, "it just works". Sometimes this speed is welcome, but (in my opinion) you end up crashing and burning sooner or later...
JAlexoid 6y ago
And I feel that I'm wasting time on understanding the stuff that I need to pass and have to remember 100 times more things, than I need to. I want my code to be clear and with certain expectations fulfilled, rather than a mystery in front of me. I'm not there to learn what could be passed into my functions - I'm there to create functionality.

catdog 6y ago

> 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, especially after it outscales what one person is able to (fully) overview. Static types are something a program can reason about so it allows so much more productivity boosting tooling to be created. This also goes way beyond simply catching type errors at compile time vs. runtime (a downside which can largely be mitigated by test coverage). Just look what an IDE for e.g. Java can do simply in helping you navigating a big codebase. Then throw in refactoring which is in many cases can even be a completely automated operation and in much more cases is at least greatly assisted by the tools. Tools for dynamic languages can often at most guess, making good guesses is hard so in practice you get mostly stuff which is pretty limited in its usefulness.

archarios 6y ago

I've contributed to large codebases that have static typing (C++ and TypeScript) and dynamic typing (JavaScript) and I've come to the conclusion over the years that static typing isn't really worth it as long as you have the discipline to write tests for your code. The most basic unit tests cover type checking concerns. Refactoring might require a bit more search/replace but I don't see how that is a big deal. Tests make refactoring safer than with just types. Tests act as good documentation of how you expect your code to behave and what expected inputs/outputs there are. You just don't get autocomplete which is a pretty overrated feature imo.

wolfadex 6y ago

I'd love for the study to include various types of static types. Testing against only C#/Java style type systems seems fairly narrow compared to the various kinda of static type systems available.

root_axis 6y ago

I just can't imagine how strong types can be viewed as anything other than an immense benefit. Maybe on some personal projects or a throwaway prototype or simple scripts it might not be worth the effort, but if you're working on any kind of software that needs to be maintained over a period of years, having strong types is always better than not having them. Strong types encode extremely valuable information about the composition of application data structures, omitting them can save time up front, but it's just a form of technical debt that every engineer on the project will have to pay back when they're tasked with debugging data errors in code they didn't write. So many engineering-hours wasted by developers stepping through a debugger trying to figure out why some complex object is arbitrarily missing certain properties or why the same property is sometimes a string but other times its an object with its own potential superposition of states. It's a nightmare.