5 ms·

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 lang

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>?
      - zimpenfish 6y ago
        Can't speak for NAP but Photobox was extremely strong on unit + integration testing. IIRC, a full ground-up test suite run took a few hours because it started from a bare box, installed + tested Perl + every needed module, span up a blank database, then did the unit tests, then ran a full integration test suite against that server. That was only done for a release; for general commits, it was ok to run a subset of tests to show things worked / still worked.
archarios 6y ago
Just write tests and suddenly refactoring is possible without static typing. Those tests will also cover type checking concerns implicitly.
- jdm2212 6y ago
  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.
  - archarios 6y ago
    Why couldn't you just search for where that enum is referenced and add the cases?
    - jdm2212 6y ago
      You have to know when semantically it's an instance of the enum, and when it's just a string literal (e.g. in JavaScript, where enums are just a pre-defined set of allowed strings). Also, you might assign to it in one place, and then use the resulting variable in many other places farther down the call chain. Now you have to find all those usages. Static typing makes both of those trivial if your language (or linter) has enum-exhaustiveness checks for switch statements.
    - hnick 6y ago
      You can't always find everything with a search in a dynamic language. Some things are resolved at runtime. In our Perl code base, finding function calls is difficult for this reason (you can eval a string name to get a module or function and call it, based on a configuration setting in a file).
- wtetzner 6y ago
  Tests can't replace types, just like types can't replace tests. You need both. Types can't check the correctness of everything, but they do prove that certain classes of errors don't exist in your program. Tests, on the other hand, can test for many more types of bugs, but they can only look for errors, they can't prove correctness (except in very small, closed environments where you can literally test every possible combination of inputs and outputs).

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>?
    - zimpenfish 6y ago
      Can't speak for NAP but Photobox was extremely strong on unit + integration testing. IIRC, a full ground-up test suite run took a few hours because it started from a bare box, installed + tested Perl + every needed module, span up a blank database, then did the unit tests, then ran a full integration test suite against that server. That was only done for a release; for general commits, it was ok to run a subset of tests to show things worked / still worked.

archarios 6y ago

Just write tests and suddenly refactoring is possible without static typing. Those tests will also cover type checking concerns implicitly.

jdm2212 6y ago
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.
- archarios 6y ago
  Why couldn't you just search for where that enum is referenced and add the cases?
  - jdm2212 6y ago
    You have to know when semantically it's an instance of the enum, and when it's just a string literal (e.g. in JavaScript, where enums are just a pre-defined set of allowed strings). Also, you might assign to it in one place, and then use the resulting variable in many other places farther down the call chain. Now you have to find all those usages. Static typing makes both of those trivial if your language (or linter) has enum-exhaustiveness checks for switch statements.
  - hnick 6y ago
    You can't always find everything with a search in a dynamic language. Some things are resolved at runtime. In our Perl code base, finding function calls is difficult for this reason (you can eval a string name to get a module or function and call it, based on a configuration setting in a file).
wtetzner 6y ago
Tests can't replace types, just like types can't replace tests. You need both. Types can't check the correctness of everything, but they do prove that certain classes of errors don't exist in your program. Tests, on the other hand, can test for many more types of bugs, but they can only look for errors, they can't prove correctness (except in very small, closed environments where you can literally test every possible combination of inputs and outputs).